IIO core correctly will take care of firmware node if it's not set in
the driver. Drop ACPI and OF specifics from the driver and allow IIO
core to handle this.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/iio/proximity/sx_common.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iio/proximity/sx_common.c b/drivers/iio/proximity/sx_common.c
index 8ad814d96b7e..6bb68c1835da 100644
--- a/drivers/iio/proximity/sx_common.c
+++ b/drivers/iio/proximity/sx_common.c
@@ -5,7 +5,6 @@
* Common part of most Semtech SAR sensor.
*/
-#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/byteorder/generic.h>
#include <linux/delay.h>
@@ -520,8 +519,6 @@ int sx_common_probe(struct i2c_client *client,
if (ret)
return dev_err_probe(dev, ret, "error reading WHOAMI\n");
- ACPI_COMPANION_SET(&indio_dev->dev, ACPI_COMPANION(dev));
- indio_dev->dev.of_node = client->dev.of_node;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = data->chip_info->iio_channels;
--
2.35.1
On Mon, 30 May 2022 20:43:26 +0300
Andy Shevchenko <[email protected]> wrote:
> IIO core correctly will take care of firmware node if it's not set in
> the driver. Drop ACPI and OF specifics from the driver and allow IIO
> core to handle this.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
Looks fine to me. As such I'll apply it now, but Gwendal, you've
been active with this driver recently so if you have time to sanity check
that would be great. Once I've caught up with new stuff I plan to check
where we are with your various series on this driver.
Thanks,
Jonathan
> ---
> drivers/iio/proximity/sx_common.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/iio/proximity/sx_common.c b/drivers/iio/proximity/sx_common.c
> index 8ad814d96b7e..6bb68c1835da 100644
> --- a/drivers/iio/proximity/sx_common.c
> +++ b/drivers/iio/proximity/sx_common.c
> @@ -5,7 +5,6 @@
> * Common part of most Semtech SAR sensor.
> */
>
> -#include <linux/acpi.h>
> #include <linux/bitops.h>
> #include <linux/byteorder/generic.h>
> #include <linux/delay.h>
> @@ -520,8 +519,6 @@ int sx_common_probe(struct i2c_client *client,
> if (ret)
> return dev_err_probe(dev, ret, "error reading WHOAMI\n");
>
> - ACPI_COMPANION_SET(&indio_dev->dev, ACPI_COMPANION(dev));
> - indio_dev->dev.of_node = client->dev.of_node;
> indio_dev->modes = INDIO_DIRECT_MODE;
>
> indio_dev->channels = data->chip_info->iio_channels;
The reason we have the code ACPI_COMPANION_SET and dev.of_node set (by
commit 74a53a959028e ("iio:proximity:sx_common: Fix device property
parsing on DT systems") from Stephen is we are getting device propery
in ->get_default_reg(), which is called in sx_common_init_device(),
before devm_iio_device_register().
We have the same code path in other driver, like adc/stm32-adc.c,
where indio_dev->dev.of_node is set manually to be able to set the
resolution based on device tree properties.
Gwendal.
On Fri, Jun 3, 2022 at 9:57 AM Jonathan Cameron <[email protected]> wrote:
>
> On Mon, 30 May 2022 20:43:26 +0300
> Andy Shevchenko <[email protected]> wrote:
>
> > IIO core correctly will take care of firmware node if it's not set in
> > the driver. Drop ACPI and OF specifics from the driver and allow IIO
> > core to handle this.
> >
> > Signed-off-by: Andy Shevchenko <[email protected]>
> Looks fine to me. As such I'll apply it now, but Gwendal, you've
> been active with this driver recently so if you have time to sanity check
> that would be great. Once I've caught up with new stuff I plan to check
> where we are with your various series on this driver.
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/proximity/sx_common.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/iio/proximity/sx_common.c b/drivers/iio/proximity/sx_common.c
> > index 8ad814d96b7e..6bb68c1835da 100644
> > --- a/drivers/iio/proximity/sx_common.c
> > +++ b/drivers/iio/proximity/sx_common.c
> > @@ -5,7 +5,6 @@
> > * Common part of most Semtech SAR sensor.
> > */
> >
> > -#include <linux/acpi.h>
> > #include <linux/bitops.h>
> > #include <linux/byteorder/generic.h>
> > #include <linux/delay.h>
> > @@ -520,8 +519,6 @@ int sx_common_probe(struct i2c_client *client,
> > if (ret)
> > return dev_err_probe(dev, ret, "error reading WHOAMI\n");
> >
> > - ACPI_COMPANION_SET(&indio_dev->dev, ACPI_COMPANION(dev));
> > - indio_dev->dev.of_node = client->dev.of_node;
> > indio_dev->modes = INDIO_DIRECT_MODE;
> >
> > indio_dev->channels = data->chip_info->iio_channels;
>
On Mon, Jun 13, 2022 at 11:31 PM Gwendal Grignou <[email protected]> wrote:
>
> The reason we have the code ACPI_COMPANION_SET and dev.of_node set (by
> commit 74a53a959028e ("iio:proximity:sx_common: Fix device property
> parsing on DT systems") from Stephen is we are getting device propery
> in ->get_default_reg(), which is called in sx_common_init_device(),
> before devm_iio_device_register().
>
> We have the same code path in other driver, like adc/stm32-adc.c,
> where indio_dev->dev.of_node is set manually to be able to set the
> resolution based on device tree properties.
Ah, thanks for this insight! I will rework the patch accordingly (yes,
there is something to clean up even in this case).
> On Fri, Jun 3, 2022 at 9:57 AM Jonathan Cameron <[email protected]> wrote:
> > On Mon, 30 May 2022 20:43:26 +0300
> > Andy Shevchenko <[email protected]> wrote:
> >
> > > IIO core correctly will take care of firmware node if it's not set in
> > > the driver. Drop ACPI and OF specifics from the driver and allow IIO
> > > core to handle this.
> > >
> > > Signed-off-by: Andy Shevchenko <[email protected]>
> > Looks fine to me. As such I'll apply it now, but Gwendal, you've
> > been active with this driver recently so if you have time to sanity check
> > that would be great. Once I've caught up with new stuff I plan to check
> > where we are with your various series on this driver.
--
With Best Regards,
Andy Shevchenko
On Tue, 14 Jun 2022 11:27:21 +0200
Andy Shevchenko <[email protected]> wrote:
> On Mon, Jun 13, 2022 at 11:31 PM Gwendal Grignou <[email protected]> wrote:
> >
> > The reason we have the code ACPI_COMPANION_SET and dev.of_node set (by
> > commit 74a53a959028e ("iio:proximity:sx_common: Fix device property
> > parsing on DT systems") from Stephen is we are getting device propery
> > in ->get_default_reg(), which is called in sx_common_init_device(),
> > before devm_iio_device_register().
> >
> > We have the same code path in other driver, like adc/stm32-adc.c,
> > where indio_dev->dev.of_node is set manually to be able to set the
> > resolution based on device tree properties.
>
> Ah, thanks for this insight! I will rework the patch accordingly (yes,
> there is something to clean up even in this case).
>
> > On Fri, Jun 3, 2022 at 9:57 AM Jonathan Cameron <[email protected]> wrote:
> > > On Mon, 30 May 2022 20:43:26 +0300
> > > Andy Shevchenko <[email protected]> wrote:
> > >
> > > > IIO core correctly will take care of firmware node if it's not set in
> > > > the driver. Drop ACPI and OF specifics from the driver and allow IIO
> > > > core to handle this.
> > > >
> > > > Signed-off-by: Andy Shevchenko <[email protected]>
> > > Looks fine to me. As such I'll apply it now, but Gwendal, you've
> > > been active with this driver recently so if you have time to sanity check
> > > that would be great. Once I've caught up with new stuff I plan to check
> > > where we are with your various series on this driver.
>
Dropped patch