Re: [PATCH] spidev: Make probe to fail early if a spidev compatible is used

[Javier Martinez Canillas <javierm@xxxxxxxxxx>]

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@xxxxxxxxxx>
> 
> 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