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.

Daniel Golle (3):
  dt-bindings: net: dsa: add bindings for MaxLinear MxL862xx
  net: dsa: add tag formats for MxL862xx switches
  net: dsa: add basic initial driver for MxL862xx switches

 .../bindings/net/dsa/maxlinear,mxl862xx.yaml  | 160 ++++++++
 MAINTAINERS                                   |   8 +
 drivers/net/dsa/Kconfig                       |   2 +
 drivers/net/dsa/Makefile                      |   1 +
 drivers/net/dsa/mxl862xx/Kconfig              |  12 +
 drivers/net/dsa/mxl862xx/Makefile             |   3 +
 drivers/net/dsa/mxl862xx/mxl862xx-api.h       | 104 +++++
 drivers/net/dsa/mxl862xx/mxl862xx-cmd.h       |  28 ++
 drivers/net/dsa/mxl862xx/mxl862xx-host.c      | 204 ++++++++++
 drivers/net/dsa/mxl862xx/mxl862xx-host.h      |   3 +
 drivers/net/dsa/mxl862xx/mxl862xx.c           | 360 ++++++++++++++++++
 drivers/net/dsa/mxl862xx/mxl862xx.h           |  27 ++
 include/net/dsa.h                             |   2 +
 net/dsa/Kconfig                               |   7 +
 net/dsa/Makefile                              |   1 +
 net/dsa/tag_mxl862xx.c                        | 109 ++++++
 16 files changed, 1031 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/maxlinear,mxl862xx.yaml
 create mode 100644 drivers/net/dsa/mxl862xx/Kconfig
 create mode 100644 drivers/net/dsa/mxl862xx/Makefile
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx-api.h
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx-cmd.h
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx-host.c
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx-host.h
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx.c
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx.h
 create mode 100644 net/dsa/tag_mxl862xx.c

-- 
2.52.0

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?

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).

On Wed, Dec 03, 2025 at 11:23:11PM +0000, Daniel Golle wrote:
> On Wed, Dec 03, 2025 at 10:26:05PM +0200, Vladimir Oltean wrote:
> > 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).

I'm not sure I understand either, but is it possible that since the base
Ethernet switch IP was already MDIO-based, Maxlinear wanted to offer a
single programming interface for the entire SoC as visible from an
external host, so that's why they continued exposing the other stuff
that they did in MMD 30 (temperature sensor, LEDs, etc) using this North
Korean guided tour kind of approach.

I am noting that there also seems no way to control the 'GPIO' pins as
GPIO from the external host. No way to set a direction or a value on
them. They seem to be "GPIO" only for the microcontroller.

It also seems possible that Maxlinear studied what other MDIO-based DSA
drivers offer, and they wanted to keep things in line with that,
(over)simplifying access to resources to keep things tidy when they are
all driven from DSA.

Although for other switches like the NXP SJA1110 (which has a SPI-to-AHB
bridge to gain direct access into sub-devices that are also mapped in the
microcontroller's address space) I try to push for the MFD model to be
used, for better scalability outside of drivers/net/dsa/, I think that
trying to horseshoe MFD on top of the MxL86252, at least in the way exposed
by the MDIO slave API implemented by its microcontroller, would be
overkill and a big a mistake.

But before I give my OK on your driver design choice, could you:
- confirm that the Zephyr-based MDIO slave firmware is the single
  external register access method for these chips in production? No
  register access or other special communication protocol with the
  microcontroller over Ethernet, no secret SPI-to-AHB bridge that can be
  used when there is no firmware running? The firmware image is maintained
  by Maxlinear, and their customers can't customize it, right?
- make a list of all the subsystems you foresee this chip will register
  itself with? Essentially how will it drive the sub-devices that the
  firmware does give it access to.

So what I'm trying to gauge is how complex this driver will be in its
fully developed form, to make sure it won't suffer from early underdesign
issues.

On Wed, Dec 03, 2025 at 11:23:11PM +0000, Daniel Golle wrote:
> 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.
> 

As you didn't respond to Vladimir's statement here, I will also echo
this. Why do you have no phylink_mac_ops ?

New DSA drivers are expected to always have phylink_mac_ops, and not
rely on the legacy fallback in net/dsa/port.c

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

On Thu, Dec 04, 2025 at 01:02:14AM +0000, Russell King (Oracle) wrote:
> On Wed, Dec 03, 2025 at 11:23:11PM +0000, Daniel Golle wrote:
> > 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.
> > 
> 
> As you didn't respond to Vladimir's statement here, I will also echo
> this. Why do you have no phylink_mac_ops ?
> 
> New DSA drivers are expected to always have phylink_mac_ops, and not
> rely on the legacy fallback in net/dsa/port.c

All three phylink_mac_ops functions are no-ops for the internal PHYs,
see also

https://github.com/frank-w/BPI-Router-Linux/blob/6.18-rc/drivers/net/dsa/mxl862xx/mxl862xx.c#L3242

The exception in the reference driver are the SerDes PCS ports, and for
those I'd rather use .pcs_config than setting the interface mode in
.phylink_mac_config.
Hence I was planing to introduce phylink_mac_ops together with support
for the SerDes ports, and it will only have a .mac_select_pcs op.

On Thu, Dec 04, 2025 at 01:08:24PM +0000, Daniel Golle wrote:
> On Thu, Dec 04, 2025 at 01:02:14AM +0000, Russell King (Oracle) wrote:
> > On Wed, Dec 03, 2025 at 11:23:11PM +0000, Daniel Golle wrote:
> > > 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.
> > > 
> > 
> > As you didn't respond to Vladimir's statement here, I will also echo
> > this. Why do you have no phylink_mac_ops ?
> > 
> > New DSA drivers are expected to always have phylink_mac_ops, and not
> > rely on the legacy fallback in net/dsa/port.c
> 
> All three phylink_mac_ops functions are no-ops for the internal PHYs,
> see also
> 
> https://github.com/frank-w/BPI-Router-Linux/blob/6.18-rc/drivers/net/dsa/mxl862xx/mxl862xx.c#L3242

While you may end up with the same three methods remaining empty,
please do not rely on the legacy fallback, even temporarily.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!