From: Andrew Lunn <andrew@lunn.ch>
To: Joey Lu <a0987203069@gmail.com>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
mcoquelin.stm32@gmail.com, richardcochran@gmail.com,
alexandre.torgue@foss.st.com, joabreu@synopsys.com,
ychuang3@nuvoton.com, schung@nuvoton.com, yclu4@nuvoton.com,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH net-next v9 2/3] arm64: dts: nuvoton: Add Ethernet nodes
Date: Mon, 26 Jan 2026 17:17:47 +0100 [thread overview]
Message-ID: <ea3a1f85-0f27-498c-b03b-110456a751da@lunn.ch> (raw)
In-Reply-To: <20260126102257.2619862-3-a0987203069@gmail.com>
On Mon, Jan 26, 2026 at 06:22:56PM +0800, Joey Lu wrote:
> Add GMAC nodes for our MA35D1 development boards:
> two RGMII interfaces for SOM board, and one RGMII
> and one RMII interface for IoT board.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../boot/dts/nuvoton/ma35d1-iot-512m.dts | 33 +++++++++++++++++++
> .../boot/dts/nuvoton/ma35d1-som-256m.dts | 32 ++++++++++++++++++
> arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 32 ++++++++++++++++++
Did you answer my question about what these represent?
I _think_ your .dts{i} files are all messed up and need
re-architecturing.
arch/arm64/boot/dts/nuvoton/ma35d1.dtsi should represent the SoC.
There should be a .dtsi file which represents everything on the SOM.
This includes the SoC .dtsi file.
There should be a .dts file for the carrier board. It should include
the SOM .dtsi file.
You said one of the boards does not use the SOM, so it can directly
import the SoC .dtsi file.
> 3 files changed, 97 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
> index 9482bec1aa57..ee32cedf3d9b 100644
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
> @@ -18,6 +18,8 @@ aliases {
> serial12 = &uart12;
> serial13 = &uart13;
> serial14 = &uart14;
> + ethernet0 = &gmac0;
> + ethernet1 = &gmac1;
> };
>
> chosen {
> @@ -126,3 +128,34 @@ &uart14 {
> pinctrl-0 = <&pinctrl_uart14>;
> status = "okay";
> };
> +
> +&gmac0 {
> + phy-handle = <ð_phy0>;
This is a .dts file, so represents a board. You said the PHYs are on
the board, not the SOM. So this is correct.
> + status = "okay";
> +
> + mdio0: mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
The MDIO bus is a property of the SoC. It always exists, even if it is
not used. So the mdio node should be in the SoC .dtsi file.
> + eth_phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
The PHY is a property of the board, so should be in the board .dts
file.
> + };
> +};
> +
> +&gmac1 {
> + phy-mode = "rmii";
> + phy-handle = <ð_phy1>;
> + status = "okay";
Correct.
> +
> + mdio1: mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
Wrong.
> +
> + eth_phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
Correct.
> + };
> +};
> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
> index f6f20a17e501..b1b3e45280d5 100644
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
> @@ -18,6 +18,8 @@ aliases {
> serial12 = &uart12;
> serial14 = &uart14;
> serial16 = &uart16;
> + ethernet0 = &gmac0;
> + ethernet1 = &gmac1;
> };
>
> chosen {
> @@ -129,3 +131,33 @@ &uart16 {
> pinctrl-0 = <&pinctrl_uart16>;
> status = "okay";
> };
> +
> +&gmac0 {
> + phy-handle = <ð_phy0>;
> + status = "okay";
> +
> + mdio0: mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> +};
> +
> +&gmac1 {
> + phy-handle = <ð_phy1>;
> + status = "okay";
> +
> + mdio1: mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> + };
> +};
Same problem as above.
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
This represents the SoC.
> @@ -379,5 +379,37 @@ uart16: serial@40880000 {
> clocks = <&clk UART16_GATE>;
> status = "disabled";
> };
> +
> + gmac0: ethernet@40120000 {
> + compatible = "nuvoton,ma35d1-dwmac";
> + reg = <0x0 0x40120000 0x0 0x10000>;
> + interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq";
> + clocks = <&clk EMAC0_GATE>, <&clk EPLL_DIV8>;
> + clock-names = "stmmaceth", "ptp_ref";
> +
> + nuvoton,sys = <&sys 0>;
> + resets = <&sys MA35D1_RESET_GMAC0>;
> + reset-names = "stmmaceth";
> +
> + phy-mode = "rgmii-id";
PHY mode is a property of the board. The board might have extra long
clock lines, so needs 'rgmii'. The board might use MII?
Please think about the hierarchy. SoC -> SoM -> board. Put the
properties at the correct level.
Andrew
---
pw-bot: cr
next prev parent reply other threads:[~2026-01-26 16:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 10:22 [PATCH net-next v9 0/3] Add support for Nuvoton MA35D1 GMAC Joey Lu
2026-01-26 10:22 ` [PATCH net-next v9 1/3] dt-bindings: net: nuvoton: Add schema for Nuvoton MA35 family GMAC Joey Lu
2026-01-26 10:22 ` [PATCH net-next v9 2/3] arm64: dts: nuvoton: Add Ethernet nodes Joey Lu
2026-01-26 16:17 ` Andrew Lunn [this message]
2026-01-26 10:22 ` [PATCH net-next v9 3/3] net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family Joey Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea3a1f85-0f27-498c-b03b-110456a751da@lunn.ch \
--to=andrew@lunn.ch \
--cc=a0987203069@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=schung@nuvoton.com \
--cc=ychuang3@nuvoton.com \
--cc=yclu4@nuvoton.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®