Re: [PATCH v5 3/3] arm64: dts: freescale: add Nodebox v3 CPU Module

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Ethernet PHY nodes are missing hardware interrupt and reset properties despite the hardware lines being explicitly routed and documented.
--

commit 15177a59c196f0e48927f297cc2ef90524059103
Author: Vincent Jardin <vjardin@free.fr>

arm64: dts: freescale: add Nodebox v3 CPU Module

This commit introduces device tree support for the Free Mobile Nodebox v3 CPU
module. The module is built around the NXP LX2160A SoC and includes support
for various interfaces including Ethernet, I2C, and PCI.

> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-nbxv3.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-nbxv3.dtsi
> new file mode 100644
> index 0000000000000..ca4fb5329c0b2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-nbxv3.dtsi
[ ... ]
> +&emdio1 {
> +	status = "okay";
> +
> +	/* Microchip LAN8023 dual 10G PCS/retimer, Clause 45 only, one address per slice */
> +	lan8023_phy_s0: ethernet-phy@2 {
> +		compatible = "ethernet-phy-ieee802.3-c45";
> +		reg = <2>;
> +	};
> +
> +	lan8023_phy_s1: ethernet-phy@3 {
> +		compatible = "ethernet-phy-ieee802.3-c45";
> +		reg = <3>;
> +	};
> +
> +	rtl8211fd: ethernet-phy@6 {
> +		compatible = "ethernet-phy-id001c.c916";
> +		reg = <6>;
> +	};
> +};

[Severity: Medium]
Should these Ethernet PHY nodes include hardware interrupt and reset
properties?

Without the interrupts property, the kernel PHY state machine will fall back
to a 1-second polling interval, which increases latency and wastes CPU cycles.
Missing reset-gpios prevents the kernel from resetting the PHYs during probe,
leaving initialization reliant on the bootloader.

The hardware lines appear to be explicitly routed and documented below in the
gpio-line-names arrays.

[ ... ]
> +&gpio2 {
> +	gpio-line-names =
> +		"lan8023-mdint",
> +		"i2c2-alert#", "i2c4-alert#", "i2c6-alert#",
> +		"u800-tca9539-int#",
> +		"spi3-alert#",
> +		"wake0", "wake1",
> +		"carrier-hot#",
> +		"u1300-rtl8211fd-int#",
[ ... ]
> +	u800: gpio@75 {
> +		compatible = "ti,tca9539";
> +		reg = <0x75>;
> +		#gpio-cells = <2>;
> +		#interrupt-cells = <2>;
> +		gpio-controller;
> +		gpio-line-names =
> +			"carrier-gpio0", "carrier-gpio1",
> +			"carrier-gpio2", "carrier-gpio3",
> +			"carrier-gpio4", "carrier-gpio5",
> +			"carrier-gpio6", "carrier-gpio7",
> +			"carrier-gpio8", "carrier-gpio9",
> +			"carrier-gpio10", "carrier-gpio11",
> +			"", "", "",
> +			"lan8023-rst";

Is it intentional that lan8023-mdint and u1300-rtl8211fd-int# are defined
in &gpio2, and lan8023-rst is defined in u800, but they aren't linked to
their respective PHY nodes in &emdio1?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-for-upstream-nbxv3-dts-v5-0-ead604dba61b@free.fr?part=3