linux-kernel - Re: [PATCH net-next v9 0/4] net: dsa: initial support for MaxLinear MxL862xx switches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXlonmq2eM6dLqnZ@makrotopia.org>
Date: Wed, 28 Jan 2026 01:38:38 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Frank Wunderlich <frankwu@....de>, Chad Monroe <chad@...roe.io>,
	Cezary Wilmanski <cezary.wilmanski@...ran.com>,
	Avinash Jayaraman <ajayaraman@...linear.com>,
	Bing tao Xu <bxu@...linear.com>, Liang Xu <lxu@...linear.com>,
	Juraj Povazanec <jpovazanec@...linear.com>,
	"Fanni (Fang-Yi) Chan" <fchan@...linear.com>,
	"Benny (Ying-Tsan) Weng" <yweng@...linear.com>,
	"Livia M. Rosu" <lrosu@...linear.com>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH net-next v9 0/4] net: dsa: initial support for MaxLinear
 MxL862xx switches

On Wed, Jan 28, 2026 at 12:56:43AM +0200, Vladimir Oltean wrote:
> On Tue, Jan 27, 2026 at 09:37:40PM +0000, Daniel Golle wrote:
> > This series adds very basic DSA support for the MaxLinear MxL86252
> > (5 PHY ports) and MxL86282 (8 PHY ports) switches.
> > 
> > MxL862xx integrates a firmware running on an embedded processor (running
> > Zephyr RTOS). Host interaction uses a simple netlink-like 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.
> > Follow up series will bring bridge, VLAN, ... offloading,
> 
> I'm surprised the Kconfig help text says:
> 
> 	  These switches have two 10GE SerDes interfaces, one typically
> 	  used as CPU port.
> 
> yet only PHY_INTERFACE_MODE_INTERNAL is set in phylink supported_interfaces.
> You're also not making any mention of future SerDes support. What's up
> with that, how do the SerDes ports currently work and how are they
> described? (as internal?!)

Oh, sure, I'm obviously going to add both SerDes interfaces which support
various interface modes as phylink_pcs instances in a follow-up series.
I was planning to do basic bridge offloading and FDB access first, then
SerDes PCS, then LAG, then VLAN, and then last but not least using the
802.1Q-based special tag (LoC of just that feature is almost as much
as all the rest together in the vendor driver).

> 
> > and support for using a 802.1Q-based special tag instead of the
> > proprietary 8-byte tag.
> 
> Why is that?

Using an 802.1Q-based special tag is advantageous in some situations,
for example PPE offloading engines typically do support 802.1Q and
802.1ad VLANs, but do not support any special tag apart from those
of the same vendor (eg. MediaTek's PPE supports MediaTek's 4-byte
special tag, but includes "plain" 802.1Q or 802.1ad/Q-in-Q as part of
the tuple identifying a flow). Hence by implementing an 802.1Q-based
tag one can benefit from better performance, less CPU load and less
energy consumption when combining these switches with router SoCs
of other vendors if they implementing "picky" offloading fast-paths.

> 
> Another (related) question. You have this comment in tag_mxl862xx.c:
> 
> 	/* switch firmware expects ports to be counted starting from 1 */
> 
> from which I don't completely understand how is the firmware involved
> (does it process the tags?). Would the expectation also apply to the
> 802.1Q based tagger?

No. The 802.1Q-based tagger is basically implemented entirely by
setting up additional bridges, virtual bridge ports and special VLAN
forwarding rules. It takes more than just "switching" the tag protocol...
But hence it can be implemented in pretty much any way we want.

> 
> What's the real story behind port index 0? Does it really not exist, or
> is it some attempt to hide an internal port that's not supposed to be used?

It's just an oddity of the management firmware which runs on the switch.
Port ID 0 has special meaning, physical ports are counted started from 1.
For example, when adding FDB entries, port_id == 0 means not specifying a
port (eg. for filter rules). However, it *is* weird that BIT(0) of any
portmap isn't ever used in the driver, and it looks like it could be like
you describe below. I will ask.

> 
> If the latter, I guess something like the snippet below (seen in
> arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts) would simplify
> the driver by a bit:
> 
> 	ethernet-switch@0 {
> 		...
> 		ethernet-ports {
> 			...
> 			/* Microcontroller port */
> 			port@0 {
> 				reg = <0>;
> 				status = "disabled";
> 			};

This construct could never the less help to make things more easy and
less annoying to deal with. I might just start counting from reg = <1>
in DT and have a dummy/reserved port 0.

Always having add/substract 1 is often confusing because then you have
to remember if a port number or mask stored in some structure or
variable denotes the DSA perspective or the switch firmware perspective.
Unifying the two would definitely be beneficial. I can give that a short
tomorrow.