All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Marek Vasut" <marex@nabladev.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"Cheick Traore" <cheick.traore-ext@st.com>,
	"Olivier Moysan" <olivier.moysan@foss.st.com>
Subject: Re: [PATCH 1/8] dt-bindings: iio: adc: stm32-adc: add support for stm32mp23 and stm32mp25
Date: Thu, 17 Sep 2026 03:53:38 +0100	[thread overview]
Message-ID: <20260917035338.2ef5ded6@jic23-hlaptop> (raw)
In-Reply-To: <6e28ede2-686c-4972-8a15-348ae090cec8@foss.st.com>

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.

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


  reply	other threads:[~2026-09-17  2:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 15:51 [PATCH 0/8] iio: adc: stm32: add support for stm32mp23 and stm32mp25 Fabrice Gasnier
2026-09-11 15:51 ` [PATCH 1/8] dt-bindings: iio: adc: stm32-adc: " Fabrice Gasnier
2026-09-11 16:02   ` sashiko-bot
2026-09-11 18:08   ` Marek Vasut
2026-09-13  3:08   ` Jonathan Cameron
2026-09-15  7:49     ` Fabrice Gasnier
2026-09-17  2:53       ` Jonathan Cameron [this message]
2026-09-17  7:27         ` Fabrice Gasnier
2026-09-21  2:05           ` Jonathan Cameron
2026-09-11 15:51 ` [PATCH 2/8] iio: adc: stm32-adc: manage characterization voltage diversity Fabrice Gasnier
2026-09-11 16:10   ` Andy Shevchenko
2026-09-11 16:15   ` sashiko-bot
2026-09-11 15:51 ` [PATCH 3/8] iio: adc: stm32-adc: add support for stm32mp23 and stm32mp25 Fabrice Gasnier
2026-09-11 16:22   ` Andy Shevchenko
2026-09-11 16:26   ` sashiko-bot
2026-09-13  3:25   ` Jonathan Cameron
2026-09-11 15:51 ` [PATCH 4/8] arm64: dts: st: add vrefint calibration on stm32mp23 Fabrice Gasnier
2026-09-11 18:10   ` Marek Vasut
2026-09-11 15:51 ` [PATCH 5/8] arm64: dts: st: add vrefint calibration on stm32mp25 Fabrice Gasnier
2026-09-11 15:51 ` [PATCH 6/8] arm64: dts: st: add ADC nodes on stm32mp231 Fabrice Gasnier
2026-09-11 15:51 ` [PATCH 7/8] arm64: dts: st: add ADC nodes on stm32mp251 Fabrice Gasnier
2026-09-11 15:51 ` [PATCH 8/8] arm64: dts: st: add ADC support on stm32mp257f-ev1 board Fabrice Gasnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260917035338.2ef5ded6@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andy@kernel.org \
    --cc=cheick.traore-ext@st.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marex@nabladev.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=olivier.moysan@foss.st.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.