[PATCH net-next v3 0/2] Add MxL Ethernet driver & devicetree binding

[PATCH net-next v3 0/2] Add MxL Ethernet driver & devicetree binding

[Jack Ping CHNG]

Hello netdev maintainers,

This patch series adds support for the MaxLinear LGM SoC's Ethernet
controller, including:

Patch 1: Introduces the devicetree binding documentation for the MaxLinear
LGM Network Processor.
Patch 2: Adds build infrastructure and the main driver for the MaxLinear
LGM SoC Ethernet controller.

The driver supports multi-port operation and is integrated with standard
Linux network device driver framework. The devicetree binding documents
the required properties for the hardware description.

Changelog:
v2 -> v3:
  - Renamed compatible string and YAML filename to maxlinear.
  - Changed child nodes to ethernet-ports with port@N.
  - Added reg and mdio properties.
  - Added schema references for port and mdio.
  - Updated required properties and example.
  - Add resource management and better error handling
  - Improved device tree integration for multiple ports

v1 -> v2:
  - Moved devicetree bindings to the first patch in the series.
  - Verified bindings with 'make dt_binding_check DT_SCHEMA_FILES=mxl,lgm-eth.yaml'.
  - Reformatted commit messages to follow Linux kernel submission guidelines.
  - Removed redundant code and addressed all reviewer comments.

links:
v2: https://lore.kernel.org/netdev/20250826031044.563778-3-jchng@maxlinear.com/
v1: https://lore.kernel.org/netdev/20250822090809.1464232-1-jchng@maxlinear.com/

Jack Ping CHNG (2):
  dt-bindings: net: mxl: Add MxL LGM Network Processor SoC
  net: maxlinear: Add support for MxL LGM SoC

 .../bindings/net/maxlinear,lgm-eth.yaml       | 119 +++++++++++
 .../device_drivers/ethernet/index.rst         |   1 +
 .../device_drivers/ethernet/maxlinear/mxl.rst |  49 +++++
 MAINTAINERS                                   |   8 +
 drivers/net/ethernet/Kconfig                  |   1 +
 drivers/net/ethernet/Makefile                 |   1 +
 drivers/net/ethernet/maxlinear/Kconfig        |  15 ++
 drivers/net/ethernet/maxlinear/Makefile       |   6 +
 drivers/net/ethernet/maxlinear/mxl_eth.c      | 202 ++++++++++++++++++
 9 files changed, 402 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/maxlinear,lgm-eth.yaml
 create mode 100644 Documentation/networking/device_drivers/ethernet/maxlinear/mxl.rst
 create mode 100644 drivers/net/ethernet/maxlinear/Kconfig
 create mode 100644 drivers/net/ethernet/maxlinear/Makefile
 create mode 100644 drivers/net/ethernet/maxlinear/mxl_eth.c

-- 
2.34.1

[PATCH net-next v3 1/2] dt-bindings: net: mxl: Add MxL LGM Network Processor SoC

[Jack Ping CHNG]

Add devicetree binding documentation for the MaxLinear LGM SoC
Ethernet controller.

Signed-off-by: Jack Ping CHNG <jchng@maxlinear.com>
---
 .../bindings/net/maxlinear,lgm-eth.yaml       | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/maxlinear,lgm-eth.yaml

diff --git a/Documentation/devicetree/bindings/net/maxlinear,lgm-eth.yaml b/Documentation/devicetree/bindings/net/maxlinear,lgm-eth.yaml
new file mode 100644
index 000000000000..d613f4e535f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxlinear,lgm-eth.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/maxlinear,lgm-eth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxLinear LGM Ethernet Controller
+
+maintainers:
+  - Jack Ping Chng <jchng@maxlinear.com>
+
+description:
+  Binding for MaxLinear LGM Ethernet controller
+
+properties:
+  compatible:
+    enum:
+      - maxlinear,lgm-eth
+
+  reg:
+    maxItems: 2
+
+  reg-names:
+    items:
+      - const: port
+      - const: ctrl
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: ethif
+
+  resets:
+    maxItems: 1
+
+  ethernet-ports:
+    type: object
+    additionalProperties: false
+
+    properties:
+      "#address-cells":
+        const: 1
+
+      "#size-cells":
+        const: 0
+
+    patternProperties:
+      "^port@[0-3]$":
+        type: object
+        $ref: ethernet-controller.yaml#
+        additionalProperties: false
+
+        properties:
+          reg:
+            description: port id
+            maxItems: 1
+
+          phy-handle:
+            maxItems: 1
+
+        required:
+          - reg
+          - phy-handle
+
+  mdio:
+    $ref: mdio.yaml#
+    unevaluatedProperties: false
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - resets
+  - mdio
+
+examples:
+  - |
+    ethernet@e7140000 {
+        compatible = "maxlinear,lgm-eth";
+        reg = <0xe7140000 0x1200>,<0xe7150000 0x4000>;
+        reg-names = "port", "ctrl";
+        clocks = <&cgu0 32>;
+        clock-names = "ethif";
+        resets = <&rcu0 0x70 8>;
+
+        ethernet-ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port@0 {
+                reg = <0>;
+                phy-handle = <&eth_phy0>;
+            };
+
+            port@1 {
+                reg = <1>;
+                phy-handle = <&eth_phy1>;
+            };
+        };
+
+        mdio {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            eth_phy0: ethernet-phy@0 {
+                reg = <0>;
+            };
+
+            eth_phy1: ethernet-phy@1 {
+                reg = <1>;
+            };
+        };
+    };
-- 
2.34.1

Re: [PATCH net-next v3 1/2] dt-bindings: net: mxl: Add MxL LGM Network Processor SoC

[Krzysztof Kozlowski]

On Fri, Aug 29, 2025 at 08:48:42PM +0800, Jack Ping CHNG wrote:
> +title: MaxLinear LGM Ethernet Controller
> +
> +maintainers:
> +  - Jack Ping Chng <jchng@maxlinear.com>
> +
> +description:
> +  Binding for MaxLinear LGM Ethernet controller

Drop "Binding for" and write proper description of hardware, not what
binding is for.

What is LGM? What is LGM SoC? Why there is nowhere anything about that
LGM SoC?

> +
> +properties:
> +  compatible:
> +    enum:
> +      - maxlinear,lgm-eth
> +
> +  reg:
> +    maxItems: 2
> +
> +  reg-names:
> +    items:
> +      - const: port
> +      - const: ctrl
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    items:
> +      - const: ethif
> +
> +  resets:
> +    maxItems: 1
> +
> +  ethernet-ports:
> +    type: object
> +    additionalProperties: false
> +
> +    properties:
> +      "#address-cells":
> +        const: 1
> +
> +      "#size-cells":
> +        const: 0
> +
> +    patternProperties:
> +      "^port@[0-3]$":
> +        type: object
> +        $ref: ethernet-controller.yaml#
> +        additionalProperties: false
> +
> +        properties:
> +          reg:
> +            description: port id
> +            maxItems: 1
> +
> +          phy-handle:
> +            maxItems: 1
> +
> +        required:
> +          - reg
> +          - phy-handle
> +
> +  mdio:
> +    $ref: mdio.yaml#
> +    unevaluatedProperties: false
> +
> +additionalProperties: false

Why did you move this? Previous position was correct, after required:.

> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - clock-names
> +  - resets
> +  - mdio
> +
> +examples:
> +  - |
> +    ethernet@e7140000 {
> +        compatible = "maxlinear,lgm-eth";
> +        reg = <0xe7140000 0x1200>,<0xe7150000 0x4000>;

Missing space after ,

> +        reg-names = "port", "ctrl";
> +        clocks = <&cgu0 32>;
> +        clock-names = "ethif";
> +        resets = <&rcu0 0x70 8>;

Best regards,
Krzysztof

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

[Jack Ping CHNG]

Add mxl_eth driver to introduce the initial implementation of ethernet
support for Maxlinear LGM SoC.
LGM SoC has a multi port MAC controller to interface with the PHY. It also
has a master MDIO interface to control the external MDIO configured
devices.

Signed-off-by: Jack Ping CHNG <jchng@maxlinear.com>
---
 .../device_drivers/ethernet/index.rst         |   1 +
 .../device_drivers/ethernet/maxlinear/mxl.rst |  49 +++++
 MAINTAINERS                                   |   8 +
 drivers/net/ethernet/Kconfig                  |   1 +
 drivers/net/ethernet/Makefile                 |   1 +
 drivers/net/ethernet/maxlinear/Kconfig        |  15 ++
 drivers/net/ethernet/maxlinear/Makefile       |   6 +
 drivers/net/ethernet/maxlinear/mxl_eth.c      | 202 ++++++++++++++++++
 8 files changed, 283 insertions(+)
 create mode 100644 Documentation/networking/device_drivers/ethernet/maxlinear/mxl.rst
 create mode 100644 drivers/net/ethernet/maxlinear/Kconfig
 create mode 100644 drivers/net/ethernet/maxlinear/Makefile
 create mode 100644 drivers/net/ethernet/maxlinear/mxl_eth.c

diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst
index 40ac552641a3..13d3cbc96e87 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -44,6 +44,7 @@ Contents:
    marvell/octeontx2
    marvell/octeon_ep
    marvell/octeon_ep_vf
+   maxlinear/mxl
    mellanox/mlx5/index
    meta/fbnic
    microsoft/netvsc
diff --git a/Documentation/networking/device_drivers/ethernet/maxlinear/mxl.rst b/Documentation/networking/device_drivers/ethernet/maxlinear/mxl.rst
new file mode 100644
index 000000000000..cb25b9da2579
--- /dev/null
+++ b/Documentation/networking/device_drivers/ethernet/maxlinear/mxl.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+MaxLinear Multi-MAC Network Processor (NP)
+===============================================
+
+Copyright(c) 2025 MaxLinear, Inc.
+
+Overview
+========
+
+This document describes the Linux driver for the MaxLinear Network Processor
+(NP), a high-performance controller supporting multiple MACs and
+advanced packet processing capabilities.
+
+The MaxLinear Network processor integrates programmable hardware accelerators
+for tasks such as Layer 2, 3, 4 forwarding, flow steering, and traffic shaping.
+It is designed to operate in high-throughput applications.
+
+Key Features
+============
+
+- Support for up to 4 independent 10 Gbit/s MAC interfaces
+- Full-duplex 10G operation
+- Multiqueue support for parallel RX/TX paths (per MAC)
+
+Supported Devices
+=================
+
+The driver supports the following MaxLinear NPU family devices:
+- MaxLinear LGM
+
+Each device supports multiple MACs and high-performance data pipelines managed
+through internal firmware and programmable engines.
+
+Kernel Configuration
+====================
+
+The driver is located in the menu structure at:
+
+  -> Device Drivers
+    -> Network device support
+      -> Ethernet driver support
+        -> MaxLinear NPU Ethernet driver
+
+Or set in your kernel config:
+  CONFIG_NET_VENDOR_MAXLINEAR=y
+  CONFIG_MAXLINEAR_ETH=y
+
diff --git a/MAINTAINERS b/MAINTAINERS
index fe168477caa4..d1475db89d86 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15102,6 +15102,14 @@ W:	https://linuxtv.org
 T:	git git://linuxtv.org/media.git
 F:	drivers/media/radio/radio-maxiradio*
 
+MAXLINEAR ETHERNET DRIVER
+M:	Jack Ping Chng <jchng@maxlinear.com>
+L:	netdev@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/net/maxlinear,lgm-eth.yaml
+F:	Documentation/networking/device_drivers/ethernet/maxlinear/mxl.rst
+F:	drivers/net/ethernet/maxlinear/
+
 MAXLINEAR ETHERNET PHY DRIVER
 M:	Xu Liang <lxu@maxlinear.com>
 L:	netdev@vger.kernel.org
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index f86d4557d8d7..3e94ff7922c8 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -121,6 +121,7 @@ config LANTIQ_XRX200
 source "drivers/net/ethernet/adi/Kconfig"
 source "drivers/net/ethernet/litex/Kconfig"
 source "drivers/net/ethernet/marvell/Kconfig"
+source "drivers/net/ethernet/maxlinear/Kconfig"
 source "drivers/net/ethernet/mediatek/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/meta/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 67182339469a..760d598df197 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_LANTIQ_ETOP) += lantiq_etop.o
 obj-$(CONFIG_LANTIQ_XRX200) += lantiq_xrx200.o
 obj-$(CONFIG_NET_VENDOR_LITEX) += litex/
 obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
+obj-$(CONFIG_NET_VENDOR_MAXLINEAR) += maxlinear/
 obj-$(CONFIG_NET_VENDOR_MEDIATEK) += mediatek/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
 obj-$(CONFIG_NET_VENDOR_META) += meta/
diff --git a/drivers/net/ethernet/maxlinear/Kconfig b/drivers/net/ethernet/maxlinear/Kconfig
new file mode 100644
index 000000000000..b88cdd9675fb
--- /dev/null
+++ b/drivers/net/ethernet/maxlinear/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config NET_VENDOR_MAXLINEAR
+	bool "MaxLinear devices"
+	help
+	  If you have a MaxLinear SoC with ethernet, say Y.
+
+if NET_VENDOR_MAXLINEAR
+
+config MXL_NPU
+	tristate "MaxLinear NPU Ethernet driver"
+	help
+	  This driver supports the MaxLinear NPU Ethernet.
+
+endif #NET_VENDOR_MAXLINEAR
+
diff --git a/drivers/net/ethernet/maxlinear/Makefile b/drivers/net/ethernet/maxlinear/Makefile
new file mode 100644
index 000000000000..0577b325494c
--- /dev/null
+++ b/drivers/net/ethernet/maxlinear/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for the MaxLinear network device drivers.
+#
+
+obj-$(CONFIG_MXL_NPU) += mxl_eth.o
diff --git a/drivers/net/ethernet/maxlinear/mxl_eth.c b/drivers/net/ethernet/maxlinear/mxl_eth.c
new file mode 100644
index 000000000000..036a800efe18
--- /dev/null
+++ b/drivers/net/ethernet/maxlinear/mxl_eth.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025  MaxLinear, Inc.
+ */
+#include <linux/clk.h>
+#include <linux/etherdevice.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#define ETH_TX_TIMEOUT		(10 * HZ)
+#define MXL_NUM_TX_RING		8
+#define MXL_NUM_RX_RING		8
+#define MXL_NUM_PORT		4
+
+struct mxl_eth_drvdata {
+	struct net_device *ndevs[MXL_NUM_PORT];
+	void __iomem *port_base;
+	void __iomem *ctrl_base;
+	struct clk *clks;
+};
+
+struct eth_priv {
+	struct platform_device *pdev;
+	struct device_node *np;
+	int port_id;
+};
+
+static int mxl_eth_open(struct net_device *ndev)
+{
+	netif_carrier_on(ndev);
+	netif_start_queue(ndev);
+	return 0;
+}
+
+static int mxl_eth_stop(struct net_device *ndev)
+{
+	netif_stop_queue(ndev);
+	netif_carrier_off(ndev);
+	return 0;
+}
+
+static int mxl_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+{
+	dev_kfree_skb(skb);
+	return NETDEV_TX_OK;
+}
+
+static const struct net_device_ops mxl_eth_netdev_ops = {
+	.ndo_open       = mxl_eth_open,
+	.ndo_stop       = mxl_eth_stop,
+	.ndo_start_xmit = mxl_eth_start_xmit,
+};
+
+static int mxl_eth_create_ndev(struct platform_device *pdev,
+			       struct device_node *np,
+			       struct net_device **ndev_out)
+{
+	struct net_device *ndev;
+	struct eth_priv *priv;
+	int ret;
+
+	ndev = devm_alloc_etherdev_mqs(&pdev->dev, sizeof(struct eth_priv),
+				       MXL_NUM_TX_RING, MXL_NUM_RX_RING);
+	if (!ndev) {
+		dev_err(&pdev->dev, "alloc_etherdev_mq failed\n");
+		return -ENOMEM;
+	}
+
+	ndev->netdev_ops = &mxl_eth_netdev_ops;
+	ndev->watchdog_timeo = ETH_TX_TIMEOUT;
+	ndev->max_mtu = ETH_FRAME_LEN;
+	ndev->min_mtu = ETH_MIN_MTU;
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+
+	priv = netdev_priv(ndev);
+	priv->pdev = pdev;
+	priv->np = np;
+
+	if (of_property_read_u32(np, "reg", &priv->port_id) < 0) {
+		dev_err(&pdev->dev, "failed to get port id\n");
+		return -EINVAL;
+	}
+
+	ret = register_netdev(ndev);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to register net device\n");
+		return ret;
+	}
+
+	*ndev_out = ndev;
+	return 0;
+}
+
+static void mxl_eth_cleanup(struct mxl_eth_drvdata *drvdata)
+{
+	int i;
+
+	for (i = 0; i < MXL_NUM_PORT && drvdata->ndevs[i]; i++) {
+		unregister_netdev(drvdata->ndevs[i]);
+		drvdata->ndevs[i] = NULL;
+	}
+}
+
+static int mxl_eth_probe(struct platform_device *pdev)
+{
+	struct mxl_eth_drvdata *drvdata;
+	struct device_node *eth_np, *np;
+	struct reset_control *rst;
+	int ret, i = 0;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->port_base =
+		devm_platform_ioremap_resource_byname(pdev, "port");
+	if (IS_ERR(drvdata->port_base))
+		return PTR_ERR(drvdata->port_base);
+
+	drvdata->ctrl_base =
+		devm_platform_ioremap_resource_byname(pdev, "ctrl");
+	if (IS_ERR(drvdata->ctrl_base))
+		return PTR_ERR(drvdata->ctrl_base);
+
+	drvdata->clks = devm_clk_get_enabled(&pdev->dev, "ethif");
+	if (IS_ERR(drvdata->clks))
+		return dev_err_probe(&pdev->dev, PTR_ERR(drvdata->clks),
+				     "failed to get/enable clock\n");
+
+	rst = devm_reset_control_get(&pdev->dev, NULL);
+	if (IS_ERR(rst))
+		return dev_err_probe(&pdev->dev, PTR_ERR(rst),
+				     "failed to get reset control\n");
+
+	reset_control_assert(rst);
+	udelay(1);
+	reset_control_deassert(rst);
+
+	platform_set_drvdata(pdev, drvdata);
+
+	eth_np = of_get_child_by_name(pdev->dev.of_node, "ethernet-ports");
+	if (!eth_np)
+		return dev_err_probe(&pdev->dev, -ENODEV,
+				     "no ethernet-ports node found!\n");
+
+	for_each_available_child_of_node(eth_np, np) {
+		ret = mxl_eth_create_ndev(pdev, np, &drvdata->ndevs[i++]);
+		if (ret) {
+			of_node_put(np);
+			goto err_cleanup;
+		}
+
+		if (i >= MXL_NUM_PORT) {
+			of_node_put(np);
+			break;
+		}
+	}
+
+	if (!i)
+		return dev_err_probe(&pdev->dev, -ENODEV,
+				     "no valid ethernet port\n");
+
+	return 0;
+
+err_cleanup:
+	mxl_eth_cleanup(drvdata);
+	return ret;
+}
+
+static void mxl_eth_remove(struct platform_device *pdev)
+{
+	struct mxl_eth_drvdata *drvdata = platform_get_drvdata(pdev);
+
+	mxl_eth_cleanup(drvdata);
+}
+
+/* Device Tree match table */
+static const struct of_device_id mxl_eth_of_match[] = {
+	{ .compatible = "maxlinear,lgm-eth" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxl_eth_of_match);
+
+/* Platform driver struct */
+static struct platform_driver mxl_eth_drv = {
+	.probe    = mxl_eth_probe,
+	.remove   = mxl_eth_remove,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = mxl_eth_of_match,
+	},
+};
+
+module_platform_driver(mxl_eth_drv);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Ethernet driver for MxL SoC");
-- 
2.34.1

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

[Andrew Lunn]

> +This document describes the Linux driver for the MaxLinear Network Processor
> +(NP), a high-performance controller supporting multiple MACs and
> +advanced packet processing capabilities.
> +
> +The MaxLinear Network processor integrates programmable hardware accelerators
> +for tasks such as Layer 2, 3, 4 forwarding, flow steering, and traffic shaping.

By L2 and L3, do you mean this device can bridge and route frames
between ports? So it is actually a switch?

	Andrew

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

[Jack Ping Chng]

Hi Andrew,

On Fri, 29 Aug 2025 22:24:06 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > +This document describes the Linux driver for the MaxLinear Network Processor
> > +(NP), a high-performance controller supporting multiple MACs and
> > +advanced packet processing capabilities.
> > +
> > +The MaxLinear Network processor integrates programmable hardware accelerators
> > +for tasks such as Layer 2, 3, 4 forwarding, flow steering, and traffic shaping.
> 
> By L2 and L3, do you mean this device can bridge and route frames
> between ports? So it is actually a switch?

Yes, the SoC does support packet acceleration. 
However, this patch series primarily focuses on the host interface to deliver packets to the CPU, 
where bridging and routing are handled within the network stack.

Best regards,
Jack

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

[Andrew Lunn]

On Mon, Sep 01, 2025 at 09:38:44AM +0000, Jack Ping Chng wrote:
> Hi Andrew,
> 
> On Fri, 29 Aug 2025 22:24:06 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
> > > +This document describes the Linux driver for the MaxLinear Network Processor
> > > +(NP), a high-performance controller supporting multiple MACs and
> > > +advanced packet processing capabilities.
> > > +
> > > +The MaxLinear Network processor integrates programmable hardware accelerators
> > > +for tasks such as Layer 2, 3, 4 forwarding, flow steering, and traffic shaping.
> > 
> > By L2 and L3, do you mean this device can bridge and route frames
> > between ports? So it is actually a switch?
> 
> Yes, the SoC does support packet acceleration. 
> However, this patch series primarily focuses on the host interface to deliver packets to the CPU, 
> where bridging and routing are handled within the network stack.

Linux has two ways to support a switch. Pure switchdev, or switchdev +
DSA. Which to use depends on the architecture of the device. I would
like to check now, before you get too far, what the hardware
architecture is.

Are there any public available block diagrams of this device?

How does the host direct a frame out a specific port of the switch?
How does the host know which port a frame came in on?

	Andrew

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

[Jack Ping Chng]

On Mon, 1 Sep 2025 15:11:08 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Mon, Sep 01, 2025 at 09:38:44AM +0000, Jack Ping Chng wrote:
> > Hi Andrew,
> >
> > On Fri, 29 Aug 2025 22:24:06 +0200
> > Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > > +This document describes the Linux driver for the MaxLinear Network Processor
> > > > +(NP), a high-performance controller supporting multiple MACs and
> > > > +advanced packet processing capabilities.
> > > > +
> > > > +The MaxLinear Network processor integrates programmable hardware accelerators
> > > > +for tasks such as Layer 2, 3, 4 forwarding, flow steering, and traffic shaping.
> > >
> > > By L2 and L3, do you mean this device can bridge and route frames
> > > between ports? So it is actually a switch?
> >
> > Yes, the SoC does support packet acceleration.
> > However, this patch series primarily focuses on the host interface to deliver packets to the CPU,
> > where bridging and routing are handled within the network stack.
> 
> Linux has two ways to support a switch. Pure switchdev, or switchdev +
> DSA. Which to use depends on the architecture of the device. I would
> like to check now, before you get too far, what the hardware
> architecture is.

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

Best regards,
Jack

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

[Andrew Lunn]

> 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

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

[Jack Ping Chng]

On Tue, 2 Sep 2025 14:30:19 +0200
Andrew Lunn <andrew@lunn.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

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

[Andrew Lunn]

> To clarify, this driver does not implement any switch functionality.

So you have all this nice hardware to accelerate L2, L3, etc, but you
are not going to use it? Linux will always ignore it and do it all in
software?

Somehow, i don't think this is true. At some point, you will want to
make use of that hardware. And Linux has very specific ways to do
that. You need to be looking forward to the time you start to use this
hardware, because if you get it wrong now, you will end up throwing
this driver away and starting again. I've seen it happen.

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

So this sounds like a pure switchdev driver, although DSA could still
be used. So, look forward, spend some time looking at other drivers
which implement the swichdev API, look at the mediatek drivers which
do acceleration of NAT, and make sure your architecture is correct.

	Andrew

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

[Andrew Lunn]

> +#define MXL_NUM_PORT		4

> +	if (of_property_read_u32(np, "reg", &priv->port_id) < 0) {
> +		dev_err(&pdev->dev, "failed to get port id\n");
> +		return -EINVAL;
> +	}

So the value of the port_id/reg does not matter? In device tree i
could use 42, 1024, 65535, 24?

	Andrew

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

[Krzysztof Kozlowski]

On Fri, Aug 29, 2025 at 08:48:43PM +0800, Jack Ping CHNG wrote:
> +
> +static int mxl_eth_probe(struct platform_device *pdev)
> +{
> +	struct mxl_eth_drvdata *drvdata;
> +	struct device_node *eth_np, *np;
> +	struct reset_control *rst;
> +	int ret, i = 0;
> +
> +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +
> +	drvdata->port_base =
> +		devm_platform_ioremap_resource_byname(pdev, "port");

Very odd wrapping. That's one line or wrap according to Linux coding
style.

> +	if (IS_ERR(drvdata->port_base))
> +		return PTR_ERR(drvdata->port_base);
> +
> +	drvdata->ctrl_base =
> +		devm_platform_ioremap_resource_byname(pdev, "ctrl");

Fix wrapping

> +	if (IS_ERR(drvdata->ctrl_base))
> +		return PTR_ERR(drvdata->ctrl_base);
> +
> +	drvdata->clks = devm_clk_get_enabled(&pdev->dev, "ethif");
> +	if (IS_ERR(drvdata->clks))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(drvdata->clks),
> +				     "failed to get/enable clock\n");
> +
> +	rst = devm_reset_control_get(&pdev->dev, NULL);
> +	if (IS_ERR(rst))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(rst),
> +				     "failed to get reset control\n");
> +
> +	reset_control_assert(rst);
> +	udelay(1);
> +	reset_control_deassert(rst);
> +
> +	platform_set_drvdata(pdev, drvdata);
> +
> +	eth_np = of_get_child_by_name(pdev->dev.of_node, "ethernet-ports");
> +	if (!eth_np)
> +		return dev_err_probe(&pdev->dev, -ENODEV,
> +				     "no ethernet-ports node found!\n");
> +
> +	for_each_available_child_of_node(eth_np, np) {

No, I asked you to use scoped loop.

> +		ret = mxl_eth_create_ndev(pdev, np, &drvdata->ndevs[i++]);
> +		if (ret) {
> +			of_node_put(np);

Best regards,
Krzysztof

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

[Simon Horman]

On Fri, Aug 29, 2025 at 08:48:43PM +0800, Jack Ping CHNG wrote:
> Add mxl_eth driver to introduce the initial implementation of ethernet
> support for Maxlinear LGM SoC.
> LGM SoC has a multi port MAC controller to interface with the PHY. It also
> has a master MDIO interface to control the external MDIO configured
> devices.
> 
> Signed-off-by: Jack Ping CHNG <jchng@maxlinear.com>

...

> diff --git a/drivers/net/ethernet/maxlinear/mxl_eth.c b/drivers/net/ethernet/maxlinear/mxl_eth.c

...

> +static int mxl_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)

Hi Jack,

I think it would better for the return type of mxl_eth_start_xmit to be
netdev_tx_t to match the signature of the .ndo_start_xmit member of const
struct net_device_ops.

Flagged by Clang 20.1.8 with
KCFLAGS=-Wincompatible-function-pointer-types-strict

drivers/net/ethernet/maxlinear/mxl_eth.c:56:20: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
   56 |         .ndo_start_xmit = mxl_eth_start_xmit,
      |                           ^~~~~~~~~~~~~~~~~~

> +{
> +	dev_kfree_skb(skb);
> +	return NETDEV_TX_OK;
> +}
> +
> +static const struct net_device_ops mxl_eth_netdev_ops = {
> +	.ndo_open       = mxl_eth_open,
> +	.ndo_stop       = mxl_eth_stop,
> +	.ndo_start_xmit = mxl_eth_start_xmit,
> +};

...