From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"linux-amlogic@lists.infradead.org"
<linux-amlogic@lists.infradead.org>,
"linux-imx@nxp.com" <linux-imx@nxp.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Chunyan Zhang <zhang.lyra@gmail.com>,
"Hennerich, Michael" <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>,
Jerome Brunet <jbrunet@baylibre.com>,
Heiko Stuebner <heiko@sntech.de>,
Florian Boor <florian.boor@kernelconcepts.de>,
"Regus, Ciprian" <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>, Chen-Yu Tsai <wens@csie.org>,
Orson Zhai <orsonzhai@gmail.com>
Subject: RE: [PATCH 13/15] iio: health: max30100: do not use internal iio_dev lock
Date: Tue, 20 Sep 2022 12:44:08 +0000 [thread overview]
Message-ID: <SJ0PR03MB6778FC7FD469F7C2BC7FB9DB994C9@SJ0PR03MB6778.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20220920142319.61557023@xps-13>
> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@bootlin.com>
> Sent: Tuesday, September 20, 2022 2:23 PM
> To: Sa, Nuno <Nuno.Sa@analog.com>
> Cc: 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; Chunyan Zhang <zhang.lyra@gmail.com>; Hennerich,
> Michael <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>; Jerome Brunet <jbrunet@baylibre.com>;
> Heiko Stuebner <heiko@sntech.de>; Florian Boor
> <florian.boor@kernelconcepts.de>; Regus, Ciprian
> <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>; Chen-Yu Tsai <wens@csie.org>; Orson Zhai
> <orsonzhai@gmail.com>
> Subject: Re: [PATCH 13/15] iio: health: max30100: do not use internal iio_dev
> lock
>
> [External]
>
> Hi Nuno,
>
Hi Miquel,
Thanks for reviewing...
> nuno.sa@analog.com wrote on Tue, 20 Sep 2022 13:28:19 +0200:
>
> > 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
> > allow it. Hence to get rid of the 'mlock' we need to:
> >
> > 1. Use iio_device_claim_direct_mode() to check if direct mode can be
> > claimed and if we can return -EINVAL (as the original code);
> >
> > 2. Make sure that buffering is not disabled while doing a raw read. For
> > that, we can make use of the local lock that already exists.
> >
> > While at it, fixed a minor coding style complain...
> >
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > ---
> > drivers/iio/health/max30100.c | 24 +++++++++++++++++-------
> > 1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/iio/health/max30100.c b/drivers/iio/health/max30100.c
> > index ad5717965223..aa494cad5df0 100644
> > --- a/drivers/iio/health/max30100.c
> > +++ b/drivers/iio/health/max30100.c
> > @@ -185,8 +185,19 @@ static int max30100_buffer_postenable(struct
> iio_dev *indio_dev)
> > static int max30100_buffer_predisable(struct iio_dev *indio_dev)
> > {
> > struct max30100_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 = max30100_set_powermode(data, false);
> > + mutex_unlock(&data->lock);
> >
> > - return max30100_set_powermode(data, false);
> > + return ret;
> > }
> >
> > static const struct iio_buffer_setup_ops max30100_buffer_setup_ops = {
> > @@ -387,18 +398,17 @@ static int max30100_read_raw(struct iio_dev
> *indio_dev,
> > * Temperature reading can only be acquired while engine
> > * is running
> > */
> > - mutex_lock(&indio_dev->mlock);
> > -
> > - if (!iio_buffer_enabled(indio_dev))
> > + if (!iio_device_claim_direct_mode(indio_dev)) {
>
> I wonder if this line change here is really needed. I agree the whole
> construction looks like what iio_device_claim_direct_mode() does but in
> practice I don't see the point of acquiring any lock here if we just
> release it no matter what happens right after.
>
I can see that this is odd (at the very least) but AFAIK, this is the only way
to safely infer if buffering is enabled or not. iio_buffer_enabled() has no
protection against someone concurrently enabling/disabling the buffer.
So the call is needed to make sure 'mlock' is internally grabbed before
calling iio_buffer_enabled().
> Unless of course if there is a hidden goal like "stop exporting
> iio_buffer_enabled()" or something like that.
>
> At least I would separate this from the main change which targets the
> removal of mlock because I don't see how it is directly related.
In a sense both changes are needed to ultimately get rid of mlock. I'm
also not sure how could I do the separation... Do you have something
in mind?
- Nuno Sá
next prev parent reply other threads:[~2022-09-20 12:47 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 [this message]
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 ` [PATCH 14/15] iio: health: max30102: " Nuno Sá
2022-09-24 15:54 ` 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=SJ0PR03MB6778FC7FD469F7C2BC7FB9DB994C9@SJ0PR03MB6778.namprd03.prod.outlook.com \
--to=nuno.sa@analog.com \
--cc=Ciprian.Regus@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=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).