[PATCH v4] iio: accel: adxl345: Add ACPI HID table

[PATCH v4] iio: accel: adxl345: Add ACPI HID table

[Kai-Heng Feng]

x86 boards may use ACPI HID "ADS0345" for adxl345 device.

Analog replied:
"ADS034X is not a valid PNP ID. ADS0345 would be.
I'm not aware that this ID is already taken.
Feel free to submit a mainline Linux input mailing list patch."

So add an ACPI match table for that accordingly.

Since ACPI device may not match to any I2C ID, use the name and type
directly from ACPI ID table in absence of I2C ID.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v4:
 - Drop "ADS0345:00" and use driver_date from ACPI table directly.

v3:
 - Convert the driver from input to iio.

v2:
 - Drop ACPI_PTR()
 - Drop redundant empty line and comma
 - Add info from vendor

 drivers/iio/accel/adxl345_i2c.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/accel/adxl345_i2c.c b/drivers/iio/accel/adxl345_i2c.c
index a431cba216e69..cdcc3ef1f1d33 100644
--- a/drivers/iio/accel/adxl345_i2c.c
+++ b/drivers/iio/accel/adxl345_i2c.c
@@ -22,20 +22,32 @@ static const struct regmap_config adxl345_i2c_regmap_config = {
 static int adxl345_i2c_probe(struct i2c_client *client,
 			     const struct i2c_device_id *id)
 {
+	struct device *dev = &client->dev;
+	const struct acpi_device_id *acpi_id;
+	enum adxl345_device_type type;
+	const char *name;
 	struct regmap *regmap;
 
-	if (!id)
-		return -ENODEV;
+	if (id) {
+		type = id->driver_data;
+		name = id->name;
+	} else {
+		acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
+		if (acpi_id) {
+			type = acpi_id->driver_data;
+			name = acpi_id->id;
+		} else
+			return -ENODEV;
+	}
 
 	regmap = devm_regmap_init_i2c(client, &adxl345_i2c_regmap_config);
 	if (IS_ERR(regmap)) {
-		dev_err(&client->dev, "Error initializing i2c regmap: %ld\n",
+		dev_err(dev, "Error initializing i2c regmap: %ld\n",
 			PTR_ERR(regmap));
 		return PTR_ERR(regmap);
 	}
 
-	return adxl345_core_probe(&client->dev, regmap, id->driver_data,
-				  id->name);
+	return adxl345_core_probe(&client->dev, regmap, type, name);
 }
 
 static const struct i2c_device_id adxl345_i2c_id[] = {
@@ -54,10 +66,17 @@ static const struct of_device_id adxl345_of_match[] = {
 
 MODULE_DEVICE_TABLE(of, adxl345_of_match);
 
+static const struct acpi_device_id adxl345_acpi_match[] = {
+	{ "ADS0345", ADXL345 },
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, adxl345_acpi_match);
+
 static struct i2c_driver adxl345_i2c_driver = {
 	.driver = {
 		.name	= "adxl345_i2c",
 		.of_match_table = adxl345_of_match,
+		.acpi_match_table = adxl345_acpi_match,
 	},
 	.probe		= adxl345_i2c_probe,
 	.id_table	= adxl345_i2c_id,
-- 
2.34.1

Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

[Kai-Heng Feng]

On Thu, Feb 17, 2022 at 6:57 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
>
>
> On Thursday, February 17, 2022, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
>>
>> x86 boards may use ACPI HID "ADS0345" for adxl345 device.
>>
>> Analog replied:
>> "ADS034X is not a valid PNP ID. ADS0345 would be.
>> I'm not aware that this ID is already taken.
>> Feel free to submit a mainline Linux input mailing list patch."
>>
>> So add an ACPI match table for that accordingly.
>>
>> Since ACPI device may not match to any I2C ID, use the name and type
>> directly from ACPI ID table in absence of I2C ID.
>>
>> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> ---
>> v4:
>>  - Drop "ADS0345:00" and use driver_date from ACPI table directly.
>>
>> v3:
>>  - Convert the driver from input to iio.
>>
>> v2:
>>  - Drop ACPI_PTR()
>>  - Drop redundant empty line and comma
>>  - Add info from vendor
>>
>>  drivers/iio/accel/adxl345_i2c.c | 29 ++++++++++++++++++++++++-----
>>  1 file changed, 24 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iio/accel/adxl345_i2c.c b/drivers/iio/accel/adxl345_i2c.c
>> index a431cba216e69..cdcc3ef1f1d33 100644
>> --- a/drivers/iio/accel/adxl345_i2c.c
>> +++ b/drivers/iio/accel/adxl345_i2c.c
>> @@ -22,20 +22,32 @@ static const struct regmap_config adxl345_i2c_regmap_config = {
>>  static int adxl345_i2c_probe(struct i2c_client *client,
>>                              const struct i2c_device_id *id)
>>  {
>> +       struct device *dev = &client->dev;
>> +       const struct acpi_device_id *acpi_id;
>> +       enum adxl345_device_type type;
>> +       const char *name;
>>         struct regmap *regmap;
>>
>> -       if (!id)
>> -               return -ENODEV;
>> +       if (id) {
>> +               type = id->driver_data;
>> +               name = id->name;
>> +       } else {
>> +               acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
>> +               if (acpi_id) {
>> +                       type = acpi_id->driver_data;
>> +                       name = acpi_id->id;
>> +               } else
>> +                       return -ENODEV;
>> +       }
>>
>
>
> Thanks, but can we do this in ACPI agnostic way?
>
> Can be as simple as
>
> if (id)
>   ...
> else {
>   match = device_get_match_data(dev);
>   if (!match)
>     return -ENODEV;
> }
>
> Note, it might require to reconsider what is put in the driver data (either convert to pointers, or be sure that valid type is never a 0/NULL).

Unlike acpi_match_device(), device_get_match_data() only get
driver_data, so we need a new struct to provide both name and type.

>
> Also note, in both cases using ID name for name us fragile. Probably we have to fix that first. Let me check today’s evening.

Can you please explain more on this? How does ID name make it fragile?

Kai-Heng

>
>>
>>         regmap = devm_regmap_init_i2c(client, &adxl345_i2c_regmap_config);
>>         if (IS_ERR(regmap)) {
>> -               dev_err(&client->dev, "Error initializing i2c regmap: %ld\n",
>> +               dev_err(dev, "Error initializing i2c regmap: %ld\n",
>>                         PTR_ERR(regmap));
>>                 return PTR_ERR(regmap);
>>         }
>>
>> -       return adxl345_core_probe(&client->dev, regmap, id->driver_data,
>> -                                 id->name);
>> +       return adxl345_core_probe(&client->dev, regmap, type, name);
>>  }
>>
>>  static const struct i2c_device_id adxl345_i2c_id[] = {
>> @@ -54,10 +66,17 @@ static const struct of_device_id adxl345_of_match[] = {
>>
>>  MODULE_DEVICE_TABLE(of, adxl345_of_match);
>>
>> +static const struct acpi_device_id adxl345_acpi_match[] = {
>> +       { "ADS0345", ADXL345 },
>> +       { }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, adxl345_acpi_match);
>> +
>>  static struct i2c_driver adxl345_i2c_driver = {
>>         .driver = {
>>                 .name   = "adxl345_i2c",
>>                 .of_match_table = adxl345_of_match,
>> +               .acpi_match_table = adxl345_acpi_match,
>>         },
>>         .probe          = adxl345_i2c_probe,
>>         .id_table       = adxl345_i2c_id,
>> --
>> 2.34.1
>>
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

[Andy Shevchenko]

On Fri, Feb 18, 2022 at 4:46 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
> On Thu, Feb 17, 2022 at 6:57 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Thursday, February 17, 2022, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:

...

> >> +               acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> >> +               if (acpi_id) {
> >> +                       type = acpi_id->driver_data;
> >> +                       name = acpi_id->id;
> >> +               } else
> >> +                       return -ENODEV;
> >
> > Thanks, but can we do this in ACPI agnostic way?
> >
> > Can be as simple as
> >
> > if (id)
> >   ...
> > else {
> >   match = device_get_match_data(dev);
> >   if (!match)
> >     return -ENODEV;
> > }
> >
> > Note, it might require to reconsider what is put in the driver data (either convert to pointers, or be sure that valid type is never a 0/NULL).
>
> Unlike acpi_match_device(), device_get_match_data() only get
> driver_data, so we need a new struct to provide both name and type.

It's unfortunate. Let me think about it a bit more.

> > Also note, in both cases using ID name for name us fragile. Probably we have to fix that first. Let me check today’s evening.
>
> Can you please explain more on this? How does ID name make it fragile?

I thought this one is used somehow by userspace to distinguish the
instance of the device, but looking into the rest of the IIO drivers
it seems more or less  a field for part number. That said, the ID is
okay to use. I hope Jonathan may correct me.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

[Jonathan Cameron]

On Fri, 18 Feb 2022 09:39:14 +0100
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 18, 2022 at 4:46 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
> > On Thu, Feb 17, 2022 at 6:57 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:  
> > > On Thursday, February 17, 2022, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:  
> 
> ...
> 
> > >> +               acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> > >> +               if (acpi_id) {
> > >> +                       type = acpi_id->driver_data;
> > >> +                       name = acpi_id->id;
> > >> +               } else
> > >> +                       return -ENODEV;  
> > >
> > > Thanks, but can we do this in ACPI agnostic way?
> > >
> > > Can be as simple as
> > >
> > > if (id)
> > >   ...
> > > else {
> > >   match = device_get_match_data(dev);
> > >   if (!match)
> > >     return -ENODEV;
> > > }
> > >
> > > Note, it might require to reconsider what is put in the driver data (either convert to pointers, or be sure that valid type is never a 0/NULL).  
> >
> > Unlike acpi_match_device(), device_get_match_data() only get
> > driver_data, so we need a new struct to provide both name and type.  
> 
> It's unfortunate. Let me think about it a bit more.
Usual solution is just to add that name to a per device type structure.
In this particular case there isn't one so far though and an enum is used
in the one place we might otherwise have used a part number specific structure.

Probably the easiest thing to do is use the enum to do a lookup in an array
of structures and have the string there.

> 
> > > Also note, in both cases using ID name for name us fragile. Probably we have to fix that first. Let me check today’s evening.  
> >
> > Can you please explain more on this? How does ID name make it fragile?  
> 
> I thought this one is used somehow by userspace to distinguish the
> instance of the device, but looking into the rest of the IIO drivers
> it seems more or less  a field for part number. That said, the ID is
> okay to use. I hope Jonathan may correct me.
> 
Should be part number.  Instances are distinguished via label rather than
name (or via the device parent on older kernels where we didn't have
label).

There are a few places where we accidentally let though IDs that aren't
always simply the part number and they became part of the ABI so we
couldn't really fix them after the event.

Jonathan

Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

[Andy Shevchenko]

On Fri, Feb 18, 2022 at 1:03 PM Jonathan Cameron <jic23@kernel.org> wrote:
> On Fri, 18 Feb 2022 09:39:14 +0100
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Fri, Feb 18, 2022 at 4:46 AM Kai-Heng Feng
> > <kai.heng.feng@canonical.com> wrote:
> > > On Thu, Feb 17, 2022 at 6:57 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > > On Thursday, February 17, 2022, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> >
> > ...
> >
> > > >> +               acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> > > >> +               if (acpi_id) {
> > > >> +                       type = acpi_id->driver_data;
> > > >> +                       name = acpi_id->id;
> > > >> +               } else
> > > >> +                       return -ENODEV;
> > > >
> > > > Thanks, but can we do this in ACPI agnostic way?
> > > >
> > > > Can be as simple as
> > > >
> > > > if (id)
> > > >   ...
> > > > else {
> > > >   match = device_get_match_data(dev);
> > > >   if (!match)
> > > >     return -ENODEV;
> > > > }
> > > >
> > > > Note, it might require to reconsider what is put in the driver data (either convert to pointers, or be sure that valid type is never a 0/NULL).
> > >
> > > Unlike acpi_match_device(), device_get_match_data() only get
> > > driver_data, so we need a new struct to provide both name and type.
> >
> > It's unfortunate. Let me think about it a bit more.
> Usual solution is just to add that name to a per device type structure.
> In this particular case there isn't one so far though and an enum is used
> in the one place we might otherwise have used a part number specific structure.
>
> Probably the easiest thing to do is use the enum to do a lookup in an array
> of structures and have the string there.
>
> >
> > > > Also note, in both cases using ID name for name us fragile. Probably we have to fix that first. Let me check today’s evening.
> > >
> > > Can you please explain more on this? How does ID name make it fragile?
> >
> > I thought this one is used somehow by userspace to distinguish the
> > instance of the device, but looking into the rest of the IIO drivers
> > it seems more or less  a field for part number. That said, the ID is
> > okay to use. I hope Jonathan may correct me.
> >
> Should be part number.  Instances are distinguished via label rather than
> name (or via the device parent on older kernels where we didn't have
> label).
>
> There are a few places where we accidentally let though IDs that aren't
> always simply the part number and they became part of the ABI so we
> couldn't really fix them after the event.

Thanks for chiming in.
So, can we simply use dev_name() then? Or would it be too bad to have
the device instance name there?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

[Jonathan Cameron]

On Fri, 18 Feb 2022 13:27:17 +0100
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 18, 2022 at 1:03 PM Jonathan Cameron <jic23@kernel.org> wrote:
> > On Fri, 18 Feb 2022 09:39:14 +0100
> > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:  
> > > On Fri, Feb 18, 2022 at 4:46 AM Kai-Heng Feng
> > > <kai.heng.feng@canonical.com> wrote:  
> > > > On Thu, Feb 17, 2022 at 6:57 PM Andy Shevchenko
> > > > <andy.shevchenko@gmail.com> wrote:  
> > > > > On Thursday, February 17, 2022, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:  
> > >
> > > ...
> > >  
> > > > >> +               acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> > > > >> +               if (acpi_id) {
> > > > >> +                       type = acpi_id->driver_data;
> > > > >> +                       name = acpi_id->id;
> > > > >> +               } else
> > > > >> +                       return -ENODEV;  
> > > > >
> > > > > Thanks, but can we do this in ACPI agnostic way?
> > > > >
> > > > > Can be as simple as
> > > > >
> > > > > if (id)
> > > > >   ...
> > > > > else {
> > > > >   match = device_get_match_data(dev);
> > > > >   if (!match)
> > > > >     return -ENODEV;
> > > > > }
> > > > >
> > > > > Note, it might require to reconsider what is put in the driver data (either convert to pointers, or be sure that valid type is never a 0/NULL).  
> > > >
> > > > Unlike acpi_match_device(), device_get_match_data() only get
> > > > driver_data, so we need a new struct to provide both name and type.  
> > >
> > > It's unfortunate. Let me think about it a bit more.  
> > Usual solution is just to add that name to a per device type structure.
> > In this particular case there isn't one so far though and an enum is used
> > in the one place we might otherwise have used a part number specific structure.
> >
> > Probably the easiest thing to do is use the enum to do a lookup in an array
> > of structures and have the string there.
> >  
> > >  
> > > > > Also note, in both cases using ID name for name us fragile. Probably we have to fix that first. Let me check today’s evening.  
> > > >
> > > > Can you please explain more on this? How does ID name make it fragile?  
> > >
> > > I thought this one is used somehow by userspace to distinguish the
> > > instance of the device, but looking into the rest of the IIO drivers
> > > it seems more or less  a field for part number. That said, the ID is
> > > okay to use. I hope Jonathan may correct me.
> > >  
> > Should be part number.  Instances are distinguished via label rather than
> > name (or via the device parent on older kernels where we didn't have
> > label).
> >
> > There are a few places where we accidentally let though IDs that aren't
> > always simply the part number and they became part of the ABI so we
> > couldn't really fix them after the event.  
> 
> Thanks for chiming in.
> So, can we simply use dev_name() then? Or would it be too bad to have
> the device instance name there?

I'd rather it wasn't the device instance.  All the documentation etc
says part number for this so that's what will be expected by most
users.  The docs are deliberately vague (Typically a part number)
because some devices don't have one and we have those historical parts
where I missed they were using the instance name when reviewing.

Jonathan



>