Hello Dmitry, Thanks a lot for your feedback. On 07/30/2015 06:37 PM, Dmitry Torokhov wrote: > On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: >> Hi Javier, >> >> On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: >>> Hello, >>> >>> Short version: >>> >>> This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables >>> to export that information so modules have the correct aliases built-in >>> and autoloading works correctly. >>> >>> Longer version: >>> >>> Currently it's mandatory for I2C drivers to have an I2C device ID table >>> regardless if the device was registered using platform data or OF. This >>> is because the I2C core needs an I2C device ID table for two reasons: >>> >>> 1) Match the I2C client with a I2C device ID so a struct i2c_device_id >>> is passed to the I2C driver probe() function. >>> >>> 2) Export the module aliases from the I2C device ID table so userspace >>> can auto-load the correct module. This is because i2c_device_uevent >>> always reports a MODALIAS of the form i2c:<client->name>. >> >> Why are we not fixing this? We emit specially carved uevent for >> ACPI-based devices, why not the same for OF? Platform bus does this... > > Ah, now I see the 27/27 patch. I think it is exactly what we need. And Yes, patch 27/27 is needed but the problem is as I explained before that there are drivers relying on the current behavior. The item c) in the list of issues that I mentioned. So those drivers need to be fixed before that patch is merged... > probably for SPI bus as well. > Yes, I didn't mention SPI because the cover letter became too long already but it does indeed have the same issue and I discussed this with Mark already some time ago [0]. Once I2C uevent report is fixed, I plan to do the same for SPI. > Thanks. > [0]: https://lkml.org/lkml/2014/9/11/458 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
