[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SEYPR06MB5134DD6F514225EA8607DC979D192@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Wed, 15 Jan 2025 02:57:04 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Andrew Lunn <andrew@...n.ch>, Ninad Palsule <ninad@...ux.ibm.com>
CC: "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
"andrew@...econstruct.com.au" <andrew@...econstruct.com.au>,
"conor+dt@...nel.org" <conor+dt@...nel.org>, "davem@...emloft.net"
<davem@...emloft.net>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "eajames@...ux.ibm.com"
<eajames@...ux.ibm.com>, "edumazet@...gle.com" <edumazet@...gle.com>,
"joel@....id.au" <joel@....id.au>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
"kuba@...nel.org" <kuba@...nel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "minyard@....org" <minyard@....org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"openipmi-developer@...ts.sourceforge.net"
<openipmi-developer@...ts.sourceforge.net>, "pabeni@...hat.com"
<pabeni@...hat.com>, "ratbert@...aday-tech.com" <ratbert@...aday-tech.com>,
"robh@...nel.org" <robh@...nel.org>
Subject:
回覆: 回覆: 回覆: 回覆: [PATCH v2 05/10] ARM: dts: aspeed: system1: Add RGMII support
Hi Andrew and Ninad,
> >
> > Thanks. What will be the "phy-mode" value after you make these changes?
> >
> > Will it be "rgmii-id" for MAC1..4?
>
> It should be.
Perhaps we will keep using "rgmii", still add RGMII delay configure on MAC side.
The reason is we cannot be sure all PHYs have support for phy-mode property.
We will refer to the other MACs and PHYs driver about phy-mode and
rx/tx-internal-delay-ps properties how they implement.
Currently, we will plan to implement RGMII delay in ftgmac100 driver based on
ethernet-controller.yaml.
At same time, we will think how to configure these phy-mode "rgmii-rxid", "rgmii-txid"
and "rgmii-id in MAC driver.
>
> > If that is the case then I can test it with current configuration
> > which may add extra delays in the RX from PHY side.
>
> I would then expect traffic will not flow correctly, and your see CRC errors,
> because of double delays. It is however a useful test, because if it does
> somehow work, it probably means the PHY driver is also broken with its
> handling of delays. I don't know what PHY driver you are using, but those in
> mainline should be correct, it is something i try to review carefully.
We will submit a series patch of RGMII delay in ftgmac100 driver to mainline.
Thanks,
Jacky
Powered by blists - more mailing lists