netdev - [PATCH net-next 3/6] net: phy: Store module caps for PHYs embedded in SFP

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: <20260114225731.811993-4-maxime.chevallier@bootlin.com>
Date: Wed, 14 Jan 2026 23:57:25 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: davem@...emloft.net,
	Andrew Lunn <andrew@...n.ch>,
	Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>,
	Jonas Jelonek <jelonek.jonas@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	thomas.petazzoni@...tlin.com,
	Simon Horman <horms@...nel.org>,
	Romain Gantois <romain.gantois@...tlin.com>,
	Marek Behún <kabel@...nel.org>,
	bcm-kernel-feedback-list@...adcom.com
Subject: [PATCH net-next 3/6] net: phy: Store module caps for PHYs embedded in SFP

When a PHY device is embedded in an SFP module, the PHY driver doesn't
have any information about the module.

Most of the SGMII to 100BaseFX modules seem to contain a Broadcom BCM5461
PHY. This device seems to support a wide range of possible
configurations, with RGMII or SGMII inputs, and BaseT, 100BaseFX and
possibly 1000BaseX output.

However, there doesn't seem to be a capability register that returns
reliable-enough values to detect from the PHY driver what configuration
we are in. On the Prolabs or FS SGMII to 100FX modules for example, the
PHY returns 10/100/1000BaseT capabilities.

We can know the exact configuration by looking at the SFP eeprom, and
the list of linkmodes built by parsing it and applying the quirks and
fixups. Let's make that information available to PHY drivers, so that
they may use that in their .get_features() and configuration process.

Signed-off-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
---
 drivers/net/phy/sfp.c | 5 +++++
 include/linux/phy.h   | 4 ++++
 2 files changed, 9 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 5b42af1cf6aa..1f9112efef62 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1895,6 +1895,11 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)
 	/* Mark this PHY as being on a SFP module */
 	phy->is_on_sfp_module = true;
 
+	/* We need to populate the parent_sfp_caps now, as it may be used during
+	 * the phy registering process, such as in phydrv->get_features()
+	 */
+	phy->parent_sfp_caps = sfp_get_module_caps(sfp->sfp_bus);
+
 	err = phy_device_register(phy);
 	if (err) {
 		phy_device_free(phy);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3beb5dbba791..a515c014679e 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -649,6 +649,8 @@ struct phy_oatc14_sqi_capability {
  * @ports: List of PHY ports structures
  * @n_ports: Number of ports currently attached to the PHY
  * @max_n_ports: Max number of ports this PHY can expose
+ * @parent_sfp_caps: Capabilities of the SFP module that embeds this PHY. Only
+ *		     valid when is_on_sfp_module is true.
  * @lock:  Mutex for serialization access to PHY
  * @state_queue: Work queue for state machine
  * @link_down_events: Number of times link was lost
@@ -791,6 +793,8 @@ struct phy_device {
 	int n_ports;
 	int max_n_ports;
 
+	const struct sfp_module_caps *parent_sfp_caps;
+
 	u8 mdix;
 	u8 mdix_ctrl;
 
-- 
2.49.0