linux-kernel - Re: [RFC PATCH v2 2/2] net: mdio: rtl9300: setup PHY polling registers

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: <aXITnCLt945xHqaP@shell.armlinux.org.uk>
Date: Thu, 22 Jan 2026 12:10:04 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Daniel Golle <daniel@...rotopia.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>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jonas Jelonek <jelonek.jonas@...il.com>,
	Markus Stockhausen <markus.stockhausen@....de>
Subject: Re: [RFC PATCH v2 2/2] net: mdio: rtl9300: setup PHY polling
 registers

On Thu, Jan 22, 2026 at 04:00:56AM +0000, Daniel Golle wrote:
> +	/* Detect if PHY has 2.5G/5G/10G capabilities */
> +	if (linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, phydev->supported) ||
> +	    linkmode_test_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, phydev->supported) ||
> +	    linkmode_test_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, phydev->supported))
> +		mac_type = SMI_MAC_TYPE_CTRL_2G_PLUS;
> +	else
> +		mac_type = SMI_MAC_TYPE_CTRL_1G;

There are PHYs which change their support depending on how they're
configured, and there are PHYs that aren't configured correctly at
probe time (and thus their ->supported mask is not correct.)

The next thing I'm concerned about is the need to encode register
information into this driver for each PHY that could be connected.
Will there only be a small subset of PHYs that get used with this
switch, or can any PHY be connected? If the latter, then encoding
register information doesn't scale.

So, I don't think this is a good solution.

I'm wondering whether it would be better to have a callback through
the bus when the PHY is connected with a netdev (in other words,
after phy_init_hw() in phy_attach_direct()) which should be when
the ->supported mask is fully up to date. This also means that the
driver is bound, and we could then consider some kind of interface
that would allow data about the PHY to be requested, such as register
information. That would likely eliminate your need to test the
phydev->supported bitmask (which I think is there to determine whether
you need to tell your MDIO polling controller where certain registers
are.)

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