[PATCH net-next 0/6] net: sfp: Add support for SGMII to 100FX modules

[PATCH net-next 0/6] net: sfp: Add support for SGMII to 100FX modules

[Maxime Chevallier]

Hi everyone,

This series is an attempt to add support for _some_ SGMII to 100BaseFX
SFP modules. Getting these to work was a bit challenging, and none of that
could have been done without the precious help from Florian [1].

[1] : https://lore.kernel.org/netdev/20250624233922.45089b95@fedora.home/

Thanks again :)

These modules are quite useful, as some MACs can output SGMII and 1000BaseX,
but can't do 100BaseFX. Should anyone want to connect such a device to a
100FX link-partner, they need to either use an external media-converter,
or an SFP module that has a built-in PHY for that.

SGMII can convey 100M link, but the clock speed stays at 1.25GHz. A
100FX link is clocked at 125MHz, hence the media-converter in the
middle.

As this is something I had to get working, I got my hands on 4 such SFP
modules :

 - A "Cisco-compatible" Prolabs module : "CISCO-PROLABS GLC-GE-100FX-C"
 - A "Generic" Prolabs module : "PROLABS SFP-GE-100FX-C"
 - A FS module : "FS SFP-GE-100FX"
 - A Phoenix Contact module : "PHOENIX CONTACT 2891081"

Out of these, the 2 Prolabs and the FS module contain a Broadcom BCM5461
PHY. Out-of-the-box, they don't work, but thanks to Florian's help I was
able to get the Cisco-Prolabs and the FS one to work.

I couldn't get the Generic Prolabs to work, even though the PHY is
detected and accessible. As for the Phoenix Contact one, I don't know
which PHY it contains, and I couldn't get anything out of it.

This series therefore brings support for the "Cisco-compatible" Prolabs, and the
FS one.

Some oddities were discovered along the way. Some modules are missing
the 100_fx bit in their EEPROM. Even stranger, trying to access the
BCM5461 PHY with regular mdio-i2c accesses causes the PHY to freeze and
get the i2c bus in an unrecoverable stuck state. However, accessing them
in single-byte mdio-i2c accesses does work !

Another thing that needed to be addressed is the SFP interface
selection, that expected that 100FX modules would be using the
PHY_INTERFACE_MODE_100BASEX mode. That's addressed by patch 2, and I'd
really like some feedback from Russell there, I may be breaking things
:(

All in all, this series contains a lot of hacks, but for such peculiar
modules one could expect that this wouldn't fit the current model.

This was tested on 3 different MACs :
 - The KSZ9477's SGMII port (old version of xpcs)
 - The Macchiatobin's eth3 port (mvpp2 + Marvell PCS)
 - A Cyclone V Socfpga device (stmmac + Lynx PCS)

Thank you,

Maxime

Maxime Chevallier (6):
  net: sfp: Add support for SGMII to 100FX modules
  net: phylink: Allow more interfaces in SFP interface selection
  net: phy: Store module caps for PHYs embedded in SFP
  net: phy: broadcom: Support SGMII to 100FX on BCM5461
  net: mdio: mdio-i2c: Add single-byte C22 MDIO protocol
  net: sfp: Add support for some BCM5461-based SGMII to 100FX modules

 drivers/net/mdio/mdio-i2c.c   | 12 +++--
 drivers/net/phy/broadcom.c    | 94 +++++++++++++++++++++++++++++++++++
 drivers/net/phy/phy-caps.h    |  5 ++
 drivers/net/phy/phy_caps.c    | 47 ++++++++++++++++++
 drivers/net/phy/phylink.c     | 24 +++------
 drivers/net/phy/sfp-bus.c     | 11 ++++
 drivers/net/phy/sfp.c         | 31 +++++++++++-
 include/linux/mdio/mdio-i2c.h |  1 +
 include/linux/phy.h           |  4 ++
 9 files changed, 207 insertions(+), 22 deletions(-)

-- 
2.49.0

[PATCH net-next 1/6] net: sfp: Add support for SGMII to 100FX modules

[Maxime Chevallier]

There exist some SFP modules that rely on a built-in PHY (usually a
Broadcom BCM5461) to output 100baseFX, using SGMII as the
phy_interface.

This is relevant as there are devices that support SGMII and 1000BaseX,
but not 100FX natively on their SFP cages.

SGMII can be used to convey 100Mbps links with symbol repetition, but the
serdes lane stays clocked at 1.25GHz. We therefore absolutely need a
media-converter to adapt this to 100BaseFX, that runs at 125MHz.

What this means for the sfp-bus infrastructure is that we may have a PHY
to probe when dealing with a 100FX (and possibly a 100LX) module, and if
this PHY exist it will use SGMII.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/phy/sfp-bus.c | 11 +++++++++++
 drivers/net/phy/sfp.c     |  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index b945d75966d5..85c9f21af69b 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -105,6 +105,14 @@ static void sfp_module_parse_may_have_phy(struct sfp_bus *bus,
 		return;
 	}
 
+	/* Some 100M fiber modules have a PHY, acting as an SGMII to 100FX
+	 * media converter.
+	 */
+	if (id->base.e100_base_fx || id->base.e100_base_lx) {
+		bus->caps.may_have_phy = true;
+		return;
+	}
+
 	if (id->base.phys_id != SFF8024_ID_DWDM_SFP) {
 		switch (id->base.extended_cc) {
 		case SFF8024_ECC_10GBASE_T_SFI:
@@ -188,6 +196,9 @@ static void sfp_module_parse_support(struct sfp_bus *bus,
 	if (id->base.e100_base_fx || id->base.e100_base_lx) {
 		phylink_set(modes, 100baseFX_Full);
 		__set_bit(PHY_INTERFACE_MODE_100BASEX, interfaces);
+
+		/* SGMII to 100Base-FX modules with internal PHY */
+		__set_bit(PHY_INTERFACE_MODE_SGMII, interfaces);
 	}
 	if ((id->base.e_base_px || id->base.e_base_bx10) && br_nom == 100) {
 		phylink_set(modes, 100baseFX_Full);
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 84bef5099dda..5b42af1cf6aa 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2446,7 +2446,8 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
 	    sfp->id.base.extended_cc == SFF8024_ECC_5GBASE_T ||
 	    sfp->id.base.extended_cc == SFF8024_ECC_2_5GBASE_T)
 		sfp->mdio_protocol = MDIO_I2C_C45;
-	else if (sfp->id.base.e1000_base_t)
+	else if (sfp->id.base.e1000_base_t || sfp->id.base.e100_base_fx ||
+		 sfp->id.base.e100_base_lx)
 		sfp->mdio_protocol = MDIO_I2C_MARVELL_C22;
 	else
 		sfp->mdio_protocol = MDIO_I2C_NONE;
-- 
2.49.0

[PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Maxime Chevallier]

When phylink handles an SFP module that contains a PHY, it selects a
phy_interface to use to communicate with it. This selection ensures that
the highest speed gets achieved, based on the linkmodes we want to
support in the module.

This approach doesn't take into account the supported interfaces
reported by the module, but also doesn't handle the fact that the same
linkmode may be achieved using different phy_interface modes.

It becomes an issue when trying to support SGMII to 100FX modules. We
can't feed it 100BaseX, and its MDI isn't 1000BaseT (the modes we expect
for SGMII to be selected).

Let's therefore use a different approach :

 - Get the common interfaces between what the module and the SFP Bus
   support
 - From that common interface list, select the one that can allow us to
   achieve the highest speed

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/phy/phy-caps.h |  5 ++++
 drivers/net/phy/phy_caps.c | 47 ++++++++++++++++++++++++++++++++++++++
 drivers/net/phy/phylink.c  | 24 ++++++-------------
 3 files changed, 59 insertions(+), 17 deletions(-)

diff --git a/drivers/net/phy/phy-caps.h b/drivers/net/phy/phy-caps.h
index 5f3f757e0b2f..4a07ac74ef13 100644
--- a/drivers/net/phy/phy-caps.h
+++ b/drivers/net/phy/phy-caps.h
@@ -10,6 +10,7 @@
 #include <linux/ethtool.h>
 #include <linux/phy.h>
 
+/* this must be sorted by speed */
 enum {
 	LINK_CAPA_10HD = 0,
 	LINK_CAPA_10FD,
@@ -66,4 +67,8 @@ void phy_caps_medium_get_supported(unsigned long *supported,
 				   int lanes);
 u32 phy_caps_mediums_from_linkmodes(unsigned long *linkmodes);
 
+phy_interface_t
+phy_caps_select_fastest_interface(const unsigned long *interfaces,
+				  const unsigned long *linkmodes);
+
 #endif /* __PHY_CAPS_H */
diff --git a/drivers/net/phy/phy_caps.c b/drivers/net/phy/phy_caps.c
index 17a63c931335..11e7a1efcf30 100644
--- a/drivers/net/phy/phy_caps.c
+++ b/drivers/net/phy/phy_caps.c
@@ -443,3 +443,50 @@ u32 phy_caps_mediums_from_linkmodes(unsigned long *linkmodes)
 	return mediums;
 }
 EXPORT_SYMBOL_GPL(phy_caps_mediums_from_linkmodes);
+
+/**
+ * phy_caps_select_fastest_interface - Select the fastest interface that can
+ *				       support the fastest of the given
+ *				       linkmodes
+ * @interfaces: The interface list to lookup from
+ * @linkmodes: Linkmodes we want to support
+ *
+ * Returns: The fastest matching interface, PHY_INTERFACE_MODE_NA otherwise.
+ */
+phy_interface_t
+phy_caps_select_fastest_interface(const unsigned long *interfaces,
+				  const unsigned long *linkmodes)
+{
+	phy_interface_t interface = PHY_INTERFACE_MODE_NA;
+	u32 target_link_caps = 0;
+	int i, max_capa = 0;
+
+	/* Link caps from the linkmodes */
+	for_each_set_bit(i, linkmodes, __ETHTOOL_LINK_MODE_MASK_NBITS) {
+		const struct link_mode_info *linkmode;
+
+		linkmode = &link_mode_params[i];
+		target_link_caps |= speed_duplex_to_capa(linkmode->speed,
+							 linkmode->duplex);
+	}
+
+	for_each_set_bit(i, interfaces, PHY_INTERFACE_MODE_MAX) {
+		u32 interface_caps = phy_caps_from_interface(i);
+		u32 interface_max_capa;
+
+		/* Can we achieve at least one mode with this interface ? */
+		if (!(interface_caps & target_link_caps))
+			continue;
+
+		/* Biggest link_capa we can achieve with this interface */
+		interface_max_capa = fls(interface_caps & target_link_caps);
+
+		if (interface_max_capa > max_capa) {
+			max_capa = interface_max_capa;
+			interface = i;
+		}
+	}
+
+	return interface;
+}
+EXPORT_SYMBOL_GPL(phy_caps_select_fastest_interface);
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 43d8380aaefb..18fa417b87dd 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -2808,27 +2808,19 @@ EXPORT_SYMBOL_GPL(phylink_ethtool_set_wol);
 static phy_interface_t phylink_sfp_select_interface(struct phylink *pl,
 						const unsigned long *link_modes)
 {
-	phy_interface_t interface;
+	DECLARE_PHY_INTERFACE_MASK(common_interfaces);
 
-	interface = sfp_select_interface(pl->sfp_bus, link_modes);
-	if (interface == PHY_INTERFACE_MODE_NA) {
-		phylink_err(pl,
-			    "selection of interface failed, advertisement %*pb\n",
-			    __ETHTOOL_LINK_MODE_MASK_NBITS,
-			    link_modes);
-		return interface;
-	}
+	/* Interfaces supported both by the module and the bus */
+	phy_interface_and(common_interfaces, pl->sfp_interfaces,
+			  pl->config->supported_interfaces);
 
-	if (!test_bit(interface, pl->config->supported_interfaces)) {
+	if (phy_interface_empty(common_interfaces)) {
 		phylink_err(pl,
-			    "selection of interface failed, SFP selected %s (%u) but MAC supports %*pbl\n",
-			    phy_modes(interface), interface,
-			    (int)PHY_INTERFACE_MODE_MAX,
-			    pl->config->supported_interfaces);
+			    "selection of interface failed, no common interface between MAC and SFP\n");
 		return PHY_INTERFACE_MODE_NA;
 	}
 
-	return interface;
+	return phy_caps_select_fastest_interface(common_interfaces, link_modes);
 }
 
 static phy_interface_t phylink_sfp_select_interface_speed(struct phylink *pl,
@@ -3697,8 +3689,6 @@ static int phylink_sfp_config_phy(struct phylink *pl, struct phy_device *phy)
 	struct phylink_link_state config;
 	int ret;
 
-	/* We're not using pl->sfp_interfaces, so clear it. */
-	phy_interface_zero(pl->sfp_interfaces);
 	linkmode_copy(support, phy->supported);
 
 	memset(&config, 0, sizeof(config));
-- 
2.49.0

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Russell King (Oracle)]

On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
> When phylink handles an SFP module that contains a PHY, it selects a
> phy_interface to use to communicate with it. This selection ensures that
> the highest speed gets achieved, based on the linkmodes we want to
> support in the module.
> 
> This approach doesn't take into account the supported interfaces
> reported by the module

This is intentional by design, because the capabilities of the PHY
override in this case. Unfortunately, as I've said previously, the
rush to throw in a regurgitated version of my obsoleted
"host_interfaces" rather messed up my replacement patch set which
had the PHY driver advertising the interface capabilities of the
PHY, which were then going to be used to make the PHY interface
selection when attaching the PHY.

I've still got the code, but I can't now push it into mainline
because, with the obsolete host_interfaces stuff merged, we will end
up with two competing solutions.

In any case, I really would appreciate people looking through
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue

before doing development on SFP and phylink to see whether I've
already something that solves their issue. Quite simply, I don't have
the time to push every patch out that I have, especially as I'm up to
my eyeballs with the crappy stmmac driver now, but also because I
have work items from Oracle that reduce the time I can work on
mainline. BTW, the "age" stated in cgit is based on the commit time
(which gets reset when rebased) not the initial merge time. You will
see that the "supported_interfaces" stuff dates from 2019, not 2025.

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

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Maxime Chevallier]

Hi Russell,

On 15/01/2026 00:30, Russell King (Oracle) wrote:
> On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
>> When phylink handles an SFP module that contains a PHY, it selects a
>> phy_interface to use to communicate with it. This selection ensures that
>> the highest speed gets achieved, based on the linkmodes we want to
>> support in the module.
>>
>> This approach doesn't take into account the supported interfaces
>> reported by the module
> 
> This is intentional by design, because the capabilities of the PHY
> override in this case.

OK makes sense. Just to summarize my understanding, let me know if
I'm wrong there :

 - The interfaces list we have in sfp_module_caps is to be used when we 
   don't have a PHY in the module (there may be one, but we don't
   know/care about it).

 - When we do have a PHY, we _should_ select the interface based on what
   the MAC (+ PCS + Serdes etc.) can output on this sfp-bus and what
   the SFP PHY can take as an input. We ignore the sfp_module_caps
   interfaces list.

> Unfortunately, as I've said previously, the> rush to throw in a regurgitated version of my obsoleted
> "host_interfaces" rather messed up my replacement patch set which
> had the PHY driver advertising the interface capabilities of the
> PHY, which were then going to be used to make the PHY interface
> selection when attaching the PHY.
>
> I've still got the code, but I can't now push it into mainline
> because, with the obsolete host_interfaces stuff merged, we will end
> up with two competing solutions.
> 
> In any case, I really would appreciate people looking through
> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
> 
> before doing development on SFP and phylink to see whether I've
> already something that solves their issue.

So what's the plan there ? This work here is kinda low priority
for me, I wanted to get this out there before continuing with
phy_port followup. Without this patch though, this whole series
is blocked as SGMII will never be selected for 100FX modules.

With your permission, can I pick up your patchs for supported_interfaces
and see what I can do from there ? I also found host_interfaces to be
not enough there.

Knowing that for me, phy_port is the priorty, this is going to be
something I'll do on my free time so don't expect fast progress :(

> Quite simply, I don't have> the time to push every patch out that I have, especially as I'm up to
> my eyeballs with the crappy stmmac driver now, but also because I
> have work items from Oracle that reduce the time I can work on
> mainline. BTW, the "age" stated in cgit is based on the commit time
> (which gets reset when rebased) not the initial merge time. You will
> see that the "supported_interfaces" stuff dates from 2019, not 2025.

Besides that part, will you take a look at the rest of the series ? I'm
not saying that to rush you, but this whole SGMII to 100Fx journey seemed
to me that a lot of hacky stuff, I'd like to get your opinion on the rest
before iterating and facing anther blocking problem down the line on
another part of that series.

I know you have a lot on your plate, but as I said, this series is probably
going to move slowly anyways :)

Maxime

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Maxime Chevallier]

Hi Russell,

On 15/01/2026 00:30, Russell King (Oracle) wrote:
> On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
>> When phylink handles an SFP module that contains a PHY, it selects a
>> phy_interface to use to communicate with it. This selection ensures that
>> the highest speed gets achieved, based on the linkmodes we want to
>> support in the module.
>>
>> This approach doesn't take into account the supported interfaces
>> reported by the module
> 
> This is intentional by design, because the capabilities of the PHY
> override in this case. Unfortunately, as I've said previously, the
> rush to throw in a regurgitated version of my obsoleted
> "host_interfaces" rather messed up my replacement patch set which
> had the PHY driver advertising the interface capabilities of the
> PHY, which were then going to be used to make the PHY interface
> selection when attaching the PHY.
> 
> I've still got the code, but I can't now push it into mainline
> because, with the obsolete host_interfaces stuff merged, we will end
> up with two competing solutions.
> 
> In any case, I really would appreciate people looking through
> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
> 
> before doing development on SFP and phylink to see whether I've
> already something that solves their issue. Quite simply, I don't have
> the time to push every patch out that I have, especially as I'm up to
> my eyeballs with the crappy stmmac driver now, but also because I
> have work items from Oracle that reduce the time I can work on
> mainline.

net-next being closed, I was going through my backlog and I was thinking
about giving this series another go after net-next re-opens, I'd like to
sync with you about the way forward.

In your tree there's :

net: phylink: use phy interface mode bitmaps for SFP PHYs	
net: phy: add supported_interfaces to Aquantia AQR113C
net: phy: add supported_interfaces to marvell10g PHYs
net: phy: add supported_interfaces to marvell PHYs
net: phy: add supported_interfaces to bcm84881
net: phy: add supported_interfaces to phylib

These would be pre-requisites for the 100FX-SGMII SFP support, as the
interface resolution currently doesn't elect SGMII for 100FX modules.

That would require some changes to the current host_interfaces API as
well, potentially replacing it altogether.

Is this something you can do, or can I get your permission to submit
these (ofc maybe with more stuff to deal with host_interfaces)

Thanks,

Maxime

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Russell King (Oracle)]

On Fri, Feb 13, 2026 at 09:41:43AM +0100, Maxime Chevallier wrote:
> Hi Russell,
> 
> On 15/01/2026 00:30, Russell King (Oracle) wrote:
> > On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
> >> When phylink handles an SFP module that contains a PHY, it selects a
> >> phy_interface to use to communicate with it. This selection ensures that
> >> the highest speed gets achieved, based on the linkmodes we want to
> >> support in the module.
> >>
> >> This approach doesn't take into account the supported interfaces
> >> reported by the module
> > 
> > This is intentional by design, because the capabilities of the PHY
> > override in this case. Unfortunately, as I've said previously, the
> > rush to throw in a regurgitated version of my obsoleted
> > "host_interfaces" rather messed up my replacement patch set which
> > had the PHY driver advertising the interface capabilities of the
> > PHY, which were then going to be used to make the PHY interface
> > selection when attaching the PHY.
> > 
> > I've still got the code, but I can't now push it into mainline
> > because, with the obsolete host_interfaces stuff merged, we will end
> > up with two competing solutions.
> > 
> > In any case, I really would appreciate people looking through
> > http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
> > 
> > before doing development on SFP and phylink to see whether I've
> > already something that solves their issue. Quite simply, I don't have
> > the time to push every patch out that I have, especially as I'm up to
> > my eyeballs with the crappy stmmac driver now, but also because I
> > have work items from Oracle that reduce the time I can work on
> > mainline.
> 
> net-next being closed, I was going through my backlog and I was thinking
> about giving this series another go after net-next re-opens, I'd like to
> sync with you about the way forward.
> 
> In your tree there's :
> 
> net: phylink: use phy interface mode bitmaps for SFP PHYs	
> net: phy: add supported_interfaces to Aquantia AQR113C
> net: phy: add supported_interfaces to marvell10g PHYs
> net: phy: add supported_interfaces to marvell PHYs
> net: phy: add supported_interfaces to bcm84881
> net: phy: add supported_interfaces to phylib
> 
> These would be pre-requisites for the 100FX-SGMII SFP support, as the
> interface resolution currently doesn't elect SGMII for 100FX modules.
> 
> That would require some changes to the current host_interfaces API as
> well, potentially replacing it altogether.
> 
> Is this something you can do, or can I get your permission to submit
> these (ofc maybe with more stuff to deal with host_interfaces)

One of the issues that will need to be solved is how to tell
100FX-SGMII (e.g. https://www.fs.com/uk/products/37770.html) which need
SGMII apart from 100FX modules that don't (e.g.
https://www.fs.com/uk/products/37324.html)

host_interfaces don't satisfy that, because this has nothing to do with
what the host can do. Either the module has a PHY and uses SGMII on
the host side, or it doesn't have a PHY in which case 100BASE-X needs
to be used. If we have a PHY, then we will work out using what we
already have.

Given that 100FX-SGMII, the PHY _should_ be coming up in SGMII mode,
so that's what we need to use to talk to them. If we change the PHY's
mode to something else, we get into the horrid problems that is rate
matching, which gives us the problem that we don't have very good
support for that (e.g. PHYs that require the MAC to pace the transmit
rate.)

I suspect there is no way to tell these SFPs apart using the EEPROM,
which means we're left with the "does this module that looks like a
optical module have a PHY?" problem that we already use for copper
SFPs. If there's no detectable PHY, then we'd likely have to assume
that the SFP requires 100BASE-X.

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

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Maxime Chevallier]

Hi Russell,

On 05/03/2026 16:05, Russell King (Oracle) wrote:
> On Fri, Feb 13, 2026 at 09:41:43AM +0100, Maxime Chevallier wrote:
>> Hi Russell,
>>
>> On 15/01/2026 00:30, Russell King (Oracle) wrote:
>>> On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
>>>> When phylink handles an SFP module that contains a PHY, it selects a
>>>> phy_interface to use to communicate with it. This selection ensures that
>>>> the highest speed gets achieved, based on the linkmodes we want to
>>>> support in the module.
>>>>
>>>> This approach doesn't take into account the supported interfaces
>>>> reported by the module
>>>
>>> This is intentional by design, because the capabilities of the PHY
>>> override in this case. Unfortunately, as I've said previously, the
>>> rush to throw in a regurgitated version of my obsoleted
>>> "host_interfaces" rather messed up my replacement patch set which
>>> had the PHY driver advertising the interface capabilities of the
>>> PHY, which were then going to be used to make the PHY interface
>>> selection when attaching the PHY.
>>>
>>> I've still got the code, but I can't now push it into mainline
>>> because, with the obsolete host_interfaces stuff merged, we will end
>>> up with two competing solutions.
>>>
>>> In any case, I really would appreciate people looking through
>>> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
>>>
>>> before doing development on SFP and phylink to see whether I've
>>> already something that solves their issue. Quite simply, I don't have
>>> the time to push every patch out that I have, especially as I'm up to
>>> my eyeballs with the crappy stmmac driver now, but also because I
>>> have work items from Oracle that reduce the time I can work on
>>> mainline.
>>
>> net-next being closed, I was going through my backlog and I was thinking
>> about giving this series another go after net-next re-opens, I'd like to
>> sync with you about the way forward.
>>
>> In your tree there's :
>>
>> net: phylink: use phy interface mode bitmaps for SFP PHYs	
>> net: phy: add supported_interfaces to Aquantia AQR113C
>> net: phy: add supported_interfaces to marvell10g PHYs
>> net: phy: add supported_interfaces to marvell PHYs
>> net: phy: add supported_interfaces to bcm84881
>> net: phy: add supported_interfaces to phylib
>>
>> These would be pre-requisites for the 100FX-SGMII SFP support, as the
>> interface resolution currently doesn't elect SGMII for 100FX modules.
>>
>> That would require some changes to the current host_interfaces API as
>> well, potentially replacing it altogether.
>>
>> Is this something you can do, or can I get your permission to submit
>> these (ofc maybe with more stuff to deal with host_interfaces)
> 
> One of the issues that will need to be solved is how to tell
> 100FX-SGMII (e.g. https://www.fs.com/uk/products/37770.html) which need
> SGMII apart from 100FX modules that don't (e.g.
> https://www.fs.com/uk/products/37324.html)
> 
> host_interfaces don't satisfy that, because this has nothing to do with
> what the host can do. Either the module has a PHY and uses SGMII on
> the host side, or it doesn't have a PHY in which case 100BASE-X needs
> to be used. If we have a PHY, then we will work out using what we
> already have.
> 
> Given that 100FX-SGMII, the PHY _should_ be coming up in SGMII mode,
> so that's what we need to use to talk to them.

_should_ indeed. All modules I got required some level of configuration
of the internal PHY for it to work, and without Florian's help [1] on
how to setup the broadcom PHY in SGMII to 100FX mode, all the modules I
tried were just fancy paperweights :(

[1] : https://lore.kernel.org/netdev/24146e10-5e9c-42f5-9bbe-fe69ddb01d95@broadcom.com/

> If we change the PHY's
> mode to something else, we get into the horrid problems that is rate
> matching, which gives us the problem that we don't have very good
> support for that (e.g. PHYs that require the MAC to pace the transmit
> rate.)
> 
> I suspect there is no way to tell these SFPs apart using the EEPROM,
> which means we're left with the "does this module that looks like a
> optical module have a PHY?" problem that we already use for copper
> SFPs. If there's no detectable PHY, then we'd likely have to assume
> that the SFP requires 100BASE-X.
> 

I agree with that completely. From the few such modules I have, we don't
have much to work with in the eeprom to come-up with a proper generic
support for these.

I see no way around that other than probing for a PHY for every 100FX
module, and see what we get. Alternatively, we could rely on fixups
and have that internal hardcoded database of supported modules ?

Maxime

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Russell King (Oracle)]

On Thu, Mar 05, 2026 at 05:35:50PM +0100, Maxime Chevallier wrote:
> Hi Russell,
> 
> On 05/03/2026 16:05, Russell King (Oracle) wrote:
> > On Fri, Feb 13, 2026 at 09:41:43AM +0100, Maxime Chevallier wrote:
> >> Hi Russell,
> >>
> >> On 15/01/2026 00:30, Russell King (Oracle) wrote:
> >>> On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
> >>>> When phylink handles an SFP module that contains a PHY, it selects a
> >>>> phy_interface to use to communicate with it. This selection ensures that
> >>>> the highest speed gets achieved, based on the linkmodes we want to
> >>>> support in the module.
> >>>>
> >>>> This approach doesn't take into account the supported interfaces
> >>>> reported by the module
> >>>
> >>> This is intentional by design, because the capabilities of the PHY
> >>> override in this case. Unfortunately, as I've said previously, the
> >>> rush to throw in a regurgitated version of my obsoleted
> >>> "host_interfaces" rather messed up my replacement patch set which
> >>> had the PHY driver advertising the interface capabilities of the
> >>> PHY, which were then going to be used to make the PHY interface
> >>> selection when attaching the PHY.
> >>>
> >>> I've still got the code, but I can't now push it into mainline
> >>> because, with the obsolete host_interfaces stuff merged, we will end
> >>> up with two competing solutions.
> >>>
> >>> In any case, I really would appreciate people looking through
> >>> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
> >>>
> >>> before doing development on SFP and phylink to see whether I've
> >>> already something that solves their issue. Quite simply, I don't have
> >>> the time to push every patch out that I have, especially as I'm up to
> >>> my eyeballs with the crappy stmmac driver now, but also because I
> >>> have work items from Oracle that reduce the time I can work on
> >>> mainline.
> >>
> >> net-next being closed, I was going through my backlog and I was thinking
> >> about giving this series another go after net-next re-opens, I'd like to
> >> sync with you about the way forward.
> >>
> >> In your tree there's :
> >>
> >> net: phylink: use phy interface mode bitmaps for SFP PHYs	
> >> net: phy: add supported_interfaces to Aquantia AQR113C
> >> net: phy: add supported_interfaces to marvell10g PHYs
> >> net: phy: add supported_interfaces to marvell PHYs
> >> net: phy: add supported_interfaces to bcm84881
> >> net: phy: add supported_interfaces to phylib
> >>
> >> These would be pre-requisites for the 100FX-SGMII SFP support, as the
> >> interface resolution currently doesn't elect SGMII for 100FX modules.
> >>
> >> That would require some changes to the current host_interfaces API as
> >> well, potentially replacing it altogether.
> >>
> >> Is this something you can do, or can I get your permission to submit
> >> these (ofc maybe with more stuff to deal with host_interfaces)
> > 
> > One of the issues that will need to be solved is how to tell
> > 100FX-SGMII (e.g. https://www.fs.com/uk/products/37770.html) which need
> > SGMII apart from 100FX modules that don't (e.g.
> > https://www.fs.com/uk/products/37324.html)
> > 
> > host_interfaces don't satisfy that, because this has nothing to do with
> > what the host can do. Either the module has a PHY and uses SGMII on
> > the host side, or it doesn't have a PHY in which case 100BASE-X needs
> > to be used. If we have a PHY, then we will work out using what we
> > already have.
> > 
> > Given that 100FX-SGMII, the PHY _should_ be coming up in SGMII mode,
> > so that's what we need to use to talk to them.
> 
> _should_ indeed. All modules I got required some level of configuration
> of the internal PHY for it to work, and without Florian's help [1] on
> how to setup the broadcom PHY in SGMII to 100FX mode, all the modules I
> tried were just fancy paperweights :(
> 
> [1] : https://lore.kernel.org/netdev/24146e10-5e9c-42f5-9bbe-fe69ddb01d95@broadcom.com/

If they don't come up configured correctly, then how do commercial off
the shelf switches work with these modules?

> > If we change the PHY's
> > mode to something else, we get into the horrid problems that is rate
> > matching, which gives us the problem that we don't have very good
> > support for that (e.g. PHYs that require the MAC to pace the transmit
> > rate.)
> > 
> > I suspect there is no way to tell these SFPs apart using the EEPROM,
> > which means we're left with the "does this module that looks like a
> > optical module have a PHY?" problem that we already use for copper
> > SFPs. If there's no detectable PHY, then we'd likely have to assume
> > that the SFP requires 100BASE-X.
> 
> I agree with that completely. From the few such modules I have, we don't
> have much to work with in the eeprom to come-up with a proper generic
> support for these.
> 
> I see no way around that other than probing for a PHY for every 100FX
> module, and see what we get. Alternatively, we could rely on fixups
> and have that internal hardcoded database of supported modules ?

Note that there is base.e100_base_fx and base.e100_base_lx, but also
base.e_base_px and base.e_base_bx10 which can also require 100BASE-X
provided the bitrate is for 100. It would be good to know what
capabilities your modules report.

(side note, I'm looking at:
        if ((id->base.e_base_px || id->base.e_base_bx10) && br_nom == 100) {
and wondering whether that should be 1.25x 100.)

I have some EEPROM dumps in my database for:

        Transceiver codes                         : 0x00 0x00 0x01 0x20 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : SONET: OC-3, short reach
        Transceiver type                          : Ethernet: 100BASE-FX
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x10 0x02 0x10 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : SONET: SONET reach specifier bit 1
        Transceiver type                          : SONET: OC-3, single mode, inter. reach
        Transceiver type                          : Ethernet: 100BASE-LX/LX10
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x00 0x01 0x10 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : SONET: OC-3, short reach
        Transceiver type                          : Ethernet: 100BASE-LX/LX10
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x00 0x00 0x40 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : Ethernet: BASE-BX10
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

I don't have the actual modules though. I think all of these are
ones which require 100BASE-X rather than having a PHY.

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

Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Maxime Chevallier]

>>>> In your tree there's :
>>>>
>>>> net: phylink: use phy interface mode bitmaps for SFP PHYs	
>>>> net: phy: add supported_interfaces to Aquantia AQR113C
>>>> net: phy: add supported_interfaces to marvell10g PHYs
>>>> net: phy: add supported_interfaces to marvell PHYs
>>>> net: phy: add supported_interfaces to bcm84881
>>>> net: phy: add supported_interfaces to phylib
>>>>
>>>> These would be pre-requisites for the 100FX-SGMII SFP support, as the
>>>> interface resolution currently doesn't elect SGMII for 100FX modules.
>>>>
>>>> That would require some changes to the current host_interfaces API as
>>>> well, potentially replacing it altogether.
>>>>
>>>> Is this something you can do, or can I get your permission to submit
>>>> these (ofc maybe with more stuff to deal with host_interfaces)
>>>
>>> One of the issues that will need to be solved is how to tell
>>> 100FX-SGMII (e.g. https://www.fs.com/uk/products/37770.html) which need
>>> SGMII apart from 100FX modules that don't (e.g.
>>> https://www.fs.com/uk/products/37324.html)
>>>
>>> host_interfaces don't satisfy that, because this has nothing to do with
>>> what the host can do. Either the module has a PHY and uses SGMII on
>>> the host side, or it doesn't have a PHY in which case 100BASE-X needs
>>> to be used. If we have a PHY, then we will work out using what we
>>> already have.
>>>
>>> Given that 100FX-SGMII, the PHY _should_ be coming up in SGMII mode,
>>> so that's what we need to use to talk to them.
>>
>> _should_ indeed. All modules I got required some level of configuration
>> of the internal PHY for it to work, and without Florian's help [1] on
>> how to setup the broadcom PHY in SGMII to 100FX mode, all the modules I
>> tried were just fancy paperweights :(
>>
>> [1] : https://lore.kernel.org/netdev/24146e10-5e9c-42f5-9bbe-fe69ddb01d95@broadcom.com/
> 
> If they don't come up configured correctly, then how do commercial off
> the shelf switches work with these modules?

I have no clue, I've only ever tested these with linux boards :/

> 
>>> If we change the PHY's
>>> mode to something else, we get into the horrid problems that is rate
>>> matching, which gives us the problem that we don't have very good
>>> support for that (e.g. PHYs that require the MAC to pace the transmit
>>> rate.)
>>>
>>> I suspect there is no way to tell these SFPs apart using the EEPROM,
>>> which means we're left with the "does this module that looks like a
>>> optical module have a PHY?" problem that we already use for copper
>>> SFPs. If there's no detectable PHY, then we'd likely have to assume
>>> that the SFP requires 100BASE-X.
>>
>> I agree with that completely. From the few such modules I have, we don't
>> have much to work with in the eeprom to come-up with a proper generic
>> support for these.
>>
>> I see no way around that other than probing for a PHY for every 100FX
>> module, and see what we get. Alternatively, we could rely on fixups
>> and have that internal hardcoded database of supported modules ?
> 
> Note that there is base.e100_base_fx and base.e100_base_lx, but also
> base.e_base_px and base.e_base_bx10 which can also require 100BASE-X
> provided the bitrate is for 100. It would be good to know what
> capabilities your modules report.

Ah I didn't know about e_base_bx10 and e_base_px. See below for the capabilities.

> 
> (side note, I'm looking at:
>         if ((id->base.e_base_px || id->base.e_base_bx10) && br_nom == 100) {
> and wondering whether that should be 1.25x 100.)
> 
> I have some EEPROM dumps in my database for:
> 
>         Transceiver codes                         : 0x00 0x00 0x01 0x20 0x00 0x00 0x00 0x00 0x00
>         Transceiver type                          : SONET: OC-3, short reach
>         Transceiver type                          : Ethernet: 100BASE-FX
>         Encoding                                  : 0x02 (4B/5B)
>         BR, Nominal                               : 100MBd
> 
>         Connector                                 : 0x07 (LC)
>         Transceiver codes                         : 0x00 0x10 0x02 0x10 0x00 0x00 0x00 0x00 0x00
>         Transceiver type                          : SONET: SONET reach specifier bit 1
>         Transceiver type                          : SONET: OC-3, single mode, inter. reach
>         Transceiver type                          : Ethernet: 100BASE-LX/LX10
>         Encoding                                  : 0x02 (4B/5B)
>         BR, Nominal                               : 100MBd
> 
>         Connector                                 : 0x07 (LC)
>         Transceiver codes                         : 0x00 0x00 0x01 0x10 0x00 0x00 0x00 0x00 0x00
>         Transceiver type                          : SONET: OC-3, short reach
>         Transceiver type                          : Ethernet: 100BASE-LX/LX10
>         Encoding                                  : 0x02 (4B/5B)
>         BR, Nominal                               : 100MBd
> 
>         Connector                                 : 0x07 (LC)
>         Transceiver codes                         : 0x00 0x00 0x00 0x40 0x00 0x00 0x00 0x00 0x00
>         Transceiver type                          : Ethernet: BASE-BX10
>         Encoding                                  : 0x02 (4B/5B)
>         BR, Nominal                               : 100MBd
> 
> I don't have the actual modules though. I think all of these are
> ones which require 100BASE-X rather than having a PHY.

Then here's more for your database :)

 - Prolabs GLC-GE-100FX-C, with bcm5461 PHY. Works after this series.

	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80
	Encoding                                  : 0x02 (4B/5B)
	BR Nominal                                : 100MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF)                              : 0km
	Length (OM2)                              : 2000m
	Length (OM1)                              : 2000m
	Length (Copper or Active cable)           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1310nm
	Vendor name                               : CISCO-PROLABS
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : GLC-GE-100FX-C
	Vendor rev                                : D2
	Option values                             : 0x00 0x1a
	Option                                    : TX_DISABLE implemented
	BR margin max                             : 0%
	BR margin min                             : 0%
	Vendor SN                                 : PRLF6AFB1141
	Date code                                 : 241216


 - Prolabs SFP-GE-100FX-C, with bcm5461 PHY. Doesn't work after this series :

	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x00 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : Ethernet: 100BASE-FX
	Encoding                                  : 0x02 (4B/5B)
	BR Nominal                                : 100MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF)                              : 0km
	Length (OM2)                              : 2000m
	Length (OM1)                              : 2000m
	Length (Copper or Active cable)           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1310nm
	Vendor name                               : PROLABS
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : SFP-GE-100FX-C
	Vendor rev                                : A3
	Option values                             : 0x00 0x1a
	Option                                    : TX_DISABLE implemented
	BR margin max                             : 0%
	BR margin min                             : 0%
	Vendor SN                                 : PR21F07D1463
	Date code                                 : 250416
	Optical diagnostics support               : Yes
	Laser bias current                        : 0.000 mA
	Laser output power                        : 0.0000 mW / -inf dBm
	Receiver signal average optical power     : 0.0000 mW / -inf dBm
	Module temperature                        : 22.17 degrees C / 71.90 degrees F
	Module voltage                            : 3.3329 V
	Alarm/warning flags implemented           : Yes
	Laser bias current high alarm             : Off
	Laser bias current low alarm              : On
	Laser bias current high warning           : Off
	Laser bias current low warning            : On
	Laser output power high alarm             : Off
	Laser output power low alarm              : On
	Laser output power high warning           : Off
	Laser output power low warning            : On
	Module temperature high alarm             : Off
	Module temperature low alarm              : Off
	Module temperature high warning           : Off
	Module temperature low warning            : Off
	Module voltage high alarm                 : Off
	Module voltage low alarm                  : Off
	Module voltage high warning               : Off
	Module voltage low warning                : Off
	Laser rx power high alarm                 : Off
	Laser rx power low alarm                  : On
	Laser rx power high warning               : Off
	Laser rx power low warning                : On
	Laser bias current high alarm threshold   : 100.000 mA
	Laser bias current low alarm threshold    : 2.000 mA
	Laser bias current high warning threshold : 80.000 mA
	Laser bias current low warning threshold  : 4.000 mA
	Laser output power high alarm threshold   : 0.1510 mW / -8.21 dBm
	Laser output power low alarm threshold    : 0.0253 mW / -15.97 dBm
	Laser output power high warning threshold : 0.1259 mW / -9.00 dBm
	Laser output power low warning threshold  : 0.0316 mW / -15.00 dBm
	Module temperature high alarm threshold   : 75.00 degrees C / 167.00 degrees F
	Module temperature low alarm threshold    : -5.00 degrees C / 23.00 degrees F
	Module temperature high warning threshold : 70.00 degrees C / 158.00 degrees F
	Module temperature low warning threshold  : 0.00 degrees C / 32.00 degrees F
	Module voltage high alarm threshold       : 3.6300 V
	Module voltage low alarm threshold        : 2.9700 V
	Module voltage high warning threshold     : 3.4600 V
	Module voltage low warning threshold      : 3.1300 V
	Laser rx power high alarm threshold       : 1.0000 mW / 0.00 dBm
	Laser rx power low alarm threshold        : 0.0003 mW / -35.23 dBm
	Laser rx power high warning threshold     : 0.5000 mW / -3.01 dBm
	Laser rx power low warning threshold      : 0.0006 mW / -32.22 dBm

- FS SFP-GB-GE-T, with bcm5461 PHY, works after this series :

	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Encoding                                  : 0x02 (4B/5B)
	BR Nominal                                : 100MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF)                              : 0km
	Length (OM2)                              : 2000m
	Length (OM1)                              : 2000m
	Length (Copper or Active cable)           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1310nm
	Vendor name                               : FS
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : SFP-GE-100FX
	Vendor rev                                : 1.0
	Option values                             : 0x00 0x12
	Option                                    : TX_DISABLE implemented
	BR margin max                             : 0%
	BR margin min                             : 0%
	Vendor SN                                 : C2405662285
	Date code                                 : 240606
	Optical diagnostics support               : Yes
	Laser bias current                        : 0.000 mA
	Laser output power                        : 0.0000 mW / -inf dBm
	Receiver signal average optical power     : 0.0000 mW / -inf dBm
	Module temperature                        : 3.96 degrees C / 39.13 degrees F
	Module voltage                            : 3.3236 V
	Alarm/warning flags implemented           : Yes
	Laser bias current high alarm             : Off
	Laser bias current low alarm              : On
	Laser bias current high warning           : Off
	Laser bias current low warning            : Off
	Laser output power high alarm             : Off
	Laser output power low alarm              : On
	Laser output power high warning           : Off
	Laser output power low warning            : Off
	Module temperature high alarm             : Off
	Module temperature low alarm              : Off
	Module temperature high warning           : Off
	Module temperature low warning            : Off
	Module voltage high alarm                 : Off
	Module voltage low alarm                  : Off
	Module voltage high warning               : Off
	Module voltage low warning                : Off
	Laser rx power high alarm                 : Off
	Laser rx power low alarm                  : On
	Laser rx power high warning               : Off
	Laser rx power low warning                : Off
	Laser bias current high alarm threshold   : 90.000 mA
	Laser bias current low alarm threshold    : 2.000 mA
	Laser bias current high warning threshold : 80.000 mA
	Laser bias current low warning threshold  : 4.000 mA
	Laser output power high alarm threshold   : 0.0631 mW / -12.00 dBm
	Laser output power low alarm threshold    : 0.0063 mW / -22.01 dBm
	Laser output power high warning threshold : 0.0501 mW / -13.00 dBm
	Laser output power low warning threshold  : 0.0079 mW / -21.02 dBm
	Module temperature high alarm threshold   : 85.00 degrees C / 185.00 degrees F
	Module temperature low alarm threshold    : -5.00 degrees C / 23.00 degrees F
	Module temperature high warning threshold : 75.00 degrees C / 167.00 degrees F
	Module temperature low warning threshold  : 0.00 degrees C / 32.00 degrees F
	Module voltage high alarm threshold       : 3.5700 V
	Module voltage low alarm threshold        : 3.1300 V
	Module voltage high warning threshold     : 3.4700 V
	Module voltage low warning threshold      : 3.1500 V
	Laser rx power high alarm threshold       : 0.7943 mW / -1.00 dBm
	Laser rx power low alarm threshold        : 0.0006 mW / -32.22 dBm
	Laser rx power high warning threshold     : 0.6310 mW / -2.00 dBm
	Laser rx power low warning threshold      : 0.0008 mW / -30.97 dBm

- Phoenix Contact FL SFP FX, not sure what's in it, not even sure it's
the right kind of module as it shows 200MBd ?

	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : SONET: OC-3, short reach
	Encoding                                  : 0x02 (4B/5B)
	BR Nominal                                : 200MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF)                              : 0km
	Length (OM2)                              : 2000m
	Length (OM1)                              : 2000m
	Length (Copper or Active cable)           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1310nm
	Vendor name                               : PHOENIX CONTACT
	Vendor OUI                                : 00:a0:45
	Vendor PN                                 : 2891081
	Vendor rev                                : 02
	Option values                             : 0x00 0x1a
	Option                                    : TX_DISABLE implemented
	BR margin max                             : 0%
	BR margin min                             : 0%
	Vendor SN                                 : 3053642005
	Date code                                 : 240709
	Optical diagnostics support               : Yes
	Laser bias current                        : 0.000 mA
	Laser output power                        : 0.0000 mW / -inf dBm
	Receiver signal average optical power     : 0.0000 mW / -inf dBm
	Module temperature                        : 17.00 degrees C / 62.60 degrees F
	Module voltage                            : 3.3285 V
	Alarm/warning flags implemented           : Yes
	Laser bias current high alarm             : Off
	Laser bias current low alarm              : On
	Laser bias current high warning           : Off
	Laser bias current low warning            : On
	Laser output power high alarm             : Off
	Laser output power low alarm              : On
	Laser output power high warning           : Off
	Laser output power low warning            : On
	Module temperature high alarm             : Off
	Module temperature low alarm              : Off
	Module temperature high warning           : Off
	Module temperature low warning            : Off
	Module voltage high alarm                 : Off
	Module voltage low alarm                  : Off
	Module voltage high warning               : Off
	Module voltage low warning                : Off
	Laser rx power high alarm                 : Off
	Laser rx power low alarm                  : On
	Laser rx power high warning               : Off
	Laser rx power low warning                : On
	Laser bias current high alarm threshold   : 80.000 mA
	Laser bias current low alarm threshold    : 2.000 mA
	Laser bias current high warning threshold : 70.000 mA
	Laser bias current low warning threshold  : 4.000 mA
	Laser output power high alarm threshold   : 0.0794 mW / -11.00 dBm
	Laser output power low alarm threshold    : 0.0100 mW / -20.00 dBm
	Laser output power high warning threshold : 0.0631 mW / -12.00 dBm
	Laser output power low warning threshold  : 0.0126 mW / -19.00 dBm
	Module temperature high alarm threshold   : 110.00 degrees C / 230.00 degrees F
	Module temperature low alarm threshold    : -40.00 degrees C / -40.00 degrees F
	Module temperature high warning threshold : 100.00 degrees C / 212.00 degrees F
	Module temperature low warning threshold  : -35.00 degrees C / -31.00 degrees F
	Module voltage high alarm threshold       : 3.6000 V
	Module voltage low alarm threshold        : 3.0000 V
	Module voltage high warning threshold     : 3.5000 V
	Module voltage low warning threshold      : 3.1000 V
	Laser rx power high alarm threshold       : 0.5012 mW / -3.00 dBm
	Laser rx power low alarm threshold        : 0.0010 mW / -30.00 dBm
	Laser rx power high warning threshold     : 0.3981 mW / -4.00 dBm
	Laser rx power low warning threshold      : 0.0013 mW / -28.86 dBm

Maxime
> 

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

[Maxime Chevallier]

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@bootlin.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

[PATCH net-next 4/6] net: phy: broadcom: Support SGMII to 100FX on BCM5461

[Maxime Chevallier]

Multiple SFP modules of the type "SGMII to 100BaseFX" appear to be using
a Broadcom BCM5461 PHY as a media converter inside the module. This is
the case for at least the Prolabs GLC-GE-100FX-C, and the FS
SFP-GE-100FX modules.

Out of the box, these modules don't work, and need the PHY to be
configured. Florian Fainelli has helped a lot, and provided some
programming instructions to use this mode in the PHY.

Implement support for that mode, based on Florian's instructions and some
more tweaks found by trial and error.

There's no register we can read from the PHY to know that the PHY is
operating in SGMII to 100FX, so we also add a .get_features() callback
that populates the PHY's supported linkmodes according to the module
caps parsed from the eeprom.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/phy/broadcom.c | 94 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index cb306f9e80cc..bcdd6ed70b6b 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -16,6 +16,7 @@
 #include <linux/delay.h>
 #include <linux/module.h>
 #include <linux/phy.h>
+#include <linux/sfp.h>
 #include <linux/device.h>
 #include <linux/brcmphy.h>
 #include <linux/of.h>
@@ -455,6 +456,78 @@ static int bcm54811_config_init(struct phy_device *phydev)
 	return bcm5481x_set_brrmode(phydev, priv->brr_mode);
 }
 
+static int bcm5461_config_init(struct phy_device *phydev)
+{
+	int rc, val;
+
+	/* We don't have any special steps to follow for anything other than
+	 * SGMII to 100BaseFX
+	 */
+	if (phydev->interface != PHY_INTERFACE_MODE_SGMII ||
+	    !linkmode_test_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT,
+			       phydev->supported))
+		return 0;
+
+	/* Select 1000BASE-X register set (primary SerDes) */
+	val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
+	if (val < 0)
+		return val;
+	val |= BCM54XX_SHD_MODE_1000BX;
+	rc = bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE, val);
+	if (rc < 0)
+		return rc;
+
+	/* Power down SerDes interface */
+	rc = phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN);
+	if (rc < 0)
+		return rc;
+
+	/* Select proper interface mode */
+	val &= ~BCM54XX_SHD_INTF_SEL_MASK;
+	val |= phydev->interface == PHY_INTERFACE_MODE_SGMII ?
+		BCM54XX_SHD_INTF_SEL_SGMII :
+		BCM54XX_SHD_INTF_SEL_GBIC;
+	rc = bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE, val);
+	if (rc < 0)
+		return rc;
+
+	/* Power up SerDes interface */
+	rc = phy_clear_bits(phydev, MII_BMCR, BMCR_PDOWN);
+	if (rc < 0)
+		return rc;
+
+	/* For 100BaseFX, the signal detection is configured in bit 5 of the shadow
+	 * 0b01100 in the 0x1C register.
+	 *
+	 * 0 to use EN_10B/SD as CMOS/TTL signal detect (default)
+	 * 1 to use SD_100FX± as PECL signal detect
+	 */
+	rc = bcm_phy_write_shadow(phydev, 0xC, BIT(5));
+	if (rc < 0)
+		return rc;
+
+	/* You can use either copper or SGMII interface for 100BaseFX and that will
+	 * be configured this way:
+	 *
+	 * - in register 0x1C, shadow 0b10 (1000Base-T/100Base-TX/10Base-T Spare
+	 * Control 1), set bit 4 to 1 to enable 100BaseFX
+	 */
+	rc = bcm_phy_write_shadow(phydev, 0x2, BIT(4));
+	if (rc < 0)
+		return rc;
+
+	/* disable auto-negotiation with register 0x00 = 0x2100 */
+	phy_write(phydev, MII_BMCR, 0x2100);
+
+	/* set register 0x18 to 0x430 (bit 10 -> normal mode, bits 5:4 control
+	 * the edge rate. 0b00 -> 4ns, 0b01 -> 5ns, 0b10 -> 3ns, 0b11 -> 0ns. This
+	 * is the auxiliary control register (MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL).
+	 */
+	phy_write(phydev, 0x18, 0x430);
+
+	return 0;
+}
+
 static int bcm54xx_config_init(struct phy_device *phydev)
 {
 	int reg, err, val;
@@ -492,6 +565,9 @@ static int bcm54xx_config_init(struct phy_device *phydev)
 	case PHY_ID_BCM54210E:
 		err = bcm54210e_config_init(phydev);
 		break;
+	case PHY_ID_BCM5461:
+		err = bcm5461_config_init(phydev);
+		break;
 	case PHY_ID_BCM54612E:
 		err = bcm54612e_config_init(phydev);
 		break;
@@ -1255,6 +1331,23 @@ static void bcm54xx_link_change_notify(struct phy_device *phydev)
 	bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_EXP08, ret);
 }
 
+static int bcm5461_get_features(struct phy_device *phydev)
+{
+	if (!phy_on_sfp(phydev))
+		return genphy_read_abilities(phydev);
+
+	if (!phydev->parent_sfp_caps)
+		return -EINVAL;
+
+	/* For SGMII to 100FX modules, the reported linkmodes from
+	 * genphy_read_abilities() are incorrect. Let's repy on the SFP module
+	 * caps
+	 */
+	linkmode_copy(phydev->supported, phydev->parent_sfp_caps->link_modes);
+
+	return 0;
+}
+
 static int lre_read_master_slave(struct phy_device *phydev)
 {
 	int cfg = MASTER_SLAVE_CFG_UNKNOWN, state;
@@ -1505,6 +1598,7 @@ static struct phy_driver broadcom_drivers[] = {
 	.probe		= bcm54xx_phy_probe,
 	.config_init	= bcm54xx_config_init,
 	.config_intr	= bcm_phy_config_intr,
+	.get_features	= bcm5461_get_features,
 	.handle_interrupt = bcm_phy_handle_interrupt,
 	.link_change_notify	= bcm54xx_link_change_notify,
 	.led_brightness_set	= bcm_phy_led_brightness_set,
-- 
2.49.0

[PATCH net-next 5/6] net: mdio: mdio-i2c: Add single-byte C22 MDIO protocol

[Maxime Chevallier]

In commit d4bd3aca33c2 ("net: mdio: mdio-i2c: Add support for single-byte
SMBus operations"), we introduced single-byte SMBus support for the
mdio-i2c. This was intended to deal with the case where the I2C adapter
that accesses the SFP module is limited to single-byte smbus accesses.
We find this type of adapters in some PHY devices such as the VSC8552.

It was discovered that some SFP modules have a built-in PHY that only
reply to single-byte smbus accesses. This is the case for the Prolabs
GLC-GE-100FX-C SGMII to 100FX module, which contains a Broadcom BCM5461
PHY.

In that case, trying to access the PHY with regular 16-bit transactions
with the mdio-i2c driver causes the PHY to stall the i2c bus completely,
without any way to recover. Accessing it in single-byte mode however,
works fine.

Add a dedicated MDIO_I2C_SINGLE_BYTE_C22 protocol type, so that we can
setup the mdio-i2c driver accordingly. The good news here is that this
should work on pretty much every setup, as a true I2C adapter is also
capable of single-byte accesses thanks to the i2c smbus emulation layer.

Some care will need to be taken should we add support for word-only
smbus adapters.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/mdio/mdio-i2c.c   | 12 ++++++++----
 drivers/net/phy/sfp.c         |  1 +
 include/linux/mdio/mdio-i2c.h |  1 +
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mdio/mdio-i2c.c b/drivers/net/mdio/mdio-i2c.c
index ed20352a589a..86ae8a5c0ebd 100644
--- a/drivers/net/mdio/mdio-i2c.c
+++ b/drivers/net/mdio/mdio-i2c.c
@@ -452,7 +452,8 @@ static bool mdio_i2c_check_functionality(struct i2c_adapter *i2c,
 		return true;
 
 	if (i2c_check_functionality(i2c, I2C_FUNC_SMBUS_BYTE_DATA) &&
-	    protocol == MDIO_I2C_MARVELL_C22)
+	    (protocol == MDIO_I2C_MARVELL_C22 ||
+	     protocol == MDIO_I2C_SINGLE_BYTE_C22))
 		return true;
 
 	return false;
@@ -475,9 +476,12 @@ struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
 	mii->parent = parent;
 	mii->priv = i2c;
 
-	/* Only use SMBus if we have no other choice */
-	if (i2c_check_functionality(i2c, I2C_FUNC_SMBUS_BYTE_DATA) &&
-	    !i2c_check_functionality(i2c, I2C_FUNC_I2C)) {
+	/* Only use single-byte SMBus if explicitly asked, or if we have no
+	 * other choice.
+	 */
+	if (protocol == MDIO_I2C_SINGLE_BYTE_C22 ||
+	    (i2c_check_functionality(i2c, I2C_FUNC_SMBUS_BYTE_DATA) &&
+	    !i2c_check_functionality(i2c, I2C_FUNC_I2C))) {
 		mii->read = smbus_byte_mii_read_default_c22;
 		mii->write = smbus_byte_mii_write_default_c22;
 		return mii;
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 1f9112efef62..bff91735f681 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2016,6 +2016,7 @@ static int sfp_sm_probe_for_phy(struct sfp *sfp)
 		break;
 
 	case MDIO_I2C_MARVELL_C22:
+	case MDIO_I2C_SINGLE_BYTE_C22:
 		err = sfp_sm_probe_phy(sfp, SFP_PHY_ADDR, false);
 		break;
 
diff --git a/include/linux/mdio/mdio-i2c.h b/include/linux/mdio/mdio-i2c.h
index 65b550a6fc32..f51c474da5b1 100644
--- a/include/linux/mdio/mdio-i2c.h
+++ b/include/linux/mdio/mdio-i2c.h
@@ -16,6 +16,7 @@ enum mdio_i2c_proto {
 	MDIO_I2C_MARVELL_C22,
 	MDIO_I2C_C45,
 	MDIO_I2C_ROLLBALL,
+	MDIO_I2C_SINGLE_BYTE_C22,
 };
 
 struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
-- 
2.49.0

[PATCH net-next 6/6] net: sfp: Add support for some BCM5461-based SGMII to 100FX modules

[Maxime Chevallier]

The Prolabs GLC-GE-100FX-C SFP module is a 100BaseFX module that plugs
into a Cisco SGMII capable cage, thus allowing to use 100M fiber on ports
that would usually only support SGMII and 1000BaseX.

This module contains a Broadcom BCM5461 PHY, but fails to properly indicate
support for e.100_fx mode.

The FS SFP-GE-100FX-C is a similar module, but this one does have the
e.100_fx bit set.

Add a quirk and fixup for these modules, to have a consistent linkmode
set, and make sure we use SGMII as the PHY interface.

The Prolabs module absolutely needs single-byte mdio accesses, otherwise
it freezes the i2c bus.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/phy/sfp.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index bff91735f681..fb12616a67c1 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -481,6 +481,23 @@ static void sfp_quirk_ubnt_uf_instant(const struct sfp_eeprom_id *id,
 			 caps->link_modes);
 }
 
+static void sfp_fixup_sgmii_100fx(struct sfp *sfp)
+{
+	sfp->mdio_protocol = MDIO_I2C_SINGLE_BYTE_C22;
+	sfp->module_t_wait = msecs_to_jiffies(500);
+}
+
+static void sfp_quirk_sgmii_100fx(const struct sfp_eeprom_id *id,
+				  struct sfp_module_caps *caps)
+{
+	/* Prolabs GLC-GE-100FX-C SGMII to 100FX module doesn't set the
+	 * base.e100_base_fx bit.
+	 */
+	linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT,
+			 caps->link_modes);
+	__set_bit(PHY_INTERFACE_MODE_SGMII, caps->interfaces);
+}
+
 #define SFP_QUIRK(_v, _p, _s, _f) \
 	{ .vendor = _v, .part = _p, .support = _s, .fixup = _f, }
 #define SFP_QUIRK_S(_v, _p, _s) SFP_QUIRK(_v, _p, _s, NULL)
@@ -553,6 +570,11 @@ static const struct sfp_quirk sfp_quirks[] = {
 	SFP_QUIRK_F("Turris", "RTSFP-2.5G", sfp_fixup_rollball),
 	SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
 	SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
+
+	SFP_QUIRK("CISCO-PROLABS", "GLC-GE-100FX-C",
+		  sfp_quirk_sgmii_100fx, sfp_fixup_sgmii_100fx),
+	SFP_QUIRK("FS", "SFP-GE-100FX",
+		  sfp_quirk_sgmii_100fx, sfp_fixup_sgmii_100fx),
 };
 
 static size_t sfp_strlen(const char *str, size_t maxlen)
-- 
2.49.0