Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752701AbbD0P1a (ORCPT ); Mon, 27 Apr 2015 11:27:30 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:39673 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751086AbbD0P12 (ORCPT ); Mon, 27 Apr 2015 11:27:28 -0400 Date: Mon, 27 Apr 2015 16:27:05 +0100 From: Mark Brown To: Martin Sperl Cc: Hans de Goede , Michal Suchanek , Maxime Ripard , linux-sunxi , Jonathan Corbet , linux-spi , linux-doc , Linux Kernel Mailing List Message-ID: <20150427152705.GU22845@sirena.org.uk> References: <20150426110144.GK22845@sirena.org.uk> <553CCABA.3090504@redhat.com> <12F80B18-7418-430E-94F7-5A20C133BA9A@martin.sperl.org> <20150426125113.GF5627@lukather> <20150427093618.GL22845@sirena.org.uk> <553E099C.4070208@redhat.com> <20150427112539.GR22845@sirena.org.uk> <553E4447.6080202@martin.sperl.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4N6yfb5C0fB00J+0" Content-Disposition: inline In-Reply-To: <553E4447.6080202@martin.sperl.org> X-Cookie: Your present plans will be successful. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example. 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 Content-Length: 3887 Lines: 89 --4N6yfb5C0fB00J+0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 27, 2015 at 04:14:31PM +0200, Martin Sperl wrote: > On 2015-04-27 13:25, Mark Brown wrote: > >I don't think you've fully considered your use case here. As I said in > >my reply to your earlier e-mail I think what you're looking for here is > >something like better UI around overlays. Registering a SPI bus without > >knowing what's connected to it doesn't allow generic maker style usage > >of the board, it's just as likely to hinder a user as help them. For > So you see that spi is disabled by default - the pins are > free to use for anything. > The firmware then integrates the overrrides into the device-tree > before loading the kernel. > So to enable spi in general you add the following to /boot/config.txt: > dtparam=spi=on > That gives you spi plus two "generic" spidev devices. OK, so that is just a default overlay which is abusing the fact that we will bind to spidev without a DT compatible and when the binding is undocumented (which also applies to other devices and buses sadly). Unfortunately nobody ever mentioned this upstream and the feedback upstream that listing spidev in a DT is a bad idea has been ignored. The whole reason we're doing this in the first place is that we got sick of telling people that using spidev in DTs like this was a bad idea. > If you want to include a mcp2515 you add also the following: > dtoverlay=mcp2515-can0-overlay > and that loads also the overlay for the mcp2515 can module. And this is just a user specified overlay which is completely fine already. > So coming from this perspective I believe that there is some > concern in the raspberry pi community, because the description > they provide is now specific to the HW and their intent and so > the loud "croaking" of spidev will irritate people even when > they have done everything the best they can. It does sound like the people maintianing the u-boot fork for the Pi need to talk to both u-boot upstream (nothing here is specific to the Pi that I can see) and the kernel community a bit more. I'd be a bit worried that they may be relying on other things that just happen to work without being intentional (and are therefore more vulnerable to issues) and it's a bit depressing to see things like this stuck in a fork where only a limited community can make use of them. > The only thing that could possibly be better would be that > the user would define the "real" name of the device in the > device tree and spidev would bind to it if there is no driver > available (but that would require this "fallback" binding by > spidev in case of no driver). Yes, that is exactly the solution I'd suggest - change the UI to provide a DT compatible to be used for the new device. That would also have the benefit of meaning that users who have connected some device that does have a driver that works with a simple binding wouldn't need to write an overlay which seems like it should be useful. --4N6yfb5C0fB00J+0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVPlVFAAoJECTWi3JdVIfQOaEH/2YyEyD3rQKI8CsKdEoxt7T7 YwA9/PT4G9FDPujpp9uAQwrayV3rJm+tIgXl6ykYw0rHQo1DZApXuXPyDn0zw/OS 5jSQ7pW+AQpmXfKj/nC+k6XwDFU6S5N3kRpuRziHb9s2TxKVHZu/cQwzsyeTcISE 13nvEBp/c44F/9MnxQisZh9uYlI7ZyzQyiaTVIUwxnz3Y5NjPZ9s9af5ZPmAISER JXNvtQmCiHaOMCLxlBDNl65LR6QnQMHRwwRerdt0dVFSjKxlXywbtHqNDyyNw5Hu DnrHCFczkeHF//QaD4gsM0p8zAA2E56WRbcmropUkqFKoUohPa6YD5puFi3MaFs= =M3im -----END PGP SIGNATURE----- --4N6yfb5C0fB00J+0-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/