RE: [PATCH V3] leds: pca955x: Add ACPI support for pca955x

[Phong Vo]

+-Original Message-
+From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
+Sent: Wednesday, November 30, 2016 4:00 PM
+To: Phong Vo
+Cc: Mika Westerberg; Rafael J. Wysocki; Richard Purdie; linux-
+l...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
+a...@vger.kernel.org; Loc Ho; Thang Nguyen; patches; Tin Huynh
+Subject: Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
+
+Hi Phong,
+
+On 11/30/2016 09:23 AM, Phong Vo wrote:
+> +-Original Message-
+> +From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
+> +Sent: Wednesday, November 30, 2016 3:18 PM
+> +To: Tin Huynh
+> +Cc: Mika Westerberg; Rafael J. Wysocki; Richard Purdie; linux-
+> +l...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
+> +a...@vger.kernel.org; Loc Ho; Thang Nguyen; Phong Vo; patches
+> +Subject: Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
+> +
+> +On 11/30/2016 09:06 AM, Tin Huynh wrote:
+> +> On Wed, Nov 30, 2016 at 3:01 PM, Jacek Anaszewski
+> +> <j.anaszew...@samsung.com> wrote:
+> +>>
+> +>> On 11/30/2016 08:51 AM, Jacek Anaszewski wrote:
+> +>>>
+> +>>> Hi Tin,
+> +>>>
+> +>>> How this patch is different from the one already merged?
+> +>>>
+> +>>> Best regards,
+> +>>> Jacek Anaszewski
+> +>>>
+>
+> Hi Jacek, I am answering on behalf of Tin.
+> This patch is for the leds:pca955x driver while the previous one was
+> for leds:pca963x driver!
+> They are almost the same in the coding construct, but different
+drivers.
+
+Ah, indeed, that's why I got lost with patch version numbering :-)
+
+> +>>> On 11/30/2016 04:08 AM, Tin Huynh wrote:
+> +>>>>
+> +>>>> This patch enables ACPI support for leds-pca955x driver.
+> +>>>>
+> +>>>> Signed-off-by: Tin Huynh <tnhu...@apm.com>
+> +>>>> ---
+> +>>>>  drivers/leds/leds-pca955x.c |   22 +-
+> +>>>>  1 files changed, 21 insertions(+), 1 deletions(-)
+> +>>>>
+> +>>>> Change from V2:
+> +>>>>  -Correct coding conventions.
+> +>>>>
+> +>>>> Change from V1:
+> +>>>>  -Remove CONFIG_ACPI.
+> +>>>>
+> +>>>> diff --git a/drivers/leds/leds-pca955x.c
+> +>>>> b/drivers/leds/leds-pca955x.c index 840401a..b168ebe 100644
+> +>>>> --- a/drivers/leds/leds-pca955x.c
+> +>>>> +++ b/drivers/leds/leds-pca955x.c
+> +>>>> @@ -40,6 +40,7 @@
+> +>>>>   *  bits the chip supports.
+> +>>>>   */
+> +>>>>
+> +>>>> +#include 
+> +>>>>  #include 
+> +>>>>  #include 
+> +>>>>  #include 
+> +>>>> @@ -100,6 +101,15 @@ struct pca955x_chipdef {  };
+> +>>>> MODULE_DEVICE_TABLE(i2c, pca955x_id);
+> +>>>>
+> +>>>> +static const struct acpi_device_id pca955x_acpi_ids[] = {
+> +>>>> +{ .id = "PCA9550", .driver_data = pca9550 },
+> +>>>> +{ .id = "PCA9551", .driver_data = pca9551 },
+> +>>>> +{ .id = "PCA9552", .driver_data = pca9552 },
+> +>>>> +{ .id = "PCA9553", .driver_data = pca9553 },
+> +>>>> +{ }
+> +>>
+> +>>
+> +>> OK, I see that you brought back explicit properties in the
+> +>> structure initializer. Is there some vital reason for that?
+>
+> It's not vital, but to make it consistent with what was done for
+> pca963x,
+
+For pca963x I applied the version without explicit properties.
+Note that this is consistent with pca963x_id array above the added
+pca963x_acpi_ids. For pca955x the situation is the same.
+
+> and also per suggestion by Mika on reviewing  a different driver
+> mux:954x in another thread.
+
+Could you give a reference to that thread? In the review of V1 of this
+patch Mika mentioned "{ "PCA9553", pca9553 }" scheme.
+

Actually it was Peter Rosin (not Mika) on linux-i2c and the reference to
that is follows

https://lkml.org/lkml/2016/11/18/732

I am including Robin here.

Thanks.

+> I would think this would make the definition clearer.
+>
+> +>> You're mentioning "correcting coding conventions" in the patch
+> +>> changelog. checkpatch.pl --strict doesn't complain about that, so
+> +>> what coding conventions you have on mind?
+> +>
+> +>
+> +>>
+> +>>
+> +>>>> +MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+> +>>>> +
+> +>>>>  struct pca955x {
+> +>>>

RE: [PATCH V3] leds: pca955x: Add ACPI support for pca955x

[Phong Vo]

+-Original Message-
+From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
+Sent: Wednesday, November 30, 2016 4:00 PM
+To: Phong Vo
+Cc: Mika Westerberg; Rafael J. Wysocki; Richard Purdie; linux-
+l...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
+a...@vger.kernel.org; Loc Ho; Thang Nguyen; patches; Tin Huynh
+Subject: Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
+
+Hi Phong,
+
+On 11/30/2016 09:23 AM, Phong Vo wrote:
+> +-Original Message-
+> +From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
+> +Sent: Wednesday, November 30, 2016 3:18 PM
+> +To: Tin Huynh
+> +Cc: Mika Westerberg; Rafael J. Wysocki; Richard Purdie; linux-
+> +l...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
+> +a...@vger.kernel.org; Loc Ho; Thang Nguyen; Phong Vo; patches
+> +Subject: Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
+> +
+> +On 11/30/2016 09:06 AM, Tin Huynh wrote:
+> +> On Wed, Nov 30, 2016 at 3:01 PM, Jacek Anaszewski
+> +>  wrote:
+> +>>
+> +>> On 11/30/2016 08:51 AM, Jacek Anaszewski wrote:
+> +>>>
+> +>>> Hi Tin,
+> +>>>
+> +>>> How this patch is different from the one already merged?
+> +>>>
+> +>>> Best regards,
+> +>>> Jacek Anaszewski
+> +>>>
+>
+> Hi Jacek, I am answering on behalf of Tin.
+> This patch is for the leds:pca955x driver while the previous one was
+> for leds:pca963x driver!
+> They are almost the same in the coding construct, but different
+drivers.
+
+Ah, indeed, that's why I got lost with patch version numbering :-)
+
+> +>>> On 11/30/2016 04:08 AM, Tin Huynh wrote:
+> +>>>>
+> +>>>> This patch enables ACPI support for leds-pca955x driver.
+> +>>>>
+> +>>>> Signed-off-by: Tin Huynh 
+> +>>>> ---
+> +>>>>  drivers/leds/leds-pca955x.c |   22 +-
+> +>>>>  1 files changed, 21 insertions(+), 1 deletions(-)
+> +>>>>
+> +>>>> Change from V2:
+> +>>>>  -Correct coding conventions.
+> +>>>>
+> +>>>> Change from V1:
+> +>>>>  -Remove CONFIG_ACPI.
+> +>>>>
+> +>>>> diff --git a/drivers/leds/leds-pca955x.c
+> +>>>> b/drivers/leds/leds-pca955x.c index 840401a..b168ebe 100644
+> +>>>> --- a/drivers/leds/leds-pca955x.c
+> +>>>> +++ b/drivers/leds/leds-pca955x.c
+> +>>>> @@ -40,6 +40,7 @@
+> +>>>>   *  bits the chip supports.
+> +>>>>   */
+> +>>>>
+> +>>>> +#include 
+> +>>>>  #include 
+> +>>>>  #include 
+> +>>>>  #include 
+> +>>>> @@ -100,6 +101,15 @@ struct pca955x_chipdef {  };
+> +>>>> MODULE_DEVICE_TABLE(i2c, pca955x_id);
+> +>>>>
+> +>>>> +static const struct acpi_device_id pca955x_acpi_ids[] = {
+> +>>>> +{ .id = "PCA9550", .driver_data = pca9550 },
+> +>>>> +{ .id = "PCA9551", .driver_data = pca9551 },
+> +>>>> +{ .id = "PCA9552", .driver_data = pca9552 },
+> +>>>> +{ .id = "PCA9553", .driver_data = pca9553 },
+> +>>>> +{ }
+> +>>
+> +>>
+> +>> OK, I see that you brought back explicit properties in the
+> +>> structure initializer. Is there some vital reason for that?
+>
+> It's not vital, but to make it consistent with what was done for
+> pca963x,
+
+For pca963x I applied the version without explicit properties.
+Note that this is consistent with pca963x_id array above the added
+pca963x_acpi_ids. For pca955x the situation is the same.
+
+> and also per suggestion by Mika on reviewing  a different driver
+> mux:954x in another thread.
+
+Could you give a reference to that thread? In the review of V1 of this
+patch Mika mentioned "{ "PCA9553", pca9553 }" scheme.
+

Actually it was Peter Rosin (not Mika) on linux-i2c and the reference to
that is follows

https://lkml.org/lkml/2016/11/18/732

I am including Robin here.

Thanks.

+> I would think this would make the definition clearer.
+>
+> +>> You're mentioning "correcting coding conventions" in the patch
+> +>> changelog. checkpatch.pl --strict doesn't complain about that, so
+> +>> what coding conventions you have on mind?
+> +>
+> +>
+> +>>
+> +>>
+> +>>>> +MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+> +>>>> +
+> +>>>>  struct pca955x {
+> +>>>>  struct mutex lock;
+> +>>>> 

RE: [PATCH V3] leds: pca955x: Add ACPI support for pca955x

[Phong Vo]

+-Original Message-
+From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
+Sent: Wednesday, November 30, 2016 3:18 PM
+To: Tin Huynh
+Cc: Mika Westerberg; Rafael J. Wysocki; Richard Purdie; linux-
+l...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
+a...@vger.kernel.org; Loc Ho; Thang Nguyen; Phong Vo; patches
+Subject: Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
+
+On 11/30/2016 09:06 AM, Tin Huynh wrote:
+> On Wed, Nov 30, 2016 at 3:01 PM, Jacek Anaszewski
+> <j.anaszew...@samsung.com> wrote:
+>>
+>> On 11/30/2016 08:51 AM, Jacek Anaszewski wrote:
+>>>
+>>> Hi Tin,
+>>>
+>>> How this patch is different from the one already merged?
+>>>
+>>> Best regards,
+>>> Jacek Anaszewski
+>>>

Hi Jacek, I am answering on behalf of Tin.
This patch is for the leds:pca955x driver while the previous one was for
leds:pca963x driver!
They are almost the same in the coding construct, but different drivers.

+>>> On 11/30/2016 04:08 AM, Tin Huynh wrote:
+>>>>
+>>>> This patch enables ACPI support for leds-pca955x driver.
+>>>>
+>>>> Signed-off-by: Tin Huynh <tnhu...@apm.com>
+>>>> ---
+>>>>  drivers/leds/leds-pca955x.c |   22 +-
+>>>>  1 files changed, 21 insertions(+), 1 deletions(-)
+>>>>
+>>>> Change from V2:
+>>>>  -Correct coding conventions.
+>>>>
+>>>> Change from V1:
+>>>>  -Remove CONFIG_ACPI.
+>>>>
+>>>> diff --git a/drivers/leds/leds-pca955x.c
+>>>> b/drivers/leds/leds-pca955x.c index 840401a..b168ebe 100644
+>>>> --- a/drivers/leds/leds-pca955x.c
+>>>> +++ b/drivers/leds/leds-pca955x.c
+>>>> @@ -40,6 +40,7 @@
+>>>>   *  bits the chip supports.
+>>>>   */
+>>>>
+>>>> +#include 
+>>>>  #include 
+>>>>  #include 
+>>>>  #include 
+>>>> @@ -100,6 +101,15 @@ struct pca955x_chipdef {  };
+>>>> MODULE_DEVICE_TABLE(i2c, pca955x_id);
+>>>>
+>>>> +static const struct acpi_device_id pca955x_acpi_ids[] = {
+>>>> +{ .id = "PCA9550", .driver_data = pca9550 },
+>>>> +{ .id = "PCA9551", .driver_data = pca9551 },
+>>>> +{ .id = "PCA9552", .driver_data = pca9552 },
+>>>> +{ .id = "PCA9553", .driver_data = pca9553 },
+>>>> +{ }
+>>
+>>
+>> OK, I see that you brought back explicit properties in the structure
+>> initializer. Is there some vital reason for that?

It's not vital, but to make it consistent with what was done for pca963x,
and also per suggestion by Mika on reviewing  a different driver mux:954x in
another thread.
I would think this would make the definition clearer.

+>> You're mentioning "correcting coding conventions" in the patch
+>> changelog. checkpatch.pl --strict doesn't complain about that, so
+>> what coding conventions you have on mind?
+>
+>
+>>
+>>
+>>>> +MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+>>>> +
+>>>>  struct pca955x {
+>>>>  struct mutex lock;
+>>>>  struct pca955x_led *leds;
+>>>> @@ -250,7 +260,16 @@ static int pca955x_probe(struct i2c_client
+*client,
+>>>>  struct led_platform_data *pdata;
+>>>>  int i, err;
+>>>>
+>>>> -chip = _chipdefs[id->driver_data];
+>>>> +if (id) {
+>>>> +chip = _chipdefs[id->driver_data];
+>>>> +} else {
+>>>> +const struct acpi_device_id *acpi_id;
+>
+> I added '{}' follow if
+
+You had it already in V1. Please verify if the patch applied to the for-
+next branch of linux-leds.git has the shape you intended:
+
+https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-
+leds.git/commit/?h=for-next=e46895b71a26da404c4d95cb2bab1a67cf8b20bc
+
+--
+Best regards,
+Jacek Anaszewski

RE: [PATCH V3] leds: pca955x: Add ACPI support for pca955x

[Phong Vo]

+-Original Message-
+From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
+Sent: Wednesday, November 30, 2016 3:18 PM
+To: Tin Huynh
+Cc: Mika Westerberg; Rafael J. Wysocki; Richard Purdie; linux-
+l...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
+a...@vger.kernel.org; Loc Ho; Thang Nguyen; Phong Vo; patches
+Subject: Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
+
+On 11/30/2016 09:06 AM, Tin Huynh wrote:
+> On Wed, Nov 30, 2016 at 3:01 PM, Jacek Anaszewski
+>  wrote:
+>>
+>> On 11/30/2016 08:51 AM, Jacek Anaszewski wrote:
+>>>
+>>> Hi Tin,
+>>>
+>>> How this patch is different from the one already merged?
+>>>
+>>> Best regards,
+>>> Jacek Anaszewski
+>>>

Hi Jacek, I am answering on behalf of Tin.
This patch is for the leds:pca955x driver while the previous one was for
leds:pca963x driver!
They are almost the same in the coding construct, but different drivers.

+>>> On 11/30/2016 04:08 AM, Tin Huynh wrote:
+>>>>
+>>>> This patch enables ACPI support for leds-pca955x driver.
+>>>>
+>>>> Signed-off-by: Tin Huynh 
+>>>> ---
+>>>>  drivers/leds/leds-pca955x.c |   22 +-
+>>>>  1 files changed, 21 insertions(+), 1 deletions(-)
+>>>>
+>>>> Change from V2:
+>>>>  -Correct coding conventions.
+>>>>
+>>>> Change from V1:
+>>>>  -Remove CONFIG_ACPI.
+>>>>
+>>>> diff --git a/drivers/leds/leds-pca955x.c
+>>>> b/drivers/leds/leds-pca955x.c index 840401a..b168ebe 100644
+>>>> --- a/drivers/leds/leds-pca955x.c
+>>>> +++ b/drivers/leds/leds-pca955x.c
+>>>> @@ -40,6 +40,7 @@
+>>>>   *  bits the chip supports.
+>>>>   */
+>>>>
+>>>> +#include 
+>>>>  #include 
+>>>>  #include 
+>>>>  #include 
+>>>> @@ -100,6 +101,15 @@ struct pca955x_chipdef {  };
+>>>> MODULE_DEVICE_TABLE(i2c, pca955x_id);
+>>>>
+>>>> +static const struct acpi_device_id pca955x_acpi_ids[] = {
+>>>> +{ .id = "PCA9550", .driver_data = pca9550 },
+>>>> +{ .id = "PCA9551", .driver_data = pca9551 },
+>>>> +{ .id = "PCA9552", .driver_data = pca9552 },
+>>>> +{ .id = "PCA9553", .driver_data = pca9553 },
+>>>> +{ }
+>>
+>>
+>> OK, I see that you brought back explicit properties in the structure
+>> initializer. Is there some vital reason for that?

It's not vital, but to make it consistent with what was done for pca963x,
and also per suggestion by Mika on reviewing  a different driver mux:954x in
another thread.
I would think this would make the definition clearer.

+>> You're mentioning "correcting coding conventions" in the patch
+>> changelog. checkpatch.pl --strict doesn't complain about that, so
+>> what coding conventions you have on mind?
+>
+>
+>>
+>>
+>>>> +MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+>>>> +
+>>>>  struct pca955x {
+>>>>  struct mutex lock;
+>>>>  struct pca955x_led *leds;
+>>>> @@ -250,7 +260,16 @@ static int pca955x_probe(struct i2c_client
+*client,
+>>>>  struct led_platform_data *pdata;
+>>>>  int i, err;
+>>>>
+>>>> -chip = _chipdefs[id->driver_data];
+>>>> +if (id) {
+>>>> +chip = _chipdefs[id->driver_data];
+>>>> +} else {
+>>>> +const struct acpi_device_id *acpi_id;
+>
+> I added '{}' follow if
+
+You had it already in V1. Please verify if the patch applied to the for-
+next branch of linux-leds.git has the shape you intended:
+
+https://git.kernel.org/cgit/linux/kernel/git/j.anaszewski/linux-
+leds.git/commit/?h=for-next=e46895b71a26da404c4d95cb2bab1a67cf8b20bc
+
+--
+Best regards,
+Jacek Anaszewski

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

[Phong Vo]

>From: Mika Westerberg 
>Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when
using DT ids through ACPI
>Date: Monday 13th June 2016 09:26:55 UTC (5 months ago)
>
>On Fri, Jun 10, 2016 at 06:57:36PM +0300, Crestez Dan Leonard wrote:
>> On 06/10/2016 09:32 AM, Mika Westerberg wrote:
>> > On Thu, Jun 09, 2016 at 04:06:03PM +0300, Crestez Dan Leonard wrote:
>> >> When devices are instatiated through devicetree the i2c_client->name
is
>> >> set to the compatible string with company name stripped out. This is
>> >> then matched to the i2c_device_id table to pass the device_id to the
>> >> probe function. This id parameter is used by some device drivers to
>> >> differentiate between model numbers.
>> >>
>> >> When using ACPI this id parameter is NULL and the driver usually
needs
>> >> to do ACPI-specific differentiation.
>> >>
>> >> This patch attempts to find a valid i2c_device_id when using ACPI
with
>> >> DT-like compatible strings.
>> >
>> > So I don't really understand why it would be good idea to pass
>> > i2c_device_id for devices which are matched against their ACPI/DT
>> > tables. Apparently DT is already doing that so maybe there is some
>> > reason.
>> >
>> > Anyway, why not fill in the device name when it is first enumerated
>> > if it uses DT compatible property? Just like DT does.
>> >
>> This automatic matching of i2c_device_id works for devicetree because
>> of_i2c_register_device sets i2c_board_info.type to the compatible
string
>> with the vendor prefix removed. For I2C devices described via ACPI the
>> i2c_board_info.type string is set to the ACPI device name. This ends up
>> something like "PRP0001:00".
>>
>> This could be changed in acpi_i2c_get_info to use the of_compatible
>> string from DSD if present. Is that what you mean? That would work and
>> it would be cleaner than my patch. Something like this:
>>
>> diff --git drivers/i2c/i2c-core.c drivers/i2c/i2c-core.c
>> index 1e0ef9b..ba2fe7f 100644
>> --- drivers/i2c/i2c-core.c
>> +++ drivers/i2c/i2c-core.c
>> @@ -181,7 +181,24 @@ static int acpi_i2c_get_info(struct acpi_device
>*adev,
>>
>> acpi_dev_free_resource_list(_list);
>>
>> -   strlcpy(info->type, dev_name(>dev), sizeof(info->type));
>> +   /*
>> +    * If we have a DT id set info.type to the first compatible
>> string with
>> +    * the vendor prefix stripped. This is similar to
>of_modalias_node
>> +    */
>> +   if (adev->data.of_compatible) {
>> +   const union acpi_object *obj;
>> +   const char *str, *chr;
>> +
>> +   obj = adev->data.of_compatible;
>> +   if (obj->type == ACPI_TYPE_PACKAGE)
>> +   obj = obj->package.elements;
>> +   str = obj->string.pointer;
>> +   chr = strchr(str, ',');
>> +   if (chr)
>> +   str = chr + 1;
>> +   strlcpy(info->type, str, sizeof(info->type));
>> +   } else
>> +   strlcpy(info->type, dev_name(>dev),
>> sizeof(info->type));
>>
>> return 0;
>>  }>
>
>Yes, that's what I mean.
>
>> The biggest concern is that this would change the i2c device name
>> between kernel versions. Is that acceptable?
>
>I don't think that is a problem since I still have not seen a single
>system using ACPI _DSD so I would not expect anything to break.
>
>However, I'm still not convinced it is good idea to return i2c_device_id
>from a completely different table if we match using ACPI/DT table.

All,

Is there a conclusion on this? We have been tackling the same issue and
incidentally arrived at a
similar solution as like Lenard proposed  in the patch above.

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

[Phong Vo]

>From: Mika Westerberg 
>Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when
using DT ids through ACPI
>Date: Monday 13th June 2016 09:26:55 UTC (5 months ago)
>
>On Fri, Jun 10, 2016 at 06:57:36PM +0300, Crestez Dan Leonard wrote:
>> On 06/10/2016 09:32 AM, Mika Westerberg wrote:
>> > On Thu, Jun 09, 2016 at 04:06:03PM +0300, Crestez Dan Leonard wrote:
>> >> When devices are instatiated through devicetree the i2c_client->name
is
>> >> set to the compatible string with company name stripped out. This is
>> >> then matched to the i2c_device_id table to pass the device_id to the
>> >> probe function. This id parameter is used by some device drivers to
>> >> differentiate between model numbers.
>> >>
>> >> When using ACPI this id parameter is NULL and the driver usually
needs
>> >> to do ACPI-specific differentiation.
>> >>
>> >> This patch attempts to find a valid i2c_device_id when using ACPI
with
>> >> DT-like compatible strings.
>> >
>> > So I don't really understand why it would be good idea to pass
>> > i2c_device_id for devices which are matched against their ACPI/DT
>> > tables. Apparently DT is already doing that so maybe there is some
>> > reason.
>> >
>> > Anyway, why not fill in the device name when it is first enumerated
>> > if it uses DT compatible property? Just like DT does.
>> >
>> This automatic matching of i2c_device_id works for devicetree because
>> of_i2c_register_device sets i2c_board_info.type to the compatible
string
>> with the vendor prefix removed. For I2C devices described via ACPI the
>> i2c_board_info.type string is set to the ACPI device name. This ends up
>> something like "PRP0001:00".
>>
>> This could be changed in acpi_i2c_get_info to use the of_compatible
>> string from DSD if present. Is that what you mean? That would work and
>> it would be cleaner than my patch. Something like this:
>>
>> diff --git drivers/i2c/i2c-core.c drivers/i2c/i2c-core.c
>> index 1e0ef9b..ba2fe7f 100644
>> --- drivers/i2c/i2c-core.c
>> +++ drivers/i2c/i2c-core.c
>> @@ -181,7 +181,24 @@ static int acpi_i2c_get_info(struct acpi_device
>*adev,
>>
>> acpi_dev_free_resource_list(_list);
>>
>> -   strlcpy(info->type, dev_name(>dev), sizeof(info->type));
>> +   /*
>> +    * If we have a DT id set info.type to the first compatible
>> string with
>> +    * the vendor prefix stripped. This is similar to
>of_modalias_node
>> +    */
>> +   if (adev->data.of_compatible) {
>> +   const union acpi_object *obj;
>> +   const char *str, *chr;
>> +
>> +   obj = adev->data.of_compatible;
>> +   if (obj->type == ACPI_TYPE_PACKAGE)
>> +   obj = obj->package.elements;
>> +   str = obj->string.pointer;
>> +   chr = strchr(str, ',');
>> +   if (chr)
>> +   str = chr + 1;
>> +   strlcpy(info->type, str, sizeof(info->type));
>> +   } else
>> +   strlcpy(info->type, dev_name(>dev),
>> sizeof(info->type));
>>
>> return 0;
>>  }>
>
>Yes, that's what I mean.
>
>> The biggest concern is that this would change the i2c device name
>> between kernel versions. Is that acceptable?
>
>I don't think that is a problem since I still have not seen a single
>system using ACPI _DSD so I would not expect anything to break.
>
>However, I'm still not convinced it is good idea to return i2c_device_id
>from a completely different table if we match using ACPI/DT table.

All,

Is there a conclusion on this? We have been tackling the same issue and
incidentally arrived at a
similar solution as like Lenard proposed  in the patch above.