From: Rob Herring <robh@kernel.org>
To: Thierry Reding <thierry.reding@kernel.org>
Cc: Lee Jones <lee@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Laxman Dewangan <ldewangan@nvidia.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
mfd@lists.linux.dev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
linux-sound@vger.kernel.org, linux-tegra@vger.kernel.org,
Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH 1/2] dt-bindings: mfd: as3722: Convert to json-schema
Date: Mon, 28 Sep 2026 16:41:22 -0500 [thread overview]
Message-ID: <20260928214122.GA804761-robh@kernel.org> (raw)
In-Reply-To: <20260928-as3722-bindings-v1-1-35f423a9f2b2@nvidia.com>
On Mon, Sep 28, 2026 at 06:24:40PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the AMS AS3722 PMIC bindings from the free-form text format to
> json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/mfd/ams,as3722.yaml | 276 +++++++++++++++++++++
> Documentation/devicetree/bindings/mfd/as3722.txt | 214 ----------------
> .../bindings/regulator/as3722-regulator.txt | 91 -------
> 3 files changed, 276 insertions(+), 305 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ams,as3722.yaml b/Documentation/devicetree/bindings/mfd/ams,as3722.yaml
> new file mode 100644
> index 000000000000..6a6444500396
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ams,as3722.yaml
> @@ -0,0 +1,276 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ams,as3722.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMS AS3722 Power Management IC
> +
> +maintainers:
> + - Laxman Dewangan <ldewangan@nvidia.com>
> + - Lee Jones <lee.jones@linaro.org>
> +
> +properties:
> + compatible:
> + const: ams,as3722
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + # standard properties
> + interrupt-controller:
> + description: The AS3722 has an internal interrupt controller which takes
> + the interrupt request from internal sub-blocks like RTC, regulators,
> + GPIOs as well as external input.
> +
> + "#interrupt-cells":
> + description: The first cell is the IRQ number. IRQ numbers for different
> + interrupt source of AS3722 are defined at dt-bindings/mfd/as3722.h The
> + second cell is the flags, encoded as the trigger masks from binding
> + document interrupts.txt, using dt-bindings/irq.
> + const: 2
> +
> + # from gpio.yaml
> + gpio-controller: true
> + "#gpio-cells": true
Constraints?
> +
> + # optional properties
> + ams,enable-internal-int-pullup:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: Boolean property, to enable internal pullup on interrupt pin.
> + Omitting this will disable internal pullup on INT pin.
No need to say "Boolean property" when the schema defines that.
> +
> + ams,enable-internal-i2c-pullup:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: Boolean property, to enable internal pullup on I2C SCL/SDA
> + pins. Omitting this will disable internal pullup on I2C SCL/SDA lines.
> +
> + ams,enable-ac-ok-power-on:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: Boolean property, to enable exit out of power off mode with
> + AC_OK pin (pin enabled in power off mode).
> +
> + ams,system-power-controller:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: The AS3722 supports the system power off by turning off all
> + its rails. The device node should contain this boolean property to
> + enable this functionality.
> +
> + pinmux:
> + type: object
additionalProperties: false
> + description: |
> + Device has 8 GPIO pins which can be configured as GPIO as well as the
> + special IO functions.
> +
> + Please refer to pinctrl-bindings.txt in this directory for details of
> + the common pinctrl bindings used by client devices, including the
> + meaning of the phrase "pin configuration node".
> +
> + patternProperties:
> + "^gpio[0-7_]+$":
> + description: |
Don't need '|'
> + Child nodes of the pinmux node represent some desired configuration
> + for a list of pins. This configuration can include the mux function
> + to select on those pin(s), and various pin configuration parameters,
> + such as pull-up, open drain.
> + type: object
blank line
I prefer that 'description' is consistently either first or last
(in initial schema properties before 'properties'). You have a mixture.
> + properties:
> + pins:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + description: List of pins for this configuration group.
> + items:
> + enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ]
> +
> + function:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: Function configuration for this configuration group.
> + enum: [ gpio, interrupt-out, gpio-in-interrupt,
> + vsup-vbat-low-undebounce-out, vsup-vbat-low-debounce-out,
> + voltage-in-standby, oc-pg-sd0, oc-pg-sd6, powergood-out,
> + pwm-in, pwm-out, clk32k-out, watchdog-in, soft-reset-in ]
> +
> + bias-disable:
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + bias-pull-up:
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + bias-pull-down:
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + bias-high-impedance:
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + drive-open-drain:
> + $ref: /schemas/types.yaml#/definitions/flag
Other than cases which have 2 possible types, these all have types
which don't need to be repeated here. You also need a $ref to
pincfg-node.yaml and pinmux-node.yaml (for function).
> +
> + additionalProperties: false
Preferred to put this before 'properties' for the indented cases.
> +
> + required:
> + - pins
> +
> + regulators:
> + type: object
> + description: Device has multiple DCDC and LDOs. The node "regulators" is
> + required if regulator functionality is needed.
> +
> + properties:
> + vsup-sd2-supply:
> + description: input supply for SD2
> +
> + vsup-sd3-supply:
> + description: input supply for SD3
> +
> + vsup-sd4-supply:
> + description: input supply for SD4
> +
> + vsup-sd5-supply:
> + description: input supply for SD5
> +
> + vin-ldo0-supply:
> + description: input supply for LDO0
> +
> + vin-ldo1-6-supply:
> + description: input supply for LDO1 and LDO6
> +
> + vin-ldo2-5-7-supply:
> + description: input supply for LDO2, LDO5 and LDO7
> +
> + vin-ldo3-4-supply:
> + description: input supply for LDO3 and LDO4
> +
> + vin-ldo9-10-supply:
> + description: input supply for LDO9 and LDO10
> +
> + vin-ldo11-supply:
> + description: input supply for LDO11
> +
> + patternProperties:
> + "^(sd[0-6]|ldo[0-7]|ldo9|ldo10|ldo11)$":
> + type: object
Missing regulator.yaml ref and unevaluateProperties?
> + description: These sub-nodes must be named after one of the regulators
> + found on the AS3277. Each sub-node should contain the constraints and
> + initialization information for that regulator.
> +
> + properties:
> + ams,ext-control:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: External control of the rail. The value of this
> + property will tell which external input is controlling this rail.
> + Valid values are 0, 1, 2 ad 3. If this property does not exist,
> + the default value is 0. The external control pin macros are
> + defined in dt-bindings/mfd/as3722.h.
> + oneOf:
> + - description: there is no external control of this rail
> + const: 0
> + - description: rail is controlled by ENABLE1 input pin
> + const: 1
> + - description: rail is controlled by ENABLE2 input pin
> + const: 2
> + - description: rail is controlled by ENABLE3 input pin
> + const: 3
> + default: 0
> +
> + ams,enable-tracking:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: Enable tracking with SD1, only supported by LDO3.
next prev parent reply other threads:[~2026-09-28 21:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 16:24 [PATCH 0/2] arm64: tegra: Fix DT validation issues for Tegra132 Thierry Reding
2026-09-28 16:24 ` [PATCH 1/2] dt-bindings: mfd: as3722: Convert to json-schema Thierry Reding
2026-09-28 21:41 ` Rob Herring [this message]
2026-09-28 16:24 ` [PATCH 2/2] dt-bindings: sound: tegra-ahub: " Thierry Reding
2026-09-28 16:38 ` Mark Brown
2026-09-28 19:23 ` Mark Brown
2026-09-29 11:44 ` Thierry Reding
2026-09-28 21:46 ` Rob Herring
2026-09-29 11:21 ` Thierry Reding
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=20260928214122.GA804761-robh@kernel.org \
--to=robh@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=ldewangan@nvidia.com \
--cc=lee@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mfd@lists.linux.dev \
--cc=thierry.reding@gmail.com \
--cc=thierry.reding@kernel.org \
--cc=treding@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®