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

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] GPIO hog 'thermtrip-hog' on gpio1 pin 23 structurally conflicts with the FSPI pin multiplexer configuration.
- [Medium] The FSPI flash is artificially restricted to 1-bit bus width despite the hardware being wired for 4-bit Quad SPI.
- [Medium] Ethernet PHYs are missing their hardware interrupt assignments, forcing the kernel into inefficient polling mode.
- [Medium] The LAN8023 PHY nodes are missing the `reset-gpios` property, leaving the PHY unreset during initialization.
--

commit 7aa7c67b7fab76be5b6b8b173d9fb60dc30944d9
Author: Vincent Jardin [off-list ref]
Subject: arm64: dts: freescale: add Nodebox v3 CPU Module

This commit introduces the device tree files for the Free Mobile Nodebox v3 CPU
Module based on the NXP LX2160A SoC. It configures the SPI, MDIO, Ethernet, and
GPIO controllers for the board.

[ ... ]

+&fspi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&fspi_dqs_sck_cs10_pins>, <&fspi_data30_pins>;
+};

[Severity: High]
Does this pinmux configuration conflict with the thermtrip-hog defined on gpio1
pin 23?

During boot, the pin controller configures the RCWPMUXCR0 register (via
fspi_dqs_sck_cs10_pins) to route pins 20-23 to the FSPI (XSPI1) controller en
masse. Concurrently, the GPIO driver applies the thermtrip-hog to pin 23 in
fsl-lx2160a-nbxv3.dtsi, attempting to drive it low as a GPIO.

Because the pin multiplexer strictly routes pin 23 to FSPI instead of the GPIO
controller, the GPIO hog will fail to control the physical pad. Furthermore,
the FSPI controller will actively drive pin 23 during SPI accesses, which can
inadvertently toggle the thermal trip line and cause unexpected hardware
shutdowns.

[ ... ]

[ ... ]

+&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>;
+	};

[Severity: Medium]
Will this force the kernel into an inefficient polling mode for the Ethernet
PHYs?

The hardware possesses dedicated interrupt lines for the PHYs, as the gpio2
node explicitly defines the line names 'lan8023-mdint' and
'u1300-rtl8211fd-int#'. Without interrupts and interrupt-parent properties in
the PHY nodes (lan8023_phy_s0, lan8023_phy_s1, and rtl8211fd), the PHY driver
will fall back to periodically polling the MDIO bus to check for link state
changes.

[Severity: Medium]
Should this node also include a reset-gpios property to ensure the PHY is
properly initialized?

The u800 I2C GPIO expander explicitly defines line 15 as 'lan8023-rst'.
Without claiming this GPIO (e.g., reset-gpios = <&u800 15 GPIO_ACTIVE_LOW>),
the Ethernet driver will not execute a hardware reset sequence during probing,
leaving the hardware dependent on the state the bootloader left it in and
potentially failing to recover from a suspended state.

[ ... ]

+&fspi {
+	status = "okay";
+
+	/* GigaDevice GD55LB02GF, 256 MiB boot NOR */
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		spi-max-frequency = <150000000>;
+		spi-rx-bus-width = <1>;
+		spi-tx-bus-width = <1>;
+	};
+};

[Severity: Medium]
Does this artificially restrict the FSPI flash to a 1-bit bus width despite the
hardware being wired for 4-bit Quad SPI?

The pinctrl-0 property in the .dts file includes <&fspi_data30_pins>, which
configures four data lines (DATA[3:0]) for the FSPI controller. However, this
flash@0 node sets the spi-rx-bus-width and spi-tx-bus-width to 1. This mismatch
forces the SPI NOR flash driver to operate in single-bit mode rather than
quad mode, needlessly degrading I/O performance.

[ ... ]

+&gpio1 {
+	status = "okay";

[ ... ]

+	thermtrip-hog {
+		gpio-hog;
+		gpios = <23 GPIO_ACTIVE_HIGH>;
+		output-low;
+		line-name = "thermtrip";
+	};

[Severity: High]
Does this GPIO hog structurally conflict with the FSPI pin multiplexer
configuration in the .dts file?

As mentioned earlier, the fspi node routes pin 23 to the FSPI controller,
meaning the GPIO controller is disconnected from the physical pad. Attempting
to hog it here will fail and may allow the SPI controller to inadvertently
trigger the thermal trip line during accesses.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907-for-upstream-nbxv3-dts-v2-0-6b4afd36180b@free.fr?part=3