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

[Fabrice Gasnier]

On 9/17/26 04:53, Jonathan Cameron wrote:
> On Tue, 15 Sep 2026 09:49:01 +0200
> Fabrice Gasnier <fabrice.gasnier at 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 at 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 at st.com>
>>>> Signed-off-by: Cheick Traore <cheick.traore-ext at st.com>
>>>> Co-developed-by: Olivier Moysan <olivier.moysan at foss.st.com>
>>>> Signed-off-by: Olivier Moysan <olivier.moysan at foss.st.com>
>>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier at 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) ?

Please advise,
Best Regards,
Fabrice

> 
>> I plan to update it in v2.
>>
>> Thanks,
>> Fabrice
>>
>>>
>>>
>>>   
>>
>