Re: [PATCH v4 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Mon, May 11, 2026 at 12:11:31PM +0200, Josua Mayer wrote:
> +&eqos {
> +	/* delays are added by connected ethernet-switch cpu port */
> +	phy-mode = "rgmii";

Documentation/devicetree/bindings/net/ethernet-controller.yaml says:

# Informative
# ===========
#
# 'phy-modes' & 'phy-connection-type' properties 'rgmii', 'rgmii-id',
# 'rgmii-rxid', and 'rgmii-txid' are frequently used wrongly by
# developers. This informative section clarifies their usage.
#
# The RGMII specification requires a 2ns delay between the data and
# clock signals on the RGMII bus. How this delay is implemented is not
# specified.
#
# One option is to make the clock traces on the PCB longer than the
# data traces. A sufficient difference in length can provide the 2ns
# delay. If both the RX and TX delays are implemented in this manner,
# 'rgmii' should be used, so indicating the PCB adds the delays.
#
# If the PCB does not add these delays via extra long traces,
# 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',
# where either the MAC or PHY adds the delay.
#
# If only one of the two delays are implemented via extra long clock
# lines, either 'rgmii-rxid' or 'rgmii-txid' should be used,
# indicating the MAC or PHY should implement one of the delays
# internally, while the PCB implements the other delay.
#
# Device Tree describes hardware, and in this case, it describes the
# PCB between the MAC and the PHY, if the PCB implements delays or
# not.
#
# In practice, very few PCBs make use of extra long clock lines. Hence
# any RGMII phy mode other than 'rgmii-id' is probably wrong, and is
# unlikely to be accepted during review without details provided in
# the commit description and comments in the .dts file.

My understanding from the above is that when the RGMII delays are
provided by the switch, the eqos should have phy-mode = "rgmii-id".

> +	pinctrl-0 = <&eqos_pins>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +
> +	fixed-link {
> +		full-duplex;
> +		speed = <1000>;
> +	};
> +};
> +
> +&lpspi0 {
> +	cs-gpios = <&lsio_gpio1 8 GPIO_ACTIVE_LOW>, <&lsio_gpio1 7 GPIO_ACTIVE_LOW>;
> +	pinctrl-0 = <&lpspi0_pins>, <&switch_pins>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +
> +	ethernet-switch@0 {
> +		compatible = "nxp,sja1110a";
> +		reg = <0>;
> +		reset-gpios = <&lsio_gpio4 3 GPIO_ACTIVE_LOW>;
> +		spi-max-frequency = <4000000>;
> +
> +		ethernet-ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			/* 100Base-TX on connector J26 */
> +			port@1 {

Some people might prefer seeing ethernet-port@N instead of port@N, to
fully avoid confusion with dtschema/schemas/graph.yaml (although, the
container node being ethernet-ports now, the confusion should be
avoidable).

Also, if you ever perform device tree fixups from the bootloader (like
for setting status = "disabled" to status = "okay" for the ports that go
to addon boards), please never hardcode fixup paths, but always use eth
aliases to get to them. This is in case the port node names ever change,
to avoid bootloader regressions.

> +				reg = <0x1>;
> +				phy-handle = <&switch_port1_base_tx_phy>;
> +				phy-mode = "internal";
> +			};