Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934387AbbEMOgZ (ORCPT ); Wed, 13 May 2015 10:36:25 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:37576 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933665AbbEMOgX (ORCPT ); Wed, 13 May 2015 10:36:23 -0400 Date: Wed, 13 May 2015 15:36:10 +0100 From: Mark Brown To: Maxime Ripard Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Hans de Goede , linux-spi@vger.kernel.org, Martin Sperl , Michal Suchanek Message-ID: <20150513143610.GT2761@sirena.org.uk> References: <1431462804-30467-1-git-send-email-maxime.ripard@free-electrons.com> <20150513112604.GI3066@sirena.org.uk> <20150513125102.GA2628@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IQvoI1rdlCKiYEYW" Content-Disposition: inline In-Reply-To: <20150513125102.GA2628@lukather> X-Cookie: 13. ... r-q1 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: [PATCH] spi: Force the registration of the spidev devices 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: 3324 Lines: 80 --IQvoI1rdlCKiYEYW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote: > I'd say we're also ok because if we delegate the device driving logic > to userspace, we should expect it to know what it does to first drive > the device properly, but also to open the right device for this. > What's the worst that could happen in such a case? The data are output > without any chipselect line being driven by the controller? Isn't that > supposed to be ignored by the devices? I'm more worried about the chip select line being connected to the "make the board catch fire" signal or whatever (more realistically causing us to drive against some other external component) if the extra chip selects weren't pinmuxed away. > > > This also adds an i2cdev-like feeling, where you get all the > > > spidev devices all the time, without any modification. > > I2C is a bit safer here since it's a shared bus so you can't do > > anything to devices not connected to the bus by mistake. > I'm not sure to understand what you mean here. How is SPI different > from that aspect? Chip select signals. > > This still leaves us in the situation where if we do know the device > > that is connected we have to explicitly bind it in spidev which is > > apparently unreasonably difficult for people. > You can still do that, but the point is that you don't have to. Right, but that's not what I'd expect to happen (and seems to make it easier for people to not list things in the DT at all which doesn't seem great). If we're going to make it available by default I'd expect to be able to use a userspace driver with anything that doesn't have a driver bound rather than with devices that explicitly don't have any identification. > > I'm also concerned about the interactions with DT overlays here - > > what happens if a DT overlay or other dynamic hardware instantiation > > comes along later and does bind something to this chip select? It > > seems like we should be able to combine the two models, and the fact > > that we only create these devices with a Kconfig option is a bit of > > an interesting thing here. > I think the safe approach would be, just like I told in this thread, > to just check whether the modalias is spidev. If it is, destroy the > previous (spidev) device, create a new device as specified by the DT, > you're done. Sure, but I don't see code for that here. --IQvoI1rdlCKiYEYW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVU2FXAAoJECTWi3JdVIfQ3msH/j28nkDo0Hdiv2GqwXIJQl+u DVzir7diipbhKKL0f09NO5zg4be05OP4D/K37lh7x9OdiHqCEW8WZy6PM9ucPoGC 8BnJwjpS7NcS9khQ8U1lpXFeyD21YnnSpZ23IXcaQB20V3JX3X4bXqZ819xdvzUj BoEa6qgGj3OixQxN/upCeWTK0hvob2TBVdPIVEFeSKvFNrigegmO6P8wzHSBZGZA hQ/gLc59YhJww7uoHicuaHhdLZZ2C9nzPTxke3Du/yXq50rOMPAuxnrI+i5UgvCh e5RQx658aFKiLqfbI4Npwu1/9EKi8c8Vaxy7kb0rJx70q/3u5WnVtHeeH1U4T7o= =Lx1M -----END PGP SIGNATURE----- --IQvoI1rdlCKiYEYW-- -- 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/