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

["Kordian Chmielewski (mlody1212)" <kudzo51@gmail.com>]

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)