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

[Florian Fainelli <florian.fainelli@broadcom.com>]

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