Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Sun, 18 Apr 2021 16:59:02 +0300 Andy Shevchenko wrote: > On Sun, Apr 18, 2021 at 4:49 PM Andy Shevchenko > wrote: > > > > On Sun, Apr 18, 2021 at 2:07 PM Jonathan Cameron wrote: > > > > Thanks for review, my answers below. > > > > > On Wed, 14 Apr 2021 22:54:53 +0300 > > > Andy Shevchenko wrote: > > > > > > > We can utilize separate drivers for accelerometer and magnetometer, > > > > so here is the glue driver to enable LSM9DS0 IMU support. > > > > > > > > The idea was suggested by Crestez Dan Leonard in [1]. The proposed > > > > change > > > > was sent as RFC due to race condition concerns, which are indeed > > > > possible. > > > > > > If you are going to mention races, good to give some flavour in here! > > > > I meant that the initial idea is racy due to different devices > > communicating to the same i2c address. > > So, any sequence of transfers are not serialized and you may end up with > > > > drv1 -> i2c > > drv2 -> i2c > > drv1 <- i2c # garbage > > > > > This driver makes me very nervous indeed. > > > > Why?! This one is race free as far as I can see. Or maybe I interpret > > this wrongly and you are talking about initial RFC? > > > > > I haven't 'found' any places > > > where the fact we'll write the same registers from each of the drivers > > > causes problems (e.g. int pin setup etc) but perhaps I'm missing > > > something. > > > > > > Shall we say that makes me rather keener to get eyes (and thought) on this > > > patch than normal :) > > > > How should I amend the commit message to state: > > 1. First idea (RFC by the link) *is* racy AFAIU > > 2. This one *is not* racy. Great. I read it as meaning they were both potentially racey! This is less worrying. > > I re-read this and now understand better what you meant. > So, it may be that the initial proposal may work without any > amendment, but since I haven't investigated much, I should rather use > the phrase "potentially racy". In my variant it's using one regmap for > both drivers (not two), which makes the register state consistent. Am > I wrong? I think this approach is fine. I'd be more worried about the two 'sub' drivers not necessarily being happy that someone else touches state they care about. There are places where I think we write the same value to the same register twice during setup with this model, but that shouldn't matter. I'm not 100% sure that there aren't other cases though I think there aren't. So what you have is probably fine, but more eyes would make me happier ;) Lots of people care about this particular driver so hopefully we'll get them. > Do we have some places where we may write to the same register concurrently? > Only ones I can find are the setup ones where it writes the same value twice I think. So *crosses fingers* :) Given timing (missed merge window) we have masses of time to let this sit on list a while and see if anyone can spot issues neither of us have found. Jonathan
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Sun, Apr 18, 2021 at 4:49 PM Andy Shevchenko wrote: > > On Sun, Apr 18, 2021 at 2:07 PM Jonathan Cameron wrote: > > Thanks for review, my answers below. > > > On Wed, 14 Apr 2021 22:54:53 +0300 > > Andy Shevchenko wrote: > > > > > We can utilize separate drivers for accelerometer and magnetometer, > > > so here is the glue driver to enable LSM9DS0 IMU support. > > > > > > The idea was suggested by Crestez Dan Leonard in [1]. The proposed change > > > was sent as RFC due to race condition concerns, which are indeed possible. > > > > If you are going to mention races, good to give some flavour in here! > > I meant that the initial idea is racy due to different devices > communicating to the same i2c address. > So, any sequence of transfers are not serialized and you may end up with > > drv1 -> i2c > drv2 -> i2c > drv1 <- i2c # garbage > > > This driver makes me very nervous indeed. > > Why?! This one is race free as far as I can see. Or maybe I interpret > this wrongly and you are talking about initial RFC? > > > I haven't 'found' any places > > where the fact we'll write the same registers from each of the drivers > > causes problems (e.g. int pin setup etc) but perhaps I'm missing something. > > > > Shall we say that makes me rather keener to get eyes (and thought) on this > > patch than normal :) > > How should I amend the commit message to state: > 1. First idea (RFC by the link) *is* racy AFAIU > 2. This one *is not* racy. I re-read this and now understand better what you meant. So, it may be that the initial proposal may work without any amendment, but since I haven't investigated much, I should rather use the phrase "potentially racy". In my variant it's using one regmap for both drivers (not two), which makes the register state consistent. Am I wrong? Do we have some places where we may write to the same register concurrently? -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Sun, Apr 18, 2021 at 2:07 PM Jonathan Cameron wrote:
Thanks for review, my answers below.
> On Wed, 14 Apr 2021 22:54:53 +0300
> Andy Shevchenko wrote:
>
> > We can utilize separate drivers for accelerometer and magnetometer,
> > so here is the glue driver to enable LSM9DS0 IMU support.
> >
> > The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
> > was sent as RFC due to race condition concerns, which are indeed possible.
>
> If you are going to mention races, good to give some flavour in here!
I meant that the initial idea is racy due to different devices
communicating to the same i2c address.
So, any sequence of transfers are not serialized and you may end up with
drv1 -> i2c
drv2 -> i2c
drv1 <- i2c # garbage
> This driver makes me very nervous indeed.
Why?! This one is race free as far as I can see. Or maybe I interpret
this wrongly and you are talking about initial RFC?
> I haven't 'found' any places
> where the fact we'll write the same registers from each of the drivers
> causes problems (e.g. int pin setup etc) but perhaps I'm missing something.
>
> Shall we say that makes me rather keener to get eyes (and thought) on this
> patch than normal :)
How should I amend the commit message to state:
1. First idea (RFC by the link) *is* racy AFAIU
2. This one *is not* racy.
> > In order to amend the initial change,
You see, *in order to amend*, so here is the *amended* version.
> I went further by providing a specific
> > multi-instantiate probe driver that reuses existing accelerometer and
> > magnetometer.
> >
> > [1]: https://lore.kernel.org/patchwork/patch/670353/
> >
> > Suggested-by: Crestez Dan Leonard
> > Cc: mr.laho...@laposte.net
> > Cc: Matija Podravec
> > Cc: Sergey Borishchenko
> > Signed-off-by: Andy Shevchenko
>
> A few comments in here, though mostly about stuff related to the origin code
> you are copying so perhaps not tidying them up is preferable because it would
> complicate comparison of the two cases.
...
> > + {
> > + .wai = 0x49,
> > + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS,
> > + .sensors_supported = {
> > + [0] = LSM9DS0_IMU_DEV_NAME,
>
> What does the name attribute report for these?
>
> Previously we've had the _accel etc postfix to differentiate the devices. I
> don't
> suppose it matters to much though as easy enough to identify the accelerometer
> etc from what channels are present.
>
> Of course driver may get name from somewhere different anyway, I haven't
> checked,
> just noticed this was different and wondered what the affect might be.
Yes, it has a postfix, that's why I leave it like this.
...
> > +static int st_lsm9ds0_power_enable(struct device *dev, struct st_lsm9ds0
> > *lsm9ds0)
> > +{
> > + int ret;
> > +
> > + /* Regulators not mandatory, but if requested we should enable them.
> > */
>
> That's a bit of a missleading comment though cut and paste from the other
> driver
> code. Key is that they will be handled by stub regulators if we don't provide
> the which is not really what that comment implies.
I see. I will remove it.
> > + lsm9ds0->vdd = devm_regulator_get(dev, "vdd");
> > + if (IS_ERR(lsm9ds0->vdd)) {
> > + dev_err(dev, "unable to get Vdd supply\n");
> > + return PTR_ERR(lsm9ds0->vdd);
> > + }
> > + ret = regulator_enable(lsm9ds0->vdd);
> > + if (ret) {
> > + dev_warn(dev, "Failed to enable specified Vdd supply\n");
>
> Given we fail to probe if this is true, dev_warn seems a bit soft.
Right. I'll move to dev_err().
> > + return ret;
> > + }
> > +
> > + lsm9ds0->vdd_io = devm_regulator_get(dev, "vddio");
> > + if (IS_ERR(lsm9ds0->vdd_io)) {
> > + dev_err(dev, "unable to get Vdd_IO supply\n");
> > + regulator_disable(lsm9ds0->vdd);
> > + return PTR_ERR(lsm9ds0->vdd_io);
> > + }
> > + ret = regulator_enable(lsm9ds0->vdd_io);
> > + if (ret) {
> > + dev_warn(dev, "Failed to enable specified Vdd_IO supply\n");
Ditto.
> > + regulator_disable(lsm9ds0->vdd);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Wed, 14 Apr 2021 22:54:53 +0300
Andy Shevchenko wrote:
> We can utilize separate drivers for accelerometer and magnetometer,
> so here is the glue driver to enable LSM9DS0 IMU support.
>
> The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
> was sent as RFC due to race condition concerns, which are indeed possible.
If you are going to mention races, good to give some flavour in here!
This driver makes me very nervous indeed. I haven't 'found' any places
where the fact we'll write the same registers from each of the drivers
causes problems (e.g. int pin setup etc) but perhaps I'm missing something.
Shall we say that makes me rather keener to get eyes (and thought) on this
patch than normal :)
>
> In order to amend the initial change, I went further by providing a specific
> multi-instantiate probe driver that reuses existing accelerometer and
> magnetometer.
>
> [1]: https://lore.kernel.org/patchwork/patch/670353/
>
> Suggested-by: Crestez Dan Leonard
> Cc: mr.laho...@laposte.net
> Cc: Matija Podravec
> Cc: Sergey Borishchenko
> Signed-off-by: Andy Shevchenko
A few comments in here, though mostly about stuff related to the origin code
you are copying so perhaps not tidying them up is preferable because it would
complicate comparison of the two cases.
> ---
> drivers/iio/accel/st_accel_core.c| 89 +-
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/Makefile | 1 +
> drivers/iio/imu/st_lsm9ds0/Kconfig | 28
> drivers/iio/imu/st_lsm9ds0/Makefile | 5 +
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h | 23 +++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c | 163 +++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c | 84 ++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c | 83 ++
> drivers/iio/magnetometer/st_magn_core.c | 98 +++
> include/linux/iio/common/st_sensors.h| 2 +
> 11 files changed, 576 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/imu/st_lsm9ds0/Kconfig
> create mode 100644 drivers/iio/imu/st_lsm9ds0/Makefile
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c
>
> diff --git a/drivers/iio/accel/st_accel_core.c
> b/drivers/iio/accel/st_accel_core.c
> index 5c258c1ca62d..dc32ebefe3fc 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -980,7 +980,94 @@ static const struct st_sensor_settings
> st_accel_sensors_settings[] = {
> .multi_read_bit = true,
> .bootime = 2,
> },
> -
> + {
> + .wai = 0x49,
> + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS,
> + .sensors_supported = {
> + [0] = LSM9DS0_IMU_DEV_NAME,
What does the name attribute report for these?
Previously we've had the _accel etc postfix to differentiate the devices. I
don't
suppose it matters to much though as easy enough to identify the accelerometer
etc from what channels are present.
Of course driver may get name from somewhere different anyway, I haven't
checked,
just noticed this was different and wondered what the affect might be.
>
> /* Default accel DRDY is available on INT1 pin */
> diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> index f02883b08480..001ca2c3ff95 100644
> --- a/drivers/iio/imu/Kconfig
> +++ b/drivers/iio/imu/Kconfig
> @@ -94,6 +94,7 @@ config KMX61
> source "drivers/iio/imu/inv_icm42600/Kconfig"
> source "drivers/iio/imu/inv_mpu6050/Kconfig"
> source "drivers/iio/imu/st_lsm6dsx/Kconfig"
> +source "drivers/iio/imu/st_lsm9ds0/Kconfig"
>
> endmenu
>
> diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
> index 13e9ff442b11..c82748096c77 100644
> --- a/drivers/iio/imu/Makefile
> +++ b/drivers/iio/imu/Makefile
> @@ -26,3 +26,4 @@ obj-y += inv_mpu6050/
> obj-$(CONFIG_KMX61) += kmx61.o
>
> obj-y += st_lsm6dsx/
> +obj-y += st_lsm9ds0/
> diff --git a/drivers/iio/imu/st_lsm9ds0/Kconfig
> b/drivers/iio/imu/st_lsm9ds0/Kconfig
> new file mode 100644
> index ..53b7017014f8
> --- /dev/null
> +++ b/drivers/iio/imu/st_lsm9ds0/Kconfig
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config IIO_ST_LSM9DS0
> + tristate "STMicroelectronics LSM9DS0 IMU driver"
> + depends on (I2C || SPI_MASTER) && SYSFS
> + depends on !SENSORS_LIS3_I2C
> + depends on !SENSORS_LIS3_SPI
> + select IIO_ST_LSM9DS0_I2C if I2C
> + select IIO_ST_LSM9DS0_SPI if SPI_MASTER
> + select IIO_ST_ACCEL_3AXIS
> + select IIO_ST_MAGN_3AXIS
> +
> + help
> + Say yes here to build support for STMicroelectronics LSM9DS0 IMU
> + sensor. Supported devices: accelerometer/magnetometer of lsm9ds0.
> +
>
[PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
We can utilize separate drivers for accelerometer and magnetometer,
so here is the glue driver to enable LSM9DS0 IMU support.
The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
was sent as RFC due to race condition concerns, which are indeed possible.
In order to amend the initial change, I went further by providing a specific
multi-instantiate probe driver that reuses existing accelerometer and
magnetometer.
[1]: https://lore.kernel.org/patchwork/patch/670353/
Suggested-by: Crestez Dan Leonard
Cc: mr.laho...@laposte.net
Cc: Matija Podravec
Cc: Sergey Borishchenko
Signed-off-by: Andy Shevchenko
---
drivers/iio/accel/st_accel_core.c| 89 +-
drivers/iio/imu/Kconfig | 1 +
drivers/iio/imu/Makefile | 1 +
drivers/iio/imu/st_lsm9ds0/Kconfig | 28
drivers/iio/imu/st_lsm9ds0/Makefile | 5 +
drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h | 23 +++
drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c | 163 +++
drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c | 84 ++
drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c | 83 ++
drivers/iio/magnetometer/st_magn_core.c | 98 +++
include/linux/iio/common/st_sensors.h| 2 +
11 files changed, 576 insertions(+), 1 deletion(-)
create mode 100644 drivers/iio/imu/st_lsm9ds0/Kconfig
create mode 100644 drivers/iio/imu/st_lsm9ds0/Makefile
create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h
create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c
create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c
create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c
diff --git a/drivers/iio/accel/st_accel_core.c
b/drivers/iio/accel/st_accel_core.c
index 5c258c1ca62d..dc32ebefe3fc 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -980,7 +980,94 @@ static const struct st_sensor_settings
st_accel_sensors_settings[] = {
.multi_read_bit = true,
.bootime = 2,
},
-
+ {
+ .wai = 0x49,
+ .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS,
+ .sensors_supported = {
+ [0] = LSM9DS0_IMU_DEV_NAME,
+ },
+ .ch = (struct iio_chan_spec *)st_accel_16bit_channels,
+ .odr = {
+ .addr = 0x20,
+ .mask = GENMASK(7, 4),
+ .odr_avl = {
+ { 3, 0x01, },
+ { 6, 0x02, },
+ { 12, 0x03, },
+ { 25, 0x04, },
+ { 50, 0x05, },
+ { 100, 0x06, },
+ { 200, 0x07, },
+ { 400, 0x08, },
+ { 800, 0x09, },
+ { 1600, 0x0a, },
+ },
+ },
+ .pw = {
+ .addr = 0x20,
+ .mask = GENMASK(7, 4),
+ .value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE,
+ },
+ .enable_axis = {
+ .addr = ST_SENSORS_DEFAULT_AXIS_ADDR,
+ .mask = ST_SENSORS_DEFAULT_AXIS_MASK,
+ },
+ .fs = {
+ .addr = 0x21,
+ .mask = GENMASK(5, 3),
+ .fs_avl = {
+ [0] = {
+ .num = ST_ACCEL_FS_AVL_2G,
+ .value = 0x00,
+ .gain = IIO_G_TO_M_S_2(61),
+ },
+ [1] = {
+ .num = ST_ACCEL_FS_AVL_4G,
+ .value = 0x01,
+ .gain = IIO_G_TO_M_S_2(122),
+ },
+ [2] = {
+ .num = ST_ACCEL_FS_AVL_6G,
+ .value = 0x02,
+ .gain = IIO_G_TO_M_S_2(183),
+ },
+ [3] = {
+ .num = ST_ACCEL_FS_AVL_8G,
+ .value = 0x03,
+ .gain = IIO_G_TO_M_S_2(244),
+ },
+ [4] = {
+ .num = ST_ACCEL_FS_AVL_16G,
+ .value = 0x04,
+ .gain = IIO_G_TO_M_S_2(732),
+ },
+ },
+ },
+ .bdu = {
+ .addr = 0x20,
+
