All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kurt Borja" <kuurtb@gmail.com>
To: "David Lechner" <dlechner@baylibre.com>,
	"Kurt Borja" <kuurtb@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@intel.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Benson Leung" <bleung@chromium.org>,
	"Antoniu Miclaus" <antoniu.miclaus@analog.com>,
	"Gwendal Grignou" <gwendal@chromium.org>,
	"Shrikant Raskar" <raskar.shree97@gmail.com>,
	"Per-Daniel Olsson" <perdaniel.olsson@axis.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Guenter Roeck" <groeck@chromium.org>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	chrome-platform@lists.linux.dev
Subject: Re: [PATCH RFC 5/6] iio: health: max30102: Use cleanup.h for IIO locks
Date: Thu, 04 Dec 2025 12:07:43 -0500	[thread overview]
Message-ID: <DEPLIJFBZQ36.20XX5DCMCJVB3@gmail.com> (raw)
In-Reply-To: <f96694db-2ad5-46d3-a380-cba3eaa2de2f@baylibre.com>

On Wed Dec 3, 2025 at 4:52 PM -05, David Lechner wrote:
> On 12/3/25 1:18 PM, Kurt Borja wrote:
>> Simplify and drop "hacky" busy-waiting code in max30102_read_raw() by
>> using scoped_guard().
>> 
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>>  drivers/iio/health/max30102.c | 24 +++++++-----------------
>>  1 file changed, 7 insertions(+), 17 deletions(-)
>> 
>> diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c
>> index 678720102f2b..c642842cb5fb 100644
>> --- a/drivers/iio/health/max30102.c
>> +++ b/drivers/iio/health/max30102.c
>> @@ -24,6 +24,7 @@
>>  #include <linux/iio/iio.h>
>>  #include <linux/iio/buffer.h>
>>  #include <linux/iio/kfifo_buf.h>
>> +#include <linux/cleanup.h>
>>  
>>  #define MAX30102_DRV_NAME	"max30102"
>>  #define MAX30102_PART_NUMBER	0x15
>> @@ -468,6 +469,7 @@ static int max30102_read_raw(struct iio_dev *indio_dev,
>>  {
>>  	struct max30102_data *data = iio_priv(indio_dev);
>>  	int ret = -EINVAL;
>> +	bool direct_en;
>>  
>>  	switch (mask) {
>>  	case IIO_CHAN_INFO_RAW:
>> @@ -475,25 +477,13 @@ 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
>>  		 */
>> -any_mode_retry:
>> -		if (!iio_device_claim_buffer(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(indio_dev))
>> -				goto any_mode_retry;
>> +		scoped_guard(iio_device_claim, indio_dev) {
>
> scoped_guard() is sketchy in switch statements because there is
> a hidden for loop. If someone came along later and put a break;
> inside of the scope, it would break out of the hidden for loop
> rather than the apparent switch case!
>
> Besides that, it adds extra indent that we could avoid.
>
>> +			direct_en = !iio_buffer_enabled(indio_dev);
>>  
>> -			ret = max30102_get_temp(data, val, true);
>> -			iio_device_release_direct(indio_dev);
>> -		} else {
>> -			ret = max30102_get_temp(data, val, false);
>> -			iio_device_release_buffer(indio_dev);
>> +			ret = max30102_get_temp(data, val, direct_en);
>> +			if (ret)
>> +				return ret;
>>  		}
>> -		if (ret)
>> -			return ret;
>>  
>>  		ret = IIO_VAL_INT;
>>  		break;
>> 
>
> I would write the whole function like this:
>
> static int max30102_read_raw(struct iio_dev *indio_dev,
> 			     struct iio_chan_spec const *chan,
> 			     int *val, int *val2, long mask)
> {
> 	struct max30102_data *data = iio_priv(indio_dev);
> 	int ret;
>
> 	switch (mask) {
> 	case IIO_CHAN_INFO_RAW: {
> 		/*
> 		 * Temperature reading can only be acquired when not in
> 		 * shutdown; leave shutdown briefly when buffer not running
> 		 */
> 		guard(iio_device_claim)(indio_dev);

AFAIK you can't guard() inside switch-case blocks. I don't know the
exact reason, but it has to be scoped_guard().

> 		ret = max30102_get_temp(data, val, !iio_buffer_enabled(indio_dev));
> 		if (ret)
> 			return ret;
>
> 		return IIO_VAL_INT;
> 	}
> 	case IIO_CHAN_INFO_SCALE:
> 		*val = 1000;  /* 62.5 */
> 		*val2 = 16;
> 		return IIO_VAL_FRACTIONAL;
> 	default:
> 		return -EINVAL;
> 	}
> }
>
> Could also simplify things further by moving the call to iio_buffer_enabled()
> into max30102_get_temp().

I'll do it like this if this survives v2.


-- 
 ~ Kurt


  reply	other threads:[~2025-12-04 17:07 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03 19:18 [PATCH RFC 0/6] iio: core: Introduce cleanup.h support for mode locks Kurt Borja
2025-12-03 19:18 ` [PATCH RFC 1/6] iio: core: Match iio_device_claim_*() return semantics Kurt Borja
2025-12-04 14:23   ` Nuno Sá
2025-12-04 15:05     ` Andy Shevchenko
2025-12-06 18:07       ` Jonathan Cameron
2025-12-04 17:27     ` Kurt Borja
2025-12-06 18:05     ` Jonathan Cameron
2025-12-07 15:59       ` Kurt Borja
2025-12-03 19:18 ` [PATCH RFC 2/6] iio: core: Match iio_device_claim_*() naming Kurt Borja
2025-12-03 21:50   ` David Lechner
2025-12-04 17:35     ` Kurt Borja
2025-12-06 18:11       ` Jonathan Cameron
2025-12-03 19:18 ` [PATCH RFC 3/6] iio: core: Add cleanup.h support for iio_device_claim_*() Kurt Borja
2025-12-03 21:50   ` David Lechner
2025-12-03 22:34     ` David Lechner
2025-12-04 17:18       ` Kurt Borja
2025-12-04 17:36         ` Andy Shevchenko
2025-12-06 18:43           ` Jonathan Cameron
2025-12-06 20:40             ` Andy Shevchenko
2025-12-07 16:00             ` Kurt Borja
2025-12-06 18:20   ` Jonathan Cameron
2025-12-07 15:59     ` Kurt Borja
2025-12-03 19:18 ` [PATCH RFC 4/6] iio: light: vcnl4000: Use cleanup.h for IIO locks Kurt Borja
2025-12-03 22:19   ` David Lechner
2025-12-03 19:18 ` [PATCH RFC 5/6] iio: health: max30102: " Kurt Borja
2025-12-03 21:52   ` David Lechner
2025-12-04 17:07     ` Kurt Borja [this message]
2025-12-04 17:35       ` David Lechner
2025-12-04 17:47         ` Kurt Borja
2025-12-06 18:17           ` Jonathan Cameron
2025-12-07 15:59             ` Kurt Borja
2025-12-03 19:18 ` [PATCH RFC 6/6] iio: light: opt4060: " Kurt Borja
2025-12-03 22:40   ` David Lechner
2025-12-04 17:23     ` Kurt Borja
2025-12-04 14:42   ` Nuno Sá
2025-12-04 17:31     ` Kurt Borja
2025-12-04 14:36 ` [PATCH RFC 0/6] iio: core: Introduce cleanup.h support for mode locks Nuno Sá
2025-12-04 15:07   ` Andy Shevchenko
2025-12-06 18:46     ` Jonathan Cameron
2025-12-07 16:00       ` Kurt Borja
2025-12-09 10:34       ` Nuno Sá
2025-12-09 17:05         ` David Lechner
2025-12-10  9:17           ` Nuno Sá
2025-12-10 18:04             ` Jonathan Cameron
2025-12-04 17:33   ` Kurt Borja

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=DEPLIJFBZQ36.20XX5DCMCJVB3@gmail.com \
    --to=kuurtb@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=antoniu.miclaus@analog.com \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=dlechner@baylibre.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=perdaniel.olsson@axis.com \
    --cc=raskar.shree97@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.