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

From: Fabrice Gasnier

Date: Thu Sep 17 2026 - 03:30:46 EST


On 9/17/26 04:53, Jonathan Cameron wrote:
> On Tue, 15 Sep 2026 09:49:01 +0200
> Fabrice Gasnier <fabrice.gasnier@xxxxxxxxxxx> wrote:
>
>> On 9/13/26 05:08, Jonathan Cameron wrote:
>>> On Fri, 11 Sep 2026 17:51:23 +0200
>>> Fabrice Gasnier <fabrice.gasnier@xxxxxxxxxxx> 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@xxxxxx>
>>>> Signed-off-by: Cheick Traore <cheick.traore-ext@xxxxxx>
>>>> Co-developed-by: Olivier Moysan <olivier.moysan@xxxxxxxxxxx>
>>>> Signed-off-by: Olivier Moysan <olivier.moysan@xxxxxxxxxxx>
>>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@xxxxxxxxxxx>
>>>
>>> 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
>>
>>>
>>>
>>>
>>
>