netdev - RE: [PATCH net-next v3 2/2] net: maxlinear: Add support for MxL LGM SoC

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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PH7PR19MB563690779EFD1FEB867A81BEB400A@PH7PR19MB5636.namprd19.prod.outlook.com>
Date: Thu, 4 Sep 2025 06:33:01 +0000
From: Jack Ping Chng <jchng@...linear.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>, "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>, Yi xin Zhu
	<yzhu@...linear.com>, Suresh Nagaraj <sureshnagaraj@...linear.com>
Subject: RE: [PATCH net-next v3 2/2] net: maxlinear: Add support for MxL LGM
 SoC

On Tue, 2 Sep 2025 14:30:19 +0200
Andrew Lunn <andrew@...n.ch> wrote:

> > The switch core hardware block is part of the MaxLinear Lightning
> > Mountain (LGM) SoC, which integrates Ethernet XGMACs for connectivity
> > with external PHY devices via PCS.
> > At initialization, we configure the switch core ports to enable only
> > Layer 2 frame forwarding between the CPU (Host Interface) port and the
> > Ethernet ports.
>
> So there is a dedicated port for the CPU. That is one valuable piece
> of information for this decision.
>
> > L2/FDB learning and forwarding will not be enabled for any port.
> > The CPU port facilitates packet transfers between the Ethernet ports
> > and the CPU within the SoC using DMA. All forwarding and routing
> > logic is handled in the Linux network stack.
> >
> > LGM SoC also has a separate HW offload engine for packet routing and
> > bridging per flow.  This is not within the scope of this patch series.
> >
> > > Are there any public available block diagrams of this device?
> >
> > We will  update the documentation accordingly in the upcoming version.
> > Please find the packet flow at a high level below:
> > Rx:
> > PHY -> Switch Core XGMAC -> Host Interface Port -> DMA Rx -> CPU
> > Tx:
> > CPU -> DMA Tx -> Host Interface Port -> Switch Core XGMAC -> PHY
> >
> > > How does the host direct a frame out a specific port of the switch?
> >
> > In the TX direction, there is a predefined mapping between the Ethernet
> > interface and the corresponding destination switch port.
> > The Ethernet driver communicates this mapping to the DMA driver,
> > which then embeds it into the DMA descriptor as sideband information.
>
> So, there are not DMA channels per port. The CPU has a collection of
> DMA channels, it can pick any, and just needs to set a field in the
> DMA descriptor to indicate the egress port.
>
> > This ensures that the data is forwarded correctly through the switch fabric
> >
> > > How does the host know which port a frame came in on?
> >
> > On the RX side, the source switch port  is mapped to a specific DMA Rx
> > channel. The DMA Rx descriptor also carries the ingress port as
> > sideband information.
> > Either of these methods can be used to determine the source switch port.
>
> So here you do have a fixed mapping of port to DMA channel, but you
> don't actually need it.
>
> So this sounds a bit like the Qualcomm IPQESS device.
>
> https://lists.infradead.org/pipermail%252
> Flinux-arm-kernel%2F2022-
> May%2F743213.html&data=05%7C02%7Cjchng%40maxlinear.com%7C85f1f75bab584d678edb08ddea1c8
> 213%7Cdac2800513e041b882807663835f2b1d%7C0%7C0%7C638924130370008536%7CUnknown%7CTW
> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=98FRlgiORUVgvaJX1Q%2Bmrwwfq%2Bib6p5CxRPksa%2FhFGg%3
> D&reserved=0
>
> This never got merged, but it was going the direction of a DSA driver.
> However, you could also do a pure switchdev driver.
>
> The advantage of a DSA driver would be a lot of infrastructure you can
> just use, where as a pure switchdev driver will require you to
> reinvent a few wheels. So a DSA driver would be smaller, simpler, less
> bugs.

Hi Andrew,

Thank you for your feedback.
To clarify, this driver does not implement any switch functionality.
Its purpose is limited to controlling individual MACs, without support
for bridging, VLANs, or other switch-related features.
All packet forwarding and routing will be handled entirely by the Linux
networking stack.
Also, we have separate Tx/Rx channels mapped to the interfaces we are
registering. We also have a separate packet processor engine for
bridging and routing based on the sessions.

Best regards,
Jack