[PATCH 00/27] Export I2C and OF module aliases in missing drivers

[PATCH 00/27] Export I2C and OF module aliases in missing drivers

[Javier Martinez Canillas]

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>.

Lee Jones posted a patch series [0] to solve 1) by allowing the I2C
drivers to have a probe() function that does not get a i2c_device_id.

The problem is that his series didn't take into account 2) so if that
was merged and the I2C ID table is removed from all the drivers that
don't needed it, module auto-loading will break for those.

But even now there are many I2C drivers were module auto-loading is
not working because of the fact that the I2C core always reports the
MODALIAS as i2c:<client->name> and many developers didn't expect this.

I've identified I2C drivers with 3 types of different issues:

a) Those that have an i2c_table but are not exported. The match works
   and the correct i2c_device_id is passed on probe but since the ID
   table is not exported, module auto-load won't work.

b) Those that have a of_table but are not exported. This is currently
   not an issue since even when the of_table is used to match the dev
   with the driver, an OF modalias is not reported by the I2C core.
   But if the I2C core is changed to report the MODALIAS of the form
   of:N*T*C as it's made by other subsystems, then module auto-load
   will break for these drivers.

c) Those that don't have a of_table but should since are OF drivers
   with DT bindings doc for them. Since the I2C core does not report
   a OF modalias and since i2c_device_match() fallbacks to match the
   device part of the compatible string with the I2C device ID table,
   many OF drivers don't have an of_table to match. After all having
   a I2C device ID table is mandatory so it works without a of_table.

So, in order to not make mandatory to have a I2C device ID table, at
least a) and b) needs to be addressed, this series does that.

c) should be fixed too since it seems wrong that a driver with a DT
binding document, does not have a OF table and export it to modules.

Also stripping the vendor part from the compatible string to match
with the I2C devices ID table and reporting only the device name to
user-space doesn't seem to be correct. I've identified at least two
drivers that have the same name on their I2C device ID table so the
manufacturer prefix is important. But I've not tried to fix c) yet
since that is not so easy to automate due drivers not having all the
information (i.e: the device name can match a documented compatible
string device part but without the vendor prefix is hard to tell).

I split the changes so the patches in this series are independent and
can be picked individually by subsystem maintainers. Patch #27 changes
the logic of i2c_device_uevent() to report an OF modalias if the device
was registered using OF. But this patch is included in the series only
as an RFC for illustration purposes since changing that without fixing
c) will break module auto-loading for the drivers of devices registered
with OF but that don't have a of_match_table.

Although arguably, those drivers were relying on the assumption that a
MODALIAS=i2c:<foo> would always be reported even for the OF case which
is not the true on other subsystems.

[0]: https://lkml.org/lkml/2014/8/28/283

Best regards,
Javier


Javier Martinez Canillas (27):
  mfd: stw481x: Export I2C module alias information
  spi: xcomm: Export I2C module alias information
  iio: Export I2C module alias information in missing drivers
  [media] Export I2C module alias information in missing drivers
  macintosh: therm_windtunnel: Export I2C module alias information
  misc: eeprom: Export I2C module alias information in missing drivers
  Input: Export I2C module alias information in missing drivers
  power: Export I2C module alias information in missing drivers
  i2c: core: Export I2C module alias information in dummy driver
  backlight: tosa: Export I2C module alias information
  [media] staging: media: lirc: Export I2C module alias information
  usb: phy: isp1301: Export I2C module alias information
  ALSA: ppc: keywest: Export I2C module alias information
  hwmon: (nct7904) Export I2C module alias information
  regulator: fan53555: Export I2C module alias information
  mfd: Export OF module alias information in missing drivers
  iio: Export OF module alias information in missing drivers
  hwmon: (g762) Export OF module alias information
  extcon: Export OF module alias information in missing drivers
  ASoC: Export OF module alias information in missing codec drivers
  rtc: Export OF module alias information in missing drivers
  macintosh: therm_windtunnel: Export OF module alias information
  leds: Export OF module alias information in missing drivers
  [media] smiapp: Export OF module alias information
  Input: touchscreen - Export OF module alias information
  regulator: isl9305: Export OF module alias information
  i2c: (RFC, don't apply) report OF style modalias when probing using DT

 drivers/extcon/extcon-rt8973a.c         | 1 +
 drivers/extcon/extcon-sm5502.c          | 1 +
 drivers/hwmon/g762.c                    | 1 +
 drivers/hwmon/nct7904.c                 | 1 +
 drivers/i2c/i2c-core.c                  | 9 +++++++++
 drivers/iio/accel/mma8452.c             | 1 +
 drivers/iio/accel/stk8312.c             | 1 +
 drivers/iio/accel/stk8ba50.c            | 1 +
 drivers/iio/light/cm32181.c             | 1 +
 drivers/iio/light/cm3232.c              | 1 +
 drivers/iio/light/cm36651.c             | 1 +
 drivers/iio/light/gp2ap020a00f.c        | 1 +
 drivers/iio/light/stk3310.c             | 1 +
 drivers/input/misc/gp2ap002a00f.c       | 1 +
 drivers/input/touchscreen/egalax_ts.c   | 1 +
 drivers/input/touchscreen/goodix.c      | 1 +
 drivers/input/touchscreen/mms114.c      | 1 +
 drivers/leds/leds-pca963x.c             | 1 +
 drivers/leds/leds-tca6507.c             | 1 +
 drivers/macintosh/therm_windtunnel.c    | 2 ++
 drivers/media/i2c/ir-kbd-i2c.c          | 1 +
 drivers/media/i2c/s5k6a3.c              | 1 +
 drivers/media/i2c/smiapp/smiapp-core.c  | 1 +
 drivers/mfd/rt5033.c                    | 1 +
 drivers/mfd/stw481x.c                   | 1 +
 drivers/mfd/tps65217.c                  | 1 +
 drivers/mfd/tps65218.c                  | 1 +
 drivers/misc/eeprom/eeprom.c            | 1 +
 drivers/misc/eeprom/max6875.c           | 1 +
 drivers/power/bq24190_charger.c         | 1 +
 drivers/power/rt5033_battery.c          | 2 +-
 drivers/regulator/fan53555.c            | 1 +
 drivers/regulator/isl9305.c             | 1 +
 drivers/rtc/rtc-ab-b5ze-s3.c            | 1 +
 drivers/rtc/rtc-isl12022.c              | 1 +
 drivers/rtc/rtc-isl12057.c              | 1 +
 drivers/spi/spi-xcomm.c                 | 1 +
 drivers/staging/media/lirc/lirc_zilog.c | 1 +
 drivers/usb/phy/phy-isp1301.c           | 1 +
 drivers/video/backlight/tosa_bl.c       | 1 +
 sound/ppc/keywest.c                     | 1 +
 sound/soc/codecs/da9055.c               | 1 +
 sound/soc/codecs/wm8510.c               | 1 +
 sound/soc/codecs/wm8523.c               | 1 +
 sound/soc/codecs/wm8580.c               | 1 +
 45 files changed, 54 insertions(+), 1 deletion(-)

-- 
2.4.3

[PATCH 01/27] mfd: stw481x: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/mfd/stw481x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/stw481x.c b/drivers/mfd/stw481x.c
index 7ceb3df09e25..ca613df36143 100644
--- a/drivers/mfd/stw481x.c
+++ b/drivers/mfd/stw481x.c
@@ -231,6 +231,7 @@ static const struct i2c_device_id stw481x_id[] = {
 	{ "stw481x", 0 },
 	{ },
 };
+MODULE_DEVICE_TABLE(i2c, stw481x_id);
 
 static const struct of_device_id stw481x_match[] = {
 	{ .compatible = "st,stw4810", },
-- 
2.4.3

Re: [PATCH 01/27] mfd: stw481x: Export I2C module alias information

[Lee Jones]

On Thu, 30 Jul 2015, Javier Martinez Canillas wrote:

> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> 
> ---
> 
>  drivers/mfd/stw481x.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

> diff --git a/drivers/mfd/stw481x.c b/drivers/mfd/stw481x.c
> index 7ceb3df09e25..ca613df36143 100644
> --- a/drivers/mfd/stw481x.c
> +++ b/drivers/mfd/stw481x.c
> @@ -231,6 +231,7 @@ static const struct i2c_device_id stw481x_id[] = {
>  	{ "stw481x", 0 },
>  	{ },
>  };
> +MODULE_DEVICE_TABLE(i2c, stw481x_id);
>  
>  static const struct of_device_id stw481x_match[] = {
>  	{ .compatible = "st,stw4810", },

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 02/27] spi: xcomm: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/spi/spi-xcomm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-xcomm.c b/drivers/spi/spi-xcomm.c
index d0561a8d9f16..3c28e24b10f5 100644
--- a/drivers/spi/spi-xcomm.c
+++ b/drivers/spi/spi-xcomm.c
@@ -237,6 +237,7 @@ static const struct i2c_device_id spi_xcomm_ids[] = {
 	{ "spi-xcomm" },
 	{ },
 };
+MODULE_DEVICE_TABLE(i2c, spi_xcomm_ids);
 
 static struct i2c_driver spi_xcomm_driver = {
 	.driver = {
-- 
2.4.3

[PATCH 03/27] iio: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/iio/accel/stk8312.c  | 1 +
 drivers/iio/accel/stk8ba50.c | 1 +
 drivers/iio/light/stk3310.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/iio/accel/stk8312.c b/drivers/iio/accel/stk8312.c
index c2bd1444d6da..a553736b6e51 100644
--- a/drivers/iio/accel/stk8312.c
+++ b/drivers/iio/accel/stk8312.c
@@ -662,6 +662,7 @@ static const struct i2c_device_id stk8312_i2c_id[] = {
 	{"STK8312", 0},
 	{}
 };
+MODULE_DEVICE_TABLE(i2c, stk8312_i2c_id);
 
 static const struct acpi_device_id stk8312_acpi_id[] = {
 	{"STK8312", 0},
diff --git a/drivers/iio/accel/stk8ba50.c b/drivers/iio/accel/stk8ba50.c
index 16cee637109b..80f77d8704b5 100644
--- a/drivers/iio/accel/stk8ba50.c
+++ b/drivers/iio/accel/stk8ba50.c
@@ -572,6 +572,7 @@ static const struct i2c_device_id stk8ba50_i2c_id[] = {
 	{"stk8ba50", 0},
 	{}
 };
+MODULE_DEVICE_TABLE(i2c, stk8ba50_i2c_id);
 
 static const struct acpi_device_id stk8ba50_acpi_id[] = {
 	{"STK8BA50", 0},
diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
index 48ff7942fa00..993eb201148e 100644
--- a/drivers/iio/light/stk3310.c
+++ b/drivers/iio/light/stk3310.c
@@ -672,6 +672,7 @@ static const struct i2c_device_id stk3310_i2c_id[] = {
 	{"STK3311", 0},
 	{}
 };
+MODULE_DEVICE_TABLE(i2c, stk3310_i2c_id);
 
 static const struct acpi_device_id stk3310_acpi_id[] = {
 	{"STK3310", 0},
-- 
2.4.3

Re: [PATCH 03/27] iio: Export I2C module alias information in missing drivers

[Jonathan Cameron]

On 30/07/15 17:18, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Applied to the togreg branch of iio.git

Thanks,

Jonathan
> 
> ---
> 
>  drivers/iio/accel/stk8312.c  | 1 +
>  drivers/iio/accel/stk8ba50.c | 1 +
>  drivers/iio/light/stk3310.c  | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/drivers/iio/accel/stk8312.c b/drivers/iio/accel/stk8312.c
> index c2bd1444d6da..a553736b6e51 100644
> --- a/drivers/iio/accel/stk8312.c
> +++ b/drivers/iio/accel/stk8312.c
> @@ -662,6 +662,7 @@ static const struct i2c_device_id stk8312_i2c_id[] = {
>  	{"STK8312", 0},
>  	{}
>  };
> +MODULE_DEVICE_TABLE(i2c, stk8312_i2c_id);
>  
>  static const struct acpi_device_id stk8312_acpi_id[] = {
>  	{"STK8312", 0},
> diff --git a/drivers/iio/accel/stk8ba50.c b/drivers/iio/accel/stk8ba50.c
> index 16cee637109b..80f77d8704b5 100644
> --- a/drivers/iio/accel/stk8ba50.c
> +++ b/drivers/iio/accel/stk8ba50.c
> @@ -572,6 +572,7 @@ static const struct i2c_device_id stk8ba50_i2c_id[] = {
>  	{"stk8ba50", 0},
>  	{}
>  };
> +MODULE_DEVICE_TABLE(i2c, stk8ba50_i2c_id);
>  
>  static const struct acpi_device_id stk8ba50_acpi_id[] = {
>  	{"STK8BA50", 0},
> diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
> index 48ff7942fa00..993eb201148e 100644
> --- a/drivers/iio/light/stk3310.c
> +++ b/drivers/iio/light/stk3310.c
> @@ -672,6 +672,7 @@ static const struct i2c_device_id stk3310_i2c_id[] = {
>  	{"STK3311", 0},
>  	{}
>  };
> +MODULE_DEVICE_TABLE(i2c, stk3310_i2c_id);
>  
>  static const struct acpi_device_id stk3310_acpi_id[] = {
>  	{"STK3310", 0},
> 

[PATCH 04/27] [media] Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/media/i2c/ir-kbd-i2c.c | 1 +
 drivers/media/i2c/s5k6a3.c     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 175a76114953..728d2cc8a3e7 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -478,6 +478,7 @@ static const struct i2c_device_id ir_kbd_id[] = {
 	{ "ir_rx_z8f0811_hdpvr", 0 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, ir_kbd_id);
 
 static struct i2c_driver ir_kbd_driver = {
 	.driver = {
diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c
index bc389d5e42ae..b1b1574dfb95 100644
--- a/drivers/media/i2c/s5k6a3.c
+++ b/drivers/media/i2c/s5k6a3.c
@@ -363,6 +363,7 @@ static int s5k6a3_remove(struct i2c_client *client)
 static const struct i2c_device_id s5k6a3_ids[] = {
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, s5k6a3_ids);
 
 #ifdef CONFIG_OF
 static const struct of_device_id s5k6a3_of_match[] = {
-- 
2.4.3

[PATCH 05/27] macintosh: therm_windtunnel: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/macintosh/therm_windtunnel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/therm_windtunnel.c b/drivers/macintosh/therm_windtunnel.c
index 109dcaa15934..97269567ec01 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -408,6 +408,7 @@ static const struct i2c_device_id therm_windtunnel_id[] = {
 	{ "therm_adm1030", adm1030 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, therm_windtunnel_id);
 
 static int
 do_probe(struct i2c_client *cl, const struct i2c_device_id *id)
-- 
2.4.3

Re: [05/27] macintosh: therm_windtunnel: Export I2C module alias information

[Michael Ellerman]

On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> 
>  drivers/macintosh/therm_windtunnel.c | 1 +
>  1 file changed, 1 insertion(+)

Who are you expecting to merge this?

cheers

Re: [05/27] macintosh: therm_windtunnel: Export I2C module alias information

[Javier Martinez Canillas]

Hello Michael,

On 08/18/2015 12:24 PM, Michael Ellerman wrote:
> On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
>> regardless if the driver was matched using the I2C id_table or the
>> of_match_table. So the driver needs to export the I2C table and this
>> be built into the module or udev won't have the necessary information
>> to auto load the correct module when the device is added.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>>  drivers/macintosh/therm_windtunnel.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Who are you expecting to merge this?
> 

I was expecting Benjamin Herrenschmidt since he is listed in MAINTAINERS
for drivers/macintosh. I cc'ed him in the patch but now in your answer I
don't see him in the cc list, strange.

But I'll be happy to re-post if there is another person who is handling
the patches for this driver now.

BTW there is another patch [0] for the same driver to export the OF id
table information, that was not picked either.

> cheers
> 

[0]: https://lkml.org/lkml/2015/7/30/503

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [05/27] macintosh: therm_windtunnel: Export I2C module alias information

[Michael Ellerman]

On Tue, 2015-08-18 at 12:35 +0200, Javier Martinez Canillas wrote:
> Hello Michael,
> 
> On 08/18/2015 12:24 PM, Michael Ellerman wrote:
> > On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
> >> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> >> regardless if the driver was matched using the I2C id_table or the
> >> of_match_table. So the driver needs to export the I2C table and this
> >> be built into the module or udev won't have the necessary information
> >> to auto load the correct module when the device is added.
> >>
> >> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> >> ---
> >>
> >>  drivers/macintosh/therm_windtunnel.c | 1 +
> >>  1 file changed, 1 insertion(+)
> > 
> > Who are you expecting to merge this?
> > 
> 
> I was expecting Benjamin Herrenschmidt since he is listed in MAINTAINERS
> for drivers/macintosh. I cc'ed him in the patch but now in your answer I
> don't see him in the cc list, strange.

That's the mailing list dropping him from CC because he's subscribed.

> But I'll be happy to re-post if there is another person who is handling
> the patches for this driver now.
> 
> BTW there is another patch [0] for the same driver to export the OF id
> table information, that was not picked either.

Yep, I'll grab them both.

cheers

Re: [05/27] macintosh: therm_windtunnel: Export I2C module alias information

[Javier Martinez Canillas]

Hello Michael,

On 08/19/2015 02:51 AM, Michael Ellerman wrote:
> On Tue, 2015-08-18 at 12:35 +0200, Javier Martinez Canillas wrote:
>> Hello Michael,
>>
>> On 08/18/2015 12:24 PM, Michael Ellerman wrote:
>>> On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
>>>> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
>>>> regardless if the driver was matched using the I2C id_table or the
>>>> of_match_table. So the driver needs to export the I2C table and this
>>>> be built into the module or udev won't have the necessary information
>>>> to auto load the correct module when the device is added.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>> ---
>>>>
>>>>  drivers/macintosh/therm_windtunnel.c | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>
>>> Who are you expecting to merge this?
>>>
>>
>> I was expecting Benjamin Herrenschmidt since he is listed in MAINTAINERS
>> for drivers/macintosh. I cc'ed him in the patch but now in your answer I
>> don't see him in the cc list, strange.
> 
> That's the mailing list dropping him from CC because he's subscribed.
> 
>> But I'll be happy to re-post if there is another person who is handling
>> the patches for this driver now.
>>
>> BTW there is another patch [0] for the same driver to export the OF id
>> table information, that was not picked either.
> 
> Yep, I'll grab them both.
>

Perfect, thanks a lot!
 
> cheers
> 
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [05/27] macintosh: therm_windtunnel: Export I2C module alias information

[Michael Ellerman]

On Thu, 2015-30-07 at 16:18:30 UTC, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/cb0eefcc3271ea1d3704

cheers

[PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/misc/eeprom/eeprom.c  | 1 +
 drivers/misc/eeprom/max6875.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
index b432873def96..4bb54e1c40a7 100644
--- a/drivers/misc/eeprom/eeprom.c
+++ b/drivers/misc/eeprom/eeprom.c
@@ -203,6 +203,7 @@ static const struct i2c_device_id eeprom_id[] = {
 	{ "eeprom", 0 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, eeprom_id);
 
 static struct i2c_driver eeprom_driver = {
 	.driver = {
diff --git a/drivers/misc/eeprom/max6875.c b/drivers/misc/eeprom/max6875.c
index 580ff9df5529..c74920cc3d18 100644
--- a/drivers/misc/eeprom/max6875.c
+++ b/drivers/misc/eeprom/max6875.c
@@ -197,6 +197,7 @@ static const struct i2c_device_id max6875_id[] = {
 	{ "max6875", 0 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, max6875_id);
 
 static struct i2c_driver max6875_driver = {
 	.driver = {
-- 
2.4.3

Re: [PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Jean Delvare]

Hi Javier,

On Thu, 30 Jul 2015 18:18:31 +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> 
> ---
> 
>  drivers/misc/eeprom/eeprom.c  | 1 +
>  drivers/misc/eeprom/max6875.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
> index b432873def96..4bb54e1c40a7 100644
> --- a/drivers/misc/eeprom/eeprom.c
> +++ b/drivers/misc/eeprom/eeprom.c
> @@ -203,6 +203,7 @@ static const struct i2c_device_id eeprom_id[] = {
>  	{ "eeprom", 0 },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(i2c, eeprom_id);
>  
>  static struct i2c_driver eeprom_driver = {
>  	.driver = {

I seem to recall this one is missing on purpose. The legacy eeprom
driver is deprecated in favor of the at24 driver, so no one should
declare "eeprom" i2c devices and thus the module alias is useless. So I
would leave the legacy eeprom driver alone.

The only feature the at24 driver is missing is device auto-detection as
far as I know. Maybe it should be added to ease the transition. Or
maybe not, I admit I'm not sure.

> diff --git a/drivers/misc/eeprom/max6875.c b/drivers/misc/eeprom/max6875.c
> index 580ff9df5529..c74920cc3d18 100644
> --- a/drivers/misc/eeprom/max6875.c
> +++ b/drivers/misc/eeprom/max6875.c
> @@ -197,6 +197,7 @@ static const struct i2c_device_id max6875_id[] = {
>  	{ "max6875", 0 },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(i2c, max6875_id);
>  
>  static struct i2c_driver max6875_driver = {
>  	.driver = {

That one is needed, I agree.

Reviewed-by: Jean Delvare <jdelvare@suse.de>

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

Hello Jean,

On 08/03/2015 01:05 PM, Jean Delvare wrote:
> Hi Javier,
> 
> On Thu, 30 Jul 2015 18:18:31 +0200, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
>> regardless if the driver was matched using the I2C id_table or the
>> of_match_table. So the driver needs to export the I2C table and this
>> be built into the module or udev won't have the necessary information
>> to auto load the correct module when the device is added.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>
>> ---
>>
>>  drivers/misc/eeprom/eeprom.c  | 1 +
>>  drivers/misc/eeprom/max6875.c | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
>> index b432873def96..4bb54e1c40a7 100644
>> --- a/drivers/misc/eeprom/eeprom.c
>> +++ b/drivers/misc/eeprom/eeprom.c
>> @@ -203,6 +203,7 @@ static const struct i2c_device_id eeprom_id[] = {
>>  	{ "eeprom", 0 },
>>  	{ }
>>  };
>> +MODULE_DEVICE_TABLE(i2c, eeprom_id);
>>  
>>  static struct i2c_driver eeprom_driver = {
>>  	.driver = {
> 
> I seem to recall this one is missing on purpose. The legacy eeprom
> driver is deprecated in favor of the at24 driver, so no one should
> declare "eeprom" i2c devices and thus the module alias is useless. So I
> would leave the legacy eeprom driver alone.
>
> The only feature the at24 driver is missing is device auto-detection as
> far as I know. Maybe it should be added to ease the transition. Or
> maybe not, I admit I'm not sure.
>

It's up to you but since the driver is still in mainline and it has an
i2c_device_id table, an "eeprom" I2C device can be registered and matched
by the I2C core but if built as a module, it won't be autoloaded.

I'm not familiar with the at24 platform so feel free to discard the patch
if you think that it is not needed and no one is really using this driver
(although in that case I think we the driver should just be removed).

>> diff --git a/drivers/misc/eeprom/max6875.c b/drivers/misc/eeprom/max6875.c
>> index 580ff9df5529..c74920cc3d18 100644
>> --- a/drivers/misc/eeprom/max6875.c
>> +++ b/drivers/misc/eeprom/max6875.c
>> @@ -197,6 +197,7 @@ static const struct i2c_device_id max6875_id[] = {
>>  	{ "max6875", 0 },
>>  	{ }
>>  };
>> +MODULE_DEVICE_TABLE(i2c, max6875_id);
>>  
>>  static struct i2c_driver max6875_driver = {
>>  	.driver = {
> 
> That one is needed, I agree.
> 
> Reviewed-by: Jean Delvare <jdelvare@suse.de>
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Jean Delvare]

Le Monday 03 August 2015 à 16:07 +0200, Javier Martinez Canillas a
écrit :
> Hello Jean,
> 
> On 08/03/2015 01:05 PM, Jean Delvare wrote:
> > Hi Javier,
> > 
> > On Thu, 30 Jul 2015 18:18:31 +0200, Javier Martinez Canillas wrote:
> >> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> >> regardless if the driver was matched using the I2C id_table or the
> >> of_match_table. So the driver needs to export the I2C table and this
> >> be built into the module or udev won't have the necessary information
> >> to auto load the correct module when the device is added.
> >>
> >> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> >>
> >> ---
> >>
> >>  drivers/misc/eeprom/eeprom.c  | 1 +
> >>  drivers/misc/eeprom/max6875.c | 1 +
> >>  2 files changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
> >> index b432873def96..4bb54e1c40a7 100644
> >> --- a/drivers/misc/eeprom/eeprom.c
> >> +++ b/drivers/misc/eeprom/eeprom.c
> >> @@ -203,6 +203,7 @@ static const struct i2c_device_id eeprom_id[] = {
> >>  	{ "eeprom", 0 },
> >>  	{ }
> >>  };
> >> +MODULE_DEVICE_TABLE(i2c, eeprom_id);
> >>  
> >>  static struct i2c_driver eeprom_driver = {
> >>  	.driver = {
> > 
> > I seem to recall this one is missing on purpose. The legacy eeprom
> > driver is deprecated in favor of the at24 driver, so no one should
> > declare "eeprom" i2c devices and thus the module alias is useless. So I
> > would leave the legacy eeprom driver alone.
> >
> > The only feature the at24 driver is missing is device auto-detection as
> > far as I know. Maybe it should be added to ease the transition. Or
> > maybe not, I admit I'm not sure.
> >
> 
> It's up to you but since the driver is still in mainline and it has an
> i2c_device_id table, an "eeprom" I2C device can be registered and matched
> by the I2C core but if built as a module, it won't be autoloaded.

The eeprom driver instantiates its own devices, so auto-loading is not
needed. "eeprom" devices should not be found in device trees, that would
be a bug. Adding an alias is an invitation to introduce such bugs thus
my request to not add such an alias.

> I'm not familiar with the at24 platform so feel free to discard the patch
> if you think that it is not needed and no one is really using this driver
> (although in that case I think we the driver should just be removed).

I'm really talking about the at24 eeprom driver
(drivers/misc/eeprom/at24.c) which has nothing to to with the at91
platform, if that's what you are confusing with.

Yes, the long-term plan is to get rid of the legacy eeprom driver. But
we need a transition path for users. Either the at24 driver should be
able to instantiate SPD and EDID devices as the eeprom driver does, or
we need a user-space helper to do that kind of detection, so that
consumer scripts such as decode-dimms keep working. The former is a
smaller change, I just hope it won't have any drawback.

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

Hello Jean,

On 08/03/2015 06:50 PM, Jean Delvare wrote:
> Le Monday 03 August 2015 à 16:07 +0200, Javier Martinez Canillas a
> écrit :
>> Hello Jean,
>>
>> On 08/03/2015 01:05 PM, Jean Delvare wrote:
>>> Hi Javier,
>>>
>>> On Thu, 30 Jul 2015 18:18:31 +0200, Javier Martinez Canillas wrote:
>>>> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
>>>> regardless if the driver was matched using the I2C id_table or the
>>>> of_match_table. So the driver needs to export the I2C table and this
>>>> be built into the module or udev won't have the necessary information
>>>> to auto load the correct module when the device is added.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>
>>>> ---
>>>>
>>>>  drivers/misc/eeprom/eeprom.c  | 1 +
>>>>  drivers/misc/eeprom/max6875.c | 1 +
>>>>  2 files changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
>>>> index b432873def96..4bb54e1c40a7 100644
>>>> --- a/drivers/misc/eeprom/eeprom.c
>>>> +++ b/drivers/misc/eeprom/eeprom.c
>>>> @@ -203,6 +203,7 @@ static const struct i2c_device_id eeprom_id[] = {
>>>>  	{ "eeprom", 0 },
>>>>  	{ }
>>>>  };
>>>> +MODULE_DEVICE_TABLE(i2c, eeprom_id);
>>>>  
>>>>  static struct i2c_driver eeprom_driver = {
>>>>  	.driver = {
>>>
>>> I seem to recall this one is missing on purpose. The legacy eeprom
>>> driver is deprecated in favor of the at24 driver, so no one should
>>> declare "eeprom" i2c devices and thus the module alias is useless. So I
>>> would leave the legacy eeprom driver alone.
>>>
>>> The only feature the at24 driver is missing is device auto-detection as
>>> far as I know. Maybe it should be added to ease the transition. Or
>>> maybe not, I admit I'm not sure.
>>>
>>
>> It's up to you but since the driver is still in mainline and it has an
>> i2c_device_id table, an "eeprom" I2C device can be registered and matched
>> by the I2C core but if built as a module, it won't be autoloaded.
> 
> The eeprom driver instantiates its own devices, so auto-loading is not
> needed. "eeprom" devices should not be found in device trees, that would
> be a bug. Adding an alias is an invitation to introduce such bugs thus
> my request to not add such an alias.
>

OK.
 
>> I'm not familiar with the at24 platform so feel free to discard the patch
>> if you think that it is not needed and no one is really using this driver
>> (although in that case I think we the driver should just be removed).
> 
> I'm really talking about the at24 eeprom driver
> (drivers/misc/eeprom/at24.c) which has nothing to to with the at91
> platform, if that's what you are confusing with.
>

err, I didn't mention at91 but at24 and that was only because you mentioned
it before :-)

> Yes, the long-term plan is to get rid of the legacy eeprom driver. But
> we need a transition path for users. Either the at24 driver should be
> able to instantiate SPD and EDID devices as the eeprom driver does, or
> we need a user-space helper to do that kind of detection, so that
> consumer scripts such as decode-dimms keep working. The former is a
> smaller change, I just hope it won't have any drawback.
>

I'm in fact not familiar with any Atmel SoC. I just noticed that the I2C
core always repots MODALIAS uevents as i2c:<client->name> issue and so
wrote a script to find all the drivers that could be affected by this.
But I'll just blacklist drivers/misc/eeprom/eeprom.c as a false positive.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Jean Delvare]

On Mon, 3 Aug 2015 21:12:39 +0200, Javier Martinez Canillas wrote:
> On 08/03/2015 06:50 PM, Jean Delvare wrote:
> > Yes, the long-term plan is to get rid of the legacy eeprom driver. But
> > we need a transition path for users. Either the at24 driver should be
> > able to instantiate SPD and EDID devices as the eeprom driver does, or
> > we need a user-space helper to do that kind of detection, so that
> > consumer scripts such as decode-dimms keep working. The former is a
> > smaller change, I just hope it won't have any drawback.
> 
> I'm in fact not familiar with any Atmel SoC.

Again, AT24* are EEPROMs, not SoCs.

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH 06/27] misc: eeprom: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

Hello Jean,

On 08/04/2015 09:19 AM, Jean Delvare wrote:
> On Mon, 3 Aug 2015 21:12:39 +0200, Javier Martinez Canillas wrote:
>> On 08/03/2015 06:50 PM, Jean Delvare wrote:
>>> Yes, the long-term plan is to get rid of the legacy eeprom driver. But
>>> we need a transition path for users. Either the at24 driver should be
>>> able to instantiate SPD and EDID devices as the eeprom driver does, or
>>> we need a user-space helper to do that kind of detection, so that
>>> consumer scripts such as decode-dimms keep working. The former is a
>>> smaller change, I just hope it won't have any drawback.
>>
>> I'm in fact not familiar with any Atmel SoC.
> 
> Again, AT24* are EEPROMs, not SoCs.
>

Oh, sorry I misunderstood. Thanks a lot for the clarification.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH 07/27] Input: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/input/misc/gp2ap002a00f.c  | 1 +
 drivers/input/touchscreen/goodix.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/input/misc/gp2ap002a00f.c b/drivers/input/misc/gp2ap002a00f.c
index ba301af91b95..3bfdfcc20485 100644
--- a/drivers/input/misc/gp2ap002a00f.c
+++ b/drivers/input/misc/gp2ap002a00f.c
@@ -267,6 +267,7 @@ static const struct i2c_device_id gp2a_i2c_id[] = {
 	{ GP2A_I2C_NAME, 0 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, gp2a_i2c_id);
 
 static struct i2c_driver gp2a_i2c_driver = {
 	.driver = {
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index 19c792ee4dfa..4d113c9e4b77 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -420,6 +420,7 @@ static const struct i2c_device_id goodix_ts_id[] = {
 	{ "GDIX1001:00", 0 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, goodix_ts_id);
 
 #ifdef CONFIG_ACPI
 static const struct acpi_device_id goodix_acpi_match[] = {
-- 
2.4.3

Re: [PATCH 07/27] Input: Export I2C module alias information in missing drivers

[Dmitry Torokhov]

On Thu, Jul 30, 2015 at 06:18:32PM +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Applied, thank you.

> 
> ---
> 
>  drivers/input/misc/gp2ap002a00f.c  | 1 +
>  drivers/input/touchscreen/goodix.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/input/misc/gp2ap002a00f.c b/drivers/input/misc/gp2ap002a00f.c
> index ba301af91b95..3bfdfcc20485 100644
> --- a/drivers/input/misc/gp2ap002a00f.c
> +++ b/drivers/input/misc/gp2ap002a00f.c
> @@ -267,6 +267,7 @@ static const struct i2c_device_id gp2a_i2c_id[] = {
>  	{ GP2A_I2C_NAME, 0 },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(i2c, gp2a_i2c_id);
>  
>  static struct i2c_driver gp2a_i2c_driver = {
>  	.driver = {
> diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
> index 19c792ee4dfa..4d113c9e4b77 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -420,6 +420,7 @@ static const struct i2c_device_id goodix_ts_id[] = {
>  	{ "GDIX1001:00", 0 },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(i2c, goodix_ts_id);
>  
>  #ifdef CONFIG_ACPI
>  static const struct acpi_device_id goodix_acpi_match[] = {
> -- 
> 2.4.3
> 

-- 
Dmitry

[PATCH 08/27] power: Export I2C module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/power/bq24190_charger.c | 1 +
 drivers/power/rt5033_battery.c  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c
index 703ebecaf38b..bb6d85bd6e56 100644
--- a/drivers/power/bq24190_charger.c
+++ b/drivers/power/bq24190_charger.c
@@ -1515,6 +1515,7 @@ static const struct i2c_device_id bq24190_i2c_ids[] = {
 	{ "bq24190", BQ24190_REG_VPRS_PN_24190 },
 	{ },
 };
+MODULE_DEVICE_TABLE(i2c, bq24190_i2c_ids);
 
 #ifdef CONFIG_OF
 static const struct of_device_id bq24190_of_match[] = {
diff --git a/drivers/power/rt5033_battery.c b/drivers/power/rt5033_battery.c
index a7a6877b4e16..bcdd83048492 100644
--- a/drivers/power/rt5033_battery.c
+++ b/drivers/power/rt5033_battery.c
@@ -165,7 +165,7 @@ static const struct i2c_device_id rt5033_battery_id[] = {
 	{ "rt5033-battery", },
 	{ }
 };
-MODULE_DEVICE_TABLE(platform, rt5033_battery_id);
+MODULE_DEVICE_TABLE(i2c, rt5033_battery_id);
 
 static struct i2c_driver rt5033_battery_driver = {
 	.driver = {
-- 
2.4.3

Re: [PATCH 08/27] power: Export I2C module alias information in missing drivers

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

Hi,

On Thu, Jul 30, 2015 at 06:18:33PM +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.

Thanks, queued.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 09/27] i2c: core: Export I2C module alias information in dummy driver

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/i2c/i2c-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index e6d4935161e4..92dddfeb3f39 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1023,6 +1023,7 @@ static const struct i2c_device_id dummy_id[] = {
 	{ "dummy", 0 },
 	{ },
 };
+MODULE_DEVICE_TABLE(i2c, dummy_id);
 
 static int dummy_probe(struct i2c_client *client,
 		       const struct i2c_device_id *id)
-- 
2.4.3

[PATCH 10/27] backlight: tosa: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/video/backlight/tosa_bl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/backlight/tosa_bl.c b/drivers/video/backlight/tosa_bl.c
index 3ad676558c80..83742d806391 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -158,6 +158,7 @@ static const struct i2c_device_id tosa_bl_id[] = {
 	{ "tosa-bl", 0 },
 	{ },
 };
+MODULE_DEVICE_TABLE(i2c, tosa_bl_id);
 
 static struct i2c_driver tosa_bl_driver = {
 	.driver = {
-- 
2.4.3

[PATCH 11/27] [media] staging: media: lirc: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/staging/media/lirc/lirc_zilog.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c
index 261e27d6b054..bebfc3b093bc 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -1364,6 +1364,7 @@ static const struct i2c_device_id ir_transceiver_id[] = {
 	{ "ir_rx_z8f0811_hdpvr", ID_FLAG_HDPVR              },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, ir_transceiver_id);
 
 static struct i2c_driver driver = {
 	.driver = {
-- 
2.4.3

[PATCH 12/27] usb: phy: isp1301: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/usb/phy/phy-isp1301.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 8a55b37d1a02..db68156568e6 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
@@ -31,6 +31,7 @@ static const struct i2c_device_id isp1301_id[] = {
 	{ "isp1301", 0 },
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, isp1301_id);
 
 static struct i2c_client *isp1301_i2c_client;
 
-- 
2.4.3

[PATCH 13/27] ALSA: ppc: keywest: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 sound/ppc/keywest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 6120a067494a..f644a8c57e0a 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -101,6 +101,7 @@ static const struct i2c_device_id keywest_i2c_id[] = {
 	{ "keywest", 0 },		/* instantiated by us if needed */
 	{ }
 };
+MODULE_DEVICE_TABLE(i2c, keywest_i2c_id);
 
 static struct i2c_driver keywest_driver = {
 	.driver = {
-- 
2.4.3

[PATCH 14/27] hwmon: (nct7904) Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/hwmon/nct7904.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
index 6153df735e82..08ff89d222e5 100644
--- a/drivers/hwmon/nct7904.c
+++ b/drivers/hwmon/nct7904.c
@@ -575,6 +575,7 @@ static const struct i2c_device_id nct7904_id[] = {
 	{"nct7904", 0},
 	{}
 };
+MODULE_DEVICE_TABLE(i2c, nct7904_id);
 
 static struct i2c_driver nct7904_driver = {
 	.class = I2C_CLASS_HWMON,
-- 
2.4.3

Re: [lm-sensors] [PATCH 14/27] hwmon: (nct7904) Export I2C module alias information

[Guenter Roeck]

On 07/30/2015 09:18 AM, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Applied.

Thanks,
Guenter

[PATCH 15/27] regulator: fan53555: Export I2C module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/regulator/fan53555.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/fan53555.c b/drivers/regulator/fan53555.c
index 42865681c00b..4940e8287df6 100644
--- a/drivers/regulator/fan53555.c
+++ b/drivers/regulator/fan53555.c
@@ -439,6 +439,7 @@ static const struct i2c_device_id fan53555_id[] = {
 	},
 	{ },
 };
+MODULE_DEVICE_TABLE(i2c, fan53555_id);
 
 static struct i2c_driver fan53555_regulator_driver = {
 	.driver = {
-- 
2.4.3

Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias information

[Paul Bolle]

Hi Javier,

(Mark already applied this patch. Still, I couldn't wrap my head around
it. So maybe you'd still like to answer a question or two, basically to
educate me.)

On do, 2015-07-30 at 18:18 +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table.

It's the other way round, I think.

Both MODULE_DEVICE_TABLE() macros add a set of aliases to this module.
These aliases are used by userspace to load the fan53555 module if it
notices a uevent that contains the proper "MODALIAS=" string. Only after
this module is loaded by userspace will the I2C id_table and the
of_match_table be available to match this driver to the hardware found
in the machine and, if matching hardware is found, call
 fan53555_regulator_probe() to get this module to actually do something.

That being said, before this patch the fan53555 module contained these
aliases:
    alias:          of:N*T*Csilergy,syr828*
    alias:          of:N*T*Csilergy,syr827*
    alias:          of:N*T*Cfcs,fan53555*

While this patch ad these two aliases:
    alias:          i2c:syr82x
    alias:          i2c:fan53555

Now I don't have an "of" or "i2c" capable machine at hand, which makes
it a bit hard to figure out how all of this is supposed to fit together.
But I'm guessing that parsing a device tree blob that contains strings
like
    compatible = "silergy,syr828"

would add strings like
    MODALIAS=of:N[...]T[...]Csilergy,syr828

to the related uevents. (Likewise for the two other aliases.) Doesn't
that happen here?

> So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.

s/the correct module/this module/, right?

> --- a/drivers/regulator/fan53555.c
> +++ b/drivers/regulator/fan53555.c

> +MODULE_DEVICE_TABLE(i2c, fan53555_id);

As I said above this patch adds two aliases to the fan53555 module:
    alias:          i2c:syr82x
    alias:          i2c:fan53555

But neither the string "fan53555" nor the string "syr82x" generate
interesting hits in current linux-next. Are these strings perhaps only
used in out of tree device tree source files?

Thanks,


Paul Bolle

Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias information

[Javier Martinez Canillas]

Hello Paul,

Thanks a lot for the feedback.

On 08/03/2015 01:43 PM, Paul Bolle wrote:
> Hi Javier,
> 
> (Mark already applied this patch. Still, I couldn't wrap my head around
> it. So maybe you'd still like to answer a question or two, basically to
> educate me.)
> 
> On do, 2015-07-30 at 18:18 +0200, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
>> regardless if the driver was matched using the I2C id_table or the
>> of_match_table.
> 
> It's the other way round, I think.
>
> Both MODULE_DEVICE_TABLE() macros add a set of aliases to this module.
> These aliases are used by userspace to load the fan53555 module if it
> notices a uevent that contains the proper "MODALIAS=" string. Only after
> this module is loaded by userspace will the I2C id_table and the
> of_match_table be available to match this driver to the hardware found

You are right on that but...

> in the machine and, if matching hardware is found, call
>  fan53555_regulator_probe() to get this module to actually do something.
> 

...I2C is a little special in that it uses the id_table again to match
in i2c_device_probe() and pass a i2c_device_id to the I2C driver's probe
function. That is what I meant by matching but maybe I could had been more
precise.

> That being said, before this patch the fan53555 module contained these
> aliases:
>     alias:          of:N*T*Csilergy,syr828*
>     alias:          of:N*T*Csilergy,syr827*
>     alias:          of:N*T*Cfcs,fan53555*
> 
> While this patch ad these two aliases:
>     alias:          i2c:syr82x
>     alias:          i2c:fan53555
> 
> Now I don't have an "of" or "i2c" capable machine at hand, which makes
> it a bit hard to figure out how all of this is supposed to fit together.
> But I'm guessing that parsing a device tree blob that contains strings
> like
>     compatible = "silergy,syr828"
> 
> would add strings like
>     MODALIAS=of:N[...]T[...]Csilergy,syr828
>

That would be the correct behavior and is what the RFC patch #27 does.
 
> to the related uevents. (Likewise for the two other aliases.) Doesn't
> that happen here?
>

No, that is exactly the problem. Take a look to i2c_device_uevent() [0],
it just does:

add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name))

So if you have a i2c_device_id table but no MODULE_DEVICE_TABLE(i2c,...),
then module autoload won't work.

>> So the driver needs to export the I2C table and this
>> be built into the module or udev won't have the necessary information
>> to auto load the correct module when the device is added.
> 
> s/the correct module/this module/, right?
>

I don't think it's a big difference in semantics but probably yes.
 
>> --- a/drivers/regulator/fan53555.c
>> +++ b/drivers/regulator/fan53555.c
> 
>> +MODULE_DEVICE_TABLE(i2c, fan53555_id);
> 
> As I said above this patch adds two aliases to the fan53555 module:
>     alias:          i2c:syr82x
>     alias:          i2c:fan53555
> 
> But neither the string "fan53555" nor the string "syr82x" generate
> interesting hits in current linux-next. Are these strings perhaps only
> used in out of tree device tree source files?
> 

There are a lot of drivers whose platform code has not been upstreamed
so I haven't checked which ones are used an which ones are not.

But if someone is using this driver and registering a I2C device either
via board code or a Device Tree, it will break as soon as someone builds
it as a module without this patch.

> Thanks,
> 
> 
> Paul Bolle
> 

[0]: http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L483

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias information

[Paul Bolle]

Hi Javier,

On ma, 2015-08-03 at 16:29 +0200, Javier Martinez Canillas wrote:
> On 08/03/2015 01:43 PM, Paul Bolle wrote:
> > On do, 2015-07-30 at 18:18 +0200, Javier Martinez Canillas wrote:

> I2C is a little special in that it uses the id_table again to match
> in i2c_device_probe() and pass a i2c_device_id to the I2C driver's probe
> function. That is what I meant by matching but maybe I could had been more
> precise.

(So is what I2C currently does comparable to what, say, USB does (ie,
using usb_device_id for the match and also passing it to the driver's
probe function) or is it more complicated?)

> > But I'm guessing that parsing a device tree blob that contains
> > strings like
> >     compatible = "silergy,syr828"
> > 
> > would add strings like
> >     MODALIAS=of:N[...]T[...]Csilergy,syr828
>
> That would be the correct behavior and is what the RFC patch #27 does.
>  
> > to the related uevents. (Likewise for the two other aliases.) Doesn't
> > that happen here?
>
> No, that is exactly the problem.

Which also explains how these
   MODULE_DEVICE_TABLE(of, ...);

lines, which have no effect for the drivers at hand, added to my confusion.

> Take a look to i2c_device_uevent() [0],
> it just does:
> 
> add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name))
> 
> So if you have a i2c_device_id table but no 
> MODULE_DEVICE_TABLE(i2c,...),
> then module autoload won't work.

Thanks for taking the time to explain all this to me.


Paul Bolle

Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias information

[Javier Martinez Canillas]

Hello Paul,

On 08/04/2015 12:08 PM, Paul Bolle wrote:
> Hi Javier,
> 
> On ma, 2015-08-03 at 16:29 +0200, Javier Martinez Canillas wrote:
>> On 08/03/2015 01:43 PM, Paul Bolle wrote:
>>> On do, 2015-07-30 at 18:18 +0200, Javier Martinez Canillas wrote:
> 
>> I2C is a little special in that it uses the id_table again to match
>> in i2c_device_probe() and pass a i2c_device_id to the I2C driver's probe
>> function. That is what I meant by matching but maybe I could had been more
>> precise.
> 
> (So is what I2C currently does comparable to what, say, USB does (ie,
> using usb_device_id for the match and also passing it to the driver's
> probe function) or is it more complicated?)
>

Yes, is similar to what USB does. Now the difference is that USB is an
enumerable bus so you have a single id_table in USB drivers. But I2C
is not an enumerable bus so you need a i2c_device_id table and in the
case of Device Trees, also a of_device_id table.

So USB does the same but has it easy since the match is by USB idVendor,
idProduct, etc while I2C could need both the I2C and OF tables.

Currently for OF, I2C core uses the OF table in i2c_device_match() when
calling of_driver_match_device() and the I2C table in i2c_device_probe()
when calling i2c_match_id().

That's one of the reasons why OF only drivers needs an I2C table. The
other reason is due MODALIAS=i2c:<foo> uevents always been reported.

To make even more complicated, the struct i2c_device_id has a kernel_ulong_t
to store the driver data while the struct of_device_id has a const void * so
some casting would be necessary if the OF table is also used on probe in
the future to avoid the need of an I2C table in OF only drivers.
 
>>> But I'm guessing that parsing a device tree blob that contains
>>> strings like
>>>     compatible = "silergy,syr828"
>>>
>>> would add strings like
>>>     MODALIAS=of:N[...]T[...]Csilergy,syr828
>>
>> That would be the correct behavior and is what the RFC patch #27 does.
>>  
>>> to the related uevents. (Likewise for the two other aliases.) Doesn't
>>> that happen here?
>>
>> No, that is exactly the problem.
> 
> Which also explains how these
>    MODULE_DEVICE_TABLE(of, ...);
> 
> lines, which have no effect for the drivers at hand, added to my confusion.
>

Yes, it is confusing indeed and even more since this series are adding these
for the missing drivers. But the rationale for that is that once all drivers
have a proper MODULE_DEVICE_TABLE({i2c,of},...) then the I2C core can be
changed to report a proper MODALIAS=of:N*T*C* uevent.

>> Take a look to i2c_device_uevent() [0],
>> it just does:
>>
>> add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name))
>>
>> So if you have a i2c_device_id table but no 
>> MODULE_DEVICE_TABLE(i2c,...),
>> then module autoload won't work.
> 
> Thanks for taking the time to explain all this to me.
>

You are welcome and thanks a lot for the interest in the series
and feedback.

> 
> Paul Bolle
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias information

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Mon, Aug 03, 2015 at 01:43:38PM +0200, Paul Bolle wrote:

> That being said, before this patch the fan53555 module contained these
> aliases:
>     alias:          of:N*T*Csilergy,syr828*
>     alias:          of:N*T*Csilergy,syr827*
>     alias:          of:N*T*Cfcs,fan53555*

> While this patch ad these two aliases:
>     alias:          i2c:syr82x
>     alias:          i2c:fan53555

> Now I don't have an "of" or "i2c" capable machine at hand, which makes
> it a bit hard to figure out how all of this is supposed to fit together.
> But I'm guessing that parsing a device tree blob that contains strings
> like

The DT and I2C namespaces are intended to be completely unrelated to
each other, both are needed in different systems.

> But neither the string "fan53555" nor the string "syr82x" generate
> interesting hits in current linux-next. Are these strings perhaps only
> used in out of tree device tree source files?

Please stop going on about this, as has previously been discussed we do
*NOT* require board files, device tree files or any other kind of board
description to be included in mainline.  There is no expectation that we
will see anything instantiating any particular device included in the
kernel source, and in some cases such as ACPI this never happens at all.

I'm not sure how this can be made any clearer.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH 16/27] mfd: Export OF module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/mfd/rt5033.c   | 1 +
 drivers/mfd/tps65217.c | 1 +
 drivers/mfd/tps65218.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index db395a6c52bc..d60f91619c4a 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -124,6 +124,7 @@ static const struct of_device_id rt5033_dt_match[] = {
 	{ .compatible = "richtek,rt5033", },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, rt5033_dt_match);
 
 static struct i2c_driver rt5033_driver = {
 	.driver = {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index bc455feb42be..55add0453ae9 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -156,6 +156,7 @@ static const struct of_device_id tps65217_of_match[] = {
 	{ .compatible = "ti,tps65217", .data = (void *)TPS65217 },
 	{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, tps65217_of_match);
 
 static int tps65217_probe(struct i2c_client *client,
 				const struct i2c_device_id *ids)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index cb38d725250f..80b9dc363cd8 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -211,6 +211,7 @@ static const struct of_device_id of_tps65218_match_table[] = {
 	{ .compatible = "ti,tps65218", },
 	{}
 };
+MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
 
 static int tps65218_probe(struct i2c_client *client,
 				const struct i2c_device_id *ids)
-- 
2.4.3

Re: [PATCH 16/27] mfd: Export OF module alias information in missing drivers

[Lee Jones]

On Thu, 30 Jul 2015, Javier Martinez Canillas wrote:

> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
> 
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
> 
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
> 
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> 
> ---
> 
>  drivers/mfd/rt5033.c   | 1 +
>  drivers/mfd/tps65217.c | 1 +
>  drivers/mfd/tps65218.c | 1 +
>  3 files changed, 3 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> index db395a6c52bc..d60f91619c4a 100644
> --- a/drivers/mfd/rt5033.c
> +++ b/drivers/mfd/rt5033.c
> @@ -124,6 +124,7 @@ static const struct of_device_id rt5033_dt_match[] = {
>  	{ .compatible = "richtek,rt5033", },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(of, rt5033_dt_match);
>  
>  static struct i2c_driver rt5033_driver = {
>  	.driver = {
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index bc455feb42be..55add0453ae9 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -156,6 +156,7 @@ static const struct of_device_id tps65217_of_match[] = {
>  	{ .compatible = "ti,tps65217", .data = (void *)TPS65217 },
>  	{ /* sentinel */ },
>  };
> +MODULE_DEVICE_TABLE(of, tps65217_of_match);
>  
>  static int tps65217_probe(struct i2c_client *client,
>  				const struct i2c_device_id *ids)
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index cb38d725250f..80b9dc363cd8 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -211,6 +211,7 @@ static const struct of_device_id of_tps65218_match_table[] = {
>  	{ .compatible = "ti,tps65218", },
>  	{}
>  };
> +MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
>  
>  static int tps65218_probe(struct i2c_client *client,
>  				const struct i2c_device_id *ids)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 17/27] iio: Export OF module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/iio/accel/mma8452.c      | 1 +
 drivers/iio/light/cm32181.c      | 1 +
 drivers/iio/light/cm3232.c       | 1 +
 drivers/iio/light/cm36651.c      | 1 +
 drivers/iio/light/gp2ap020a00f.c | 1 +
 5 files changed, 5 insertions(+)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 13ea1ea23328..b7ad3dce6ff4 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -968,6 +968,7 @@ static const struct of_device_id mma8452_dt_ids[] = {
 	{ .compatible = "fsl,mma8452" },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, mma8452_dt_ids);
 
 static struct i2c_driver mma8452_driver = {
 	.driver = {
diff --git a/drivers/iio/light/cm32181.c b/drivers/iio/light/cm32181.c
index 1c0de2f8885d..d6fd0dace74f 100644
--- a/drivers/iio/light/cm32181.c
+++ b/drivers/iio/light/cm32181.c
@@ -353,6 +353,7 @@ static const struct of_device_id cm32181_of_match[] = {
 	{ .compatible = "capella,cm32181" },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, cm32181_of_match);
 
 static struct i2c_driver cm32181_driver = {
 	.driver = {
diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c
index 1b508c65877c..fe89b6823217 100644
--- a/drivers/iio/light/cm3232.c
+++ b/drivers/iio/light/cm3232.c
@@ -417,6 +417,7 @@ static const struct of_device_id cm3232_of_match[] = {
 	{.compatible = "capella,cm3232"},
 	{}
 };
+MODULE_DEVICE_TABLE(of, cm3232_of_match);
 
 static struct i2c_driver cm3232_driver = {
 	.driver = {
diff --git a/drivers/iio/light/cm36651.c b/drivers/iio/light/cm36651.c
index 2a39e141e90c..c8d7b5ea7e78 100644
--- a/drivers/iio/light/cm36651.c
+++ b/drivers/iio/light/cm36651.c
@@ -731,6 +731,7 @@ static const struct of_device_id cm36651_of_match[] = {
 	{ .compatible = "capella,cm36651" },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, cm36651_of_match);
 
 static struct i2c_driver cm36651_driver = {
 	.driver = {
diff --git a/drivers/iio/light/gp2ap020a00f.c b/drivers/iio/light/gp2ap020a00f.c
index 0334a814b5eb..6d41086f7c64 100644
--- a/drivers/iio/light/gp2ap020a00f.c
+++ b/drivers/iio/light/gp2ap020a00f.c
@@ -1634,6 +1634,7 @@ static const struct of_device_id gp2ap020a00f_of_match[] = {
 	{ .compatible = "sharp,gp2ap020a00f" },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, gp2ap020a00f_of_match);
 #endif
 
 static struct i2c_driver gp2ap020a00f_driver = {
-- 
2.4.3

Re: [PATCH 17/27] iio: Export OF module alias information in missing drivers

[Jonathan Cameron]

On 30/07/15 17:18, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
> 
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
> 
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
> 
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it,

Thanks

Jonathan
> 
> ---
> 
>  drivers/iio/accel/mma8452.c      | 1 +
>  drivers/iio/light/cm32181.c      | 1 +
>  drivers/iio/light/cm3232.c       | 1 +
>  drivers/iio/light/cm36651.c      | 1 +
>  drivers/iio/light/gp2ap020a00f.c | 1 +
>  5 files changed, 5 insertions(+)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 13ea1ea23328..b7ad3dce6ff4 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -968,6 +968,7 @@ static const struct of_device_id mma8452_dt_ids[] = {
>  	{ .compatible = "fsl,mma8452" },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(of, mma8452_dt_ids);
>  
>  static struct i2c_driver mma8452_driver = {
>  	.driver = {
> diff --git a/drivers/iio/light/cm32181.c b/drivers/iio/light/cm32181.c
> index 1c0de2f8885d..d6fd0dace74f 100644
> --- a/drivers/iio/light/cm32181.c
> +++ b/drivers/iio/light/cm32181.c
> @@ -353,6 +353,7 @@ static const struct of_device_id cm32181_of_match[] = {
>  	{ .compatible = "capella,cm32181" },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(of, cm32181_of_match);
>  
>  static struct i2c_driver cm32181_driver = {
>  	.driver = {
> diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c
> index 1b508c65877c..fe89b6823217 100644
> --- a/drivers/iio/light/cm3232.c
> +++ b/drivers/iio/light/cm3232.c
> @@ -417,6 +417,7 @@ static const struct of_device_id cm3232_of_match[] = {
>  	{.compatible = "capella,cm3232"},
>  	{}
>  };
> +MODULE_DEVICE_TABLE(of, cm3232_of_match);
>  
>  static struct i2c_driver cm3232_driver = {
>  	.driver = {
> diff --git a/drivers/iio/light/cm36651.c b/drivers/iio/light/cm36651.c
> index 2a39e141e90c..c8d7b5ea7e78 100644
> --- a/drivers/iio/light/cm36651.c
> +++ b/drivers/iio/light/cm36651.c
> @@ -731,6 +731,7 @@ static const struct of_device_id cm36651_of_match[] = {
>  	{ .compatible = "capella,cm36651" },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(of, cm36651_of_match);
>  
>  static struct i2c_driver cm36651_driver = {
>  	.driver = {
> diff --git a/drivers/iio/light/gp2ap020a00f.c b/drivers/iio/light/gp2ap020a00f.c
> index 0334a814b5eb..6d41086f7c64 100644
> --- a/drivers/iio/light/gp2ap020a00f.c
> +++ b/drivers/iio/light/gp2ap020a00f.c
> @@ -1634,6 +1634,7 @@ static const struct of_device_id gp2ap020a00f_of_match[] = {
>  	{ .compatible = "sharp,gp2ap020a00f" },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(of, gp2ap020a00f_of_match);
>  #endif
>  
>  static struct i2c_driver gp2ap020a00f_driver = {
> 

[PATCH 18/27] hwmon: (g762) Export OF module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/hwmon/g762.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
index 3d845947f584..b96a2a9e4df7 100644
--- a/drivers/hwmon/g762.c
+++ b/drivers/hwmon/g762.c
@@ -582,6 +582,7 @@ static const struct of_device_id g762_dt_match[] = {
 	{ .compatible = "gmt,g763" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, g762_dt_match);
 
 /*
  * Grab clock (a required property), enable it, get (fixed) clock frequency
-- 
2.4.3

Re: [PATCH 18/27] hwmon: (g762) Export OF module alias information

[Guenter Roeck]

On 07/30/2015 09:18 AM, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
>
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
>
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
>
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>

Applied.

Thanks,
Guenter

[PATCH 19/27] extcon: Export OF module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/extcon/extcon-rt8973a.c | 1 +
 drivers/extcon/extcon-sm5502.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 11592e980bc1..3428b6aae1a2 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -658,6 +658,7 @@ static const struct of_device_id rt8973a_dt_match[] = {
 	{ .compatible = "richtek,rt8973a-muic" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, rt8973a_dt_match);
 
 #ifdef CONFIG_PM_SLEEP
 static int rt8973a_muic_suspend(struct device *dev)
diff --git a/drivers/extcon/extcon-sm5502.c b/drivers/extcon/extcon-sm5502.c
index 0ffefefa2e26..92ae48415fb2 100644
--- a/drivers/extcon/extcon-sm5502.c
+++ b/drivers/extcon/extcon-sm5502.c
@@ -650,6 +650,7 @@ static const struct of_device_id sm5502_dt_match[] = {
 	{ .compatible = "siliconmitus,sm5502-muic" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, sm5502_dt_match);
 
 #ifdef CONFIG_PM_SLEEP
 static int sm5502_muic_suspend(struct device *dev)
-- 
2.4.3

[PATCH 20/27] ASoC: Export OF module alias information in missing codec drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 sound/soc/codecs/da9055.c | 1 +
 sound/soc/codecs/wm8510.c | 1 +
 sound/soc/codecs/wm8523.c | 1 +
 sound/soc/codecs/wm8580.c | 1 +
 4 files changed, 4 insertions(+)

diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c
index 04c76f37e1fd..19635d830b47 100644
--- a/sound/soc/codecs/da9055.c
+++ b/sound/soc/codecs/da9055.c
@@ -1533,6 +1533,7 @@ static const struct of_device_id da9055_of_match[] = {
 	{ .compatible = "dlg,da9055-codec", },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, da9055_of_match);
 
 /* I2C codec control layer */
 static struct i2c_driver da9055_i2c_driver = {
diff --git a/sound/soc/codecs/wm8510.c b/sound/soc/codecs/wm8510.c
index 3cff5a699e57..b098a83a44d8 100644
--- a/sound/soc/codecs/wm8510.c
+++ b/sound/soc/codecs/wm8510.c
@@ -598,6 +598,7 @@ static const struct of_device_id wm8510_of_match[] = {
 	{ .compatible = "wlf,wm8510" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, wm8510_of_match);
 
 static const struct regmap_config wm8510_regmap = {
 	.reg_bits = 7,
diff --git a/sound/soc/codecs/wm8523.c b/sound/soc/codecs/wm8523.c
index 5f8fde56e68b..aa287a3965e7 100644
--- a/sound/soc/codecs/wm8523.c
+++ b/sound/soc/codecs/wm8523.c
@@ -430,6 +430,7 @@ static const struct of_device_id wm8523_of_match[] = {
 	{ .compatible = "wlf,wm8523" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, wm8523_of_match);
 
 static const struct regmap_config wm8523_regmap = {
 	.reg_bits = 8,
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c
index abf60355f7f7..66602bf02f6e 100644
--- a/sound/soc/codecs/wm8580.c
+++ b/sound/soc/codecs/wm8580.c
@@ -916,6 +916,7 @@ static const struct of_device_id wm8580_of_match[] = {
 	{ .compatible = "wlf,wm8580" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, wm8580_of_match);
 
 static const struct regmap_config wm8580_regmap = {
 	.reg_bits = 7,
-- 
2.4.3

[PATCH 21/27] rtc: Export OF module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/rtc/rtc-ab-b5ze-s3.c | 1 +
 drivers/rtc/rtc-isl12022.c   | 1 +
 drivers/rtc/rtc-isl12057.c   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index 0fb1d767afa9..a319bf1e49de 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -1009,6 +1009,7 @@ static const struct of_device_id abb5zes3_dt_match[] = {
 	{ .compatible = "abracon,abb5zes3" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, abb5zes3_dt_match);
 #endif
 
 static const struct i2c_device_id abb5zes3_id[] = {
diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c
index 372627136786..839d1fd63cd7 100644
--- a/drivers/rtc/rtc-isl12022.c
+++ b/drivers/rtc/rtc-isl12022.c
@@ -274,6 +274,7 @@ static const struct of_device_id isl12022_dt_match[] = {
 	{ .compatible = "isil,isl12022" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, isl12022_dt_match);
 #endif
 
 static const struct i2c_device_id isl12022_id[] = {
diff --git a/drivers/rtc/rtc-isl12057.c b/drivers/rtc/rtc-isl12057.c
index ee3e8dbcacaf..a0462e5430c7 100644
--- a/drivers/rtc/rtc-isl12057.c
+++ b/drivers/rtc/rtc-isl12057.c
@@ -648,6 +648,7 @@ static const struct of_device_id isl12057_dt_match[] = {
 	{ .compatible = "isil,isl12057" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, isl12057_dt_match);
 #endif
 
 static const struct i2c_device_id isl12057_id[] = {
-- 
2.4.3

Re: [PATCH 21/27] rtc: Export OF module alias information in missing drivers

[Alexandre Belloni]

On 30/07/2015 at 18:18:46 +0200, Javier Martinez Canillas wrote :
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
> 
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
> 
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
> 
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 22/27] macintosh: therm_windtunnel: Export OF module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/macintosh/therm_windtunnel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/therm_windtunnel.c b/drivers/macintosh/therm_windtunnel.c
index 97269567ec01..68dcbcb4fc5b 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -460,6 +460,7 @@ static const struct of_device_id therm_of_match[] = {{
 	.compatible	= "adm1030"
     }, {}
 };
+MODULE_DEVICE_TABLE(of, therm_of_match);
 
 static struct platform_driver therm_of_driver = {
 	.driver = {
-- 
2.4.3

Re: [22/27] macintosh: therm_windtunnel: Export OF module alias information

[Michael Ellerman]

On Thu, 2015-30-07 at 16:18:47 UTC, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
> 
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
> 
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
> 
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a1a42b7920ba57f287d7

cheers

[PATCH 23/27] leds: Export OF module alias information in missing drivers

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/leds/leds-pca963x.c | 1 +
 drivers/leds/leds-tca6507.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
index 3f63a1bfdc4f..41f269fe0920 100644
--- a/drivers/leds/leds-pca963x.c
+++ b/drivers/leds/leds-pca963x.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_pca963x_match[] = {
 	{ .compatible = "nxp,pca9635", },
 	{},
 };
+MODULE_DEVICE_TABLE(of, of_pca963x_match);
 #else
 static struct pca963x_platform_data *
 pca963x_dt_init(struct i2c_client *client, struct pca963x_chipdef *chip)
diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c
index c1f910981781..edbecc4ca2da 100644
--- a/drivers/leds/leds-tca6507.c
+++ b/drivers/leds/leds-tca6507.c
@@ -735,6 +735,7 @@ static const struct of_device_id of_tca6507_leds_match[] = {
 	{ .compatible = "ti,tca6507", },
 	{},
 };
+MODULE_DEVICE_TABLE(of, of_tca6507_leds_match);
 
 #else
 static struct tca6507_platform_data *
-- 
2.4.3

Re: [PATCH 23/27] leds: Export OF module alias information in missing drivers

[Jacek Anaszewski]

Hi Javier,

Thanks for the patch.

On 07/30/2015 06:18 PM, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
>
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
>
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
>
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
>   drivers/leds/leds-pca963x.c | 1 +
>   drivers/leds/leds-tca6507.c | 1 +
>   2 files changed, 2 insertions(+)
>
> diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
> index 3f63a1bfdc4f..41f269fe0920 100644
> --- a/drivers/leds/leds-pca963x.c
> +++ b/drivers/leds/leds-pca963x.c
> @@ -332,6 +332,7 @@ static const struct of_device_id of_pca963x_match[] = {
>   	{ .compatible = "nxp,pca9635", },
>   	{},
>   };
> +MODULE_DEVICE_TABLE(of, of_pca963x_match);
>   #else
>   static struct pca963x_platform_data *
>   pca963x_dt_init(struct i2c_client *client, struct pca963x_chipdef *chip)
> diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c
> index c1f910981781..edbecc4ca2da 100644
> --- a/drivers/leds/leds-tca6507.c
> +++ b/drivers/leds/leds-tca6507.c
> @@ -735,6 +735,7 @@ static const struct of_device_id of_tca6507_leds_match[] = {
>   	{ .compatible = "ti,tca6507", },
>   	{},
>   };
> +MODULE_DEVICE_TABLE(of, of_tca6507_leds_match);
>
>   #else
>   static struct tca6507_platform_data *
>

Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>

-- 
Best Regards,
Jacek Anaszewski

[PATCH 24/27] [media] smiapp: Export OF module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/media/i2c/smiapp/smiapp-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
index 636ebd6fe5dc..fb39dfd55e75 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -3131,6 +3131,7 @@ static const struct of_device_id smiapp_of_table[] = {
 	{ .compatible = "nokia,smia" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, smiapp_of_table);
 
 static const struct i2c_device_id smiapp_id_table[] = {
 	{ SMIAPP_NAME, 0 },
-- 
2.4.3

[PATCH 25/27] Input: touchscreen - Export OF module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/input/touchscreen/egalax_ts.c | 1 +
 drivers/input/touchscreen/mms114.c    | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/input/touchscreen/egalax_ts.c b/drivers/input/touchscreen/egalax_ts.c
index 7bce2d90ec74..1afc08b08155 100644
--- a/drivers/input/touchscreen/egalax_ts.c
+++ b/drivers/input/touchscreen/egalax_ts.c
@@ -264,6 +264,7 @@ static const struct of_device_id egalax_ts_dt_ids[] = {
 	{ .compatible = "eeti,egalax_ts" },
 	{ /* sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, egalax_ts_dt_ids);
 
 static struct i2c_driver egalax_ts_driver = {
 	.driver = {
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index 6b69f461733c..7cce87650fc8 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -572,6 +572,7 @@ static const struct of_device_id mms114_dt_match[] = {
 	{ .compatible = "melfas,mms114" },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, mms114_dt_match);
 #endif
 
 static struct i2c_driver mms114_driver = {
-- 
2.4.3

Re: [PATCH 25/27] Input: touchscreen - Export OF module alias information

[Dmitry Torokhov]

On Thu, Jul 30, 2015 at 06:18:50PM +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So technically there's no need for a driver to export
> the OF table since currently it's not used.
> 
> In fact, the I2C device ID table is mandatory for I2C drivers since
> a i2c_device_id is passed to the driver's probe function even if the
> I2C core used the OF table to match the driver.
> 
> And since the I2C core uses different tables, OF-only drivers needs to
> have duplicated data that has to be kept in sync and also the dev node
> compatible manufacturer prefix is stripped when reporting the MODALIAS.
> 
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an I2C device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table to prevent
> breaking module autoloading if that happens.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Applied, thank you.

> 
> ---
> 
>  drivers/input/touchscreen/egalax_ts.c | 1 +
>  drivers/input/touchscreen/mms114.c    | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/input/touchscreen/egalax_ts.c b/drivers/input/touchscreen/egalax_ts.c
> index 7bce2d90ec74..1afc08b08155 100644
> --- a/drivers/input/touchscreen/egalax_ts.c
> +++ b/drivers/input/touchscreen/egalax_ts.c
> @@ -264,6 +264,7 @@ static const struct of_device_id egalax_ts_dt_ids[] = {
>  	{ .compatible = "eeti,egalax_ts" },
>  	{ /* sentinel */ }
>  };
> +MODULE_DEVICE_TABLE(of, egalax_ts_dt_ids);
>  
>  static struct i2c_driver egalax_ts_driver = {
>  	.driver = {
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index 6b69f461733c..7cce87650fc8 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -572,6 +572,7 @@ static const struct of_device_id mms114_dt_match[] = {
>  	{ .compatible = "melfas,mms114" },
>  	{ }
>  };
> +MODULE_DEVICE_TABLE(of, mms114_dt_match);
>  #endif
>  
>  static struct i2c_driver mms114_driver = {
> -- 
> 2.4.3
> 

-- 
Dmitry

[PATCH 26/27] regulator: isl9305: Export OF module alias information

[Javier Martinez Canillas]

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 drivers/regulator/isl9305.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/isl9305.c b/drivers/regulator/isl9305.c
index eae9d1ffe641..257c1943e753 100644
--- a/drivers/regulator/isl9305.c
+++ b/drivers/regulator/isl9305.c
@@ -183,6 +183,7 @@ static const struct of_device_id isl9305_dt_ids[] = {
 	{ .compatible = "isil,isl9305h" },
 	{},
 };
+MODULE_DEVICE_TABLE(of, isl9305_dt_ids);
 #endif
 
 static const struct i2c_device_id isl9305_i2c_id[] = {
-- 
2.4.3

Applied "regulator: isl9305: Export OF module alias information" to the regulator tree

[Mark Brown]

The patch

   regulator: isl9305: Export OF module alias information

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5b87af4cca175c4f03f790f2b15be7e4dd436df9 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Tue, 25 Aug 2015 08:31:17 +0200
Subject: [PATCH] regulator: isl9305: Export OF module alias information

The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).

So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.

But this means that OF-only drivers needs to have both OF and I2C id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same I2C device name for example.

To avoid the above, the I2C core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/regulator/isl9305.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/isl9305.c b/drivers/regulator/isl9305.c
index 6e3a15fe00f1..e02e9a9dddbd 100644
--- a/drivers/regulator/isl9305.c
+++ b/drivers/regulator/isl9305.c
@@ -183,6 +183,7 @@ static const struct of_device_id isl9305_dt_ids[] = {
 	{ .compatible = "isil,isl9305h" },
 	{},
 };
+MODULE_DEVICE_TABLE(of, isl9305_dt_ids);
 #endif
 
 static const struct i2c_device_id isl9305_i2c_id[] = {
-- 
2.5.0

[PATCH 27/27] i2c: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas]

An I2C driver that supports both OF and legacy platforms, will have
both a OF and I2C ID table. This means that when built as a module,
the aliases will be filled from both tables but currently always an
alias of the form i2c:<deviceId> is reported, e.g:

$ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch

So if a device is probed by matching its compatible string, udev can
get a MODALIAS uevent env var that doesn't match with one of the valid
aliases so the module won't be auto-loaded.

This patch changes the I2C core to report a OF related MODALIAS uevent
(of:N*T*C) env var instead so the module can be auto-loaded and also
report the correct alias using sysfs:

$ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
of:NtrackpadT<NULL>Catmel,maxtouch

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>



---

 drivers/i2c/i2c-core.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 92dddfeb3f39..c0668c2ed9da 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -489,6 +489,10 @@ static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
 	struct i2c_client	*client = to_i2c_client(dev);
 	int rc;
 
+	rc = of_device_uevent_modalias(dev, env);
+	if (rc != -ENODEV)
+		return rc;
+
 	rc = acpi_device_uevent_modalias(dev, env);
 	if (rc != -ENODEV)
 		return rc;
@@ -726,6 +730,10 @@ show_modalias(struct device *dev, struct device_attribute *attr, char *buf)
 	struct i2c_client *client = to_i2c_client(dev);
 	int len;
 
+	len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
+	if (len != -ENODEV)
+		return len;
+
 	len = acpi_device_modalias(dev, buf, PAGE_SIZE -1);
 	if (len != -ENODEV)
 		return len;
-- 
2.4.3

Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers

[Dmitry Torokhov]

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...

Thanks.

-- 
Dmitry

Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers

[Dmitry Torokhov]

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
probably for SPI bus as well.

Thanks.

-- 
Dmitry

Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers

[Javier Martinez Canillas]

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