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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOMqctR8MZ_r6HHEBWhgxpUsTaV=M7DfmnJ_VxTqjWu4KMBSwA@mail.gmail.com>
Date:	Sun, 26 Apr 2015 14:38:18 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Martin Sperl <kernel@...tin.sperl.org>
Cc:	Hans de Goede <hdegoede@...hat.com>,
	Mark Brown <broonie@...nel.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>,
	Jonathan Corbet <corbet@....net>,
	linux-spi <linux-spi@...r.kernel.org>,
	linux-doc <linux-doc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.

On 26 April 2015 at 13:56, Martin Sperl <kernel@...tin.sperl.org> wrote:
>
>> On 26.04.2015, at 13:23, Hans de Goede <hdegoede@...hat.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?

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@...ux-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 <broonie@...nel.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.

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.

So binding spidev is in my view just saying that you are going to
transfer random data from userspace on this bus.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/