All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
To: Chi-Wen Weng <cwweng.linux@gmail.com>
Cc: jic23@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com,
	andy@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, cwweng@nuvoton.com
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
Date: Thu, 16 Jul 2026 17:42:37 -0700	[thread overview]
Message-ID: <20260716174237.00004b79@oss.qualcomm.com> (raw)
In-Reply-To: <20260713081127.115197-2-cwweng.linux@gmail.com>

On Mon, 13 Jul 2026 16:11:26 +0800
Chi-Wen Weng <cwweng.linux@gmail.com> wrote:

> From: Chi-Wen Weng <cwweng@nuvoton.com>
> 
> Add devicetree binding for the Enhanced ADC controller found on
> Nuvoton MA35D1 SoCs.
> 
> The controller has one register region, up to four end-of-conversion
> interrupts, one functional clock, and an optional reset line. The
> binding also describes the optional external reference supply and the
> optional DMA request supported by the hardware.
> 
> ADC input pins are described using standard channel child nodes. The
> external ADC input channels are 0 to 7. Differential inputs are described
> with diff-channels and are limited to the fixed hardware pairs.
> 
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>

Hi, A few comments below,

> ---
>  .../bindings/iio/adc/nuvoton,ma35d1-eadc.yaml | 163 ++++++++++++++++++
>  1 file changed, 163 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
> new file mode 100644
> index 000000000000..1be5470643d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
...

> +  interrupts:
> +    minItems: 1
> +    maxItems: 4
> +    items:
> +      - description: ADINT0 end-of-conversion interrupt
> +      - description: ADINT1 end-of-conversion interrupt
> +      - description: ADINT2 end-of-conversion interrupt
> +      - description: ADINT3 end-of-conversion interrupt
Not sure this doc helps. What are these interrupts for?
The driver only uses one of them so why are there 4?

May well need interrupt-names to allow gaps in the list to
work but hard to tell without more information.


> +
> +patternProperties:
> +  '^channel@[0-7]$':
> +    type: object
> +    $ref: adc.yaml
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        maximum: 7
> +
> +      diff-channels: true
Do you need that explicitly. I think adc.yaml already brings that in.

> +
> +    allOf:
> +      - if:
> +          properties:
> +            reg:
> +              const: 0
> +        then:
> +          properties:
> +            diff-channels:
> +              items:
> +                - const: 0
> +                - const: 4
> +      - if:
> +          properties:
> +            reg:
> +              const: 1
> +        then:
> +          properties:
> +            diff-channels:
> +              items:
> +                - const: 1
> +                - const: 5
> +      - if:
> +          properties:
> +            reg:
> +              const: 2
> +        then:
> +          properties:
> +            diff-channels:
> +              items:
> +                - const: 2
> +                - const: 6
> +      - if:
> +          properties:
> +            reg:
> +              const: 3
> +        then:
> +          properties:
> +            diff-channels:

For these take a look at the description of diff-channels.
It states that where the pairs are hard wired you can just use reg
and not specify diff-channels.  Seems to apply here and will greatly
simplify this binding.

> +              items:
> +                - const: 3
> +                - const: 7
> +      - if:
> +          properties:
> +            reg:
> +              enum: [4, 5, 6, 7]

What are these channels?  There is a reference to one
internally wired one so what are the other 3?


> +        then:
> +          not:
> +            required:
> +              - diff-channels
> +
> +    required:
> +      - reg

  parent reply	other threads:[~2026-07-17  0:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13  8:11 [PATCH v2 0/2] iio: adc: Add Nuvoton MA35D1 EADC support Chi-Wen Weng
2026-07-13  8:11 ` [PATCH v2 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC Chi-Wen Weng
2026-07-13  9:35   ` Rob Herring (Arm)
2026-07-17  0:42   ` Jonathan Cameron [this message]
2026-07-17  0:59     ` Chi-Wen Weng
2026-07-13  8:11 ` [PATCH v2 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver Chi-Wen Weng
2026-07-13  8:30   ` sashiko-bot
2026-07-13 11:17   ` Andy Shevchenko
2026-07-13 12:06     ` Chi-Wen Weng
2026-07-14 12:25   ` Uwe Kleine-König
2026-07-15  0:55     ` Chi-Wen Weng

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=20260716174237.00004b79@oss.qualcomm.com \
    --to=jonathan.cameron@oss.qualcomm.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=cwweng.linux@gmail.com \
    --cc=cwweng@nuvoton.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --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=nuno.sa@analog.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.