linux-kernel - Re: [PATCH] net: phy: avoid config_init failure on unattached PHY during resume

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250911112525.3824360-1-yicongsrfy@163.com>
Date: Thu, 11 Sep 2025 19:25:25 +0800
From: yicongsrfy@....com
To: linux@...linux.org.uk
Cc: andrew@...n.ch,
	davem@...emloft.net,
	edumazet@...gle.com,
	hkallweit1@...il.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	yicong@...inos.cn
Subject: Re: [PATCH] net: phy: avoid config_init failure on unattached PHY during resume

On Wed, 10 Sep 2025 10:54:05 +0100, "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
>
> On Wed, Sep 10, 2025 at 05:17:03PM +0800, yicongsrfy@....com wrote:
> > Then, because `phydev->interface != PHY_INTERFACE_MODE_SGMII`, it attempts
> > to enter `ytphy_rgmii_clk_delay_config` to configure the RGMII tx/rx delay.
> > However, since this PHY device is not associated with any GMAC and is not
> > connected via an RGMII interface, the function returns `-EOPNOTSUPP`.
>
> It seems the problem is this code:
>
>         /* set rgmii delay mode */
>         if (phydev->interface != PHY_INTERFACE_MODE_SGMII) {
>                 ret = ytphy_rgmii_clk_delay_config(phydev);
>
> which assumes that phydev->interface will be either SGMII or one of
> the RGMII modes. This is not the case with a PHY that has been
> freshly probed unless phydev->interface is set in the probe function.
>
> I see the probe function decodes the PHYs operating mode and
> configures stuff based on that. Maybe, as it only supports RGMII
> and SGMII, it should also initialise phydev->interface to the initial
> operating condition of the PHY if other code in the driver relies
> upon this being set to either SGMII or one of the RGMII types.
>

Thank you for your reply!

What you mentioned above is correct.
However, there is a particular scenario as follows:

Some PHY chips support two addresses, using address 0 as a broadcast address
and address 1 as the hardware address. Both addresses respond to GMAC's MDIO
read/write operations. As a result, during 'mdio_scan', both PHY addresses are
detected, leading to the creation of two PHY device instances (for example,
as in my previous email: xxxxmac_mii_bus-XXXX:00:00 and xxxxmac_mii_bus-XXXX:00:01).

The GMAC will only attach to one of these PHY addresses. Some GMAC drivers
select the first available PHY address (via calling 'phy_find_first'), leaving
the other address idle and unattached. However, during the system resume
process, it attempts to resume this unused PHY instance.

When resuming this PHY instance, because 'phydev->interface' hasn't been
set to a valid interface mode supported by the chip (such as RGMII or SGMII),
we encounter the EOPNOTSUPP error.

I've tried modifying motorcomm.c as a workaround, but logically speaking,
it's not an ideal solution:
1. If I return 0 from the driver's resume function, mdio_bus_phy_resume will proceed.
2. If I return an error, the system will still report an error.

The key issue is: does the current kernel provide any field or mechanism
to indicate that two PHY addresses (instances) actually refer to the same
physical PHY device?

I haven't found any such mechanism in the kernel. Do you have any
suggestions on how to properly handle this?

Looking forward to your advice. Thank you!