On Wed, May 13, 2015 at 03:36:10PM +0100, Mark Brown wrote: > 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. It seems we've had this discussion at lot lately ;) That indeed might be problematic.... > > > > 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. Well, if it's not connected to the bus, it probably won't be connected to the chip select either, will it? > > > 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. The point is that if we don't have anything declared in the DT, we won't even have a device. So we can't really expect that the device will not be bound to a driver, because it won't even be there in the first place. > > > 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. No, of course. Remember that this code was written before the overlays were posted. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
