mbox series

[v1,00/13] iio: Clean up acpi_match_device() use cases

Message ID 20241023152145.3564943-1-andriy.shevchenko@linux.intel.com (mailing list archive)
Headers show
Series iio: Clean up acpi_match_device() use cases | expand

Message

Andy Shevchenko Oct. 23, 2024, 3:17 p.m. UTC
There are current uses of acpi_match_device():
- as strange way of checking if the device was enumerated via ACPI
- as a way to get IIO device name as ACPI device instance name
- as above with accompanying driver data

Deduplicate its use by providing two new helper functions in IIO ACPI
library and update the rest accordingly.

This also includes a rework of previously sent ltr501 patch.

Andy Shevchenko (13):
  iio: magnetometer: bmc150: Drop dead code from the driver
  iio: adc: pac1934: Replace strange way of checking type of enumeration
  iio: imu: inv_mpu6050: Replace strange way of checking type of
    enumeration
  iio: acpi: Improve iio_read_acpi_mount_matrix()
  iio: acpi: Add iio_get_acpi_device_name_and_data() helper function
  iio: accel: mma9551: Replace custom implementation of
    iio_get_acpi_device_name()
  iio: accel: mma9553: Replace custom implementation of
    iio_get_acpi_device_name()
  iio: gyro: bmg160: Replace custom implementation of
    iio_get_acpi_device_name()
  iio: light: isl29018: Replace a variant of
    iio_get_acpi_device_name_and_data()
  iio: light: isl29018: drop ACPI_PTR() and CONFIG_ACPI guards
  iio: light: ltr501: Drop most likely fake ACPI IDs
  iio: light: ltr501: Add LTER0303 to the supported devices
  iio: light: ltr501: Replace a variant of
    iio_get_acpi_device_name_and_data()

 drivers/iio/accel/mma9551.c                | 19 ++-------
 drivers/iio/accel/mma9553.c                | 19 ++-------
 drivers/iio/adc/pac1934.c                  |  2 +-
 drivers/iio/gyro/bmg160_core.c             | 15 --------
 drivers/iio/gyro/bmg160_i2c.c              |  4 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c |  5 +--
 drivers/iio/industrialio-acpi.c            | 45 ++++++++++++++++++++--
 drivers/iio/light/isl29018.c               | 38 ++++++------------
 drivers/iio/light/ltr501.c                 | 29 +++++---------
 drivers/iio/magnetometer/bmc150_magn.c     | 15 --------
 include/linux/iio/iio.h                    | 10 +++++
 11 files changed, 86 insertions(+), 115 deletions(-)

Comments

Hans de Goede Oct. 23, 2024, 3:36 p.m. UTC | #1
Hi,

On 23-Oct-24 5:17 PM, Andy Shevchenko wrote:
> There are current uses of acpi_match_device():
> - as strange way of checking if the device was enumerated via ACPI
> - as a way to get IIO device name as ACPI device instance name
> - as above with accompanying driver data
> 
> Deduplicate its use by providing two new helper functions in IIO ACPI
> library and update the rest accordingly.
> 
> This also includes a rework of previously sent ltr501 patch.

Thanks, the entire series looks good to me:

Reviewed-by: Hans de Goede <hdegoede@redhat.com>

for the series.

Regards,

Hans


> Andy Shevchenko (13):
>   iio: magnetometer: bmc150: Drop dead code from the driver
>   iio: adc: pac1934: Replace strange way of checking type of enumeration
>   iio: imu: inv_mpu6050: Replace strange way of checking type of
>     enumeration
>   iio: acpi: Improve iio_read_acpi_mount_matrix()
>   iio: acpi: Add iio_get_acpi_device_name_and_data() helper function
>   iio: accel: mma9551: Replace custom implementation of
>     iio_get_acpi_device_name()
>   iio: accel: mma9553: Replace custom implementation of
>     iio_get_acpi_device_name()
>   iio: gyro: bmg160: Replace custom implementation of
>     iio_get_acpi_device_name()
>   iio: light: isl29018: Replace a variant of
>     iio_get_acpi_device_name_and_data()
>   iio: light: isl29018: drop ACPI_PTR() and CONFIG_ACPI guards
>   iio: light: ltr501: Drop most likely fake ACPI IDs
>   iio: light: ltr501: Add LTER0303 to the supported devices
>   iio: light: ltr501: Replace a variant of
>     iio_get_acpi_device_name_and_data()
> 
>  drivers/iio/accel/mma9551.c                | 19 ++-------
>  drivers/iio/accel/mma9553.c                | 19 ++-------
>  drivers/iio/adc/pac1934.c                  |  2 +-
>  drivers/iio/gyro/bmg160_core.c             | 15 --------
>  drivers/iio/gyro/bmg160_i2c.c              |  4 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c |  5 +--
>  drivers/iio/industrialio-acpi.c            | 45 ++++++++++++++++++++--
>  drivers/iio/light/isl29018.c               | 38 ++++++------------
>  drivers/iio/light/ltr501.c                 | 29 +++++---------
>  drivers/iio/magnetometer/bmc150_magn.c     | 15 --------
>  include/linux/iio/iio.h                    | 10 +++++
>  11 files changed, 86 insertions(+), 115 deletions(-)
>
Jonathan Cameron Oct. 24, 2024, 7:52 a.m. UTC | #2
On Wed, 23 Oct 2024 18:17:23 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> There are current uses of acpi_match_device():
> - as strange way of checking if the device was enumerated via ACPI
> - as a way to get IIO device name as ACPI device instance name

Quick note on this one. That's an ABI bug that we are stuck with because
we missed it in review a long time back and names aren't critical enough
to justify forcing a fix through.

I don't have a particular problem with a function to wrap that up,
but thought I'd just make it clear in this thread that no new
driver should ever do this!

Jonathan


> - as above with accompanying driver data
> 
> Deduplicate its use by providing two new helper functions in IIO ACPI
> library and update the rest accordingly.
> 
> This also includes a rework of previously sent ltr501 patch.
> 
> Andy Shevchenko (13):
>   iio: magnetometer: bmc150: Drop dead code from the driver
>   iio: adc: pac1934: Replace strange way of checking type of enumeration
>   iio: imu: inv_mpu6050: Replace strange way of checking type of
>     enumeration
>   iio: acpi: Improve iio_read_acpi_mount_matrix()
>   iio: acpi: Add iio_get_acpi_device_name_and_data() helper function
>   iio: accel: mma9551: Replace custom implementation of
>     iio_get_acpi_device_name()
>   iio: accel: mma9553: Replace custom implementation of
>     iio_get_acpi_device_name()
>   iio: gyro: bmg160: Replace custom implementation of
>     iio_get_acpi_device_name()
>   iio: light: isl29018: Replace a variant of
>     iio_get_acpi_device_name_and_data()
>   iio: light: isl29018: drop ACPI_PTR() and CONFIG_ACPI guards
>   iio: light: ltr501: Drop most likely fake ACPI IDs
>   iio: light: ltr501: Add LTER0303 to the supported devices
>   iio: light: ltr501: Replace a variant of
>     iio_get_acpi_device_name_and_data()
> 
>  drivers/iio/accel/mma9551.c                | 19 ++-------
>  drivers/iio/accel/mma9553.c                | 19 ++-------
>  drivers/iio/adc/pac1934.c                  |  2 +-
>  drivers/iio/gyro/bmg160_core.c             | 15 --------
>  drivers/iio/gyro/bmg160_i2c.c              |  4 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c |  5 +--
>  drivers/iio/industrialio-acpi.c            | 45 ++++++++++++++++++++--
>  drivers/iio/light/isl29018.c               | 38 ++++++------------
>  drivers/iio/light/ltr501.c                 | 29 +++++---------
>  drivers/iio/magnetometer/bmc150_magn.c     | 15 --------
>  include/linux/iio/iio.h                    | 10 +++++
>  11 files changed, 86 insertions(+), 115 deletions(-)
>
Andy Shevchenko Oct. 24, 2024, 8:06 a.m. UTC | #3
On Thu, Oct 24, 2024 at 08:52:31AM +0100, Jonathan Cameron wrote:
> On Wed, 23 Oct 2024 18:17:23 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > There are current uses of acpi_match_device():
> > - as strange way of checking if the device was enumerated via ACPI
> > - as a way to get IIO device name as ACPI device instance name
> 
> Quick note on this one. That's an ABI bug that we are stuck with because
> we missed it in review a long time back and names aren't critical enough
> to justify forcing a fix through.
> 
> I don't have a particular problem with a function to wrap that up,
> but thought I'd just make it clear in this thread that no new
> driver should ever do this!

That's a good addition!

Let me cook a v2 where I add this to the kernel doc and actually I have to
update the SoB chain in one patch.