linux-kernel - Re: [PATCH] spi: docs: improve the SPI userspace API documentation

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]

Date:   Fri, 19 Nov 2021 09:14:45 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-spi@...r.kernel.org, Ralph Siemsen <ralph.siemsen@...aro.org>
Subject: Re: [PATCH] spi: docs: improve the SPI userspace API documentation

Hello Uwe,

Thanks for your feedback.

On 11/19/21 08:45, Uwe Kleine-König wrote:
> On Thu, Nov 18, 2021 at 10:31:43PM +0100, Javier Martinez Canillas wrote:

[snip]

>> +
>>  Set up the other device characteristics (bits per word, SPI clocking,
>>  chipselect polarity, etc) as usual, so you won't always need to override
>>  them later.
>>  
>> -(Sysfs also supports userspace driven binding/unbinding of drivers to
>> -devices.  That mechanism might be supported here in the future.)
>> +Sysfs also supports userspace driven binding/unbinding of drivers to
>> +devices.  The mechanism works by writing to the device "driver_overrride"
>> +entry.  For example:
> 
> I'd write here:
> 
> 	Sysfs also supports userspace driven binding/unbinding of
> 	drivers to devices that don't bind automatically using one of
> 	the tables above. To make the spidev driver bind to such a
> 	device, use:
>

Agreed, that looks much nicer.
 
>> +
>> +    echo spidev > /sys/bus/spi/devices/spiX.Y/driver_override
>> +    echo spiB.C > /sys/bus/spi/drivers/spidev/bind
>>  
>>  When you do that, the sysfs node for the SPI device will include a child
>>  device node with a "dev" attribute that will be understood by udev or mdev.
> 
> What is "that" here? (Maybe this refers to "Set up the other device
> characteristics [...] as usual"? Is the effect still accurate?
>

My understanding is that "that" refers to: define an register a spi_board_info
with .modalias = "$chipname" to bind the device with the spidev driver.

Since the "dev" attribute will AFAIK contain the MAJOR:MINOR numbers for the
character device in /dev. This is the reason why I left this paragraph after
the explanation of the device <--> driver binding logic.

But probably while being there I should make that paragraph more clear too ?

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat