On 26 April 2015 at 17:54, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Sun, Apr 26, 2015 at 05:33:36PM +0200, Michal Suchanek wrote: >> On 26 April 2015 at 16:33, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: >> >> On 26 April 2015 at 14:51, Maxime Ripard >> >> <maxime.rip...@free-electrons.com> wrote: >> >> > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: >> >> >> On 26 April 2015 at 13:56, Martin Sperl <ker...@martin.sperl.org> >> >> >> wrote: >> >> >> > >> >> >> >> On 26.04.2015, at 13:23, Hans de Goede <hdego...@redhat.com> 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 <ge...@linux-m68k.org> >> >> >> >> 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 <broo...@kernel.org> 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 >> compatible 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.
Yes, dumb things like not allowing people to say in the DT that the board actually has pins on it connected to a SPI bus. Which is the actual hardware which should be described in the DT. Do you have to describe a modem or terminal emulator in DT to connect it to your serial port? You just describe the port. So here you have a SPI port and it should be described in the DT as faithfully as the serial port. > >> >> > 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. Indeed. However, for the device to have a compatible the compatible must be specified in a driver and then I need a driver for the device to record the compatible in. Or do you suggest that I patch the compatible into spidev, write a driver for it, and then back out the compatible from spidev and check in the compatible again with the driver? Now that is backwards. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
