linux-kernel - Re: [PATCH 3/7] iio: adc: Add support for ad4062

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <o4kt2of4xql4azufjgiecm4jzuexgm6nkvr7aghbwfk6qd7yqd@r4plggehzces>
Date: Mon, 24 Nov 2025 09:57:26 +0100
From: Jorge Marques <gastmaier@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Jonathan Cameron <jic23@...nel.org>, 
	Jorge Marques <jorge.marques@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, 
	Michael Hennerich <Michael.Hennerich@...log.com>, David Lechner <dlechner@...libre.com>, 
	Nuno Sá <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jonathan Corbet <corbet@....net>, linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH 3/7] iio: adc: Add support for ad4062

On Mon, Nov 24, 2025 at 09:43:09AM +0200, Andy Shevchenko wrote:
> On Sun, Nov 23, 2025 at 08:48:09PM +0100, Jorge Marques wrote:
> > On Sat, Oct 18, 2025 at 05:10:32PM +0100, Jonathan Cameron wrote:
> > > On Mon, 13 Oct 2025 09:28:01 +0200
> > > Jorge Marques <jorge.marques@...log.com> wrote:
> 
> > Mostly acknowledgements and explanations, except a comment on ACQUIRE usage.
> 
> ...
> 

Hi Andy,

> > > > +static int ad4062_read_chan_raw(struct iio_dev *indio_dev, int *val)
> > > > +{
> > > > +	struct ad4062_state *st = iio_priv(indio_dev);
> > > > +	int ret;
> > > > +
> > > > +	ret = pm_runtime_resume_and_get(&st->i3cdev->dev);
> > > There is a nice new
> > > 	ACQUIRE()/ACQUIRE_ERR() related set of conditional guards defined that
> > > let you do this using cleanup.h style.
> > > 
> > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a0abc39450a3123fd52533a662fbd37e0d1508c
> > > 
> > > This looks like a perfect example of where those help.
> > > 
> > > When I catch up with review backlog I plan to look for other
> > > places to use that infrastructure in IIO.
> > > 
> > I tried implementing, here becomes
> > 
> >         ACQUIRE(pm_runtime_active_try_enabled, pm)(&st->i3cdev->dev);
> >         ret = ACQUIRE_ERR(pm_runtime_active_try_enabled, &pm);
> > 
> > At buffer and monitor, since we put the device as active during the
> > lifetime of the buffer and monitor mode, either I leave as is, or I bump
> > the counter with pm_runtime_get_noresume, so when the method leaves, the
> > counter drops to 1 and not 0, then on disable I drop the counter back to
> > 0 and queue the autosuspend with pm_runtime_put_autosuspend.
> > > 
> > > > +	if (ret)
> > > > +		return ret;
> > > > +
> > > > +	ret = ad4062_set_operation_mode(st, st->mode);
> > > > +	if (ret)
> > > > +		goto out_error;
> > > > +
> > > > +	ret = __ad4062_read_chan_raw(st, val);
> > > > +
> > > > +out_error:
> > > > +	pm_runtime_put_autosuspend(&st->i3cdev->dev);
> > > > +	return ret;
> > > > +}
> 
> I read the above code, I read it again, I don't understand the reasoning.
> The ACQUIRE() doesn't change the behaviour of the above code.
> 
> If you need to bump the reference counter, it should be done somewhere else
> where it affects the flow, or this code has a bug.
> 
> If I miss something, please elaborate.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

The part highlighted does not require bumping the reference counter, but
at the buffer acquisition and monitor mode, to not put the device back
in low power mode during the lifetime of those operations.

Buffer more:

  static int ad4062_triggered_buffer_postenable(struct iio_dev *indio_dev)
  {
          struct ad4062_state *st = iio_priv(indio_dev);
          int ret;

	  // [ Some code ]

          ACQUIRE(pm_runtime_active_try_enabled, pm)(&st->i3cdev->dev);
          ret = ACQUIRE_ERR(pm_runtime_active_try_enabled, &pm);
          if (ret)
                  return ret;

	  // [ More code ]

          pm_runtime_get_noresume(&st->i3cdev->dev);
          return 0;
  }

  static int ad4062_triggered_buffer_predisable(struct iio_dev *indio_dev)
  {
          struct ad4062_state *st = iio_priv(indio_dev);

          pm_runtime_put_autosuspend(&st->i3cdev->dev);
          return 0;
  }

Monitor mode:

  static int ad4062_monitor_mode_enable(struct ad4062_state *st, bool enable)
  {
          int ret = 0;

          if (!enable) {
                  pm_runtime_put_autosuspend(&st->i3cdev->dev);
                  return 0;
          }

          ACQUIRE(pm_runtime_active_try_enabled, pm)(&st->i3cdev->dev);
          ret = ACQUIRE_ERR(pm_runtime_active_try_enabled, &pm);
          if (ret)
                  return ret;

	  // [ Some code ]

          pm_runtime_get_noresume(&st->i3cdev->dev);
          return 0;
  }

The raw read does not require this behaviour, when the method returns,
the device returns to low power mode:

  static int ad4062_read_chan_raw(struct ad4062_state *st, int *val)
  {
          int ret;

          ACQUIRE(pm_runtime_active_try_enabled, pm)(&st->i3cdev->dev);
          ret = ACQUIRE_ERR(pm_runtime_active_try_enabled, &pm);
          if (ret)
                  return ret;

          ret = ad4062_set_operation_mode(st, st->mode);
          if (ret)
                  return ret;

          return __ad4062_read_chan_raw(st, val);
  }

I will submitted v2 shortly.

Best Regards,
Jorge