[PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[Nícolas F. R. A. Prado]

Some of the regulators in the MT6357 PMIC dtsi have compatible set to
regulator-fixed, even though they don't serve any purpose: all those
regulators are handled as a whole by the mt6357-regulator driver. In
fact this is the only dtsi in this family of chips where this is the
case: mt6359 and mt6358 don't have any such compatibles.

A side-effect caused by this is that the DT kselftest, which is supposed
to identify nodes with compatibles that can be probed, but haven't,
shows these nodes as failures.

Remove the useless compatibles to move the dtsi in line with the others
in its family and fix the DT kselftest failures.

Fixes: 55749bb478f8 ("arm64: dts: mediatek: add mt6357 device-tree")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt6357.dtsi | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt6357.dtsi b/arch/arm64/boot/dts/mediatek/mt6357.dtsi
index 5fafa842d312f3b01e7d71ddc04ef48ca52bc89d..dca4e5c3d8e210c1e118539153e77e2822066da3 100644
--- a/arch/arm64/boot/dts/mediatek/mt6357.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6357.dtsi
@@ -60,7 +60,6 @@ mt6357_vpa_reg: buck-vpa {
 			};
 
 			mt6357_vfe28_reg: ldo-vfe28 {
-				compatible = "regulator-fixed";
 				regulator-name = "vfe28";
 				regulator-min-microvolt = <2800000>;
 				regulator-max-microvolt = <2800000>;
@@ -75,7 +74,6 @@ mt6357_vxo22_reg: ldo-vxo22 {
 			};
 
 			mt6357_vrf18_reg: ldo-vrf18 {
-				compatible = "regulator-fixed";
 				regulator-name = "vrf18";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -83,7 +81,6 @@ mt6357_vrf18_reg: ldo-vrf18 {
 			};
 
 			mt6357_vrf12_reg: ldo-vrf12 {
-				compatible = "regulator-fixed";
 				regulator-name = "vrf12";
 				regulator-min-microvolt = <1200000>;
 				regulator-max-microvolt = <1200000>;
@@ -112,7 +109,6 @@ mt6357_vcn33_wifi_reg: ldo-vcn33-wifi {
 			};
 
 			mt6357_vcn28_reg: ldo-vcn28 {
-				compatible = "regulator-fixed";
 				regulator-name = "vcn28";
 				regulator-min-microvolt = <2800000>;
 				regulator-max-microvolt = <2800000>;
@@ -120,7 +116,6 @@ mt6357_vcn28_reg: ldo-vcn28 {
 			};
 
 			mt6357_vcn18_reg: ldo-vcn18 {
-				compatible = "regulator-fixed";
 				regulator-name = "vcn18";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -142,7 +137,6 @@ mt6357_vcamd_reg: ldo-vcamd {
 			};
 
 			mt6357_vcamio_reg: ldo-vcamio18 {
-				compatible = "regulator-fixed";
 				regulator-name = "vcamio";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -175,7 +169,6 @@ mt6357_vsram_proc_reg: ldo-vsram-proc {
 			};
 
 			mt6357_vaux18_reg: ldo-vaux18 {
-				compatible = "regulator-fixed";
 				regulator-name = "vaux18";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -183,7 +176,6 @@ mt6357_vaux18_reg: ldo-vaux18 {
 			};
 
 			mt6357_vaud28_reg: ldo-vaud28 {
-				compatible = "regulator-fixed";
 				regulator-name = "vaud28";
 				regulator-min-microvolt = <2800000>;
 				regulator-max-microvolt = <2800000>;
@@ -191,7 +183,6 @@ mt6357_vaud28_reg: ldo-vaud28 {
 			};
 
 			mt6357_vio28_reg: ldo-vio28 {
-				compatible = "regulator-fixed";
 				regulator-name = "vio28";
 				regulator-min-microvolt = <2800000>;
 				regulator-max-microvolt = <2800000>;
@@ -199,7 +190,6 @@ mt6357_vio28_reg: ldo-vio28 {
 			};
 
 			mt6357_vio18_reg: ldo-vio18 {
-				compatible = "regulator-fixed";
 				regulator-name = "vio18";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;

---
base-commit: 37ff6e9a2ce321b7932d3987701757fb4d87b0e6
change-id: 20250502-mt6357-regulator-fixed-compatibles-removal-16737b35cbc3

Best regards,
-- 
Nícolas F. R. A. Prado <nfraprado@collabora.com>

Re: [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[Rob Herring (Arm)]

On Fri, 02 May 2025 11:32:10 -0400, Nícolas F. R. A. Prado wrote:
> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
> regulator-fixed, even though they don't serve any purpose: all those
> regulators are handled as a whole by the mt6357-regulator driver. In
> fact this is the only dtsi in this family of chips where this is the
> case: mt6359 and mt6358 don't have any such compatibles.
> 
> A side-effect caused by this is that the DT kselftest, which is supposed
> to identify nodes with compatibles that can be probed, but haven't,
> shows these nodes as failures.
> 
> Remove the useless compatibles to move the dtsi in line with the others
> in its family and fix the DT kselftest failures.
> 
> Fixes: 55749bb478f8 ("arm64: dts: mediatek: add mt6357 device-tree")
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt6357.dtsi | 10 ----------
>  1 file changed, 10 deletions(-)
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit 37ff6e9a2ce321b7932d3987701757fb4d87b0e6

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/mediatek/' for 20250502-mt6357-regulator-fixed-compatibles-removal-v1-1-a582c16743fe@collabora.com:

arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vfe28: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vfe28: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vfe28: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vfe28: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf18: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf18: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf18: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf18: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf12: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf12: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf12: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vrf12: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn28: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn28: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn28: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn28: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn18: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn18: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn18: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcn18: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcamio18: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcamio18: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcamio18: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vcamio18: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaux18: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaux18: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaux18: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaux18: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaud28: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaud28: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaud28: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vaud28: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio28: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio28: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio28: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio28: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio18: 'clocks' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio18: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio18: 'required-opps' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: pmic (mediatek,mt6357): regulators:ldo-vio18: 'compatible' is a required property
	from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#

Re: [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[AngeloGioacchino Del Regno]

On Fri, 02 May 2025 11:32:10 -0400, Nícolas F. R. A. Prado wrote:
> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
> regulator-fixed, even though they don't serve any purpose: all those
> regulators are handled as a whole by the mt6357-regulator driver. In
> fact this is the only dtsi in this family of chips where this is the
> case: mt6359 and mt6358 don't have any such compatibles.
> 
> A side-effect caused by this is that the DT kselftest, which is supposed
> to identify nodes with compatibles that can be probed, but haven't,
> shows these nodes as failures.
> 
> [...]

Applied to v6.15-next/dts64, thanks!

[1/1] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles
      commit: d77e89b7b03fb945b4353f2dcc4a70b34baa7bcb

Cheers,
Angelo

Re: [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[Alexandre Mergnat]

Hello Nícolas and Angelo,

On 06/05/2025 10:42, AngeloGioacchino Del Regno wrote:
> On Fri, 02 May 2025 11:32:10 -0400, Nícolas F. R. A. Prado wrote:
>> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
>> regulator-fixed, even though they don't serve any purpose: all those
>> regulators are handled as a whole by the mt6357-regulator driver. In
>> fact this is the only dtsi in this family of chips where this is the
>> case: mt6359 and mt6358 don't have any such compatibles.
>>
>> A side-effect caused by this is that the DT kselftest, which is supposed
>> to identify nodes with compatibles that can be probed, but haven't,
>> shows these nodes as failures.
>>
>> [...]
> 
> Applied to v6.15-next/dts64, thanks!
> 
> [1/1] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles
>        commit: d77e89b7b03fb945b4353f2dcc4a70b34baa7bcb

I'm surprised that patch is applied after the Rob's bot reply.
Also, I've some concern:

On 02/05/2025 17:32, Nícolas F. R. A. Prado wrote:
 > Some of the regulators in the MT6357 PMIC dtsi have compatible set to
 > regulator-fixed, even though they don't serve any purpose: all those
 > regulators are handled as a whole by the mt6357-regulator driver. In
 > fact this is the only dtsi in this family of chips where this is the
 > case: mt6359 and mt6358 don't have any such compatibles.
This is the only dtsi in this family to do this, yes. But according to
all other vendor DTSI, which use regulator-fixed when a regulator can't
support a range of voltage, IMHO, it make sense to use it, isn't it ?
If other DTSI from the family of chips doesn't, why don't fix them to be
aligned with the other families?

 >
 > A side-effect caused by this is that the DT kselftest, which is supposed
 > to identify nodes with compatibles that can be probed, but haven't,
 > shows these nodes as failures.
 >
I lack of data about kselftest, but according to what is reported here, it
appear to me this is something which could be fixed in the test itself. It make
sense for a DTS, but not for a DTSI because it expose HW capability of a
device, not the board, so it isn't mandatory to probe all DTSI node.
Again, I'm not an expert, the test shouldn't show the DTSI node as failure,
but maybe more a warning.

 > Remove the useless compatibles to move the dtsi in line with the others
 > in its family and fix the DT kselftest failures.
If you remove compatible from these regulators, I think mediatek,mt6357-regulator.yaml
documentation file should be modified to be consistent and avoid dt-check error.

> 
> Cheers,
> Angelo
> 
> 

-- 
Regards,
Alexandre

Re: [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[Nícolas F. R. A. Prado]

On Tue, May 06, 2025 at 11:30:08AM +0200, Alexandre Mergnat wrote:
> Hello Nícolas and Angelo,
> 
> On 06/05/2025 10:42, AngeloGioacchino Del Regno wrote:
> > On Fri, 02 May 2025 11:32:10 -0400, Nícolas F. R. A. Prado wrote:
> > > Some of the regulators in the MT6357 PMIC dtsi have compatible set to
> > > regulator-fixed, even though they don't serve any purpose: all those
> > > regulators are handled as a whole by the mt6357-regulator driver. In
> > > fact this is the only dtsi in this family of chips where this is the
> > > case: mt6359 and mt6358 don't have any such compatibles.
> > > 
> > > A side-effect caused by this is that the DT kselftest, which is supposed
> > > to identify nodes with compatibles that can be probed, but haven't,
> > > shows these nodes as failures.
> > > 
> > > [...]
> > 
> > Applied to v6.15-next/dts64, thanks!
> > 
> > [1/1] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles
> >        commit: d77e89b7b03fb945b4353f2dcc4a70b34baa7bcb
> 
> I'm surprised that patch is applied after the Rob's bot reply.
> Also, I've some concern:
> 
> On 02/05/2025 17:32, Nícolas F. R. A. Prado wrote:
> > Some of the regulators in the MT6357 PMIC dtsi have compatible set to
> > regulator-fixed, even though they don't serve any purpose: all those
> > regulators are handled as a whole by the mt6357-regulator driver. In
> > fact this is the only dtsi in this family of chips where this is the
> > case: mt6359 and mt6358 don't have any such compatibles.
> This is the only dtsi in this family to do this, yes. But according to
> all other vendor DTSI, which use regulator-fixed when a regulator can't
> support a range of voltage, IMHO, it make sense to use it, isn't it ?
> If other DTSI from the family of chips doesn't, why don't fix them to be
> aligned with the other families?

Well, but this isn't just like any other regulator-fixed in a DTSI. In this case
it is part of a multi-function device (MFD) and so it gets probed by a parent
node. That's the source of the issue, because then no driver gets assigned to
the node itself.

> 
> >
> > A side-effect caused by this is that the DT kselftest, which is supposed
> > to identify nodes with compatibles that can be probed, but haven't,
> > shows these nodes as failures.
> >
> I lack of data about kselftest, but according to what is reported here, it
> appear to me this is something which could be fixed in the test itself. It make
> sense for a DTS, but not for a DTSI because it expose HW capability of a
> device, not the board, so it isn't mandatory to probe all DTSI node.
> Again, I'm not an expert, the test shouldn't show the DTSI node as failure,
> but maybe more a warning.

The DT kselftest is a run-time test, so it wouldn't be able to distinguish
between DTSI and DTS. But in any case, we do want to check that devices from
DTSIs have probed, a lot of the devices come from them. When a particular board
doesn't actually have a node from a DTSI present then the node should be
disabled, and in that case the kselftest ignores the node.

It would be possible to ignore this particular compatible, "regulator-fixed", in
the kselftest, if it is a compatible that can't be expected to be probed. Of
course that would mean that all the other regulator nodes that aren't MFD
children and do get probed by that driver would no longer be checked by the
test.

> 
> > Remove the useless compatibles to move the dtsi in line with the others
> > in its family and fix the DT kselftest failures.
> If you remove compatible from these regulators, I think mediatek,mt6357-regulator.yaml
> documentation file should be modified to be consistent and avoid dt-check error.

Ah, yes, totally agreed, I seem to have missed running dtbs_check on this patch,
sorry. Indeed now either the binding needs to be fixed or the patch reverted.

I believe the most reasonable option would be to update those regulators in the
binding to reference the generic regulator binding, ie:

diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
index 6327bb2f6ee0..9308008f420e 100644
--- a/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
@@ -33,7 +33,7 @@ patternProperties:

   "^ldo-v(camio18|aud28|aux18|io18|io28|rf12|rf18|cn18|cn28|fe28)$":
     type: object
-    $ref: fixed-regulator.yaml#
+    $ref: regulator.yaml#
     unevaluatedProperties: false
     description:
       Properties for single fixed LDO regulator.

as well as updating the examples in the YAML. The fixed-regulator.yaml binding
doesn't seem to provide any additional checks compared to regulator.yaml,
besides enforcing the regulator-fixed compatible, which in this case doesn't
serve any purpose.

Thoughts?

Thanks,
Nícolas

Re: [PATCH] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles

[Alexandre Mergnat]

On 06/05/2025 23:20, Nícolas F. R. A. Prado wrote:
> On Tue, May 06, 2025 at 11:30:08AM +0200, Alexandre Mergnat wrote:
>> Hello Nícolas and Angelo,
>>
>> On 06/05/2025 10:42, AngeloGioacchino Del Regno wrote:
>>> On Fri, 02 May 2025 11:32:10 -0400, Nícolas F. R. A. Prado wrote:
>>>> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
>>>> regulator-fixed, even though they don't serve any purpose: all those
>>>> regulators are handled as a whole by the mt6357-regulator driver. In
>>>> fact this is the only dtsi in this family of chips where this is the
>>>> case: mt6359 and mt6358 don't have any such compatibles.
>>>>
>>>> A side-effect caused by this is that the DT kselftest, which is supposed
>>>> to identify nodes with compatibles that can be probed, but haven't,
>>>> shows these nodes as failures.
>>>>
>>>> [...]
>>>
>>> Applied to v6.15-next/dts64, thanks!
>>>
>>> [1/1] arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles
>>>         commit: d77e89b7b03fb945b4353f2dcc4a70b34baa7bcb
>>
>> I'm surprised that patch is applied after the Rob's bot reply.
>> Also, I've some concern:
>>
>> On 02/05/2025 17:32, Nícolas F. R. A. Prado wrote:
>>> Some of the regulators in the MT6357 PMIC dtsi have compatible set to
>>> regulator-fixed, even though they don't serve any purpose: all those
>>> regulators are handled as a whole by the mt6357-regulator driver. In
>>> fact this is the only dtsi in this family of chips where this is the
>>> case: mt6359 and mt6358 don't have any such compatibles.
>> This is the only dtsi in this family to do this, yes. But according to
>> all other vendor DTSI, which use regulator-fixed when a regulator can't
>> support a range of voltage, IMHO, it make sense to use it, isn't it ?
>> If other DTSI from the family of chips doesn't, why don't fix them to be
>> aligned with the other families?
> 
> Well, but this isn't just like any other regulator-fixed in a DTSI. In this case
> it is part of a multi-function device (MFD) and so it gets probed by a parent
> node. That's the source of the issue, because then no driver gets assigned to
> the node itself.
> 

Ok, thanks for the details. After Quick check, Maxim does't use "regulator-fixed"
in the MFD too.

>>
>>>
>>> A side-effect caused by this is that the DT kselftest, which is supposed
>>> to identify nodes with compatibles that can be probed, but haven't,
>>> shows these nodes as failures.
>>>
>> I lack of data about kselftest, but according to what is reported here, it
>> appear to me this is something which could be fixed in the test itself. It make
>> sense for a DTS, but not for a DTSI because it expose HW capability of a
>> device, not the board, so it isn't mandatory to probe all DTSI node.
>> Again, I'm not an expert, the test shouldn't show the DTSI node as failure,
>> but maybe more a warning.
> 
> The DT kselftest is a run-time test, so it wouldn't be able to distinguish
> between DTSI and DTS. But in any case, we do want to check that devices from
> DTSIs have probed, a lot of the devices come from them. When a particular board
> doesn't actually have a node from a DTSI present then the node should be
> disabled, and in that case the kselftest ignores the node.
> 
> It would be possible to ignore this particular compatible, "regulator-fixed", in
> the kselftest, if it is a compatible that can't be expected to be probed. Of
> course that would mean that all the other regulator nodes that aren't MFD
> children and do get probed by that driver would no longer be checked by the
> test.
> 

Yeah this isn't the wanted behavior.

>>
>>> Remove the useless compatibles to move the dtsi in line with the others
>>> in its family and fix the DT kselftest failures.
>> If you remove compatible from these regulators, I think mediatek,mt6357-regulator.yaml
>> documentation file should be modified to be consistent and avoid dt-check error.
> 
> Ah, yes, totally agreed, I seem to have missed running dtbs_check on this patch,
> sorry. Indeed now either the binding needs to be fixed or the patch reverted.
> 
> I believe the most reasonable option would be to update those regulators in the
> binding to reference the generic regulator binding, ie:
> 
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
> index 6327bb2f6ee0..9308008f420e 100644
> --- a/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
> @@ -33,7 +33,7 @@ patternProperties:
> 
>     "^ldo-v(camio18|aud28|aux18|io18|io28|rf12|rf18|cn18|cn28|fe28)$":
>       type: object
> -    $ref: fixed-regulator.yaml#
> +    $ref: regulator.yaml#
>       unevaluatedProperties: false
>       description:
>         Properties for single fixed LDO regulator.
> 
> as well as updating the examples in the YAML. The fixed-regulator.yaml binding
> doesn't seem to provide any additional checks compared to regulator.yaml,
> besides enforcing the regulator-fixed compatible, which in this case doesn't
> serve any purpose.
> 
> Thoughts?
> 

Yes, IMHO, this yaml change should be enough.

-- 
Thanks,
Alexandre