Re: [PATCH RFC net-next 0/3] net: dsa: initial support for MaxLinear MxL862xx switches

[Daniel Golle <daniel@makrotopia.org>]

On Wed, Dec 03, 2025 at 10:26:05PM +0200, Vladimir Oltean wrote:
> Hi Daniel,
> 
> On Tue, Dec 02, 2025 at 11:37:13PM +0000, Daniel Golle wrote:
> > Hi,
> > 
> > This series adds very basic DSA support for the MaxLinear MxL86252
> > (5 PHY ports) and MxL86282 (8 PHY ports) switches. The intent is to
> > validate and get feedback on the overall approach and driver structure,
> > especially the firmware-mediated host interface.
> > 
> > MxL862xx integrates a firmware running on an embedded processor (Zephyr
> > RTOS). Host interaction uses a simple API transported over MDIO/MMD.
> > This series includes only what's needed to pass traffic between user
> > ports and the CPU port: relayed MDIO to internal PHYs, basic port
> > enable/disable, and CPU-port special tagging.
> > 
> > Thanks for taking a look.
> 
> I see no phylink_mac_ops in your patches.


> 
> How does this switch architecture deal with SFP cages? I see the I2C
> controllers aren't accessible through the MDIO relay protocol
> implemented by the microcontroller. So I guess using the sfp-bus code
> isn't going to be possible. The firmware manages the SFP cage and you
> "just" have to read the USXGMII Status Register (reg 30.19) from the
> host? How does that work out in practice?

In practise the I2C bus provided by the switch IC isn't used to connect
an SFP cage when using the chip with DSA. Vendors (Adtran,
BananaPi/Sinovoip) rather use an I2C bus of the SoC for that.
I suppose it is useful when using the chip as standalone switch.

The firmware does provide some kind of limited access to the PCS, ie.
status can be polled, interface mode can be set, autonegotiation can be
enabled or disabled, and so on (but not as nice as we would like it to
be). In that way, most SFP modules and external PHYs can be supported.

See

https://github.com/frank-w/BPI-Router-Linux/commit/c5f7a68e82fe20b9b37a60afd033b2364a8763d8

In general I don't get why all those layers of abstraction are actually
needed when using a full-featured OS on the host -- it'd be much better
to just have direct access to the register space of the switch than
having to deal with that firmware API (the firmware can also provide a
full web UI, SNMP, a CLI interface, ... -- imho more of an obstacle than
a desirable feature when using this thing with DSA).