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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
