On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:

Hello Nikolaus,

On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:

quoted

Hi Dmitry, Javier,

quoted

Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller [off-list ref]:

Hi Dmitry,

quoted

Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov [off-list ref]:

On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:

quoted

Hi Dmitry,

quoted

Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov [off-list ref]:

On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:

quoted

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

I believe I already replied to a similar patch: we alreadyhave necessary
aliases in this driver, we need to fix module loading to use it.

Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):

quoted

quoted

We really need to fix it between spi/i23c core and module utils instead
of keeping adding duplicate IDs all over drivers. We already have OF
module device table containing the same data, we should be able to use
it.

And Javier Martinez Canillas replied (23 Nov 2016):

quoted

Agreed, unfortunately until the I2C and SPI core are changed to properly
report OF modaliases, we will have to keep adding these duplicated IDs.

And changing the I2C and SPI core isn't trivial since it could break a
lot of drivers that rely on a platform modalias being reported (i.e: no
OF device IDs present in the drivers even when are registered via DT).

Therefore I didn't see a need to change it.

I agree that changing I2C and SPI core is not trivial, however this is
no reason for piling up workarounds in all drivers. Are you seriously
advocating going though *every* driver and copying OF data into I2C/SPI
instead of doing the right thing and fixing the root of the issue?

If you prefer to have this done (and I agree it would be a tiny improvement),
please do it for us all. But please after merging this workaround.

Have we been lucky to find someone who is able and willing to work on this?

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.

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.

-- 
Dmitry