[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8fa4504e-e486-41d0-9140-b24187626850@lunn.ch>
Date: Tue, 2 Sep 2025 14:30:19 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jack Ping Chng <jchng@...linear.com>
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
> Hi Andrew,
>
> Thank you for your valuable feedback.
>
> 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/linux-arm-kernel/2022-May/743213.html
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.
Andrew
Powered by blists - more mailing lists