Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

[Maxime Chevallier]

Hello everyone,

I'm reaching out to discuss an issue I've been facing with some SFP modules
that do SGMII to 100FX conversion.

I'm using that on a product that has 1G-only SFP cage, where SGMII or 1000BaseX
are the only options, and that product needs to talk to a 100FX link partner.

The only way this can ever work is with a media-converter PHY within the SFP,
and apparently such SFP exist :

https://www.fs.com/fr/products/37770.html?attribute=19567&id=335755

I've tried various SFP modules from FS, Prolabs and Phoenix Contact with
no luck. All these modules seem to integrate some variant of the
Broadcom BCM5641 PHYs.

I know that netdev@ isn't about fixing my local issues, but in the odd chance anyone
has ever either used such a module successfully, or has some insight on what is
going on with these Broadcom PHYs, I would appreciate a lot :) Any finding or
patch we can come-up with will be upstreamed of course :)

Any people with some experience on this PHY or this kind of module may be
able to shed some lights on the findings I was able to gather so far.

All modules have the same internal PHY, which exposes itself as a BCM5461 :

	ID : 002060c1
	
I know that because I was able to talk to the PHY using mdio over i2c, at
address 0x56 on the i2c bus. On some modules, the PHY doesn't reply at all,
on some it stalls the i2c bus if I try to do 16bits accesses (I have to use 8 bits
accesses), and on some modules the regular 16bits accesses work...

That alone makes me wonder if there's not some kind of firmware running in
there replying to mdio ?

Regarding what I can achieve with these, YMMV :

 - I have a pair of Prolabs module with the ID "CISCO-PROLABS     GLC-GE-100FX-C".

   These are the ones that can only do 8bits mdio accesses. When the PHY is
   left undriven by the kernel, and you plug it into an SGMII-able SFP port, you
   get a nice loop of 'link is up / link is down / link is up / ...' reported
   by the MAC (or PCS). Its eeprom doesn't even say that it's a 100fx module
   (id->base.e100_base_fx isn't set). It does say "Cisco compatible", maybe it's
   using some flavour of SGMII that I don't know about ?
   
 - I have a pair of FS modules with the ID "FS     SFP-GE-100FX". These behave
   almost exactly as the ones above, but it can be accessed with 16-bits mdio
   transactions.
   
 - I have a "PHOENIX CONTACT    2891081" that simply doesn't work
 
 - And maybe the most promising of all, a pair of "PROLABS    SFP-GE-100FX-C".
   These reply on 16bits mdio accesses, and when you plug them with the PHY
   undriven by the kernel (so relying only on internal config and straps), I
   get link-up detected by the MAC through inband SGMII, and I can receive
   traffic ! TX doesn't work though :(

On the MAC side, I tested with 3 different SoC, all using a different PCS :
 - A Turris Omnia, that uses mvneta and its PCS
 - A dwmac-socfpga board, using a Lynx / Altera TSE PCS to drive the SGMII
 - A KSZ9477 and its variant of DW XPCS.

The behaviour is the same on all of them, so I'd say there's a very good chance
the modules are acting up. TBH I don't know much about sourcing SFPs, they
behave so differently that it may just be that I didn't find the exact reference
that for some reason happens to work ?

The link-partner is a device that only does 100BaseX.

On all of these modules, I've tried to either let the PHY completely unmanaged
by the kernel, no mdio transactions whatsoever and we leave the default PHY
settings to their thing. As nothing worked, I've tried driving the PHY through
the kernel's broadcom.c driver, but that driver really doesn't support 100FX so
it's also expected that this doesn't work. Unfortunately, I don't have
access to any documentation for that PHY...

The driver does say, for a similar model :

	/* The PHY is strapped in RGMII-fiber mode when INTERF_SEL[1:0]
	 * is 01b, and the link between PHY and its link partner can be
	 * either 1000Base-X or 100Base-FX.
	 * RGMII-1000Base-X is properly supported, but RGMII-100Base-FX
	 * support is still missing as of now.
	 */

Not quite the same as our case as it's talking about RGMII, not SGMII, but
maybe the people who wrote that code know a bit more or have access to some
documentation ? I've tried to put these persons in CC :)

In any case, should anyone want to give this a shot in the future, I'm using the
following patch so that the SFP machinery can try to probe PHYs on these
non-copper modules - that patch needs splitting up and is more of a hack than
anything else.

Thanks a lot everyone, and sorry for the noise if this is misplaced,

Maxime

-------x8---------------------------------------------------------------

From 101b7cc3c343f6b28e49aa11ed6e759797a1c2b5 Mon Sep 17 00:00:00 2001
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Wed, 19 Mar 2025 16:13:58 +0100
Subject: [PATCH] net: sfp: Allow using a range of SGMII to 100BaseX SFP module

SGMII to 100BaseX modules are useful to support 100M links on a 1G
capable SFP port. These modules have an internal PHY, but none of the
tested modules appear to work.

This patch allows selecting SGMII as the host serdes interface for these
modules, as well as to try and drive the internal PHY from linux as a
last-effort attempt to get them to work, unsuccessfully.

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

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index f13c00b5b449..3ea062a66f37 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -120,6 +120,9 @@ bool sfp_may_have_phy(struct sfp_bus *bus, const struct sfp_eeprom_id *id)
 	if (id->base.e1000_base_t)
 		return true;
 
+	if (id->base.e100_base_fx)
+		return true;
+
 	if (id->base.phys_id != SFF8024_ID_DWDM_SFP) {
 		switch (id->base.extended_cc) {
 		case SFF8024_ECC_10GBASE_T_SFI:
@@ -213,6 +216,7 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
 	if (id->base.e100_base_fx || id->base.e100_base_lx) {
 		phylink_set(modes, 100baseFX_Full);
 		__set_bit(PHY_INTERFACE_MODE_100BASEX, interfaces);
+		__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);
@@ -378,7 +382,8 @@ phy_interface_t sfp_select_interface(struct sfp_bus *bus,
 		return PHY_INTERFACE_MODE_2500BASEX;
 
 	if (phylink_test(link_modes, 1000baseT_Half) ||
-	    phylink_test(link_modes, 1000baseT_Full))
+	    phylink_test(link_modes, 1000baseT_Full) ||
+	    phylink_test(link_modes, 100baseFX_Full))
 		return PHY_INTERFACE_MODE_SGMII;
 
 	if (phylink_test(link_modes, 1000baseX_Full))
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 5347c95d1e77..03ba78d71b51 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -476,6 +476,19 @@ static void sfp_quirk_ubnt_uf_instant(const struct sfp_eeprom_id *id,
 	linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT, modes);
 }
 
+static void sfp_fixup_sgmii_to_100base(struct sfp *sfp)
+{
+	sfp->mdio_protocol = MDIO_I2C_MARVELL_C22;
+}
+
+static void sfp_quirk_sgmii_to_100base(const struct sfp_eeprom_id *id,
+				       unsigned long *modes,
+				       unsigned long *interfaces)
+{
+	linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT, modes);
+	__set_bit(PHY_INTERFACE_MODE_SGMII, interfaces);
+}
+
 #define SFP_QUIRK(_v, _p, _m, _f) \
 	{ .vendor = _v, .part = _p, .modes = _m, .fixup = _f, }
 #define SFP_QUIRK_M(_v, _p, _m) SFP_QUIRK(_v, _p, _m, NULL)
@@ -543,6 +556,15 @@ 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_to_100base,
+						     sfp_fixup_sgmii_to_100base),
+	SFP_QUIRK("PROLABS", "SFP-GE-100FX-C", sfp_quirk_sgmii_to_100base,
+					       sfp_fixup_sgmii_to_100base),
+	SFP_QUIRK("FS", "SFP-GE-100FX", sfp_quirk_sgmii_to_100base,
+					sfp_fixup_sgmii_to_100base),
+	SFP_QUIRK("PHOENIX CONTACT", "2891081", sfp_quirk_sgmii_to_100base,
+						sfp_fixup_sgmii_to_100base),
 };
 
 static size_t sfp_strlen(const char *str, size_t maxlen)
-- 
2.49.0

Re: Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

[Florian Fainelli]

Howdy,

On 6/24/25 14:39, Maxime Chevallier wrote:
> Hello everyone,
> 
> I'm reaching out to discuss an issue I've been facing with some SFP modules
> that do SGMII to 100FX conversion.
> 
> I'm using that on a product that has 1G-only SFP cage, where SGMII or 1000BaseX
> are the only options, and that product needs to talk to a 100FX link partner.
> 
> The only way this can ever work is with a media-converter PHY within the SFP,
> and apparently such SFP exist :
> 
> https://www.fs.com/fr/products/37770.html?attribute=19567&id=335755
> 
> I've tried various SFP modules from FS, Prolabs and Phoenix Contact with
> no luck. All these modules seem to integrate some variant of the
> Broadcom BCM5641 PHYs.
> 
> I know that netdev@ isn't about fixing my local issues, but in the odd chance anyone
> has ever either used such a module successfully, or has some insight on what is
> going on with these Broadcom PHYs, I would appreciate a lot :) Any finding or
> patch we can come-up with will be upstreamed of course :)
> 
> Any people with some experience on this PHY or this kind of module may be
> able to shed some lights on the findings I was able to gather so far.
> 
> All modules have the same internal PHY, which exposes itself as a BCM5461 :
> 
> 	ID : 002060c1
> 	
> I know that because I was able to talk to the PHY using mdio over i2c, at
> address 0x56 on the i2c bus. On some modules, the PHY doesn't reply at all,
> on some it stalls the i2c bus if I try to do 16bits accesses (I have to use 8 bits
> accesses), and on some modules the regular 16bits accesses work...
> 
> That alone makes me wonder if there's not some kind of firmware running in
> there replying to mdio ?

Unclear, but that ID is correct for the BCM5461 and its variants.

> 
> Regarding what I can achieve with these, YMMV :
> 
>   - I have a pair of Prolabs module with the ID "CISCO-PROLABS     GLC-GE-100FX-C".
> 
>     These are the ones that can only do 8bits mdio accesses. When the PHY is
>     left undriven by the kernel, and you plug it into an SGMII-able SFP port, you
>     get a nice loop of 'link is up / link is down / link is up / ...' reported
>     by the MAC (or PCS). Its eeprom doesn't even say that it's a 100fx module
>     (id->base.e100_base_fx isn't set). It does say "Cisco compatible", maybe it's
>     using some flavour of SGMII that I don't know about ?
>     
>   - I have a pair of FS modules with the ID "FS     SFP-GE-100FX". These behave
>     almost exactly as the ones above, but it can be accessed with 16-bits mdio
>     transactions.
>     
>   - I have a "PHOENIX CONTACT    2891081" that simply doesn't work
>   
>   - And maybe the most promising of all, a pair of "PROLABS    SFP-GE-100FX-C".
>     These reply on 16bits mdio accesses, and when you plug them with the PHY
>     undriven by the kernel (so relying only on internal config and straps), I
>     get link-up detected by the MAC through inband SGMII, and I can receive
>     traffic ! TX doesn't work though :(
> 
> On the MAC side, I tested with 3 different SoC, all using a different PCS :
>   - A Turris Omnia, that uses mvneta and its PCS
>   - A dwmac-socfpga board, using a Lynx / Altera TSE PCS to drive the SGMII
>   - A KSZ9477 and its variant of DW XPCS.
> 
> The behaviour is the same on all of them, so I'd say there's a very good chance
> the modules are acting up. TBH I don't know much about sourcing SFPs, they
> behave so differently that it may just be that I didn't find the exact reference
> that for some reason happens to work ?
> 
> The link-partner is a device that only does 100BaseX.
> 
> On all of these modules, I've tried to either let the PHY completely unmanaged
> by the kernel, no mdio transactions whatsoever and we leave the default PHY
> settings to their thing. As nothing worked, I've tried driving the PHY through
> the kernel's broadcom.c driver, but that driver really doesn't support 100FX so
> it's also expected that this doesn't work. Unfortunately, I don't have
> access to any documentation for that PHY...
> 
> The driver does say, for a similar model :
> 
> 	/* The PHY is strapped in RGMII-fiber mode when INTERF_SEL[1:0]
> 	 * is 01b, and the link between PHY and its link partner can be
> 	 * either 1000Base-X or 100Base-FX.
> 	 * RGMII-1000Base-X is properly supported, but RGMII-100Base-FX
> 	 * support is still missing as of now.
> 	 */
> 
> Not quite the same as our case as it's talking about RGMII, not SGMII, but
> maybe the people who wrote that code know a bit more or have access to some
> documentation ? I've tried to put these persons in CC :)

Not sure if you can probe the various pins, but those that would be 
interesting to measure would be:

LNKSPD[1] / INTF_SEL[0]
LNKSPD[2] / INTF_SEL[1]
RGMIIEN
EN_10B/SD

You can forcibly enable RGMII operation by writing to register 0x18, 
shadow 0b111 (MII_BCM54XX_AUXCTL_SHDWSEL_MISC) and setting bit 7 
(MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_EN).

 > > In any case, should anyone want to give this a shot in the future, 
I'm using the
> following patch so that the SFP machinery can try to probe PHYs on these
> non-copper modules - that patch needs splitting up and is more of a hack than
> anything else.
> 
> Thanks a lot everyone, and sorry for the noise if this is misplaced,

For 100BaseFX, the signal detection is configured in bit 5 of the shadow 
0b01100 in the 0x1C register. You can use bcm_{read,write}_shadow() for 
that:

0 to use EN_10B/SD as CMOS/TTL signal detect (default)
1 to use SD_100FX± as PECL signal detect

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

- disable auto-negotiation with register 0x00 = 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).

It's unclear from the datasheet whether 100BaseFX can work with RGMII.

Good luck!
-- 
Florian

Re: Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

[Maxime Chevallier]

Hi Florian,

On Tue, 24 Jun 2025 15:29:25 -0700
Florian Fainelli <florian.fainelli@broadcom.com> wrote:

> Howdy,
> 
> On 6/24/25 14:39, Maxime Chevallier wrote:
> > Hello everyone,
> > 
> > I'm reaching out to discuss an issue I've been facing with some SFP modules
> > that do SGMII to 100FX conversion.
> > 
> > I'm using that on a product that has 1G-only SFP cage, where SGMII or 1000BaseX
> > are the only options, and that product needs to talk to a 100FX link partner.
> > 
> > The only way this can ever work is with a media-converter PHY within the SFP,
> > and apparently such SFP exist :
> > 
> > https://www.fs.com/fr/products/37770.html?attribute=19567&id=335755
> > 
> > I've tried various SFP modules from FS, Prolabs and Phoenix Contact with
> > no luck. All these modules seem to integrate some variant of the
> > Broadcom BCM5641 PHYs.
> > 
> > I know that netdev@ isn't about fixing my local issues, but in the odd chance anyone
> > has ever either used such a module successfully, or has some insight on what is
> > going on with these Broadcom PHYs, I would appreciate a lot :) Any finding or
> > patch we can come-up with will be upstreamed of course :)
> > 
> > Any people with some experience on this PHY or this kind of module may be
> > able to shed some lights on the findings I was able to gather so far.
> > 
> > All modules have the same internal PHY, which exposes itself as a BCM5461 :
> > 
> > 	ID : 002060c1
> > 	
> > I know that because I was able to talk to the PHY using mdio over i2c, at
> > address 0x56 on the i2c bus. On some modules, the PHY doesn't reply at all,
> > on some it stalls the i2c bus if I try to do 16bits accesses (I have to use 8 bits
> > accesses), and on some modules the regular 16bits accesses work...
> > 
> > That alone makes me wonder if there's not some kind of firmware running in
> > there replying to mdio ?  
> 
> Unclear, but that ID is correct for the BCM5461 and its variants.
> 
> > 
> > Regarding what I can achieve with these, YMMV :
> > 
> >   - I have a pair of Prolabs module with the ID "CISCO-PROLABS     GLC-GE-100FX-C".
> > 
> >     These are the ones that can only do 8bits mdio accesses. When the PHY is
> >     left undriven by the kernel, and you plug it into an SGMII-able SFP port, you
> >     get a nice loop of 'link is up / link is down / link is up / ...' reported
> >     by the MAC (or PCS). Its eeprom doesn't even say that it's a 100fx module
> >     (id->base.e100_base_fx isn't set). It does say "Cisco compatible", maybe it's
> >     using some flavour of SGMII that I don't know about ?
> >     
> >   - I have a pair of FS modules with the ID "FS     SFP-GE-100FX". These behave
> >     almost exactly as the ones above, but it can be accessed with 16-bits mdio
> >     transactions.
> >     
> >   - I have a "PHOENIX CONTACT    2891081" that simply doesn't work
> >   
> >   - And maybe the most promising of all, a pair of "PROLABS    SFP-GE-100FX-C".
> >     These reply on 16bits mdio accesses, and when you plug them with the PHY
> >     undriven by the kernel (so relying only on internal config and straps), I
> >     get link-up detected by the MAC through inband SGMII, and I can receive
> >     traffic ! TX doesn't work though :(
> > 
> > On the MAC side, I tested with 3 different SoC, all using a different PCS :
> >   - A Turris Omnia, that uses mvneta and its PCS
> >   - A dwmac-socfpga board, using a Lynx / Altera TSE PCS to drive the SGMII
> >   - A KSZ9477 and its variant of DW XPCS.
> > 
> > The behaviour is the same on all of them, so I'd say there's a very good chance
> > the modules are acting up. TBH I don't know much about sourcing SFPs, they
> > behave so differently that it may just be that I didn't find the exact reference
> > that for some reason happens to work ?
> > 
> > The link-partner is a device that only does 100BaseX.
> > 
> > On all of these modules, I've tried to either let the PHY completely unmanaged
> > by the kernel, no mdio transactions whatsoever and we leave the default PHY
> > settings to their thing. As nothing worked, I've tried driving the PHY through
> > the kernel's broadcom.c driver, but that driver really doesn't support 100FX so
> > it's also expected that this doesn't work. Unfortunately, I don't have
> > access to any documentation for that PHY...
> > 
> > The driver does say, for a similar model :
> > 
> > 	/* The PHY is strapped in RGMII-fiber mode when INTERF_SEL[1:0]
> > 	 * is 01b, and the link between PHY and its link partner can be
> > 	 * either 1000Base-X or 100Base-FX.
> > 	 * RGMII-1000Base-X is properly supported, but RGMII-100Base-FX
> > 	 * support is still missing as of now.
> > 	 */
> > 
> > Not quite the same as our case as it's talking about RGMII, not SGMII, but
> > maybe the people who wrote that code know a bit more or have access to some
> > documentation ? I've tried to put these persons in CC :)  
> 
> Not sure if you can probe the various pins, but those that would be 
> interesting to measure would be:
> 
> LNKSPD[1] / INTF_SEL[0]
> LNKSPD[2] / INTF_SEL[1]
> RGMIIEN
> EN_10B/SD
> 
> You can forcibly enable RGMII operation by writing to register 0x18, 
> shadow 0b111 (MII_BCM54XX_AUXCTL_SHDWSEL_MISC) and setting bit 7 
> (MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_EN).
> 
>  > > In any case, should anyone want to give this a shot in the future,   
> I'm using the
> > following patch so that the SFP machinery can try to probe PHYs on these
> > non-copper modules - that patch needs splitting up and is more of a hack than
> > anything else.
> > 
> > Thanks a lot everyone, and sorry for the noise if this is misplaced,  
> 
> For 100BaseFX, the signal detection is configured in bit 5 of the shadow 
> 0b01100 in the 0x1C register. You can use bcm_{read,write}_shadow() for 
> that:
> 
> 0 to use EN_10B/SD as CMOS/TTL signal detect (default)
> 1 to use SD_100FX± as PECL signal detect
> 
> 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
> 
> - disable auto-negotiation with register 0x00 = 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).
> 
> It's unclear from the datasheet whether 100BaseFX can work with RGMII.

Thank you so much ! I'm trying to achieve SGMII to 100FX, so I'll give
your instructions a try :) Thanks again for the quick answer, I'll let
you know how this goes,

Maxime

Re: Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

[Maxime Chevallier]

Hi again Florian,

On Tue, 24 Jun 2025 15:29:25 -0700
Florian Fainelli <florian.fainelli@broadcom.com> wrote:

> For 100BaseFX, the signal detection is configured in bit 5 of the shadow 
> 0b01100 in the 0x1C register. You can use bcm_{read,write}_shadow() for 
> that:
> 
> 0 to use EN_10B/SD as CMOS/TTL signal detect (default)
> 1 to use SD_100FX± as PECL signal detect
> 
> 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
> 
> - disable auto-negotiation with register 0x00 = 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).

And I have my first ping going through :) Thank you so much, if I get a
chance to meet you in person one day, drinks are on me :)

Thanks again,

Maxime

Re: Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

[Florian Fainelli]

On 6/25/25 00:15, Maxime Chevallier wrote:
> Hi again Florian,
> 
> On Tue, 24 Jun 2025 15:29:25 -0700
> Florian Fainelli <florian.fainelli@broadcom.com> wrote:
> 
>> For 100BaseFX, the signal detection is configured in bit 5 of the shadow
>> 0b01100 in the 0x1C register. You can use bcm_{read,write}_shadow() for
>> that:
>>
>> 0 to use EN_10B/SD as CMOS/TTL signal detect (default)
>> 1 to use SD_100FX± as PECL signal detect
>>
>> 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
>>
>> - disable auto-negotiation with register 0x00 = 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).
> 
> And I have my first ping going through :) Thank you so much, if I get a
> chance to meet you in person one day, drinks are on me :)

OK, that's great news, looking forward to seeing patches, and I will 
remember your offer :)
-- 
Florian