On Sun, Apr 26, 2015 at 05:33:36PM +0200, Michal Suchanek wrote: > On 26 April 2015 at 16:33, Maxime Ripard > <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: > >> On 26 April 2015 at 14:51, Maxime Ripard > >> <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > >> > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > >> >> On 26 April 2015 at 13:56, Martin Sperl <kernel@xxxxxxxxxxxxxxxx> wrote: > >> >> > > >> >> >> On 26.04.2015, at 13:23, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >> >> >> I think there is actual a use for just binding spidev as spidev, > >> >> >> think e.g. the spi pins on the raspberry pi. > >> >> >> > >> >> >> How do you deal we suggest with such a situation ? > >> >> > > >> >> > I actually asked the same question a few days ago on the spi list > >> >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as “spidev”) > >> >> > and the summary was: > >> >> > > >> >> > You can still do as before, but you have to accept that long > >> >> > irritating warning. > >> >> > > >> >> > Or you patch spidev.c to include your pattern of choice for compatiblity > >> >> > >> >> So the suggestion is to add a compatible string like olimex,uext-slot > >> >> to spidev and use that compatible in the DT? > >> > > >> > No, you add a compatible for the device that is connected to the bus > >> > through that slot. > >> > >> There is no device connected in the slot by design. The slot is there > >> for connecting random stuff you find in your mailbox or other drawers > >> and boxes. > > > > I know. Our point is add a compatible for that random device you find > > in your mailbox. > > That would be mailbox,device-tbd I suppose? If you can find a programming model and a matching datasheet for that device, I suppose, yes. > >> >> That can certainly be done but adding a new compatible for every board > >> >> that has some random pins looks like a needless nuisance to me. > >> >> Especially compared to i2c where you can just open the bus so long as > >> >> ti is enabled. > >> >> > >> >> > > >> >> > Or you implement the following proposal (which needs a volunteer): > >> >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > >> >> >> > >> >> >> So what you need is a way to handover from generic spidev to a device-specific > >> >> >> driver, cfr. what graphics drivers do when the device has been bound to by > >> >> >> vesafb or simplefb. > >> >> >> > >> >> >> Could this be implemented in a generic way in the spi or DT code? > >> >> > > >> >> > ... > >> >> >> On 23.04.2015, at 12:36, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: > >> >> >> > >> >> >>> I guess this has been suggested before: the spi core could provide spidev > >> >> >>> access to all spi client devices which are not bound by a driver? > >> >> >> > >> >> >> I don't know if it's been suggested before, certainly nobody did the > >> >> >> work to make it happen. I don't think I have a massive objection in > >> >> >> principal. > >> > > >> > Actually, I did it a year ago, and it looked at the time that it > >> > wasn't what should be done either. > >> > >> There is nothing like unclaimed device. Either there is a device and > >> driver for it may in principle be loaded later as a module or the chip > >> select is reserved for use from userspace. > > > > I never said it was perfect. > > > >> Userspace driver is valid option and should have the ability to have > >> the chip select reserved. > > > > Whether an userspace driver is a valid option can spawn a whole debate > > by its own, but it's true that we should be able to have it exported > > to the userspace. > > > > However, having a spidev compatible is not the solution to that > > problem. > > Having to patch the kernel to use an unknown device with userspace > driver is not the answer either. > > Devices which are not performance critical and don't use existing > kernel frameworks don't have any use for kernel driver. > > In fact, writing a kernel driver for them is counter-productive > because you will have to write from scratch when you connect the > device to a box running another OS due to interface *and* license > difference. And here is the debate... > Also for driver prototyping you need a compatible which makes the > device accessible. > > If no spidev general compatible is available people will just use > comaptible for some random device which happens to bind to spidev and > will send many letters of thanks to the DT maintainers when the device > used for this purpose suddenly grows a Linux driver. If people do dumb things, they should expect it to backfire. > >> > https://lkml.org/lkml/2014/4/28/612 > >> > > >> >> But how do you know there is a device? > >> >> > >> >> Devices on i2c can be probed. On spi you just transfer random data and > >> >> hope it does something useful. Some devices have readable registers > >> >> and can be probed in a device-specific way but others are write-only. > >> > > >> > Well, what's the point of communicating with a non-existent device in > >> > the first place? > >> > >> I have multitude of SPI devices which are not part of the board and > >> hence its DT and can be connected to the board with jumper wires. > >> > >> Most of them don't have a linux driver or compatible to bind with. > > > > Then create such a compatible... > > I will if and when the device is usable. That's backward. The fact that your "driver" works really doesn't depend on what the device actually is. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
