i2c: core: report OF style module alias for devices registered via OF

Message ID 20171203214050.11482-1-javierm@redhat.com
State Accepted
Headers show
Series
  • i2c: core: report OF style module alias for devices registered via OF
Related show

Commit Message

Javier Martinez Canillas Dec. 3, 2017, 9:40 p.m.
The buses should honor the firmware interface used to register the device,
but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C
devices registered via OF.

This means that user-space will never get an OF stype uevent MODALIAS even
when the drivers modules contain aliases exported from both the I2C and OF
device ID tables. For example, an Atmel maXTouch Touchscreen registered by
a DT node with compatible "atmel,maxtouch" has the following module alias:

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

So udev won't be able to auto-load a module for an OF-only device driver.
Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
table only has a workaround for how the I2C core reports the module alias.

This patch changes the I2C core to report an OF related MODALIAS uevent if
the device was registered via OF. So for the previous example, after this
patch, the reported MODALIAS for the Atmel maXTouch will be the following:

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

NOTE: This patch may break out-of-tree drivers that were relying on this
      behavior, and only had an I2C device ID table even when the device
      was registered via OF. There are no remaining drivers in mainline
      that do this, but out-of-tree drivers have to be fixed and define
      a proper OF device ID table to have module auto-loading working.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---

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

Comments

Javier Martinez Canillas Jan. 7, 2018, 1:17 p.m. | #1
Hello Wolfram,

On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The buses should honor the firmware interface used to register the device,
> but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C
> devices registered via OF.
>
> This means that user-space will never get an OF stype uevent MODALIAS even
> when the drivers modules contain aliases exported from both the I2C and OF
> device ID tables. For example, an Atmel maXTouch Touchscreen registered by
> a DT node with compatible "atmel,maxtouch" has the following module alias:
>
> $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> i2c:maxtouch
>
> So udev won't be able to auto-load a module for an OF-only device driver.
> Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
> table only has a workaround for how the I2C core reports the module alias.
>
> This patch changes the I2C core to report an OF related MODALIAS uevent if
> the device was registered via OF. So for the previous example, after this
> patch, the reported MODALIAS for the Atmel maXTouch will be the following:
>
> $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> of:NtrackpadT<NULL>Catmel,maxtouch
>
> NOTE: This patch may break out-of-tree drivers that were relying on this
>       behavior, and only had an I2C device ID table even when the device
>       was registered via OF. There are no remaining drivers in mainline
>       that do this, but out-of-tree drivers have to be fixed and define
>       a proper OF device ID table to have module auto-loading working.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> ---

Any comments on this patch?

Best regards,
Javier
Javier Martinez Canillas March 5, 2018, 11 a.m. | #2
Hello Wolfram,

On Sun, Jan 7, 2018 at 2:17 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
>
> On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> The buses should honor the firmware interface used to register the device,
>> but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C
>> devices registered via OF.
>>
>> This means that user-space will never get an OF stype uevent MODALIAS even
>> when the drivers modules contain aliases exported from both the I2C and OF
>> device ID tables. For example, an Atmel maXTouch Touchscreen registered by
>> a DT node with compatible "atmel,maxtouch" has the following module alias:
>>
>> $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
>> i2c:maxtouch
>>
>> So udev won't be able to auto-load a module for an OF-only device driver.
>> Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
>> table only has a workaround for how the I2C core reports the module alias.
>>
>> This patch changes the I2C core to report an OF related MODALIAS uevent if
>> the device was registered via OF. So for the previous example, after this
>> patch, the reported MODALIAS for the Atmel maXTouch will be the following:
>>
>> $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
>> of:NtrackpadT<NULL>Catmel,maxtouch
>>
>> NOTE: This patch may break out-of-tree drivers that were relying on this
>>       behavior, and only had an I2C device ID table even when the device
>>       was registered via OF. There are no remaining drivers in mainline
>>       that do this, but out-of-tree drivers have to be fixed and define
>>       a proper OF device ID table to have module auto-loading working.
>>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> ---
>
> Any comments on this patch?
>

Is this patch under your radar? Should I keep pushing for it or just give up?

Best regards,
Javier
Wolfram Sang March 5, 2018, 3:30 p.m. | #3
> Is this patch under your radar? Should I keep pushing for it or just give up?

Applied to for-next, thanks for your patience and your preparational
work needed to get this upstream!

We will see in linux-next if there slipped in some new drivers which
need fixing, but we have a full cycle to get them adapted.

And hopefully the benefits will shine through right away.

Thanks again!
Javier Martinez Canillas March 5, 2018, 5:09 p.m. | #4
On 03/05/2018 04:30 PM, Wolfram Sang wrote:
> 
>> Is this patch under your radar? Should I keep pushing for it or just give up?
> 
> Applied to for-next, thanks for your patience and your preparational
> work needed to get this upstream!
> 

Great, thanks a lot for your help!

> We will see in linux-next if there slipped in some new drivers which
> need fixing, but we have a full cycle to get them adapted.
>

Yes, I'll check tomorrow's linux-next to see if I can find these and
post patches for them.
 
> And hopefully the benefits will shine through right away.
> 
> Thanks again!
> 

Best regards,

Patch

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index bf52cca87363..1596aa718bc8 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -124,6 +124,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;
@@ -416,6 +420,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_modalias(dev, buf, PAGE_SIZE);
+	if (len != -ENODEV)
+		return len;
+
 	len = acpi_device_modalias(dev, buf, PAGE_SIZE -1);
 	if (len != -ENODEV)
 		return len;