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

[Josua Mayer <josua@solid-run.com>]

Hi Vladimir,

Am 11.05.26 um 13:24 schrieb Vladimir Oltean:
> 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".
I had the reverse understanding, the switch port specifies rgmii-id,
and the cpu port specifies "rgmii".

The switch port has mode rgmii-id, indicating that someone should add delays.
It is a fixed link without PHY, so switch must add the delays.

From the cpu (eqos) perspcetive it is also a fixed link without phy,
so I specify rgmii indicating nobody should add delays.

Is this correct?

>
>> +	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,
I was expecting device-tree overlays to be used, in which case aliases
are not needed.
> but always use eth
> aliases to get to them.
However if it is okay to add eth[0-9]+ aliases also for switch ports, I'll add them.
> This is in case the port node names ever change,
> to avoid bootloader regressions.
Good point!
>
>> +				reg = <0x1>;
>> +				phy-handle = <&switch_port1_base_tx_phy>;
>> +				phy-mode = "internal";
>> +			};