lkml.org 
[lkml]   [2021]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] spidev: Make probe to fail early if a spidev compatible is used
From
Hello Uwe,

On 11/10/21 08:42, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Nov 09, 2021 at 11:59:20PM +0100, Javier Martinez Canillas wrote:
>> Some Device Trees don't use a real device name in the compatible string
>> for SPI devices nodes, abusing the fact that the spidev driver name is
>> used to match as a fallback when a SPI device ID table is not defined.
>>
>> But since commit 6840615f85f6 ("spi: spidev: Add SPI ID table") a table
>> for SPI device IDs was added to the driver breaking the assumption that
>> these DTs were relying on.
>>
>> There has been a warning message for some time since commit 956b200a846e
>> ("spi: spidev: Warn loudly if instantiated from DT as "spidev""), making
>> quite clear that this case is not really supported by the spidev driver.
>>
>> Since these devices won't match anyways after the mentioned commit, there
>> is no point to continue if an spidev compatible is used. Let's just make
>> the driver probe to fail early.
>>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>
> Up to 6840615f85f6 the choices you had to use the spidev driver were
> (assuing a dt machine):
>
> a) Use compatible = "spidev" and ignore the warning
> b) Use compatible = $chipname and add $chipname to the list of
> supported devices for the spidev driver. (e.g. "rohm,dh2228fv")
> c) Use compatible = $chipname and force binding the spidev driver using
>
> echo spidev > /sys/bus/spi/devices/spiX.Y/driver_override
> echo spiX.Y > /sys/bus/spi/drivers/spidev/bind
>
> Commit 6840615f85f6 changed that in situation a) you had to switch to c)
> (well, or b) adding "spidev" to the spi id list).
>
> With the change introduced by this patch, you make it impossible to bind
> the spidev driver to such a device (without kernel source changes) even
> using approach c). I wonder if this is too harsh given that changing the
> dtb is difficult on some machines.
>

Right. I completely forgot about driver_override. I wonder if the warning
should mention that, so users can know how to get it to match again after
commit 6840615f85f6.

Because currently they would notice a change in behavior but may not know
how to make it to work again.

Honestly I would just stop supporting it, since as mentioned it was really
an abuse on the driver model device matching. But I believe that should be
made clear what the situation is. What's actually supported and what's not.

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

\
 
 \ /
  Last update: 2021-11-10 09:29    [W:0.104 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site