netdev - [PATCH RFC net-next] net: phy: move marking PHY on SFP module into SFP code

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

Date: Tue, 01 Aug 2023 19:57:34 +0100
From: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>
Cc: Frank Wunderlich <frank-w@...lic-files.de>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Eric Woudstra <ericwouds@...il.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org
Subject: [PATCH RFC net-next] net: phy: move marking PHY on SFP module into
 SFP code

Move marking the PHY as being on a SFP module into the SFP code between
getting the PHY device (and thus initialising the phy_device structure)
and registering the discovered device.

This means that PHY drivers can use phy_on_sfp() in their match and
get_features methods.

Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
---
Eric Woudstra has a SFP module that has a realtek PHY on that could
be driven by the realtek PHY driver - except that the PHY is behind
a Rollball access implementation that only supports clause 45 access.

This is a work in progress, but it seems useful in these situations
that drivers should know whether the PHY is on a module very early on,
so that a particular PHY driver instance can choose whether or not to
drive the instance, or maybe use a different PHY driver instance to
drive it - thus allowing a separate set of function pointers for the
clause-45 only accessable PHY.

Some experimental patches can be found at:

https://gist.github.com/ericwoud/d912301a93cd41b39621a65cc372a5c0#file-0000-oem-sfp-2-5g-t-patches-realtek-short-c

and onward discussion prompted this patch. Ignore the first non-patch
C file!

 drivers/net/phy/phy_device.c | 2 --
 drivers/net/phy/sfp.c        | 3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 61921d4dbb13..da544faf1661 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1487,8 +1487,6 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
 
 		if (phydev->sfp_bus_attached)
 			dev->sfp_bus = phydev->sfp_bus;
-		else if (dev->sfp_bus)
-			phydev->is_on_sfp_module = true;
 	}
 
 	/* Some Ethernet drivers try to connect to a PHY device before
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index d855a18308d7..4ecfac227865 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1763,6 +1763,9 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)
 		return PTR_ERR(phy);
 	}
 
+	/* Mark this PHY as being on a SFP module */
+	phy->is_on_sfp_module = true;
+
 	err = phy_device_register(phy);
 	if (err) {
 		phy_device_free(phy);
-- 
2.30.2