Re: [PATCH 2/2] iio: dac: add support for Microchip MCP48FEB02

[Jonathan Cameron]

On Fri, 24 Apr 2026 13:30:59 +0000
<Ariana.Lazar@xxxxxxxxxxxxx> wrote:

> Hi Jonathan,
> 
> > 
> > The statement above about it not being possible to use the internal
> > band gap
> > if a vref is wired leaves me with more questions about this.
> > 
> > I'm a bit concerned about cases like:
> > 
> > Vref is wired and eeprom is set for internal reference.   Should we
> > be very careful to not enable vref until that situation is resolved?
> > It might be on anyway but we can at least make sure we are reponsible
> > for turning it on.
> > 
> > Maybe the chip has sufficient protective elements to cope with that
> > though obviously it won't give sensible output whilst this is true.
> > 
> > If all those are fine, dev_info() makes sense to me.
> > I wonder if we should return -EBUSY for attempts to read the voltage
> > back whilst in this state as well?  Might provide some additional
> > indication something is mismatched and we don't expect the device to
> > work
> > correctly.
> >   
> 
> There are 2 possible ways to handle this:
> 
> - Keep the current approach, since restoring a mismatching
> configuration at power-up should not damage the device.
If it were just the device I'd agree, but the provision of vref
is an external thing.  Say some other OS was loaded in between
and didn't enable that regulator, + chose to use the internal
vref (maybe with resistor to pull up or down on that pin if no one
is driving it). 

> - As you suggested, only read the external regulator voltage at probe
> to compute the related scale and enable the regulator when user space
> first selects that scale.
To me this seems slightly better. Though if the device is actually fine
(if non functioning correctly) with internal band gap on and vref at
max voltage then doesn't matter.

> 
> In both cases, if you agree, I can return -EBUSY for RAW access until
> the correct scale is written from user space.

I think that probably makes sense if we are in a state that we
believe won't read a value that is correct.

> 
> I will also improve the current messages in order to ensure the user
> sets the correct configuration before attempting to read voltage.
> 
> Best regards,
> Ariana
> 
> 
> 
> 
> 
> 
>