lkml.org 
[lkml]   [2023]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/3] platform: olpc: mark SPI related data as maybe unused
Date
Hans de Goede <hdegoede@redhat.com> writes:

[...]

>>> Exposing modaliases for a non supported way of binding the driver does not really seem useful ?
>>
>> However binding the device and module loading (uevent) uses sometimes
>> different pieces. Maybe something changed in kernel, but sometime ago
>> certain buses where sending uevent for module loading with one ID (e.g.
>> platform or spi bus) but device matching would be according to OF. Thus
>> if you did not have entries in spi_device_id, the module would not autoload.
>>
>> It was exactly the case for example here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c46ed2281bbe4b84e6f3d4bdfb0e4e9ab813fa9d&context=30&ignorews=0&dt=0
>>
>> You needed spi_device_id for proper module autoloading.
>>
>> Unless something change in between in the kernel?
>
> Looks like your right, the spi_uevent() code always emits "spi:xxxxxxx" style modalias even for dt/of enumerated devices:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c#n398
>
> So the table needs to stay.
>

Yeah, and in fact dropping the spi_device_id table will cause the kernel
to warn that an spi_device_id entry doesn't exist for a given of_device_id
entry since commit 5fa6863ba692 ("spi: Check we have a spi_device_id for
each DT compatible").

Fixing that is not trivial because a lot of drivers are rely on current
behaviour of the SPI core always returning a spi:<dev> modalias. So don't
even have an OF table, even when the SPI devices are instantiated by DT.

--
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

\
 
 \ /
  Last update: 2023-03-27 01:04    [W:0.069 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site