From: "Nuno Sá" <nuno.sa@analog.com>
To: <linux-amlogic@lists.infradead.org>, <linux-imx@nxp.com>,
<linux-iio@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-rockchip@lists.infradead.org>
Cc: "Heiko Stuebner" <heiko@sntech.de>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Neil Armstrong" <narmstrong@baylibre.com>,
"Shawn Guo" <shawnguo@kernel.org>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Jyoti Bhayana" <jbhayana@google.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"Andriy Tryshnivskyy" <andriy.tryshnivskyy@opensynergy.com>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Cixi Geng" <cixi.geng1@unisoc.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Ciprian Regus" <ciprian.regus@analog.com>,
"Fabio Estevam" <festevam@gmail.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Alexandru Ardelean" <aardelean@deviqon.com>,
"Florian Boor" <florian.boor@kernelconcepts.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Orson Zhai" <orsonzhai@gmail.com>,
"Chen-Yu Tsai" <wens@csie.org>,
"Chunyan Zhang" <zhang.lyra@gmail.com>,
"Vladimir Zapolskiy" <vz@mleia.com>,
"Andy Shevchenko" <andy.shevchenko@gmail.com>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Haibo Chen" <haibo.chen@nxp.com>,
"Kevin Hilman" <khilman@baylibre.com>,
"Jonathan Cameron" <jic23@kernel.org>
Subject: [PATCH v2 15/16] iio: health: max30102: do not use internal iio_dev lock
Date: Tue, 4 Oct 2022 15:49:08 +0200 [thread overview]
Message-ID: <20221004134909.1692021-16-nuno.sa@analog.com> (raw)
In-Reply-To: <20221004134909.1692021-1-nuno.sa@analog.com>
The pattern used in this device does not quite fit in the
iio_device_claim_direct_mode() typical usage. In this case, we want to
know if we are in buffered mode or not to know if the device is powered
(buffer mode) or not. And depending on that max30102_get_temp() will
power on the device if needed. Hence, in order to keep the same
functionality, we try to:
1. Claim Buffered mode;
2: If 1) succeeds call max30102_get_temp() without powering on the
device;
3: Release Buffered mode;
4: If 1) fails, Claim Direct mode;
5: If 4) succeeds call max30102_get_temp() with powering on the device;
6: Release Direct mode;
7: If 4) fails, goto to 1) and try again.
This dance between buffered and direct mode is not particularly pretty
(as well as the loop introduced by the goto statement) but it does allow
us to get rid of the mlock usage while keeping the same behavior.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
drivers/iio/health/max30102.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c
index abbcef563807..b8b5ccf582fb 100644
--- a/drivers/iio/health/max30102.c
+++ b/drivers/iio/health/max30102.c
@@ -477,12 +477,23 @@ static int max30102_read_raw(struct iio_dev *indio_dev,
* Temperature reading can only be acquired when not in
* shutdown; leave shutdown briefly when buffer not running
*/
- mutex_lock(&indio_dev->mlock);
- if (!iio_buffer_enabled(indio_dev))
+any_mode_retry:
+ if (iio_device_claim_buffer_mode(indio_dev)) {
+ /*
+ * This one is a *bit* hacky. If we cannot claim buffer
+ * mode, then try direct mode so that we make sure
+ * things cannot concurrently change. And we just keep
+ * trying until we get one of the modes...
+ */
+ if (iio_device_claim_direct_mode(indio_dev))
+ goto any_mode_retry;
+
ret = max30102_get_temp(data, val, true);
- else
+ iio_device_release_direct_mode(indio_dev);
+ } else {
ret = max30102_get_temp(data, val, false);
- mutex_unlock(&indio_dev->mlock);
+ iio_device_release_buffer_mode(indio_dev);
+ }
if (ret)
return ret;
--
2.37.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-04 13:56 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 13:48 [PATCH v2 00/16] Make 'mlock' really private Nuno Sá
2022-10-04 13:48 ` [PATCH v2 01/16] iio: adc: ad799x: do not use internal iio_dev lock Nuno Sá
2022-10-09 11:53 ` Jonathan Cameron
2022-10-04 13:48 ` [PATCH v2 02/16] iio: adc: axp288_adc: " Nuno Sá
2022-10-09 11:55 ` Jonathan Cameron
2022-10-04 13:48 ` [PATCH v2 03/16] iio: adc: imx7d_adc: " Nuno Sá
2022-10-09 2:00 ` Bough Chen
2022-10-09 11:56 ` Jonathan Cameron
2022-10-04 13:48 ` [PATCH v2 04/16] iio: adc: lpc32xx_adc: " Nuno Sá
2022-10-09 11:57 ` Jonathan Cameron
2022-10-04 13:48 ` [PATCH v2 05/16] iio: adc: ltc2947-core: " Nuno Sá
2022-10-09 11:58 ` Jonathan Cameron
2022-10-04 13:48 ` [PATCH v2 06/16] iio: adc: meson_saradc: " Nuno Sá
2022-10-09 12:01 ` Jonathan Cameron
2022-10-04 13:49 ` [PATCH v2 07/16] iio: adc: rockchip_saradc: " Nuno Sá
2022-10-05 7:44 ` Heiko Stübner
2022-10-09 12:03 ` Jonathan Cameron
2022-10-04 13:49 ` [PATCH v2 08/16] iio: adc: sc27xx_adc: " Nuno Sá
2022-10-09 12:05 ` Jonathan Cameron
2022-10-04 13:49 ` [PATCH v2 09/16] iio: adc: vf610_adc: add helper function to read samples Nuno Sá
2022-10-09 2:10 ` Bough Chen
2022-10-04 13:49 ` [PATCH v2 10/16] iio: adc: vf610_adc: vf610_adc: do not use internal iio_dev lock Nuno Sá
2022-10-09 2:10 ` Bough Chen
2022-10-04 13:49 ` [PATCH v2 11/16] iio: common: scmi_iio: " Nuno Sá
2022-10-09 12:09 ` Jonathan Cameron
2022-10-04 13:49 ` [PATCH v2 12/16] iio: gyro: itg3200_core: " Nuno Sá
2022-10-09 12:10 ` Jonathan Cameron
2022-10-04 13:49 ` [PATCH v2 13/16] iio: core: introduce iio_device_{claim|release}_buffer_mode() APIs Nuno Sá
2022-10-04 14:08 ` Andy Shevchenko
2022-10-05 8:37 ` Nuno Sá
2022-10-09 11:41 ` Jonathan Cameron
2022-10-10 7:03 ` Nuno Sá
2022-10-04 13:49 ` [PATCH v2 14/16] iio: health: max30100: do not use internal iio_dev lock Nuno Sá
2022-10-04 14:13 ` Andy Shevchenko
2022-10-05 8:09 ` Nuno Sá
2022-10-09 12:14 ` Jonathan Cameron
2022-10-04 13:49 ` Nuno Sá [this message]
2022-10-04 14:15 ` [PATCH v2 15/16] iio: health: max30102: " Andy Shevchenko
2022-10-05 8:17 ` Nuno Sá
2022-10-09 11:44 ` Jonathan Cameron
2022-10-09 12:16 ` Jonathan Cameron
2022-10-10 7:08 ` Nuno Sá
2022-10-04 13:49 ` [PATCH v2 16/16] iio: core: move 'mlock' to 'struct iio_dev_opaque' Nuno Sá
2022-10-04 14:21 ` Andy Shevchenko
2022-10-05 8:40 ` Nuno Sá
2022-10-09 11:48 ` Jonathan Cameron
2022-10-09 11:52 ` Jonathan Cameron
2022-10-10 8:30 ` Andy Shevchenko
2022-10-09 12:19 ` Jonathan Cameron
2022-10-10 7:11 ` Nuno Sá
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221004134909.1692021-16-nuno.sa@analog.com \
--to=nuno.sa@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=aardelean@deviqon.com \
--cc=andriy.tryshnivskyy@opensynergy.com \
--cc=andy.shevchenko@gmail.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=ciprian.regus@analog.com \
--cc=cixi.geng1@unisoc.com \
--cc=festevam@gmail.com \
--cc=florian.boor@kernelconcepts.de \
--cc=haibo.chen@nxp.com \
--cc=hdegoede@redhat.com \
--cc=heiko@sntech.de \
--cc=jbhayana@google.com \
--cc=jbrunet@baylibre.com \
--cc=jic23@kernel.org \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=lars@metafoo.de \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-rockchip@lists.infradead.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=miquel.raynal@bootlin.com \
--cc=narmstrong@baylibre.com \
--cc=orsonzhai@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=vz@mleia.com \
--cc=wens@csie.org \
--cc=zhang.lyra@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).