Re: [PATCH v3 2/4] iio: health: max30100: do not use internal iio_dev lock

From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Nuno Sá" <nuno.sa@analog.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org,
	 linux-amlogic@lists.infradead.org,
	linux-rockchip@lists.infradead.org,  linux-imx@nxp.com,
	Chen-Yu Tsai <wens@csie.org>,
	Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com>,
	Ciprian Regus <ciprian.regus@analog.com>,
	 Vladimir Zapolskiy <vz@mleia.com>,
	Cixi Geng <cixi.geng1@unisoc.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Heiko Stuebner <heiko@sntech.de>,
	Fabio Estevam <festevam@gmail.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Alexandru Ardelean <aardelean@deviqon.com>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Haibo Chen <haibo.chen@nxp.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Jyoti Bhayana <jbhayana@google.com>,
	Jonathan Cameron <jic23@kernel.org>,
	 Florian Boor <florian.boor@kernelconcepts.de>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	Orson Zhai <orsonzhai@gmail.com>, Shawn Guo <shawnguo@kernel.org>,
	Kevin Hilman <khilman@baylibre.com>
Subject: Re: [PATCH v3 2/4] iio: health: max30100: do not use internal iio_dev lock
Date: Fri, 14 Oct 2022 09:16:55 +0200	[thread overview]
Message-ID: <7ab31b13e625773976f4eb4b639d3287ee0f9efa.camel@gmail.com> (raw)
In-Reply-To: <CAHp75Vc=TMsFBR8PUb7tifgM_b8foRhiAwy3VEDsX4hTOjKP=Q@mail.gmail.com>

On Wed, 2022-10-12 at 20:46 +0300, Andy Shevchenko wrote:
> On Wed, Oct 12, 2022 at 6:15 PM Nuno Sá <nuno.sa@analog.com> wrote:
> > 
> > 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, let's make use of the new
> > iio_device_claim_buffer_mode() API to make sure we stay in buffered
> > mode
> > during the complete read.
> > 
> > Note that we are shadowing the error code returned by
> > iio_device_claim_buffer_mode() so that we keep the original one
> > (-EAGAIN). The reason is that some userspace stack might already be
> > relying on this particular code so that we are not taking chances
> > and
> > leave it alone.
> 
> The above line widths seem a bit arbitrary to me. But I think it's
> due
> to function names in them.
> Perhaps you can make them less deviated by shuffling a bit, like
> moving "but to" to the next line.
> 
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > ---
> >  drivers/iio/health/max30100.c | 9 +++------
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iio/health/max30100.c
> > b/drivers/iio/health/max30100.c
> > index 2cca5e0519f8..6ac49901c9da 100644
> > --- a/drivers/iio/health/max30100.c
> > +++ b/drivers/iio/health/max30100.c
> > @@ -387,18 +387,15 @@ 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_buffer_mode(indio_dev)) {
> 
> I think a summary of replacing error code is good to have here, like
> 
> /*
>  * Replacing -EBUSY or other error code
>  * returned by iio_device_claim_buffer_mode()
>  * because user space may rely on the current
>  * one.
>  */
> 

This might make sense... I'll wait for Jonathan's review to see how
strong he feels about this. Maybe he can also add it when applying.

- Nuno Sá
> 

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