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,