From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Jonathan Cameron" <jic23@kernel.org>, "Nuno Sá" <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>,
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>,
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 02/15] iio: adc: ad799x: do not use internal iio_dev lock
Date: Mon, 26 Sep 2022 13:22:33 +0200 [thread overview]
Message-ID: <571f1608ebbe23d7223ce168872d1df4a3b79ad3.camel@gmail.com> (raw)
In-Reply-To: <20220924154517.6672e964@jic23-huawei>
On Sat, 2022-09-24 at 15:45 +0100, Jonathan Cameron wrote:
> On Tue, 20 Sep 2022 13:28:08 +0200
> Nuno Sá <nuno.sa@analog.com> wrote:
>
> > 'mlock' was being grabbed when setting the device frequency. In
> > order to
> > not introduce any functional change a new lock is added. With that
> > in
> > mind, the lock also needs to be grabbed in the places where 'mlock'
> > is.
>
> The usage in here is an example of why we originally decided to take
> mlock
> private... Annoying hard to reason about. One key thing this
> description
> doesn't mention is protection of st->config vs device state and I
> think
> the original usage of mlock is partly intended to protect that.
>
> Upshot is I'm not confident enough on this one to be happy taking it
> without
> more head scratching or some review from others!
>
Yeah, this one is odd enough...
> >
> > On the other places the lock was being used, we can just drop
> > it since we are only doing one i2c bus read/write which is already
> > safe.
> >
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
>
> > ---
> > drivers/iio/adc/ad799x.c | 18 ++++++++++++------
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ad799x.c b/drivers/iio/adc/ad799x.c
> > index 262bd7665b33..838ba8e77de1 100644
> > --- a/drivers/iio/adc/ad799x.c
> > +++ b/drivers/iio/adc/ad799x.c
> > @@ -28,6 +28,7 @@
> > #include <linux/types.h>
> > #include <linux/err.h>
> > #include <linux/module.h>
> > +#include <linux/mutex.h>
> > #include <linux/bitops.h>
> >
> > #include <linux/iio/iio.h>
> > @@ -125,6 +126,8 @@ struct ad799x_state {
> > const struct ad799x_chip_config *chip_config;
> > struct regulator *reg;
> > struct regulator *vref;
> > + /* lock to protect against multiple access to the device */
> > + struct mutex lock;
> > unsigned id;
> > u16 config;
> >
> > @@ -290,7 +293,9 @@ static int ad799x_read_raw(struct iio_dev
> > *indio_dev,
> > ret = iio_device_claim_direct_mode(indio_dev);
> > if (ret)
> > return ret;
> > + mutex_lock(&st->lock);
>
> If we claim direct mode for the frequency writing we'll avoid racing
> with
> buffers being enabled or other sysfs accesses that are claiming
> direct mode.
>
As you stated in some other patch, changing the frequency while
buffering is probably not a good idea (possible in some devices though)
but the main reason I haven't used the claim direct approach was
because it would change behavior and could, in theory, break some
userspace apps...
> That made me think we could drop the lock, but the argument gets
> tricker
> around st->config which is used in ad799x_scan_direct() and modified
> in write_event_config() in a fashion that means it could be out of
> sync.
> I'm not sure that matters but it is getting hard to reason about.
>
The write_event_config() also could use some improvement... Note that
st->config is always written even if ad799x_write_config() fails (which
for some devices is possible). I know that for an i2c write to fail
that probably means we have bigger issues but that does not make it
correct :). We should only update the variable after doing the actual
configuration...
- Nuno Sá
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2022-09-26 11:23 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á [this message]
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 ` [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=571f1608ebbe23d7223ce168872d1df4a3b79ad3.camel@gmail.com \
--to=noname.nuno@gmail.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=nuno.sa@analog.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).