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

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

[Rob Herring (Arm)]

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.

Assisted-by: Codex:gpt-5-5
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
 drivers/iio/adc/stm32-dfsdm-adc.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index 9664b9bd75d4..00f05e167afc 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -660,11 +660,8 @@ static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
 	}
 	df_ch->src = val;
 
-	ret = of_property_read_u32_index(indio_dev->dev.of_node,
-					 "st,adc-alt-channel", chan_idx,
-					 &df_ch->alt_si);
-	if (ret < 0)
-		df_ch->alt_si = 0;
+	df_ch->alt_si = of_property_present(indio_dev->dev.of_node,
+					    "st,adc-alt-channel");
 
 	return 0;
 }
@@ -1815,9 +1812,8 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
 
 	adc->dfsdm->fl_list[adc->fl_id].ford = val;
 
-	ret = of_property_read_u32(dev->of_node, "st,filter0-sync", &val);
-	if (!ret)
-		adc->dfsdm->fl_list[adc->fl_id].sync_mode = val;
+	adc->dfsdm->fl_list[adc->fl_id].sync_mode =
+		of_property_read_bool(dev->of_node, "st,filter0-sync");
 
 	adc->dev_data = dev_data;
 	ret = dev_data->init(dev, iio);
-- 
2.53.0

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

[Andy Shevchenko]

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@intel.com>

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.

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

-- 
With Best Regards,
Andy Shevchenko

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@intel.com> 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@intel.com>
>>
>> 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");
>>
> 
> 

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

[Andy Shevchenko]

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

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

[Jonathan Cameron]

On Tue, 23 Jun 2026 12:54:36 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> 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.

If we 'were' going to keep this it should have been using the helper
to set that. I thought all those had been cleaned up so didn't check
for it being directly written :(  Obviously this comment is irrelevant
given the code is going away!

Jonathan

> 
> > 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.  
>