linux-kernel - Re: [PATCH net-next v4 4/4] net: ftgmac100: Add RGMII delay support for AST2600

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aSbA8i5S36GeryXc@fedora>
Date: Wed, 26 Nov 2025 00:57:22 -0800
From: Tao Ren <rentao.bupt@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jacky Chou <jacky_chou@...eedtech.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Po-Yu Chuang <ratbert@...aday-tech.com>,
	Joel Stanley <joel@....id.au>,
	Andrew Jeffery <andrew@...econstruct.com.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
	"taoren@...a.com" <taoren@...a.com>
Subject: Re: [PATCH net-next v4 4/4] net: ftgmac100: Add RGMII delay support
 for AST2600

Hi Andrew,

On Wed, Nov 26, 2025 at 12:49:57AM +0100, Andrew Lunn wrote:
> > I try to summary in the following informations that I understand.
> > 
> > 1. with rx-internal-delay-ps OR tx-internal-delay-ps OR both
> > 
> >   Use "rx/tx-internal-delay-ps" property to configure RGMII delay at MAC side
> >   Pass "phy-mode" to PHY driver by calling of_phy_get_and_connect()
> 
> Yes, since they are new properties, you can assume the phy-mode is
> correct for these delays. We just need to watch out for DT developers
> setting these delays to 2000ps and 'rgmii', which would be against the
> guidelines.
> 
> 
> > 2. withour rx-internal-delay-ps AND tx-internal-delay-ps
> > 
> >   If "phy-mode" is 'rgmii-rxid' or 'rgmii-txid':
> > 	Keep original delay
> > 	Print Warning message
> > 	  "Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
> > 
> > There are FOUR conditions in delay configuration:
> > 'X' means RGMII delay setting from bootloader
> > A: 7500 <= X <= 8000, 0 <= X <= 500
> > B: 500 < X < 1500
> > C: 1500 <= X <= 2500
> > 	Mean "Enable RGMII delay" at MAC side
> > D: 2500 < X < 7500
> > 
> >   If "phy-mode" is 'rgmii':
> > 	Condition A:
> > 		Keep original delay
> > 		Update "phy-mode" to 'rgmii-id'
> > 		Print Information message
> > 			"Forced 'phy-mode' to rgmii-id"
> 
> So 0 <= X <= 500 is a small tuning value, so yes, is correct.
> 
> > 	Condition B and D
> > 		Keep original delay
> > 		Print Warning message
> > 	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
> 
> Yes.
> 
> > 	Condition C:
> > 		Disable RGMII delay at MAC side
> > 		Update "phy-mode" to 'rgmii-id'
> > 		Print Warning message
> > 	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
> 
> 'rx/tx-internal-delay-ps are probably not required in this case, the
> 2ns from the PHY is probably sufficient.
> 
> > 
> >   If "phy-mode" is 'rgmii-id':
> > 	Condition A:
> > 		Keep original delay
> > 		Keep "phy-mode" to 'rgmii-id'
> > 	Condition B and D
> > 		Keep original delay
> > 		Print Warning message
> > 	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
> > 	Condition C:
> > 		Disable RGMII delay at MAC side
> > 		Update "phy-mode" to 'rgmii-id'
> > 		Print Warning message
> > 	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
> > 
> 
> These look correct.
> 
> How many different boards do you have you can test with? Do you only
> have access to RDKs? Or do you have a test farm of customer boards for
> regression testing. I would throw the patchset at as many boards as
> you can to make sure there are no regressions.

I synced with Jacky offline a few times, and I'm happy to test the
patches on my Facebook Network OpenBMC platforms.

Hi Jacky,

Looking forward to your v5, and please don't hesitate to ping me offline
if you need more info about my test hardware.


Cheers,

Tao