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

[Fabrice Gasnier]

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

I plan to update it in v2.

Thanks,
Fabrice

> 
> 
>