[PATCH 0/4] ARM: dts: DTB_CHECK warning cleanup

[PATCH 0/4] ARM: dts: DTB_CHECK warning cleanup

[Frank Li]

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (4):
      ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
      ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
      ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
      ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv

 arch/arm/boot/dts/nxp/imx/imx51-babbage.dts      |  1 +
 arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts       |  1 +
 arch/arm/boot/dts/nxp/imx/imx53-ppd.dts          |  2 ++
 arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi  | 10 ++++++++++
 arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts  |  1 +
 arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi |  3 ++-
 6 files changed, 17 insertions(+), 1 deletion(-)
---
base-commit: 6920bef1402681e36b9c09e9aff8a860b0b54ccd
change-id: 20260511-b4-imx25_dts_simple_warning-e29b7a077b31

Best regards,
--
Frank Li <Frank.Li@nxp.com>

[PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Frank Li]

According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
is connected to the station management entity via the mechanical interface
defined in 22.6 shall always respond to transactions addressed to PHY
Address zero <00000>.

Use address 0 is safe because only one MDIO phy under mdio bus.

Fix below CHECK_DTBS warnings:
arm/boot/dts/nxp/imx/imx6dl-sabrelite.dtb: ethernet@2188000 (fsl,imx6q-fec): mdio: Unevaluated properties are not allowed ('ethernet-phy' was unexpected)
        from schema $id: http://devicetree.org/schemas/net/fsl,fec.yaml
/home/lizhi/source/linux-upstream-pci/arch/arm/boot/dts/nxp/imx/imx6dl-sabrelite.dtb: ethernet-phy (ethernet-phy-ieee802.3-c22): 'reg' is a required property
        from schema $id: http://devicetree.org/schemas/net/ethernet-phy.yaml

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
index 3b7d01065e87b2587a87f97438eea205be3222f8..d936732db46f07806ca07de4353ff47fe26e23b6 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
@@ -291,8 +291,9 @@ mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		ethphy: ethernet-phy {
+		ethphy: ethernet-phy@0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
 			txen-skew-ps = <0>;
 			txc-skew-ps = <3000>;
 			rxdv-skew-ps = <0>;

-- 
2.43.0

[PATCH 2/4] ARM: dts: imx: add ti,deskew = <0> for ti,tfp410

[Frank Li]

Add required proprety ti,deskew for ti,tfp410, which have not defined
default value in yaml. 0 is default value according to
drivers/gpu/drm/bridge/ti-tfp410.c.

Fix below check_dtbs warning:
    dvi-encoder (ti,tfp410): 'ti,deskew' is a required property

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 arch/arm/boot/dts/nxp/imx/imx51-babbage.dts     | 1 +
 arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts      | 1 +
 arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
index b17264e06e6916057c426179e4207c4a28acf1ab..a02e9cd0b3fa04efc4df49f8ad990515d5e81671 100644
--- a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
@@ -126,6 +126,7 @@ dvi_connector_in: endpoint {
 
 	dvi-encoder {
 		compatible = "ti,tfp410";
+		ti,deskew = <0>;
 
 		ports {
 			#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts b/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
index 0814f5665a59c3a64c6023714a3b58230ac80dda..02be8b6da69619a5d33a7b1e964e951addefa676 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
@@ -60,6 +60,7 @@ dvi_connector_in: endpoint {
 
 	dvi-converter {
 		compatible = "ti,tfp410";
+		ti,deskew = <0>;
 
 		ports {
 			#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
index c78f101c3cc122f418b708b1c274ca11b586b65c..6a6ef4a25d8dca7363a527aeea4ddcd81acd58bc 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
@@ -61,6 +61,7 @@ aliases {
 
 	encoder {
 		compatible = "ti,tfp410";
+		ti,deskew = <0>;
 
 		ports {
 			#address-cells = <1>;

-- 
2.43.0

[PATCH 3/4] ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g

[Frank Li]

Add dvdd and avdd supply and regulators for panel sii,43wvf1g to fix below
check_dtbs warnings:
    panel (sii,43wvf1g): 'dvdd-supply' is a required property

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
index 1869ad86baf202098c6062c0f511358eeffb5c5a..d3b27dc3c2c7d2ab868a8a070a164af994ed30a9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
@@ -91,6 +91,8 @@ panel_dpi: panel {
 		pinctrl-0 = <&pinctrl_display_power>;
 		backlight = <&backlight_parallel>;
 		enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+		dvdd-supply = <&reg_3p2v>;
+		avdd-supply = <&reg_5v>;
 
 		port {
 			panel_in: endpoint {
@@ -107,6 +109,14 @@ reg_3p2v: regulator-3p2v {
 		regulator-always-on;
 	};
 
+	reg_5v: regulator-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
 	reg_usb_vbus: regulator-usb-vbus {
 		compatible = "regulator-fixed";
 		regulator-name = "usb_vbus";

-- 
2.43.0

[PATCH 4/4] ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv

[Frank Li]

Add '#phy-cells' for usb-nop-xceiv to fix below check_dtbs warnings:
    usbphy-2 (usb-nop-xceiv): '#phy-cells' is a required property

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts b/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
index e45a97d3f449de9a82ecd9171bcedb0f5f41346b..f0fb88c14171919ccdd68a90c453a5d2dbaa126d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
@@ -258,6 +258,7 @@ usbphy2: usbphy-2 {
 		clock-names = "main_clk";
 		clock-frequency = <24000000>;
 		clocks = <&clks IMX5_CLK_CKO2>;
+		#phy-cells = <0>;
 		assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
 		assigned-clock-parents = <&clks IMX5_CLK_OSC>;
 	};
@@ -270,6 +271,7 @@ usbphy3: usbphy-3 {
 
 		clock-frequency = <24000000>;
 		clocks = <&clks IMX5_CLK_CKO2>;
+		#phy-cells = <0>;
 		assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
 		assigned-clock-parents = <&clks IMX5_CLK_OSC>;
 	};

-- 
2.43.0

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Andrew Lunn]

On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> is connected to the station management entity via the mechanical interface
> defined in 22.6 shall always respond to transactions addressed to PHY
> Address zero <00000>.

Did you read 22.6? I've not seen a mechanical interface as defined in
22.6 for at least 20 years, maybe 30 years.

That cause does not apply in this context.

> -		ethphy: ethernet-phy {
> +		ethphy: ethernet-phy@0 {
>  			compatible = "ethernet-phy-ieee802.3-c22";
> +			reg = <0>;

This could very well break this board. Without a reg value, the core
will find the first PHY on the bus, at whatever address it is at. If
you hard code 0, the PHY must be at 0, otherwise it will not be found.

	Andrew

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Francesco Dolcini]

On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> is connected to the station management entity via the mechanical interface
> defined in 22.6 shall always respond to transactions addressed to PHY
> Address zero <00000>.
> 
> Use address 0 is safe because only one MDIO phy under mdio bus.

I do not think this is generally safe.

Not all ethernet phy answer to the 0 broadcast address. The one that I
have personally worked with consider 0 a unicast address.

Francesco

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Francesco Dolcini]

On Tue, May 12, 2026 at 12:15:08AM +0200, Andrew Lunn wrote:
> On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> > According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> > is connected to the station management entity via the mechanical interface
> > defined in 22.6 shall always respond to transactions addressed to PHY
> > Address zero <00000>.
> 
> Did you read 22.6? I've not seen a mechanical interface as defined in
> 22.6 for at least 20 years, maybe 30 years.
> 
> That cause does not apply in this context.
> 
> > -		ethphy: ethernet-phy {
> > +		ethphy: ethernet-phy@0 {
> >  			compatible = "ethernet-phy-ieee802.3-c22";
> > +			reg = <0>;
> 
> This could very well break this board. Without a reg value, the core
> will find the first PHY on the bus, at whatever address it is at. If
> you hard code 0, the PHY must be at 0, otherwise it will not be found.

Whoops, I replied without reading your answer first.

Yes, I agree, this change will break the board functionality.

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Fabio Estevam]

Adding Gary.

On Mon, May 11, 2026 at 7:15 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> > According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> > is connected to the station management entity via the mechanical interface
> > defined in 22.6 shall always respond to transactions addressed to PHY
> > Address zero <00000>.
>
> Did you read 22.6? I've not seen a mechanical interface as defined in
> 22.6 for at least 20 years, maybe 30 years.
>
> That cause does not apply in this context.
>
> > -             ethphy: ethernet-phy {
> > +             ethphy: ethernet-phy@0 {
> >                       compatible = "ethernet-phy-ieee802.3-c22";
> > +                     reg = <0>;
>
> This could very well break this board. Without a reg value, the core
> will find the first PHY on the bus, at whatever address it is at. If
> you hard code 0, the PHY must be at 0, otherwise it will not be found.

On this board, U-Boot checks for the Ethernet PHY at addresses 4, 5, 6, and 7:

https://github.com/u-boot/u-boot/blob/master/board/boundary/nitrogen6x/nitrogen6x.c#L287-L296

In this case, shouldn't U-Boot fix up the Ethernet PHY address accordingly?

Something like mx6cuboxi does:

https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cuboxi/mx6cuboxi.c#L414-L446

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Fabio Estevam]

On Tue, May 12, 2026 at 9:23 AM Fabio Estevam <festevam@gmail.com> wrote:

> On this board, U-Boot checks for the Ethernet PHY at addresses 4, 5, 6, and 7:
>
> https://github.com/u-boot/u-boot/blob/master/board/boundary/nitrogen6x/nitrogen6x.c#L287-L296
>
> In this case, shouldn't U-Boot fix up the Ethernet PHY address accordingly?
>
> Something like mx6cuboxi does:
>
> https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cuboxi/mx6cuboxi.c#L414-L446

And from the devicetree side, imx6qdl-sr-som lists the possible
Ethernet PHY addresses it can support:

https://github.com/gregkh/linux/blob/master/arch/arm/boot/dts/nxp/imx/imx6qdl-sr-som.dtsi#L72-L95

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[Frank Li]

On Tue, May 12, 2026 at 12:15:08AM +0200, Andrew Lunn wrote:
> On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> > According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> > is connected to the station management entity via the mechanical interface
> > defined in 22.6 shall always respond to transactions addressed to PHY
> > Address zero <00000>.
>
> Did you read 22.6? I've not seen a mechanical interface as defined in
> 22.6 for at least 20 years, maybe 30 years.
>
> That cause does not apply in this context.

Thanks, I missed understand it. This board is still alive, let me double
check it.

Frank

>
> > -		ethphy: ethernet-phy {
> > +		ethphy: ethernet-phy@0 {
> >  			compatible = "ethernet-phy-ieee802.3-c22";
> > +			reg = <0>;
>
> This could very well break this board. Without a reg value, the core
> will find the first PHY on the bus, at whatever address it is at. If
> you hard code 0, the PHY must be at 0, otherwise it will not be found.
>
> 	Andrew

Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Setting the Ethernet PHY `reg` property to the MDIO broadcast address (0) instead of the actual hardware-strapped address breaks Ethernet initialization on the SABRE Lite board.
--

commit fbbd7813db5860f802e25f49f30fa7e2a33c20e6
Author: Frank Li <Frank.Li@nxp.com>
ARM: dts: imx6qdl-sabrelite: add mdio phy address 0

This commit explicitly sets the Ethernet PHY reg property to 0 to resolve
device tree schema validation warnings. It relies on the IEEE 802.3
specification indicating that a PHY should respond to the broadcast
address 0.

> diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
> --- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
> @@ -291,8 +291,9 @@ mdio {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
>  
> -		ethphy: ethernet-phy {
> +		ethphy: ethernet-phy@0 {
>  			compatible = "ethernet-phy-ieee802.3-c22";
> +			reg = <0>;

Could this cause a regression in Ethernet functionality on the Sabre Lite
board?

The device tree should accurately describe the physical hardware topology,
but the Micrel KSZ9021 PHY on the Sabre Lite board is hardware-strapped to
address 6, not 0. Furthermore, the KSZ9021 datasheet indicates that it does
not support address 0 as a broadcast address.

Prior to this patch, the absence of a reg property caused
of_mdio_parse_addr() to return an error. This triggered an auto-probing
loop over all 32 addresses, which successfully found the PHY at address 6.

By explicitly defining reg = <0>, the kernel skips the auto-scanning
fallback and exclusively probes address 0. Because the PHY does not respond
to MDIO reads at address 0, get_phy_device() will read 0xFFFF and fail with
-ENODEV, preventing the PHY from registering.

Should this instead set the reg property to the actual hardware-strapped
address 6 to satisfy the schema without breaking initialization?

>  			txen-skew-ps = <0>;
>  			txc-skew-ps = <3000>;
>  			rxdv-skew-ps = <0>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com?part=1

Re: [PATCH 2/4] ARM: dts: imx: add ti,deskew = <0> for ti,tfp410

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardcoding incorrect hardware description based on a software driver bug
--

commit e68637a2ada078494e7ee776597edfdccd03a72c
Author: Frank Li <Frank.Li@nxp.com>

ARM: dts: imx: add ti,deskew = <0> for ti,tfp410

This commit adds the required ti,deskew property to ti,tfp410 nodes
to fix dt_binding_check warnings. The value 0 is chosen based on the
default value found in the driver.

>     Add required proprety ti,deskew for ti,tfp410, which have not defined

This isn't a bug, but there's a typo (proprety) in the commit message.

>     default value in yaml. 0 is default value according to
>     drivers/gpu/drm/bridge/ti-tfp410.c.

Does this accurately describe the hardware, or is it mirroring a driver
bug?

Device Tree properties are intended to describe the physical hardware
configuration, rather than reflecting software driver fallbacks.

> diff --git a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
> index b17264e06e691..a02e9cd0b3fa0 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
> +++ b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
> @@ -126,6 +126,7 @@ dvi_connector_in: endpoint {
>  
>  	dvi-encoder {
>  		compatible = "ti,tfp410";
> +		ti,deskew = <0>;

The driver fallback of 0 appears to be a bug introduced in 2020 by commit
"drm/bridge: tfp410: fix de-skew value retrieval from DT". That commit
changed the ti,deskew scale from -4..3 to 0..7 but did not update the
fallback value from 0 to 4.

As a result, missing properties inadvertently apply maximum negative skew
instead of neutral skew.

By copying this fallback into the device trees, does this permanently
enshrine maximum negative skew into the hardware description? 

If the driver is later fixed to use the correct neutral default, these
boards will still apply maximum negative skew.

Should the physical board schematics be consulted to determine the actual
DK[3:1] pin strapping instead? If the pins are strapped for neutral skew,
the value should likely be <4>.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com?part=2