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

[Javier Martinez Canillas <javierm@xxxxxxxxxx>]

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