linux-rockchip.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Nuno Sá" <nuno.sa@analog.com>
To: <linux-arm-kernel@lists.infradead.org>,
	<linux-rockchip@lists.infradead.org>,
	<linux-amlogic@lists.infradead.org>, <linux-imx@nxp.com>,
	<linux-iio@vger.kernel.org>
Cc: "Chunyan Zhang" <zhang.lyra@gmail.com>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Cixi Geng" <cixi.geng1@unisoc.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Vladimir Zapolskiy" <vz@mleia.com>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Alexandru Ardelean" <aardelean@deviqon.com>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Andriy Tryshnivskyy" <andriy.tryshnivskyy@opensynergy.com>,
	"Haibo Chen" <haibo.chen@nxp.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Florian Boor" <florian.boor@kernelconcepts.de>,
	"Ciprian Regus" <ciprian.regus@analog.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Jyoti Bhayana" <jbhayana@google.com>,
	"Nuno Sá" <nuno.sa@analog.com>, "Chen-Yu Tsai" <wens@csie.org>,
	"Orson Zhai" <orsonzhai@gmail.com>
Subject: [PATCH 14/15] iio: health: max30102: do not use internal iio_dev lock
Date: Tue, 20 Sep 2022 13:28:20 +0200	[thread overview]
Message-ID: <20220920112821.975359-15-nuno.sa@analog.com> (raw)
In-Reply-To: <20220920112821.975359-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,
iio_buffer_enabled() was being used not to prevent the raw access
but to decide whether or not the device needs to be powered on before.
If buffering, then the device is already on. To guarantee the same
behavior, a combination of locks is being used:

1. Use iio_device_claim_direct_mode() to check if direct mode can be
claimed and if we can, then we keep it until the reading is done (which
also means the device will be powered on and off);
2. If already buffering, we need to make sure that buffering is not
disabled (and hence, powering off the device) while doing a raw read. For
that, we can make use of the local lock that already exists.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
 drivers/iio/health/max30102.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c
index abbcef563807..e984c78b99f6 100644
--- a/drivers/iio/health/max30102.c
+++ b/drivers/iio/health/max30102.c
@@ -227,9 +227,20 @@ static int max30102_buffer_postenable(struct iio_dev *indio_dev)
 static int max30102_buffer_predisable(struct iio_dev *indio_dev)
 {
 	struct max30102_data *data = iio_priv(indio_dev);
+	int ret;
+
+	/*
+	 * As stated in the comment in the read_raw() function, temperature
+	 * can only be acquired if the engine is running. As such the mutex
+	 * is used to make sure we do not power down while doing a temperature
+	 * reading.
+	 */
+	mutex_lock(&data->lock);
+	ret = max30102_set_powermode(data, MAX30102_REG_MODE_CONFIG_MODE_NONE,
+				     false);
+	mutex_unlock(&data->lock);
 
-	return max30102_set_powermode(data, MAX30102_REG_MODE_CONFIG_MODE_NONE,
-				      false);
+	return ret;
 }
 
 static const struct iio_buffer_setup_ops max30102_buffer_setup_ops = {
@@ -477,12 +488,14 @@ 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))
+		if (!iio_device_claim_direct_mode(indio_dev)) {
 			ret = max30102_get_temp(data, val, true);
-		else
+			iio_device_release_direct_mode(indio_dev);
+		} else {
+			mutex_lock(&data->lock);
 			ret = max30102_get_temp(data, val, false);
-		mutex_unlock(&indio_dev->mlock);
+			mutex_unlock(&data->lock);
+		}
 		if (ret)
 			return ret;
 
-- 
2.37.3


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2022-09-20 11:37 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 11:28 [PATCH 00/15] Make 'mlock' really private Nuno Sá
2022-09-20 11:28 ` [PATCH 01/15] iio: adc: ad_sigma_delta: do not use internal iio_dev lock Nuno Sá
2022-09-20 11:54   ` Miquel Raynal
2022-09-24 14:22     ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 02/15] iio: adc: ad799x: " Nuno Sá
2022-09-24 14:45   ` Jonathan Cameron
2022-09-26 11:22     ` Nuno Sá
2022-09-20 11:28 ` [PATCH 03/15] iio: adc: axp288_adc: " Nuno Sá
2022-09-20 13:13   ` Andy Shevchenko
2022-09-20 13:18     ` Sa, Nuno
2022-09-20 13:37       ` Andy Shevchenko
2022-09-20 13:39         ` Andy Shevchenko
2022-09-20 13:46           ` Sa, Nuno
2022-09-20 15:12             ` Andy Shevchenko
2022-09-21  9:07               ` Nuno Sá
2022-09-24 15:23                 ` Jonathan Cameron
2022-09-24 15:24   ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 04/15] iio: adc: imx7d_adc: " Nuno Sá
2022-09-24 15:26   ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 05/15] iio: adc: lpc32xx_adc: " Nuno Sá
2022-09-24 15:27   ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 06/15] iio: adc: ltc2947-core: " Nuno Sá
2022-09-20 11:28 ` [PATCH 07/15] iio: adc: meson_saradc: " Nuno Sá
2022-09-25 20:38   ` Martin Blumenstingl
2022-09-20 11:28 ` [PATCH 08/15] iio: adc: rockchip_saradc: " Nuno Sá
2022-09-20 11:28 ` [PATCH 09/15] iio: adc: sc27xx_adc: " Nuno Sá
2022-09-20 11:28 ` [PATCH 10/15] iio: adc: vf610_adc: " Nuno Sá
2022-09-24 15:37   ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 11/15] iio: common: scmi_iio: " Nuno Sá
2022-09-24 15:42   ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 12/15] iio: fyro: itg3200_core: " Nuno Sá
2022-09-24 15:43   ` Jonathan Cameron
2022-09-24 15:46   ` Jonathan Cameron
2022-09-20 11:28 ` [PATCH 13/15] iio: health: max30100: " Nuno Sá
2022-09-20 12:23   ` Miquel Raynal
2022-09-20 12:44     ` Sa, Nuno
2022-09-20 12:55       ` Miquel Raynal
2022-09-20 13:15         ` Sa, Nuno
2022-09-20 13:53           ` Miquel Raynal
2022-09-20 14:56             ` Nuno Sá
2022-09-20 15:10               ` Miquel Raynal
2022-09-24 15:53                 ` Jonathan Cameron
2022-09-26 10:06                   ` Nuno Sá
2022-10-02 11:03                     ` Jonathan Cameron
2022-10-04  7:57                       ` Nuno Sá
2022-09-20 11:28 ` Nuno Sá [this message]
2022-09-24 15:54   ` [PATCH 14/15] iio: health: max30102: " Jonathan Cameron
2022-09-30 10:04     ` Nuno Sá
2022-10-02 11:08       ` Jonathan Cameron
2022-10-04  7:53         ` Nuno Sá
2022-09-20 11:28 ` [PATCH 15/15] iio: core: move 'mlock' to 'struct iio_dev_opaque' Nuno Sá
2022-09-24 15:56   ` Jonathan Cameron

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=20220920112821.975359-15-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).