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. > >> 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. Userspace driver is valid option and should have the ability to have the chip select reserved. > > 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. > >> So binding spidev is in my view just saying that you are going to >> transfer random data from userspace on this bus. > > Yes, to a device connected on that bus. Yes, so I have this red rectangular PCB, blue PCB, and red square PCB and blue very thin rectangular PCB. Please enlighten me how to add DT bindings for these and the PCB which is in the mail and I did not pick up at the post office yet. Of course, I have some hope that the chips on the PCBs are at least somewhat compatible with what I ordered but I cannot be sure until I test that. 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/
