netdev - 回覆: 回覆: 回覆: 回覆: 回覆: 回覆: [PATCH v2 05/10] ARM: dts: aspeed: system1: Add RGMII support

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:
 <SEYPR06MB51347BB3F94A09B89BD313269DE72@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Mon, 20 Jan 2025 06:59:59 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Ninad Palsule <ninad@...ux.ibm.com>, "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

Thank you for your reply.

> >
> > Yes. I have read these mails.
> >
> > I understand what you mean.
> > "rgmii": delay on PCB, not MAC or PHY.
> > "rgmii-id": delay on MAC or PHY, not PCB.
> >
> > ftgmac100 driver gets phy driver handle from of_phy_get_and_connect(),
> > it will pass the phy-mode to phy driver from the node of mac dts.
> > Therefore, I use "rgmii-id" and the phy will enable tx/rx internal delay.
> > If I use "rgmii-id" and configure the RGMII delay in ftgmac100 driver,
> > I cannot pass the phy-mode to phy driver.
> 
> Quoting myself, yet again:
> 
> > > MAC can apply the delays, but it must mask the phy-mode it passes to the
> PHY.
> 
> If you decide the MAC does the RX clock delay, it needs to mask that from the
> phy-mode, otherwise the PHY will also do it. If you decide the MAC does the TX
> clock delay, its needs to mask that from the phy-mode.

We need to confirm the MAC and RGMII design in AST2600,
And we will replan the phy-mode configuration in ftgmac100 driver and device tree.

Thanks,
Jacky