BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

[Kordian Chmielewski (mlody1212)]

Hi all,

I am porting OpenWrt to the TP-Link Archer AX6000 v1 and AX11000 v1:
a BCM4908 with two BCM43684 radios, a BCM54991E 2.5G PHY on the WAN
socket and a BCM53134 switch for LAN 5-8. The port runs on 6.18 with
OpenWrt main. The AX6000 v1 will be public around 16 November; the
AX11000 v1 runs the same code and follows later. The first patch went
to linux-wireless on 9 November (brcmfmac).

What works today: LAN 1-4 on the SF2 with the CPU port at 2.5G, the
WAN at 100M, 1G and 2.5G, LAN 5-8, both radios with brcmfmac, USB,
Bluetooth, the LEDs and the buttons.

I would like to send the Ethernet side upstream and would like to
check the plan with you first.

As fixes for net, with Fixes: tags:

- bcm4908_enet: the TX ring could stall silently under load (an
  off-by-one in the ring indices); a DMA mapping error left the ring
  inconsistent; RX buffers and pending TX frames were not freed on
  stop; RX frames longer than the buffer were passed up; the RX
  buffer address has to be written before the OWN bit.
- bcm_sf2: with the default egress flow control thresholds of the
  BCM4908 (32 pages) the switch drops frames under load; raised,
  WAN to LAN runs at line rate. Is this net or net-next material?

For net-next, with the device trees through the BCMBCA tree:

- pinctrl-bcm4908: the "mdio" function on GPIO 48/49, the external
  MDC/MDIO pins;
- mdio-bcm-unimac: native Clause 45. The MDIO_CFG bit that enables
  it I found by testing; I would be glad to have it confirmed;
- bcm_sf2: the crossbar routing of the SerDes (the CFE leaves the
  Runner's port on the SerDes as well), 2500BASE-X and SPEED_2500 on
  port 7, and the IMP port at 2.5G;
- the BCM54991E in bcm84881.c: it has no flash, so the host uploads
  its firmware; autonegotiation and the link state are the BCM84881
  driver's;
- the device trees of both boards.

Two questions about the WAN, where I would rather ask than guess:

1. The SoC SerDes (a control register at 0x800c03c4 and its own MDIO
   address) feeds the BCM54991E its 50 MHz reference clock and has to
   follow the copper speed: SGMII at 100M and 1G, 2500BASE-X at 2.5G.
   Today the PHY driver drives it, which I know is wrong. Where should
   it live: a phylink_pcs in bcm_sf2, or a driver of its own? The
   crossbar can also give the SerDes to the SoC's packet engine (the
   Runner), which this port drives out of tree, so something both
   could use would help.

2. The PHY does not answer MDIO until its enable GPIO is high and the
   SerDes clock runs. The binding allows "ethernet-phy-id3590.5090",
   "ethernet-phy-ieee802.3-c45" for a PHY that needs such a sequence
   before its IDs can be read, but fwnode_mdiobus_register_phy() calls
   get_phy_device() whenever -c45 is there, so it reads the IDs anyway
   and finds nothing. With the ID alone the device is created as
   Clause 22, and today the driver switches it to Clause 45 in probe.
   Would a change that creates the Clause 45 device from the ID in
   that case be acceptable, or should the GPIO and the clock come up
   before the bus is scanned, for example as reset-gpios and clocks
   of the MDIO bus?

Whether the BCM54991E firmware can go to linux-firmware, and the
Wi-Fi side, wait on answers from Broadcom, which I have asked
separately. The Ethernet code does not depend on them: the PHY driver
loads its firmware with request_firmware(), and the code taken from
Broadcom's GPL files keeps their GPL-2.0 notices.

Thank you,
Kordian Chmielewski (mlody1212)

Re: BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

[Florian Fainelli]

CC Justin, William,

On 11/9/26 15:17, Kordian Chmielewski (mlody1212) wrote:
> Hi all,
> 
> I am porting OpenWrt to the TP-Link Archer AX6000 v1 and AX11000 v1:
> a BCM4908 with two BCM43684 radios, a BCM54991E 2.5G PHY on the WAN
> socket and a BCM53134 switch for LAN 5-8. The port runs on 6.18 with
> OpenWrt main. The AX6000 v1 will be public around 16 November; the
> AX11000 v1 runs the same code and follows later. The first patch went
> to linux-wireless on 9 November (brcmfmac).
> 
> What works today: LAN 1-4 on the SF2 with the CPU port at 2.5G, the
> WAN at 100M, 1G and 2.5G, LAN 5-8, both radios with brcmfmac, USB,
> Bluetooth, the LEDs and the buttons.
> 
> I would like to send the Ethernet side upstream and would like to
> check the plan with you first.
> 
> As fixes for net, with Fixes: tags:
> 
> - bcm4908_enet: the TX ring could stall silently under load (an
>    off-by-one in the ring indices); a DMA mapping error left the ring
>    inconsistent; RX buffers and pending TX frames were not freed on
>    stop; RX frames longer than the buffer were passed up; the RX
>    buffer address has to be written before the OWN bit.

Yes definitively a bug fix.

> - bcm_sf2: with the default egress flow control thresholds of the
>    BCM4908 (32 pages) the switch drops frames under load; raised,
>    WAN to LAN runs at line rate. Is this net or net-next material?

Seems reasonable to be targeted as a fix as well.

> 
> For net-next, with the device trees through the BCMBCA tree:
> 
> - pinctrl-bcm4908: the "mdio" function on GPIO 48/49, the external
>    MDC/MDIO pins;
> - mdio-bcm-unimac: native Clause 45. The MDIO_CFG bit that enables
>    it I found by testing; I would be glad to have it confirmed;

We have an internal patch we should be submitting soon that supports 
Claude 45 in mdio-bcm-unimac

> - bcm_sf2: the crossbar routing of the SerDes (the CFE leaves the
>    Runner's port on the SerDes as well), 2500BASE-X and SPEED_2500 on
>    port 7, and the IMP port at 2.5G;

OK

> - the BCM54991E in bcm84881.c: it has no flash, so the host uploads
>    its firmware; autonegotiation and the link state are the BCM84881
>    driver's;
> - the device trees of both boards.
> 
> Two questions about the WAN, where I would rather ask than guess:
> 
> 1. The SoC SerDes (a control register at 0x800c03c4 and its own MDIO
>     address) feeds the BCM54991E its 50 MHz reference clock and has to
>     follow the copper speed: SGMII at 100M and 1G, 2500BASE-X at 2.5G.
>     Today the PHY driver drives it, which I know is wrong. Where should
>     it live: a phylink_pcs in bcm_sf2, or a driver of its own? The
>     crossbar can also give the SerDes to the SoC's packet engine (the
>     Runner), which this port drives out of tree, so something both
>     could use would help.

0x800c03c4 is SWITCH_REG_SINGLE_SERDES_CNTRL and there are a few other 
adjacent registers that logically belong to the switch driver from an 
address range perspective. It seems to me like phylink_pcs would be 
adequate here.

> 
> 2. The PHY does not answer MDIO until its enable GPIO is high and the
>     SerDes clock runs. The binding allows "ethernet-phy-id3590.5090",
>     "ethernet-phy-ieee802.3-c45" for a PHY that needs such a sequence
>     before its IDs can be read, but fwnode_mdiobus_register_phy() calls
>     get_phy_device() whenever -c45 is there, so it reads the IDs anyway
>     and finds nothing. With the ID alone the device is created as
>     Clause 22, and today the driver switches it to Clause 45 in probe.
>     Would a change that creates the Clause 45 device from the ID in
>     that case be acceptable, or should the GPIO and the clock come up
>     before the bus is scanned, for example as reset-gpios and clocks
>     of the MDIO bus?

IIRC we have other internal PHYs on other Broadcom SoCs which have 
similar constraints and that would fail reading their clause 45 
identification registers, as such, I would welcome a change that aligns 
the phy_device creation between c22 and c45 from Device Tree.

> 
> Whether the BCM54991E firmware can go to linux-firmware, and the
> Wi-Fi side, wait on answers from Broadcom, which I have asked
> separately. The Ethernet code does not depend on them: the PHY driver
> loads its firmware with request_firmware(), and the code taken from
> Broadcom's GPL files keeps their GPL-2.0 notices.
> 
> Thank you,
> Kordian Chmielewski (mlody1212)


-- 
Florian

Re: BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

[Mlody12 mlody12]

Hi Florian,

Thanks for the quick reply, that clears up both questions.

I'll send the bcm4908_enet fixes to net as a series of seven patches,
and the SF2 flow control thresholds as a separate fix.

I'll hold off on my Clause 45 change to mdio-bcm-unimac for now. Would
it be possible to get a preview of your patch before it's posted? I
could test it on the AX6000 and AX11000 (BCM4908, with the BCM54991E
on the external MDIO bus) and compare it with my implementation. If
anything is missing, I could prepare a patch on top. We could then
send them together in one series, if that works for you.

If sharing it beforehand isn't possible, please Cc me when it's posted.

For the SerDes, I'll work on a phylink_pcs implementation in bcm_sf2
alongside the crossbar handling and send it for review.

I'll also prepare a separate net-next patch to make Clause 45 PHY
creation from an explicit Device Tree ID consistent with Clause 22.
I'll send that first so the WAN series can build on it.

Thanks again,
Kordian Kordian Chmielewski (mlody1212)

Re: BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

[William Zhang]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

+Anil Chaudhary

On Mon, Nov 9, 2026 at 3:55 PM Mlody12 mlody12 <kudzo51@gmail.com> wrote:
>
> Hi Florian,
>
> Thanks for the quick reply, that clears up both questions.
>
> I'll send the bcm4908_enet fixes to net as a series of seven patches,
> and the SF2 flow control thresholds as a separate fix.
>
> I'll hold off on my Clause 45 change to mdio-bcm-unimac for now. Would
> it be possible to get a preview of your patch before it's posted? I
> could test it on the AX6000 and AX11000 (BCM4908, with the BCM54991E
> on the external MDIO bus) and compare it with my implementation. If
> anything is missing, I could prepare a patch on top. We could then
> send them together in one series, if that works for you.
>
> If sharing it beforehand isn't possible, please Cc me when it's posted.
>
> For the SerDes, I'll work on a phylink_pcs implementation in bcm_sf2
> alongside the crossbar handling and send it for review.
>
> I'll also prepare a separate net-next patch to make Clause 45 PHY
> creation from an explicit Device Tree ID consistent with Clause 22.
> I'll send that first so the WAN series can build on it.
>
> Thanks again,
> Kordian Kordian Chmielewski (mlody1212)

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]

Re: BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

[Mlody12 mlody12]

Hi,

A correction to my earlier mail: the MDIO_CFG bit for Clause 45 was not
found by testing. It is bit 0, already defined as MDIO_C22/MDIO_C45 in
mdio-bcm-unimac.c. The Clause 45 access sequence follows
mdio_cmd_read_45() and mdio_cmd_write_45() from Broadcom's GPL
mdio_drv_common.c.

What I did establish by testing is that the BCM54991E can set
MDIO_READ_FAIL even when a Clause 45 read returns valid data, so my
patch ignores that flag for those reads.

Kordian Chmielewski (mlody1212)

Re: BCM4908 Ethernet and 2.5G WAN: upstreaming plan and two questions

[Kordian Chmielewski (mlody1212)]

Three corrections to my mail above and my later correction.

The AX11000 has three BCM43684 radios, not two; I mixed it up with the
AX6000.

I should not have written that the SoC SerDes gives the BCM54991E a
50 MHz clock. I took the 50 MHz from a comment in Broadcom's SerDes
setup code, read it as the PHY's clock and did not test it. I have
tested it now: with the SerDes held in IDDQ, PWRDWN and RESETPLL, the
PHY answers MDIO right after its enable GPIO goes high, takes its
firmware over MDIO and starts its CPU, and a running PHY keeps its
link. So MDIO needs the enable GPIO, not the SerDes. The SerDes status
still showed PLL lock, so I can't say the PLL itself stopped.

And, unlike what I wrote in my earlier correction, the BCM54991E does
not set MDIO_READ_FAIL on good Clause 45 reads: with a counter on the
bit, 11640 reads, none with it set. My note was older than the fix that
made the PHY answer at all.

Kordian