From: Jonathan Cameron <jic23@kernel.org>
To: Archit Anant <architanant5@gmail.com>
Cc: lars@metafoo.de, Michael.Hennerich@analog.com,
dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
linux-iio@vger.kernel.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/4] iio: adc: ad799x: cache regulator voltages during probe
Date: Sat, 21 Mar 2026 18:27:10 +0000 [thread overview]
Message-ID: <20260321182710.1621d1aa@jic23-huawei> (raw)
In-Reply-To: <20260318092715.42538-4-architanant5@gmail.com>
On Wed, 18 Mar 2026 14:57:14 +0530
Archit Anant <architanant5@gmail.com> wrote:
> Reading the regulator voltage via regulator_get_voltage() can be a slow
> operation.
Whilst that might be true, it isn't a reason for this change.
Sysfs reads that would cause it to be read are never a particularly
fast path anyway. So drop this first sentence.
> Since the reference voltages for this ADC are not expected to
> change at runtime, it is inefficient to query the regulator API every
> time userspace reads the IIO_CHAN_INFO_SCALE attribute.
>
> Determine the active reference voltage (either VREF or VCC) during
> probe() and cache it in the state structure. This improves the
> performance of ad799x_read_raw() and removes the dependency on the
> regulator pointers during fast-path reads.
>
> Suggested-by: Jonathan Cameron <jic23@kernel.org>
> Suggested-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Archit Anant <architanant5@gmail.com>
A suggested alternative approach inline.
Thanks,
Jonathan
> ---
> drivers/iio/adc/ad799x.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/ad799x.c b/drivers/iio/adc/ad799x.c
> index 7504bcf627da..ae2ad4bd37cc 100644
> --- a/drivers/iio/adc/ad799x.c
> +++ b/drivers/iio/adc/ad799x.c
> @@ -30,6 +30,7 @@
> #include <linux/module.h>
> #include <linux/mutex.h>
> #include <linux/bitops.h>
> +#include <linux/units.h>
>
> #include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
> @@ -135,6 +136,9 @@ struct ad799x_state {
> u16 config;
>
> unsigned int transfer_size;
> +
> + int vref_uV;
> +
> IIO_DECLARE_BUFFER_WITH_TS(__be16, rx_buf, AD799X_MAX_CHANNELS);
> };
>
> @@ -302,14 +306,7 @@ static int ad799x_read_raw(struct iio_dev *indio_dev,
> GENMASK(chan->scan_type.realbits - 1, 0);
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SCALE:
> - if (st->vref)
> - ret = regulator_get_voltage(st->vref);
> - else
> - ret = regulator_get_voltage(st->reg);
> -
> - if (ret < 0)
> - return ret;
> - *val = ret / 1000;
> + *val = st->vref_uV / MILLI;
> *val2 = chan->scan_type.realbits;
> return IIO_VAL_FRACTIONAL_LOG2;
> }
> @@ -828,9 +825,20 @@ static int ad799x_probe(struct i2c_client *client)
> ret = regulator_enable(st->vref);
> if (ret)
> goto error_disable_reg;
> + ret = regulator_get_voltage(st->vref);
For vref I don't think we need to keep the regulator around, so you should
be able to use devm_regulator_get_enable_read_voltage() with checking
for -ENODEV to identify it simply isn't there.
It would need a tiny bit of reordering though or a custom
devm_add_action_or_reset() registered callback to ensure that regulator
disable for vcc happens in reverse sequence of what happens on setup.
Anyone think there are actually ordering constraints on these regulators?
Would be fairly unusual for this sort of device, but not impossible.
If not, cleanest option might be;
ret = devm_regulator_get_enable_read_voltage(dev, "vref");
if (ret < 0 && ret != -ENODEV){ //get the actual error out the way first.
return ret;
if (ret == -ENODEV) {
ret = devm_regulator_get_enable_read_voltage(dev, "vcc");
if (ret < 0)
return ret;
st->vref_uv = ret;
} else {
st->vref_uv = ret;
ret = devm_regulator_get_enabled(dev, "vcc);
if (ret)
return ret;
}
Then no need to undo anything by hand in remove() and no need to keep
a pointer to any regulators around for later.
> + if (ret < 0)
> + goto error_disable_vref;
> + st->vref_uV = ret;
> }
> }
>
> + if (!st->vref) {
> + ret = regulator_get_voltage(st->reg);
> + if (ret < 0)
> + goto error_disable_reg;
> + st->vref_uV = ret;
> + }
> +
> st->client = client;
>
> indio_dev->name = id->name;
next prev parent reply other threads:[~2026-03-21 18:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 9:27 [PATCH v5 0/4] iio: adc: ad799x: modernize resource management Archit Anant
2026-03-18 9:27 ` [PATCH v5 1/4] iio: adc: ad799x: use local device pointer in probe Archit Anant
2026-03-18 9:27 ` [PATCH v5 2/4] iio: adc: ad799x: use a static buffer for scan data Archit Anant
2026-03-18 9:27 ` [PATCH v5 3/4] iio: adc: ad799x: cache regulator voltages during probe Archit Anant
2026-03-18 14:40 ` Andy Shevchenko
2026-03-19 2:36 ` Archit Anant
2026-03-21 18:27 ` Jonathan Cameron [this message]
2026-03-23 7:55 ` Andy Shevchenko
2026-03-23 12:22 ` Archit Anant
2026-03-23 14:39 ` David Lechner
2026-03-23 17:55 ` Jonathan Cameron
2026-03-24 17:20 ` Archit Anant
2026-03-18 9:27 ` [PATCH v5 4/4] iio: adc: ad799x: use devm_iio_device_register and drop remove() Archit Anant
2026-03-18 14:43 ` Andy Shevchenko
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=20260321182710.1621d1aa@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=architanant5@gmail.com \
--cc=dlechner@baylibre.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=nuno.sa@analog.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