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

[Michal Suchanek <hramrach@xxxxxxxxx>]

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?

>
>> >> 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.

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.

>
>> > 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.

>
>> >> 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.
>
> Come on, this is pure bad faith. If you don't even know what that
> device is, how do you even know how to interact with it?
>

It either works as described or not. How do you even find out without
without talking to the device?

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html