[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6349482-2f65-277d-afa7-9fb47e89221b@redhat.com>
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
Powered by blists - more mailing lists