[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGb2v657XU2wnhNHCgpLnXQrRkVBu1v5SNLUhnXcbj3RfCBN7g@mail.gmail.com>
Date: Mon, 3 Nov 2025 23:31:52 +0800
From: Chen-Yu Tsai <wens@...nel.org>
To: Andre Przywara <andre.przywara@....com>
Cc: Lee Jones <lee@...nel.org>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Samuel Holland <samuel@...lland.org>, Jernej Skrabec <jernej.skrabec@...il.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Yixun Lan <dlan@...too.org>, devicetree@...r.kernel.org, linux-sunxi@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: mfd: x-powers,axp152: Document AXP318W
On Tue, Oct 21, 2025 at 7:20 PM Andre Przywara <andre.przywara@....com> wrote:
>
> The X-Powers AXP318W is a PMIC used on some newer Allwinner devices.
> Among a large number of both DCDC and LDO regulators it features the usual
> ADC/IRQ/power key parts.
> Like other recent PMICs, it lacks the DC/DC converter PWM frequency control
> register, that rate is fixed here (1.5MHz on DCDC1, 3 MHz on the others).
>
> Add the new compatible string, and add that to the list of PMICs without
> the PWM frequency property.
> Also add more input supply properties, for the split DCDC and ALDO
> supplies.
> The PMIC features *two* switched outputs, hanging of DCDC1, and the
> manual calls them swout1 and swout2, so follow suit here and add those
> names to the pattern for matching the node names.
>
> Signed-off-by: Andre Przywara <andre.przywara@....com>
> ---
> .../bindings/mfd/x-powers,axp152.yaml | 28 ++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> index 45f015d63df16..1bed19fc91ec4 100644
> --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> @@ -83,6 +83,7 @@ allOf:
> contains:
> enum:
> - x-powers,axp313a
> + - x-powers,axp318w
> - x-powers,axp323
> - x-powers,axp15060
> - x-powers,axp717
> @@ -102,6 +103,7 @@ properties:
> - x-powers,axp221
> - x-powers,axp223
> - x-powers,axp313a
> + - x-powers,axp318w
> - x-powers,axp323
> - x-powers,axp717
> - x-powers,axp803
> @@ -156,10 +158,18 @@ properties:
> description: >
> DCDC1 power supply node, if present.
>
> + vin19-supply:
> + description: >
> + Combined DCDC1/DCDC9 power supply node, if present.
> +
> vin2-supply:
> description: >
> DCDC2 power supply node, if present.
>
> + vin23-supply:
> + description: >
> + Combined DCDC2/DCDC3 power supply node, if present.
> +
> vin3-supply:
> description: >
> DCDC3 power supply node, if present.
> @@ -168,6 +178,10 @@ properties:
> description: >
> DCDC4 power supply node, if present.
>
> + vin45-supply:
> + description: >
> + Combined DCDC4/DCDC5 power supply node, if present.
> +
> vin5-supply:
> description: >
> DCDC5 power supply node, if present.
> @@ -176,6 +190,10 @@ properties:
> description: >
> DCDC6 power supply node, if present.
>
> + vin678-supply:
> + description: >
> + Combined DCDC6/DCDC7/DCDC8 power supply node, if present.
> +
> vin7-supply:
> description: >
> DCDC7 power supply node, if present.
> @@ -220,6 +238,14 @@ properties:
> description: >
> ALDO* power supply node, if present.
>
> + aldo156in-supply:
> + description: >
> + ALDO* power supply node, if present.
> +
> + aldo234in-supply:
> + description: >
> + ALDO* power supply node, if present.
> +
> bldoin-supply:
> description: >
> BLDO* power supply node, if present.
> @@ -277,7 +303,7 @@ properties:
> Defines the work frequency of DC-DC in kHz.
>
> patternProperties:
> - "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
> + "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|swout[1-9]|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
This and the ever growing list of *-supply properties makes me wonder
whether we should expand the conditional blocks to enforce which names
are valid for whichever models. That could be done later though.
Reviewed-by: Chen-Yu Tsai <wens@...nel.org>
> $ref: /schemas/regulator/regulator.yaml#
> type: object
> unevaluatedProperties: false
> --
> 2.25.1
>
Powered by blists - more mailing lists