On Wed, Apr 30, 2014 at 06:18:11PM -0700, Mark Brown wrote: > On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote: > > On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote: > > > > Why can we not handle this by using sysfs to bind spidev to the > > > device? > > > I just tried it, and apparently, you can't really use this, since spi > > devices are created from the device tree (or ACPI) whenever the master > > registers. > > Can you be more specific as to what the issue is here? If we actually > have a specific kernel driver for a device I would strongly expect that > we would want to use it and not spidev, if we don't have one I don't see > the issue. > > > It doesn't really work either for a device that would be bound to a > > driver, that you unbind, and then try to bind to spidev instead. It > > looks like the device is released whenever you unbind it, so you can't > > really use it afterwards. > > I guess this is the issue... what exactly is the use case here? I > would only expect spidev to be used if there is no in kernel driver for > a device. The issue and use case is this: we don't have an upstreamable way to use spidev. You suggested a while back to add the compatibles of devices we would want to drive with spidev in the spidev compatible list. It's fine for devices where we should have a driver, but don't, or devices that will never ever be handled by the kernel. But it actually doesn't work in a case where you can't really predict what is on the other side of the bus. Either because, on the board you're using the pins are exposed and it's pretty much up to the user to know what to put on it. That could be handled by DT overlays though. What never works is where the device on the other side is so generic that you really can't tell what it does. Think of a microcontroller that would behave as a SPI slave. It's behaviour and what it does is pretty much dependant of what we flashed on it, and suddenly the compatible string is not the proper reprensentation anymore. i2c-dev works great in these cases, because you always have access to all the bus, and all the devices, except if the device is already used by someone. The patch I suggested is an attempt to mimic this. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
