Re: [PATCH] iio: dac: Fix passing uninitialized vref1_uV for no Vref1 case

[<Ariana.Lazar@microchip.com>]

Hi Andy,

On Tue, 2026-04-14 at 15:48 +0300, Andy Shevchenko wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On Tue, Apr 14, 2026 at 03:33:38PM +0300, Ariana Lazar wrote:
> > Initialize vref1_uV variable to 0 before calling
> > mcp47feb02_init_ch_scales() in mcp47feb02_probe() to avoid passing
> > an
> > uninitialized value when have_ext_vref1 is false.
> 
> ...
> 
> > +     vref1_uV = 0;
> >       if (chip_features->have_ext_vref1) {
> 
> I'm wondering what will happen if we do the below unconditionally?
> 
> >               ret = devm_regulator_get_enable_read_voltage(dev,
> > "vref1");
> 
> If we have no regulator, we get a dummy one, right? What is the
> voltage will
> be? 0?
> 
> >               if (ret > 0) {
> >                       vref1_uV = ret;
> >                       data->use_vref1 = true;
> >               } else {
> > -                     vref1_uV = 0;
> >                       dev_dbg(dev, "using internal band gap as
> > voltage reference 1.\n");
> >                       dev_dbg(dev, "Vref1 is unavailable.\n");
> >               }

Thank you for the review.

This is a safety check to ensure the devicetree matches the available
hardware. If Vref1 was selected in devicetree but unavailable in
hardware, the scales MCP47FEB02_SCALE_GAIN_X1 and
MCP47FEB02_SCALE_GAIN_X2 and also voltage readings would be incorrect
for the channels that use Vref1.

I did something similiar to what you have suggested in the first patch
I have submitted for this driver and checking first was recommended.

https://lore.kernel.org/all/20250927185324.2f9e8061@jic23-huawei/

Best regards,
Ariana