netdev - Re: [PATCH] net: stmmac: dwmac-sophgo: Add phy interface filter

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: <aPSubO4tJjN_ns-t@shell.armlinux.org.uk>
Date: Sun, 19 Oct 2025 10:25:00 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Inochi Amaoto <inochiama@...il.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>,
	Chen Wang <unicorn_wang@...look.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Han Gao <rabenda.cn@...il.com>, Icenowy Zheng <uwu@...nowy.me>,
	Vivian Wang <wangruikang@...as.ac.cn>, Yao Zi <ziyao@...root.org>,
	netdev@...r.kernel.org, sophgo@...ts.linux.dev,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Yixun Lan <dlan@...too.org>, Longbin Li <looong.bin@...il.com>
Subject: Re: [PATCH] net: stmmac: dwmac-sophgo: Add phy interface filter

On Sun, Oct 19, 2025 at 02:04:02AM +0200, Andrew Lunn wrote:
> > "rgmii-id" doesn't mean "there is a delay _somewhere_ in the system".
> > It's supposed to mean that the PHY should add delays on both tx and
> > rx paths.
> 
> When passed to the PHY it means that.
> 
> However, DT describes the hardware, the PCB. "rgmii-id" means the PCB
> does not provide the delays. So the MAC/PHY combination needs to add
> the delays. We normally have the PHY provide the delays, so the
> phy-mode is normally passed straight to the PHY. However, if the MAC
> is adding a delay, which it is in this case, in one direction and
> cannot be turned off, the value passed to the PHY needs to reflect
> this, to avoid double delays.
> 
> And because the MAC delay cannot be turned off, it means there are PCB
> designs which don't work, double delays. So it would be nice not to
> list them in the binding.

Well, I find this confusing. I'd suggest there needs to be common code
to deal with it so we can stop thinking about it, and just push everyone
towards using the common code.

phy_interface_t phy_fix_phy_mode_for_mac_delays(phy_interface_t interface,
						bool mac_txid, bool mac_rxid)
{
	if (!phy_interface_mode_is_rgmii(interface))
		return interface;

	if (mac_txid && mac_rxid) {
		if (interface == PHY_INTERFACE_MODE_RGMII_ID)
			return PHY_INTERFACE_MODE_RGMII;
		return PHY_INTERFACE_MODE_NA;
	}

	if (mac_txid) {
		if (interface == PHY_INTERFACE_MODE_RGMII_ID)
			return PHY_INTERFACE_MODE_RGMII_RXID;
		if (interface == PHY_INTERFACE_MODE_RGMII_TXID)
			return PHY_INTERFACE_MODE_RGMII;
		return PHY_INTERFACE_MODE_NA;
	}

	if (mac_rxid) {
		if (interface == PHY_INTERFACE_MODE_RGMII_ID)
			return PHY_INTERFACE_MODE_RGMII_TXID;
		if (interface == PHY_INTERFACE_MODE_RGMII_RXID)
			return PHY_INTERFACE_MODE_RGMII;
		return PHY_INTERFACE_MODE_NA;
	}

	return interface;
}

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!