linux-kernel - Re: [PATCH net-next v3 02/11] net: phy: introduce phy_has_c45

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: <ZMkraPZvWWKhY8lT@shell.armlinux.org.uk>
Date:   Tue, 1 Aug 2023 16:57:28 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Michael Walle <mwalle@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Yisen Zhuang <yisen.zhuang@...wei.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Marek Behún <kabel@...nel.org>,
        Xu Liang <lxu@...linear.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Simon Horman <simon.horman@...igine.com>
Subject: Re: [PATCH net-next v3 02/11] net: phy: introduce
 phy_has_c45_registers()

On Tue, Aug 01, 2023 at 05:20:22PM +0200, Michael Walle wrote:
> > In the case of the above (the code in __phy_read_mmd()), I wouldn't
> > at least initially change the test there.
> > 
> > phydev->is_c45 will only be true if we probed the PHY using clause
> > 45 accesses. Thus, it will be set if "the bus supports clause 45
> > accesses" _and_ "the PHY responds to those accesses".
> > 
> > Changing that to only "the bus supports clause 45 accesses" means
> > that a PHY supporting only clause 22 access with indirect clause
> > 45 access then fails if it's used with a bus that supports both
> > clause 22 and clause 45 accesses.
> 
> Yeah of course. It was more about the naming, but I just realized
> that with mdiobus_supports_c45() you can't access the original
> "is_c45" property of the PHY. So maybe this patch needs to be split
> into two to get rid of .is_c45:
> 
> First a mechanical one:
> phy_has_c45_registers() {
>    return phydev->is_c45;
> }

Andrew's objection was that "phy_has_c45_registers" is a misnomer, and
suggested "_transfers" instead - because a PHY can have C45 registers
that are accessible via the indirect registers in C22 space.

I'd go one further:

static bool phy_supports_c45_transfers(struct phy_device *phydev)
{
	return phydev->is_c45;
}

Since that covers that (a) the bus needs to support C45 transfers and
(b) the PHY also needs to respond to C45 transfers.

If we want to truly know whether a clause 22 PHY has clause 45
registers, that's difficult to answer, because then you're into the
realms of "does this PHY implement the indirect access method" and
we haven't been keeping track of that for the PHYs we have drivers
for - many will do, but it's optional in clause 22. The problem is
that when it's not implemented, the registers could be serving some
other function.

> phy_has_c22_registers() {
>   return !phydev->is_c45;
> }

The reverse is not true, as clause 45 PHYs can also support clause 22
registers - from 802.3:

 "For cases where a single entity combines Clause 45 MMDs with  Clause 22
 registers, then the Clause 22 registers may be accessed using the Clause
 45 electrical interface and the Clause 22 management frame structure."

 "Bit 5.0 is used to indicate that Clause 22 functionality has been
 implemented within a Clause 45 electrical interface device."

Therefore, this would more accurately describe when Clause 22 registers
are present for a PHY:

static bool phy_has_c22_registers(struct phy_device *phydev)
{
	/* If we probed the PHY without clause 45 accesses, then by
	 * definition, clause 22 registers must be present.
	 */
	if (!phydev->is_c45)
		return true;

	/* If we probed the PHY with clause 45 accesses, clause 22
	 * registers may be present if bit 0 in the Devices-in-pacakge
	 * register pair is set.
	 */
	return phydev->c45_ids.devices_in_package & BIT(0);
}

Note that this doesn't take account of whether the bus supports clause
22 register access - there are a number of MDIO buses that do not
support such accesses, and they may be coupled with a PHY that does
support clause 22 registers.

I'm aware of a SFP with a Realtek PHY on that falls into this exact
case, and getting that working is progressing at the moment.

> For all the places Andrew said it's correct. Leave all the
> other uses of .is_c45 as is for now and rework them in a
> later patch to use mdiobus_supports_{c22,c45}().

For the two cases in marvell10g and bcm84881, the test there for
is_c45 is purely to determine "was this ID found on a PHY supporting
clause 45 access" - however, in both cases, a check is made for MMDs
present in devices_in_package which will fail if the PHY wasn't
discovered in clause 45 mode.

Note that 88x3310 does not support clause 22 access. I forget whether
bcm84881 does or not.

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