From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933375AbcE3Puc (ORCPT ); Mon, 30 May 2016 11:50:32 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:55112 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932192AbcE3Pub (ORCPT ); Mon, 30 May 2016 11:50:31 -0400 Date: Mon, 30 May 2016 16:50:16 +0100 From: Mark Brown To: Michal Suchanek Cc: Geert Uytterhoeven , linux-sunxi , Maxime Ripard , Chen-Yu Tsai , linux-spi , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Message-ID: <20160530155016.GO29837@sirena.org.uk> References: <20160530112610.GJ29837@sirena.org.uk> <20160530150343.GL29837@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f9b3biUB1f7FHqGn" Content-Disposition: inline In-Reply-To: X-Cookie: Happy feast of the pig! User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 5/5] RFC spi: sun4i: add DMA support X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --f9b3biUB1f7FHqGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote: > On 30 May 2016 at 17:03, Mark Brown wrote: > > I really don't think it's worth caring too much about cases where the > > DMA driver hasn't been compiled in, it's not like SPI is the only thing > It's what the driver did to start with and it was requested to fall > back to non-DMA in the case DMA is not available. Why? I really can't see any sensible use case for this that doesn't have a better solution available. > It's possible to add a parameter like require_dma which could be used > to load the driver without dma if unset. If it was set by default then > driver ordering is not important so long as dma driver is loaded > eventually. Also an informative print that such parameter exists when > probing the driver is deferred would be helpful. It would probably > create quite a bit of log spam, however. The driver can be deferred > several times during boot. That seems fairly hacky, if we were going to do anything like that it should be the other way around so that we default to trying to use resources and even then it seems like something that should be handled at a framework level rather than having random options in individual drivers to ignore things. Having things behave inconsistently between different drivers is going to lead to a worse user experience and if this is a good idea for one driver it seems like it'd be a good idea for all of them. But really=20 --f9b3biUB1f7FHqGn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXTGE2AAoJECTWi3JdVIfQcb8H/RSeTMo6esURmCkUthwWYliR btHAMmzBnWhO2XvZ07kSQTGE8torrvMt7scQEpsEaMQDQdA/6e5pMrYe2wvcBo5B sRSnyStQic8mhszGkyaL5GRMfrMtUka30akbNrpxPYaAkDkOlZAHt4NyOga8e4sP t7guG5eG8Tb4Ynje1OgoAtP1UslRxR0D1yz4cuR3zwevWLOqyAKjGu6PhdGThAZ3 vMmqe750E/+7TCngPlzQg4zS7cLSTqxS8AbTx2vNmAo+hkf72Bkb/rIQiLNJYBP2 U7gpOOFOCkYcjznfqpNPy1DpU+UPSY8I0oJU1kdiA+csBPwX+UckGlD1bCSW2jE= =6A8K -----END PGP SIGNATURE----- --f9b3biUB1f7FHqGn--