[PATCH v2 00/16] Make 'mlock' really private

Nuno Sá
2022-10-04T13:49:43Z

This patchset cleans all the drivers directly using the iio_device 'mlock'.
This lock is private and should not be used outside the core (or by using
proper helpers).

Most of the conversions where straight, but there are some that really need
extra looking. Mainly patches [13/15] and [14/15] were a bit hacky since
iio_device_claim_direct_mode() does not fit 100%. The reason is that we
want to check if the device is buffering and do something if it is (in
which case the API return -EBUSY and released the lock. I just used a
combinations of locks to get around this (hopefully I did not messed up).

Note that this series was only compiled tested using allyesconfig for
ARM. I ran 'git grep' to make sure there were no more users of 'mlock'.
Hopefully I covered them all...

v2:

[PATCH 1-8, 10-12/16]
* Mention the inclusion of mutex.h in the commit message.

[PATCH 1-8, 10, 12/16]
* Initialize mutex as late as possible.
Note that [PATCH 11/16] was not included since the code to do so was not
direct enough. Would need to get a pointer to the private struture
outside of scmi_alloc_iiodev() to do it. While not hard, the added changes
in the code is not really worth it (IMO of course).

[PATCH 1/16]
* Refactored the commit message a bit. I guess this one will still needs
more discussion...

[PATCH 9/16]
* New patch to add an helper function to read the samples.

[PATCH 13/16]
* New patch to introduce iio_device_{claim|release}_buffer_mode() APIs.

[PATCH 14/16]
* Make use of the new iio_device_{claim|release}_buffer_mode() helpers

[PATCH 15/16]
* Make use of the new iio_device_{claim|release}_buffer_mode() helpers
in combination with claim_direct_mode(). This is needed so that we make sure
we always get one of the modes (and hence the iio_dev lock) to safely call
max30102_get_temp(). Note that I'm not particular "happy" with the code but
OTOH, it does not look as bad as I thought :). Anyways, if there are no
complains with it, I'm ok to leave it as-is. Otherwise, I think we can think
on the flag approach (briefly discussed in the first series).

Nuno Sá (16):
iio: adc: ad799x: do not use internal iio_dev lock
iio: adc: axp288_adc: do not use internal iio_dev lock
iio: adc: imx7d_adc: do not use internal iio_dev lock
iio: adc: lpc32xx_adc: do not use internal iio_dev lock
iio: adc: ltc2947-core: do not use internal iio_dev lock
iio: adc: meson_saradc: do not use internal iio_dev lock
iio: adc: rockchip_saradc: do not use internal iio_dev lock
iio: adc: sc27xx_adc: do not use internal iio_dev lock
iio: adc: vf610_adc: add helper function to read samples
iio: adc: vf610_adc: vf610_adc: do not use internal iio_dev lock
iio: common: scmi_iio: do not use internal iio_dev lock
iio: gyro: itg3200_core: do not use internal iio_dev lock
iio: core: introduce iio_device_{claim|release}_buffer_mode() APIs
iio: health: max30100: do not use internal iio_dev lock
iio: health: max30102: do not use internal iio_dev lock
iio: core: move 'mlock' to 'struct iio_dev_opaque'

drivers/iio/TODO | 3 -
drivers/iio/adc/ad799x.c | 20 ++--
drivers/iio/adc/axp288_adc.c | 10 +-
drivers/iio/adc/imx7d_adc.c | 14 ++-
drivers/iio/adc/lpc32xx_adc.c | 11 ++-
drivers/iio/adc/ltc2497-core.c | 7 +-
drivers/iio/adc/ltc2497.h | 2 +
drivers/iio/adc/meson_saradc.c | 11 ++-
drivers/iio/adc/rockchip_saradc.c | 15 ++-
drivers/iio/adc/sc27xx_adc.c | 14 ++-
drivers/iio/adc/vf610_adc.c | 104 ++++++++++++---------
drivers/iio/common/scmi_sensors/scmi_iio.c | 9 +-
drivers/iio/gyro/itg3200_core.c | 10 +-
drivers/iio/health/max30100.c | 9 +-
drivers/iio/health/max30102.c | 19 +++-
drivers/iio/industrialio-buffer.c | 29 +++---
drivers/iio/industrialio-core.c | 58 ++++++++++--
drivers/iio/industrialio-event.c | 4 +-
drivers/iio/industrialio-trigger.c | 12 +--
include/linux/iio/gyro/itg3200.h | 2 +
include/linux/iio/iio-opaque.h | 2 +
include/linux/iio/iio.h | 5 +-
22 files changed, 249 insertions(+), 121 deletions(-)

--
2.37.3