Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Javier Martinez Canillas]

Hello Dmitry,

On 02/01/2017 07:28 PM, Dmitry Torokhov wrote:

[snip]

>>
>> As said, changing the core is trivial. A RFC patch is [0].
>>
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
>

I don't think coccinelle is a good fit for this since you may have to look if
a DTS is using in its compatible string a device that's in an SPI table or if
a DT binding documents this device as a compatible string.

But yes I get your point and I agree that is just a matter of having a script
to look for these. Someone should have the time to write it though :)

>>
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>>
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>>
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important. Module autoloading does not work anyway if you have
> several compatible strings, like
> 
> 	compatible = "vendor,new-device", "vendor,generic-device";
> 
> Thanks.
>

Agree.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America