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

[Olivier MOYSAN]

Hi Andy, Jonathan,

Sorry for the late answer.

On 6/21/26 16:10, Jonathan Cameron wrote:
> On Sat, 13 Jun 2026 16:39:16 +0300
> Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
>
> > On Fri, Jun 12, 2026 at 04:51:50PM -0500, Rob Herring (Arm) wrote:
> > > The "st,adc-alt-channel" and "st,filter0-sync" properties are
> > > documented as boolean flags. The legacy parser read them as integer
> > > cells, unlike the child-node parser which already checks only for
> > > presence.
> > >
> > > Use presence and boolean helpers so both parsers follow the binding and
> > > the property type checker no longer reports the flags.
> >
> > For the patch
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
> >
> > However one interesting remark below.
> >
> > ...
> >
> > > -	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.
>
> Thanks,
>
> Jonathan

I confirm that the current legacy path is functional
(With the st,adc-alt-channel property fix applied)

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.

BRs
Olivier

> > > +					    "st,adc-alt-channel");