[net] ARM: dts: aspeed: ast2600-evb: Correct phy-mode to rgmii-id

[net] ARM: dts: aspeed: ast2600-evb: Correct phy-mode to rgmii-id

[Jacky Chou]

According to the latest ethernet-controller.yaml.
Since there is no RGMII delay on AST2600 EVB, the phy-mode property of all
MACs change to "rgmii-id" mode.

Fixes: 4d338ee40ba8 ("ARM: dts: aspeed: ast2600-evb: Enable RX delay for MAC0/MAC1")
Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB")
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
---
 arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts b/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts
index de83c0eb1d6e..c4964e536ed7 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts
@@ -123,7 +123,7 @@ ethphy3: ethernet-phy@0 {
 &mac0 {
 	status = "okay";
 
-	phy-mode = "rgmii-rxid";
+	phy-mode = "rgmii-id";
 	phy-handle = <&ethphy0>;
 
 	pinctrl-names = "default";
@@ -134,7 +134,7 @@ &mac0 {
 &mac1 {
 	status = "okay";
 
-	phy-mode = "rgmii-rxid";
+	phy-mode = "rgmii-id";
 	phy-handle = <&ethphy1>;
 
 	pinctrl-names = "default";
@@ -144,7 +144,7 @@ &mac1 {
 &mac2 {
 	status = "okay";
 
-	phy-mode = "rgmii";
+	phy-mode = "rgmii-id";
 	phy-handle = <&ethphy2>;
 
 	pinctrl-names = "default";
@@ -154,7 +154,7 @@ &mac2 {
 &mac3 {
 	status = "okay";
 
-	phy-mode = "rgmii";
+	phy-mode = "rgmii-id";
 	phy-handle = <&ethphy3>;
 
 	pinctrl-names = "default";
-- 
2.34.1

Re: [net] ARM: dts: aspeed: ast2600-evb: Correct phy-mode to rgmii-id

[Krzysztof Kozlowski]

On 21/08/2025 07:25, Jacky Chou wrote:
> According to the latest ethernet-controller.yaml.
> Since there is no RGMII delay on AST2600 EVB, the phy-mode property of all
> MACs change to "rgmii-id" mode.
> 
> Fixes: 4d338ee40ba8 ("ARM: dts: aspeed: ast2600-evb: Enable RX delay for MAC0/MAC1")
> Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB")
> Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
> ---
>  arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts | 8 ++++----

No, DTS cannot go to net. Why do you propose that?

Best regards,
Krzysztof

Re: 回覆: [net] ARM: dts: aspeed: ast2600-evb: Correct phy-mode to rgmii-id

[Krzysztof Kozlowski]

On 21/08/2025 08:17, Jacky Chou wrote:
> Hi Krzysztof,
> 
> Thank you for your reply.
> 
>>> According to the latest ethernet-controller.yaml.
>>> Since there is no RGMII delay on AST2600 EVB, the phy-mode property of
>>> all MACs change to "rgmii-id" mode.
>>>
>>> Fixes: 4d338ee40ba8 ("ARM: dts: aspeed: ast2600-evb: Enable RX delay
>>> for MAC0/MAC1")
>>> Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB")
>>> Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
>>> ---
>>>  arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts | 8 ++++----
>>
>> No, DTS cannot go to net. Why do you propose that?
>>
> 
> If there is a series of patches to add or fix about networking and this series
> Includes dts or dt-binding, I send it to net or net-next.

No. That's really irrelevant. And if you change there I2C you send to
I2C maintainers? That makes no sense.

You send it to respective maintainers. networking things go to netdev.
SoC (so DTS) goes to SoC.


> So, this is just changing the DTS settings, even if it is for MAC,
> wouldn't it be sent to net?

You must follow what MAINTAINERS tell you. Don't invent your own rules.

Best regards,
Krzysztof

Re: [net] ARM: dts: aspeed: ast2600-evb: Correct phy-mode to rgmii-id

[Andrew Lunn]

On Thu, Aug 21, 2025 at 01:25:55PM +0800, Jacky Chou wrote:
> According to the latest ethernet-controller.yaml.
> Since there is no RGMII delay on AST2600 EVB, the phy-mode property of all
> MACs change to "rgmii-id" mode.

> @@ -123,7 +123,7 @@ ethphy3: ethernet-phy@0 {
>  &mac0 {
>  	status = "okay";
>  
> -	phy-mode = "rgmii-rxid";
> +	phy-mode = "rgmii-id";
>  	phy-handle = <&ethphy0>;

How does this change actually work?

I could imaging such a change as part of a patchset which changes the
MAC driver, and how it handles RGMII delays. But on its own, how does
this not break the board?

	Andrew