linux-kernel - [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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <SEYPR06MB51342977EC2246163D14BDC19DCDA@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Thu, 13 Nov 2025 10:40:37 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: 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: [PATCH net-next v4 4/4] net: ftgmac100: Add RGMII delay support for
 AST2600

> > > This is an optional property. If it does not exist, you have an old
> > > DT blob. It is not an error. So you need to do different things
> > > depending on what the error code is. If it does not exist, just
> > > return 0 and leave the hardware alone. If it is some other error report it,
> and abort the probe.
> > >
> >
> > Based on this for next version, I want to move the "aspeed,scu" from dtsi to
> dts.
> > Change it to optional and accord it whether existed to decide it is
> > old or new DT blob.
> 
> I think that is the easy way out, not necessarily the correct way.
> 

Agreed.
That's easy to implement adding support RGMII delay configuration for AST2600.
According to aspeed,scu property if it is a new dts.
If it is old dts, ignore delay setting flow.
If new one, configure the corresponding value from tx/rx-internal-delay-ps
properties.

At first, I would just like to support for new dts based on AST2600.
The existed dts in kernel is as legacy dts for AST2600 and try to bypass
them. Therefore, I tried to use new compatible or aspeed,scu property to identify
which new dts is.

> All systems have the aspeed,scu, so it should really be in the .dtsi file.
> 
> What are you really trying to solve? That the DT blob says "rgmii", but the
> bootloader has configured the MAC to add delays? You should be able to test
> for that condition. If it is found, issue as warning, and treat phy-mode as
> 'rgmii-id'. If the DT blob says 'rgmii-id' and the MAC is configured to add the
> delays, the system is at least consistent, no need for a warning, disable the
> MAC delays and pass _RGMII_ID to the PHY. And if the blob says 'rgmii-id' and
> the MAC is not adding delays, no need to touch the MAC delay, and pass
> _RGMII_ID to the PHY.
> 
> Are there any mainline DT .dts files which say rgmii-txid, or rgmii-rxid? They
> would be rather odd, but occasionally you see them.
> Assuming there are not lots of them, i would probably just leave everything as
> is.
> 

Based on the above information, I have attempted to outline my understanding.
1. 'rgmii' + MAC delay:
Add warming, keep MAC delay and pass "rgmii-id" to PHY driver.

2. 'rgmii-id' + MAC delay:
disable MAC delay and pass "rgmii-id" to PHY driver

3. 'rgmii-id' + no MAC delay:
Keep disabling MAC delay and pass "rgmii-id" to PHY driver

4. 'rgmii-txid' or 'rgmii-rxid':
Keep original setting

I have some idea to discuss with you.
1. On 'rgmii', I want to add warming and directly disable MAC delay and pass 'rgmii-id' 
to PHY driver.

2. On 'rgmii-id', ignore if enabling MAC delay, all disable MAC delay and pass ' rgmii-id'
to PHY driver.

3. On 'rgmii-txid' or 'rgmii-rxid', keep the above item 4.

Actually, it's difficult for the driver to determine whether the MAC delay is enabled or not.
Our design doesn't use a single bit to indicate the delay state. Instead, the delay setting is 
derived from the user's configured delay value.

>From what I understand, when the TX delay value is set to zero, the data and clock signals 
are almost aligned to the edge - which likely means the MAC TX delay is disabled.

Therefore, I'd prefer the driver to simply configure the MAC delay based on the phy-mode 
and the tx/rx-internal-delay-ps properties.

As you mentioned before, the v4 behavior results in a network interface that can successfully 
probe but does not actually work.
So, I'm also considering another approach on the AST2600:
to not support rgmii, rgmii-txid, or rgmii-rxid modes directly.
If any of these are encountered, the driver could automatically treat them as rgmii-id and issue 
a warning.

Thanks,
Jacky