Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.

[Maxime Ripard]

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