Hello Dmitry,

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

[snip]

quoted

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 :)

quoted

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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html