* [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
@ 2026-02-10 17:51 Antoniu Miclaus
2026-02-10 19:35 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: Antoniu Miclaus @ 2026-02-10 17:51 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Antoniu Miclaus, linux-iio, linux-kernel
Simplify probe by using devm_regulator_get_enable_read_voltage() to
get, enable and read the regulator voltage in a single call, caching
the value at probe time.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
drivers/iio/dac/max5522.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/iio/dac/max5522.c b/drivers/iio/dac/max5522.c
index 1b8fe6b8d26e..cda1cf572e77 100644
--- a/drivers/iio/dac/max5522.c
+++ b/drivers/iio/dac/max5522.c
@@ -34,7 +34,7 @@ struct max5522_state {
struct regmap *regmap;
const struct max5522_chip_info *chip_info;
unsigned short dac_cache[2];
- struct regulator *vrefin_reg;
+ unsigned short vref_mv;
};
#define MAX5522_CHANNEL(chan) { \
@@ -79,17 +79,13 @@ static int max5522_read_raw(struct iio_dev *indio_dev,
int *val, int *val2, long info)
{
struct max5522_state *state = iio_priv(indio_dev);
- int ret;
switch (info) {
case IIO_CHAN_INFO_RAW:
*val = state->dac_cache[chan->channel];
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
- ret = regulator_get_voltage(state->vrefin_reg);
- if (ret < 0)
- return -EINVAL;
- *val = ret / 1000;
+ *val = state->vref_mv;
*val2 = 10;
return IIO_VAL_FRACTIONAL_LOG2;
default:
@@ -147,16 +143,11 @@ static int max5522_spi_probe(struct spi_device *spi)
if (!state->chip_info)
return -EINVAL;
- state->vrefin_reg = devm_regulator_get(&spi->dev, "vrefin");
- if (IS_ERR(state->vrefin_reg))
- return dev_err_probe(&spi->dev, PTR_ERR(state->vrefin_reg),
- "Vrefin regulator not specified\n");
-
- ret = regulator_enable(state->vrefin_reg);
- if (ret) {
+ ret = devm_regulator_get_enable_read_voltage(&spi->dev, "vrefin");
+ if (ret < 0)
return dev_err_probe(&spi->dev, ret,
- "Failed to enable vref regulators\n");
- }
+ "Failed to get vrefin regulator\n");
+ state->vref_mv = ret / 1000;
state->regmap = devm_regmap_init_spi(spi, &max5522_regmap_config);
--
2.43.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
2026-02-10 17:51 [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage() Antoniu Miclaus
@ 2026-02-10 19:35 ` Andy Shevchenko
2026-02-14 18:20 ` Jonathan Cameron
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2026-02-10 19:35 UTC (permalink / raw)
To: Antoniu Miclaus
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
On Tue, Feb 10, 2026 at 07:51:27PM +0200, Antoniu Miclaus wrote:
> Simplify probe by using devm_regulator_get_enable_read_voltage() to
> get, enable and read the regulator voltage in a single call, caching
> the value at probe time.
...
> - struct regulator *vrefin_reg;
> + unsigned short vref_mv;
vref_mV ?
...
> + state->vref_mv = ret / 1000;
"1000" --> "(MICRO / MILLI)" ?
(yes, this way with the parentheses).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
2026-02-10 19:35 ` Andy Shevchenko
@ 2026-02-14 18:20 ` Jonathan Cameron
2026-02-14 18:31 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Cameron @ 2026-02-14 18:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Antoniu Miclaus, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
On Tue, 10 Feb 2026 21:35:26 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Feb 10, 2026 at 07:51:27PM +0200, Antoniu Miclaus wrote:
> > Simplify probe by using devm_regulator_get_enable_read_voltage() to
> > get, enable and read the regulator voltage in a single call, caching
> > the value at probe time.
>
> ...
>
> > - struct regulator *vrefin_reg;
> > + unsigned short vref_mv;
>
> vref_mV ?
>
> ...
>
> > + state->vref_mv = ret / 1000;
>
> "1000" --> "(MICRO / MILLI)" ?
> (yes, this way with the parentheses).
I know I've argued against proliferation of the X_PER_Y macros
but this one does seem to be very common. Maybe it's time to bring in
MICROVOLTS_PER_MILLIVOLT even if it's longer than the open coded version?
Andy, what do you think? I do worry that people will see it as fine
to add many many others if we start with this one though. So maybe not.
Anyhow, doesn't need to be in this series.
Jonathan
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
2026-02-14 18:20 ` Jonathan Cameron
@ 2026-02-14 18:31 ` Andy Shevchenko
2026-02-14 18:36 ` David Lechner
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2026-02-14 18:31 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Antoniu Miclaus, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
On Sat, Feb 14, 2026 at 06:20:52PM +0000, Jonathan Cameron wrote:
> On Tue, 10 Feb 2026 21:35:26 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Feb 10, 2026 at 07:51:27PM +0200, Antoniu Miclaus wrote:
...
> > > + state->vref_mv = ret / 1000;
> >
> > "1000" --> "(MICRO / MILLI)" ?
> > (yes, this way with the parentheses).
>
> I know I've argued against proliferation of the X_PER_Y macros
> but this one does seem to be very common. Maybe it's time to bring in
>
> MICROVOLTS_PER_MILLIVOLT even if it's longer than the open coded version?
>
> Andy, what do you think? I do worry that people will see it as fine
> to add many many others if we start with this one though. So maybe not.
IIRC (sorry, if I am wrong) it was you who objected in the first place
and I proposed that from day 1 discussing the "(MICRO / MILLI)" approach
a year (?) or so ago. Answering to the Q: I am in favour of having that
definition.
> Anyhow, doesn't need to be in this series.
True.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
2026-02-14 18:31 ` Andy Shevchenko
@ 2026-02-14 18:36 ` David Lechner
2026-02-15 7:53 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: David Lechner @ 2026-02-14 18:36 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Cameron
Cc: Antoniu Miclaus, Nuno Sá, Andy Shevchenko, linux-iio,
linux-kernel
On 2/14/26 12:31 PM, Andy Shevchenko wrote:
> On Sat, Feb 14, 2026 at 06:20:52PM +0000, Jonathan Cameron wrote:
>> On Tue, 10 Feb 2026 21:35:26 +0200
>> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>>> On Tue, Feb 10, 2026 at 07:51:27PM +0200, Antoniu Miclaus wrote:
>
> ...
>
>>>> + state->vref_mv = ret / 1000;
>>>
>>> "1000" --> "(MICRO / MILLI)" ?
>>> (yes, this way with the parentheses).
>>
>> I know I've argued against proliferation of the X_PER_Y macros
>> but this one does seem to be very common. Maybe it's time to bring in
>>
>> MICROVOLTS_PER_MILLIVOLT even if it's longer than the open coded version?
>>
>> Andy, what do you think? I do worry that people will see it as fine
>> to add many many others if we start with this one though. So maybe not.
>
> IIRC (sorry, if I am wrong) it was you who objected in the first place
> and I proposed that from day 1 discussing the "(MICRO / MILLI)" approach
> a year (?) or so ago. Answering to the Q: I am in favour of having that
> definition.
>
>> Anyhow, doesn't need to be in this series.
>
> True.
>
How about MICRO_PER_MILLI? Then we won't have to add a new one
for every different type of unit.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
2026-02-14 18:36 ` David Lechner
@ 2026-02-15 7:53 ` Andy Shevchenko
2026-02-15 16:00 ` Jonathan Cameron
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2026-02-15 7:53 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Antoniu Miclaus, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
On Sat, Feb 14, 2026 at 12:36:12PM -0600, David Lechner wrote:
> On 2/14/26 12:31 PM, Andy Shevchenko wrote:
> > On Sat, Feb 14, 2026 at 06:20:52PM +0000, Jonathan Cameron wrote:
> >> On Tue, 10 Feb 2026 21:35:26 +0200
> >> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >>> On Tue, Feb 10, 2026 at 07:51:27PM +0200, Antoniu Miclaus wrote:
...
> >>>> + state->vref_mv = ret / 1000;
> >>>
> >>> "1000" --> "(MICRO / MILLI)" ?
> >>> (yes, this way with the parentheses).
> >>
> >> I know I've argued against proliferation of the X_PER_Y macros
> >> but this one does seem to be very common. Maybe it's time to bring in
> >>
> >> MICROVOLTS_PER_MILLIVOLT even if it's longer than the open coded version?
> >>
> >> Andy, what do you think? I do worry that people will see it as fine
> >> to add many many others if we start with this one though. So maybe not.
> >
> > IIRC (sorry, if I am wrong) it was you who objected in the first place
> > and I proposed that from day 1 discussing the "(MICRO / MILLI)" approach
> > a year (?) or so ago. Answering to the Q: I am in favour of having that
> > definition.
> >
> >> Anyhow, doesn't need to be in this series.
> >
> > True.
>
> How about MICRO_PER_MILLI? Then we won't have to add a new one
> for every different type of unit.
Dunno, as a physicist, I prefer the way with units.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage()
2026-02-15 7:53 ` Andy Shevchenko
@ 2026-02-15 16:00 ` Jonathan Cameron
0 siblings, 0 replies; 7+ messages in thread
From: Jonathan Cameron @ 2026-02-15 16:00 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Lechner, Antoniu Miclaus, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
On Sun, 15 Feb 2026 09:53:08 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Sat, Feb 14, 2026 at 12:36:12PM -0600, David Lechner wrote:
> > On 2/14/26 12:31 PM, Andy Shevchenko wrote:
> > > On Sat, Feb 14, 2026 at 06:20:52PM +0000, Jonathan Cameron wrote:
> > >> On Tue, 10 Feb 2026 21:35:26 +0200
> > >> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > >>> On Tue, Feb 10, 2026 at 07:51:27PM +0200, Antoniu Miclaus wrote:
>
> ...
>
> > >>>> + state->vref_mv = ret / 1000;
> > >>>
> > >>> "1000" --> "(MICRO / MILLI)" ?
> > >>> (yes, this way with the parentheses).
> > >>
> > >> I know I've argued against proliferation of the X_PER_Y macros
> > >> but this one does seem to be very common. Maybe it's time to bring in
> > >>
> > >> MICROVOLTS_PER_MILLIVOLT even if it's longer than the open coded version?
> > >>
> > >> Andy, what do you think? I do worry that people will see it as fine
> > >> to add many many others if we start with this one though. So maybe not.
> > >
> > > IIRC (sorry, if I am wrong) it was you who objected in the first place
> > > and I proposed that from day 1 discussing the "(MICRO / MILLI)" approach
> > > a year (?) or so ago. Answering to the Q: I am in favour of having that
> > > definition.
Yup. I got convinced over time! I still a little doubtful but
seemed like it was worth revisiting the question.
> > >
> > >> Anyhow, doesn't need to be in this series.
> > >
> > > True.
> >
> > How about MICRO_PER_MILLI? Then we won't have to add a new one
> > for every different type of unit.
I think it only commonly occurs for voltage because of the whole
mismatch between the regulators framework and both IIO and HWMON
in units. That's based on gut feel though rather actually checking
the code.
Jonathan
>
> Dunno, as a physicist, I prefer the way with units.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-02-15 16:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-10 17:51 [PATCH] iio: dac: max5522: use devm_regulator_get_enable_read_voltage() Antoniu Miclaus
2026-02-10 19:35 ` Andy Shevchenko
2026-02-14 18:20 ` Jonathan Cameron
2026-02-14 18:31 ` Andy Shevchenko
2026-02-14 18:36 ` David Lechner
2026-02-15 7:53 ` Andy Shevchenko
2026-02-15 16:00 ` Jonathan Cameron
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox