Re: [PATCH] iio: stm32-dfsdm: Treat flags as booleans

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Tue, Jun 23, 2026 at 11:43:49AM +0200, Olivier MOYSAN wrote:
> On 6/21/26 16:10, Jonathan Cameron wrote:
> > On Sat, 13 Jun 2026 16:39:16 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > On Fri, Jun 12, 2026 at 04:51:50PM -0500, Rob Herring (Arm) wrote:

...

> > > > -	ret = of_property_read_u32_index(indio_dev->dev.of_node,
> > > > -					 "st,adc-alt-channel", chan_idx,
> > > > -					 &df_ch->alt_si);
> > > 
> > > > +	df_ch->alt_si = of_property_present(indio_dev->dev.of_node,
> > > 
> > > I believe it still has another (serious?) issue. We usually don't use indio_dev
> > > for device properties. It's not a device that is described in DT.
> > > It seems the only driver in IIO that does that. Note, I haven't conducted any
> > > deeper research, it might be (however I'm quite in doubt) that this is correct
> > > use and one device registers a few indio_dev:s.
> > 
> > It is curious.  The registration sequence in this driver is complex, but I'm not
> > seeing anything that sets the fwnode for the struct iio_dev->dev before calling
> > the init() callbacks that end up in this code.  It is set later by iio_device_register()
> > (iirc that has something to do with consumers turning up later).
> > 
> > St folk could you take a look at this and see what we are missing
> > if it does currently work?
> > 
> > For now I'll apply this patch but might need to drop it if a fix clashes
> > with it.
> 
> I confirm that the current legacy path is functional
> (With the st,adc-alt-channel property fix applied)

Yeah, it's here
https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/adc/stm32-dfsdm-adc.c#L1772
and should gone. Basically one wants to replace all these to use device and
fwnode propery APIs and proper device node, without that hack.

> It currently works because the driver initializes np from dev->of_node in
> probe, and that value is then used in init callbacks.
> 
> I agree that this approach is not robust, as it depends on initialization
> sequencing and on using an IIO object that is not the DT owner object. I
> will prepare a patch to use the DT device directly as the single source for
> DT properties.
> 
> I also suggest keeping a fallback path for st,adc-alt-channel so we do not
> break legacy DTs that have not yet migrated to the new binding.
> I prepare this also.

-- 
With Best Regards,
Andy Shevchenko