Re: [PATCH 1/8] dt-bindings: iio: adc: stm32-adc: add support for stm32mp23 and stm32mp25

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 17 Sep 2026 09:27:10 +0200
Fabrice Gasnier <fabrice.gasnier@foss.st.com> wrote:

> On 9/17/26 04:53, Jonathan Cameron wrote:
> > On Tue, 15 Sep 2026 09:49:01 +0200
> > Fabrice Gasnier <fabrice.gasnier@foss.st.com> wrote:
> >   
> >> On 9/13/26 05:08, Jonathan Cameron wrote:  
> >>> On Fri, 11 Sep 2026 17:51:23 +0200
> >>> Fabrice Gasnier <fabrice.gasnier@foss.st.com> wrote:
> >>>     
> >>>> Add stm32mp23 and stm32mp25 compatibles. Three ADCs can be found on
> >>>> these SoCs, split into two blocks:
> >>>> - ADC12 are tightly coupled (common registers).
> >>>> - ADC3 is managed independently.
> >>>> Each ADC is a 12-bits successive approximation analog-to-digital converter,
> >>>> with up to 20 multiplexed channels that can be configured as single ended
> >>>> or differential.
> >>>>
> >>>> New property "st,adc-trigger-sel " allow to make the difference between
> >>>> the ADCs and to apply the correct trigger configuration.
> >>>>
> >>>> STM32 ADC may be in a power domain: allow a single 'power-domains'.
> >>>>
> >>>> Restrict the last channel (19), as it is wired directly to ADC Vref+.
> >>>> It's meaningless to have direct measurement. Internal Vref with
> >>>> calibration data from bsec (nvmem) must be used instead e.g. vrefint.
> >>>> Restrict deprecated properties (st,adc-channels, st,adc-diff-channels,
> >>>> st,min-sample-time-nsecs).
> >>>>
> >>>> Co-developed-by: Cheick Traore <cheick.traore-ext@st.com>
> >>>> Signed-off-by: Cheick Traore <cheick.traore-ext@st.com>
> >>>> Co-developed-by: Olivier Moysan <olivier.moysan@foss.st.com>
> >>>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> >>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>    
> >>>
> >>> Hi Fabrice, all,
> >>>     
> >>>> ---
> >>>>  .../devicetree/bindings/iio/adc/st,stm32-adc.yaml  | 106 ++++++++++++++++++---
> >>>>  1 file changed, 94 insertions(+), 12 deletions(-)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
> >>>> index c4c4575d3fa9..0e0ceaa3d8d6 100644
> >>>> --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
> >>>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
> >>>> @@ -23,11 +23,18 @@ maintainers:
> >>>>  
> >>>>  properties:
> >>>>    compatible:
> >>>> -    enum:
> >>>> -      - st,stm32f4-adc-core
> >>>> -      - st,stm32h7-adc-core
> >>>> -      - st,stm32mp1-adc-core
> >>>> -      - st,stm32mp13-adc-core
> >>>> +    oneOf:
> >>>> +      - items:
> >>>> +          - enum:
> >>>> +              - st,stm32f4-adc-core
> >>>> +              - st,stm32h7-adc-core
> >>>> +              - st,stm32mp1-adc-core
> >>>> +              - st,stm32mp13-adc-core
> >>>> +      - items:
> >>>> +          - enum:
> >>>> +              - st,stm32mp23-adc-core
> >>>> +              - st,stm32mp25-adc-core
> >>>> +          - const: st,stm32-adc-core    
> >>>
> >>> What is this?  Given these all vary in features
> >>> why would we fallback to a generic match for
> >>> these new compatibles?    
> >>
> >> Hi Jonathan, all
> >>
> >> Ack, I'll drop it in v2,
> >>  
> >>>
> >>>
> >>>     
> >>>>  additionalProperties: false
> >>>>  
> >>>>  required:
> >>>> @@ -239,11 +276,18 @@ patternProperties:
> >>>>  
> >>>>      properties:
> >>>>        compatible:
> >>>> -        enum:
> >>>> -          - st,stm32f4-adc
> >>>> -          - st,stm32h7-adc
> >>>> -          - st,stm32mp1-adc
> >>>> -          - st,stm32mp13-adc
> >>>> +        oneOf:
> >>>> +          - items:
> >>>> +              - enum:
> >>>> +                  - st,stm32f4-adc
> >>>> +                  - st,stm32h7-adc
> >>>> +                  - st,stm32mp1-adc
> >>>> +                  - st,stm32mp13-adc
> >>>> +          - items:
> >>>> +              - enum:
> >>>> +                  - st,stm32mp23-adc
> >>>> +                  - st,stm32mp25-adc
> >>>> +              - const: st,stm32-adc    
> >>>
> >>> Similar to above, what is this?    
> >>
> >> same,
> >>  
> >>>
> >>>     
> >>>> @@ -344,6 +388,12 @@ patternProperties:
> >>>>          items:
> >>>>            - const: vrefint
> >>>>  
> >>>> +      st,adc-trigger-sel:
> >>>> +        description: Selects the HW trigger configuration available on this ADC
> >>>> +        $ref: /schemas/types.yaml#/definitions/uint32
> >>>> +        enum: [0, 1]    
> >>>
> >>> Magic value that is meaningless to see in a dts.  If they
> >>> are effectively not compatible, give them different compatibles and
> >>> drop this property.  I'm unconvinced this property is more
> >>> useful than that given just how opaque the description is.    
> >>
> >> That's exactly what I was wondering about. As you suggest, I can remove
> >> this property, and introduce dedicated compatibles in V2, to clearly
> >> identify the differences.
> >>
> >> Need to distinguish:
> >> - ADC12 are tightly coupled (common registers).
> >> - ADC3 is managed independently.
> >> Triggers are different between them. The purpose of st,adc-trigger-sel
> >> was to identify that.
> >>
> >> Also MP23 and MP25 are also different (trigger list). Combining this
> >> would lead to introduce four compatibles, I'm thinking of:
> >> - st,stm32mp23-adc12
> >> - st,stm32mp23-adc3
> >> - st,stm32mp25-adc12
> >> - st,stm32mp25-adc3
> >>  
> > Naming wise, I wonder if it looks too much like adc twelve?
> > Not sure how to avoid that cleanly as adc1-2 seems odd too.  
> 
> Hi Jonathan,
> 
> Indeed, so could introduce one compatible per Soc/ADC ?
> 
> +          - st,stm32mp23-adc1
> +          - st,stm32mp23-adc2
> +          - st,stm32mp23-adc3
> +          - st,stm32mp25-adc1
> +          - st,stm32mp25-adc2
> +          - st,stm32mp25-adc3
> 
> There are some other differences between adc1 and adc2, e.g. in the
> reference manual:
> - ADC1 is connected to 18 external channels + 2 internal channels
> - ADC2 is connected to 14 external channels + 6 internal channels
> - ADC3 is connected to 14 external channels + 6 internal channels
> 
> This is resolved currently by channels child nodes with labels for
> internal channels. So maybe better to name all of them (future proof) ?
Yes. Ideally the binding would be constraining the channel nodes
and we'd need the compatible to do that.

Seems like we have a winner - separate compatibles :)

Jonathan

> 
> Please advise,
> Best Regards,
> Fabrice
> 
> >   
> >> I plan to update it in v2.
> >>
> >> Thanks,
> >> Fabrice
> >>  
> >>>
> >>>
> >>>     
> >>  
> >   
> 
>