[PATCH net-next v3 0/4] enetc: Add mdio support and device tree nodes

[PATCH net-next v3 0/4] enetc: Add mdio support and device tree nodes

[Claudiu Manoil]

This is the missing part to enable PCI probing of the ENETC ethernet
ports on the LS1028A SoC and external traffic on the LS1028A RDB board.
It's one of the first items on the TODO list for the recently merged
ENETC ethernet driver.

v3: Add DT bindings doc for ENETC connections

Claudiu Manoil (4):
  arm64: dts: fsl: ls1028a: Add PCI IERC node and ENETC endpoints
  arm64: dts: fsl: ls1028a-rdb: Add ENETC external eth ports for the
    LS1028A RDB board
  enetc: Add ENETC PF level external MDIO support
  dt-bindings: net: freescale: enetc: Add connection bindings for ENETC
    ethernet nodes

 .../devicetree/bindings/net/fsl-enetc.txt          | 109 +++++++++++
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts  |  17 ++
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi     |  33 ++++
 drivers/net/ethernet/freescale/enetc/Makefile      |   3 +-
 drivers/net/ethernet/freescale/enetc/enetc_mdio.c  | 199 +++++++++++++++++++++
 drivers/net/ethernet/freescale/enetc/enetc_pf.c    |  12 ++
 drivers/net/ethernet/freescale/enetc/enetc_pf.h    |   6 +
 7 files changed, 378 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/net/fsl-enetc.txt
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.c

-- 
2.7.4

[PATCH net-next v3 1/4] arm64: dts: fsl: ls1028a: Add PCI IERC node and ENETC endpoints

[Claudiu Manoil]

The LS1028A SoC features a PCI Integrated Endpoint Root Complex
(IERC) defining several integrated PCI devices, including the ENETC
ethernet controller integrated endpoints (IEPs). The IERC implements
ECAM (Enhanced Configuration Access Mechanism) to provide access
to the PCIe config space of the IEPs. This means the the IEPs
(including ENETC) do not support the standard PCIe BARs, instead
the Enhanced Allocation (EA) capability structures in the ECAM space
are used to fix the base addresses in the system, and the PCI
subsystem uses these structures for device enumeration and discovery.
The "ranges" entries contain basic information from these EA capabily
structures required by the kernel for device enumeration.

The current patch also enables the first 2 ENETC PFs (Physiscal
Functions) and the associated VFs (Virtual Functions), 2 VFs for
each PF.  Each of these ENETC PFs has an external ethernet port
on the LS1028A SoC.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - none
v3 - none

 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index a8cf92a..7f5a8e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -335,5 +335,38 @@
 				     <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		pcie@1f0000000 { /* Integrated Endpoint Root Complex */
+			compatible = "pci-host-ecam-generic";
+			reg = <0x01 0xf0000000 0x0 0x100000>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			#interrupt-cells = <1>;
+			msi-parent = <&its>;
+			device_type = "pci";
+			bus-range = <0x0 0x0>;
+			dma-coherent;
+			msi-map = <0 &its 0x17 0xe>;
+			iommu-map = <0 &smmu 0x17 0xe>;
+				  /* PF0-6 BAR0 - non-prefetchable memory */
+			ranges = <0x82000000 0x0 0x00000000  0x1 0xf8000000  0x0 0x160000
+				  /* PF0-6 BAR2 - prefetchable memory */
+				  0xc2000000 0x0 0x00000000  0x1 0xf8160000  0x0 0x070000
+				  /* PF0: VF0-1 BAR0 - non-prefetchable memory */
+				  0x82000000 0x0 0x00000000  0x1 0xf81d0000  0x0 0x020000
+				  /* PF0: VF0-1 BAR2 - prefetchable memory */
+				  0xc2000000 0x0 0x00000000  0x1 0xf81f0000  0x0 0x020000
+				  /* PF1: VF0-1 BAR0 - non-prefetchable memory */
+				  0x82000000 0x0 0x00000000  0x1 0xf8210000  0x0 0x020000
+				  /* PF1: VF0-1 BAR2 - prefetchable memory */
+				  0xc2000000 0x0 0x00000000  0x1 0xf8230000  0x0 0x020000>;
+
+			enetc_port0: pci@0,0 {
+				reg = <0x000000 0 0 0 0>;
+			};
+			enetc_port1: pci@0,1 {
+				reg = <0x000100 0 0 0 0>;
+			};
+		};
 	};
 };
-- 
2.7.4

[PATCH net-next v3 2/4] arm64: dts: fsl: ls1028a-rdb: Add ENETC external eth ports for the LS1028A RDB board

[Claudiu Manoil]

The LS1028A RDB board features an Atheros PHY connected over
SGMII to the ENETC PF0 (or Port0).  ENETC Port1 (PF1) has no
external connection on this board, so it can be disabled for now.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - added a mdio node as parent for the phy node
v3 - none

 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index fdeb417..f86b054 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -71,3 +71,20 @@
 &duart1 {
 	status = "okay";
 };
+
+&enetc_port0 {
+	phy-handle = <&sgmii_phy0>;
+	phy-connection-type = "sgmii";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		sgmii_phy0: ethernet-phy@2 {
+			reg = <0x2>;
+		};
+	};
+};
+
+&enetc_port1 {
+	status = "disabled";
+};
-- 
2.7.4

[PATCH net-next v3 3/4] enetc: Add ENETC PF level external MDIO support

[Claudiu Manoil]

Each ENETC PF has its own MDIO interface, the corresponding
MDIO registers are mapped in the ENETC's Port register block.
The current patch adds a driver for these PF level MDIO buses,
so that each PF can manage directly its own external link.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2 - used readx_poll_timeout()
   - added mdio node child to the port node
   - added code comments, removed redundant err messages,
     minor code cleanup
v3 - replaced dev_err w/ dev_dbg for read() issues

 drivers/net/ethernet/freescale/enetc/Makefile     |   3 +-
 drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 199 ++++++++++++++++++++++
 drivers/net/ethernet/freescale/enetc/enetc_pf.c   |  12 ++
 drivers/net/ethernet/freescale/enetc/enetc_pf.h   |   6 +
 4 files changed, 219 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.c

diff --git a/drivers/net/ethernet/freescale/enetc/Makefile b/drivers/net/ethernet/freescale/enetc/Makefile
index 6976602..7139e41 100644
--- a/drivers/net/ethernet/freescale/enetc/Makefile
+++ b/drivers/net/ethernet/freescale/enetc/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_FSL_ENETC) += fsl-enetc.o
-fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o
+fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o \
+				 enetc_mdio.o
 fsl-enetc-$(CONFIG_PCI_IOV) += enetc_msg.o
 fsl-enetc-objs := enetc_pf.o $(fsl-enetc-y)
 
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
new file mode 100644
index 0000000..77b9cd1
--- /dev/null
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/* Copyright 2019 NXP */
+
+#include <linux/mdio.h>
+#include <linux/of_mdio.h>
+#include <linux/iopoll.h>
+#include <linux/of.h>
+
+#include "enetc_pf.h"
+
+struct enetc_mdio_regs {
+	u32	mdio_cfg;	/* MDIO configuration and status */
+	u32	mdio_ctl;	/* MDIO control */
+	u32	mdio_data;	/* MDIO data */
+	u32	mdio_addr;	/* MDIO address */
+};
+
+#define bus_to_enetc_regs(bus)	(struct enetc_mdio_regs __iomem *)((bus)->priv)
+
+#define ENETC_MDIO_REG_OFFSET	0x1c00
+#define ENETC_MDC_DIV		258
+
+#define MDIO_CFG_CLKDIV(x)	((((x) >> 1) & 0xff) << 8)
+#define MDIO_CFG_BSY		BIT(0)
+#define MDIO_CFG_RD_ER		BIT(1)
+#define MDIO_CFG_ENC45		BIT(6)
+ /* external MDIO only - driven on neg MDC edge */
+#define MDIO_CFG_NEG		BIT(23)
+
+#define MDIO_CTL_DEV_ADDR(x)	((x) & 0x1f)
+#define MDIO_CTL_PORT_ADDR(x)	(((x) & 0x1f) << 5)
+#define MDIO_CTL_READ		BIT(15)
+#define MDIO_DATA(x)		((x) & 0xffff)
+
+#define TIMEOUT	1000
+static int enetc_mdio_wait_complete(struct enetc_mdio_regs __iomem *regs)
+{
+	u32 val;
+
+	return readx_poll_timeout(enetc_rd_reg, &regs->mdio_cfg, val,
+				  !(val & MDIO_CFG_BSY), 10, 10 * TIMEOUT);
+}
+
+static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
+			    u16 value)
+{
+	struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+	u32 mdio_ctl, mdio_cfg;
+	u16 dev_addr;
+	int ret;
+
+	mdio_cfg = MDIO_CFG_CLKDIV(ENETC_MDC_DIV) | MDIO_CFG_NEG;
+	if (regnum & MII_ADDR_C45) {
+		dev_addr = (regnum >> 16) & 0x1f;
+		mdio_cfg |= MDIO_CFG_ENC45;
+	} else {
+		/* clause 22 (ie 1G) */
+		dev_addr = regnum & 0x1f;
+		mdio_cfg &= ~MDIO_CFG_ENC45;
+	}
+
+	enetc_wr_reg(&regs->mdio_cfg, mdio_cfg);
+
+	ret = enetc_mdio_wait_complete(regs);
+	if (ret)
+		return ret;
+
+	/* set port and dev addr */
+	mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+	enetc_wr_reg(&regs->mdio_ctl, mdio_ctl);
+
+	/* set the register address */
+	if (regnum & MII_ADDR_C45) {
+		enetc_wr_reg(&regs->mdio_addr, regnum & 0xffff);
+
+		ret = enetc_mdio_wait_complete(regs);
+		if (ret)
+			return ret;
+	}
+
+	/* write the value */
+	enetc_wr_reg(&regs->mdio_data, MDIO_DATA(value));
+
+	ret = enetc_mdio_wait_complete(regs);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+	struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+	u32 mdio_ctl, mdio_cfg;
+	u16 dev_addr, value;
+	int ret;
+
+	mdio_cfg = MDIO_CFG_CLKDIV(ENETC_MDC_DIV) | MDIO_CFG_NEG;
+	if (regnum & MII_ADDR_C45) {
+		dev_addr = (regnum >> 16) & 0x1f;
+		mdio_cfg |= MDIO_CFG_ENC45;
+	} else {
+		dev_addr = regnum & 0x1f;
+		mdio_cfg &= ~MDIO_CFG_ENC45;
+	}
+
+	enetc_wr_reg(&regs->mdio_cfg, mdio_cfg);
+
+	ret = enetc_mdio_wait_complete(regs);
+	if (ret)
+		return ret;
+
+	/* set port and device addr */
+	mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+	enetc_wr_reg(&regs->mdio_ctl, mdio_ctl);
+
+	/* set the register address */
+	if (regnum & MII_ADDR_C45) {
+		enetc_wr_reg(&regs->mdio_addr, regnum & 0xffff);
+
+		ret = enetc_mdio_wait_complete(regs);
+		if (ret)
+			return ret;
+	}
+
+	/* initiate the read */
+	enetc_wr_reg(&regs->mdio_ctl, mdio_ctl | MDIO_CTL_READ);
+
+	ret = enetc_mdio_wait_complete(regs);
+	if (ret)
+		return ret;
+
+	/* return all Fs if nothing was there */
+	if (enetc_rd_reg(&regs->mdio_cfg) & MDIO_CFG_RD_ER) {
+		dev_dbg(&bus->dev,
+			"Error while reading PHY%d reg at %d.%hhu\n",
+			phy_id, dev_addr, regnum);
+		return 0xffff;
+	}
+
+	value = enetc_rd_reg(&regs->mdio_data) & 0xffff;
+
+	return value;
+}
+
+int enetc_mdio_probe(struct enetc_pf *pf)
+{
+	struct device *dev = &pf->si->pdev->dev;
+	struct enetc_mdio_regs __iomem *regs;
+	struct device_node *np;
+	struct mii_bus *bus;
+	int ret;
+
+	bus = mdiobus_alloc_size(sizeof(regs));
+	if (!bus)
+		return -ENOMEM;
+
+	bus->name = "Freescale ENETC MDIO Bus";
+	bus->read = enetc_mdio_read;
+	bus->write = enetc_mdio_write;
+	bus->parent = dev;
+	snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+
+	/* store the enetc mdio base address for this bus */
+	regs = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
+	bus->priv = regs;
+
+	np = of_get_child_by_name(dev->of_node, "mdio");
+	if (!np) {
+		dev_err(dev, "MDIO node missing\n");
+		ret = -EINVAL;
+		goto err_registration;
+	}
+
+	ret = of_mdiobus_register(bus, np);
+	if (ret) {
+		of_node_put(np);
+		dev_err(dev, "cannot register MDIO bus\n");
+		goto err_registration;
+	}
+
+	of_node_put(np);
+	pf->mdio = bus;
+
+	return 0;
+
+err_registration:
+	mdiobus_free(bus);
+
+	return ret;
+}
+
+void enetc_mdio_remove(struct enetc_pf *pf)
+{
+	if (pf->mdio) {
+		mdiobus_unregister(pf->mdio);
+		mdiobus_free(pf->mdio);
+	}
+}
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 7d28f5e..15876a6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -746,6 +746,7 @@ static void enetc_pf_netdev_setup(struct enetc_si *si, struct net_device *ndev,
 
 static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
 {
+	struct enetc_pf *pf = enetc_si_priv(priv->si);
 	struct device_node *np = priv->dev->of_node;
 	int err;
 
@@ -770,12 +771,22 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
 		priv->phy_node = of_node_get(np);
 	}
 
+	if (!of_phy_is_fixed_link(np)) {
+		err = enetc_mdio_probe(pf);
+		if (err) {
+			of_node_put(priv->phy_node);
+			return err;
+		}
+	}
+
 	priv->if_mode = of_get_phy_mode(np);
 	if (priv->if_mode < 0) {
 		dev_err(priv->dev, "missing phy type\n");
 		of_node_put(priv->phy_node);
 		if (of_phy_is_fixed_link(np))
 			of_phy_deregister_fixed_link(np);
+		else
+			enetc_mdio_remove(pf);
 
 		return -EINVAL;
 	}
@@ -898,6 +909,7 @@ static void enetc_pf_remove(struct pci_dev *pdev)
 
 	unregister_netdev(si->ndev);
 
+	enetc_mdio_remove(pf);
 	enetc_of_put_phy(priv);
 
 	enetc_free_msix(priv);
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index 2061ae5..10dd1b5 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -42,8 +42,14 @@ struct enetc_pf {
 	char vlan_promisc_simap; /* bitmap of SIs in VLAN promisc mode */
 	DECLARE_BITMAP(vlan_ht_filter, ENETC_VLAN_HT_SIZE);
 	DECLARE_BITMAP(active_vlans, VLAN_N_VID);
+
+	struct mii_bus *mdio; /* saved for cleanup */
 };
 
 int enetc_msg_psi_init(struct enetc_pf *pf);
 void enetc_msg_psi_free(struct enetc_pf *pf);
 void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int mbox_id, u16 *status);
+
+/* MDIO */
+int enetc_mdio_probe(struct enetc_pf *pf);
+void enetc_mdio_remove(struct enetc_pf *pf);
-- 
2.7.4

Re: [PATCH net-next v3 3/4] enetc: Add ENETC PF level external MDIO support

[Andrew Lunn]

On Fri, Feb 22, 2019 at 05:04:18PM +0200, Claudiu Manoil wrote:
> Each ENETC PF has its own MDIO interface, the corresponding
> MDIO registers are mapped in the ENETC's Port register block.
> The current patch adds a driver for these PF level MDIO buses,
> so that each PF can manage directly its own external link.
> 
> Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[PATCH net-next v3 4/4] dt-bindings: net: freescale: enetc: Add connection bindings for ENETC ethernet nodes

[Claudiu Manoil]

Define connection bindings (external PHY connections and internal links)
for the ENETC on-chip ethernet controllers.

Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v3 - added this patch to the set

 .../devicetree/bindings/net/fsl-enetc.txt          | 109 +++++++++++++++++++++
 1 file changed, 109 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/fsl-enetc.txt

diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
new file mode 100644
index 0000000..2fbb998
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
@@ -0,0 +1,109 @@
+* ENETC ethernet nodes - external connection bindings
+
+The ENETC ethernet controllers are PCIe integrated endpoints
+(IEPs), on-chip devices discoverable as standard PCIe endpoints,
+integrated into Freescale SoCs.  The ENETC devices are self
+contained, the information needed for device initialization
+is available in hardware (PCIe ECAM area).  However, depending
+on board design, their external connections are configurable.
+As usual for SoCs, device tree nodes may be used to define these
+external connections.  The rest of the document specifies how
+external connections for ENETC ethernet controllers may be
+defined via device tree nodes.
+
+Silicon (SoC) availability (<SoC name>: <SoC DT path/name>)
+	- LS1028A: [arch/arm64]	[...]freescale/fsl-ls1028a.dtsi
+
+
+* ENETC nodes
+
+Defined in the SoC device tree as "pci" child nodes of the
+"pci-host-ecam-generic" compatible "pcie" parent node also known
+as the Integrated Endpoint Root Complex (IERC) SoC node.
+
+Structure - example (LS1028A):
+
+	pcie@1f0000000 {
+		compatible = "pci-host-ecam-generic";
+		device_type = "pci";
+		...
+		enetc_port0: pci@0,0 {
+			reg = <0x000000 0 0 0 0>;
+		};
+		enetc_port1: pci@0,1 {
+			reg = <0x000100 0 0 0 0>;
+		};
+		...
+	}
+
+Each ENETC node has a device number and a function number (expressed
+by its "reg" property and pci node name, i.e. "pci@0,1" represents
+device number 0 and functions number 1).  Only the standard pci "reg"
+property is needed here.
+For easy reference, each ENETC node is tagged by a handle having the
+following format:
+
+	"enetc_port<idx>"   where, idx = 0 .. n-1;
+			    n - #of available ENETC nodes (Ports) on
+				the given SoC.
+
+NOTES
+i. The SoC H/W Reference Manual provides a mapping of the ENETC Port
+numbers to the PCIe Device Number/ Function Number.
+Example (LS1028):
+	All ENETC PFs (PCIe Physical Functions) have Device Number 0.
+	Port 0 - PF0 (pci@0,0)
+	Port 1 - PF1 (pci@0,1)
+	Port 2 - PF2 (pci@0,2)
+	Port 3 - PF6 (pci@0,6)
+
+ii. The SoC H/W Reference Manual also defines which ENETC Ports may have
+external connections (external ports) and which ones are internally
+connected to a on-chip L2 switch for instance (internal ports).
+
+
+* Defining connections for ENETC nodes
+
+To define external connections for the external ENETC Ports on a given
+board/platform, the board device tree should include the SoC device tree
+and reference the external ports by their "enetc_port<idx>" handle.
+
+Following cases arise, defining all possible connection bindings:
+
+1) The ENETC Port is connected to a MDIO configurable PHY:
+
+	In this case, the ENETC node should include a "mdio" sub-node
+	that in turn should contain the "phy" node describing the
+	external phy.  ENETC Port node structure (example):
+
+	&enetc_port0 {
+		phy-handle = <&sgmii_phy0>;
+		phy-connection-type = "sgmii";
+
+		mdio {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			sgmii_phy0: ethernet-phy@2 {
+				reg = <0x2>;
+			};
+		};
+	};
+
+	All properties are mandatory for this case, their bindings already
+	defined (see ethernet.txt and phy.txt).
+
+2) The ENETC Port has a fixed-link connection:
+
+	In this case, the ENETC Port node defines a fixed link connection,
+	with the following structure (example):
+
+	&enetc_port2 {
+		fixed-link {
+			speed = <1000>;
+			full-duplex;
+		};
+	};
+
+	The "fixed-link" node properties are standard (as defined in
+	fixed-link.txt).
+	This connection type also applies to the internal ENETC Ports.
-- 
2.7.4

Re: [PATCH net-next v3 4/4] dt-bindings: net: freescale: enetc: Add connection bindings for ENETC ethernet nodes

[Rob Herring]

On Fri, Feb 22, 2019 at 05:04:19PM +0200, Claudiu Manoil wrote:
> Define connection bindings (external PHY connections and internal links)
> for the ENETC on-chip ethernet controllers.
> 
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> v3 - added this patch to the set
> 
>  .../devicetree/bindings/net/fsl-enetc.txt          | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/fsl-enetc.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
> new file mode 100644
> index 0000000..2fbb998
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
> @@ -0,0 +1,109 @@
> +* ENETC ethernet nodes - external connection bindings
> +
> +The ENETC ethernet controllers are PCIe integrated endpoints
> +(IEPs), on-chip devices discoverable as standard PCIe endpoints,
> +integrated into Freescale SoCs.  The ENETC devices are self
> +contained, the information needed for device initialization
> +is available in hardware (PCIe ECAM area).  However, depending
> +on board design, their external connections are configurable.
> +As usual for SoCs, device tree nodes may be used to define these
> +external connections.  The rest of the document specifies how
> +external connections for ENETC ethernet controllers may be
> +defined via device tree nodes.
> +
> +Silicon (SoC) availability (<SoC name>: <SoC DT path/name>)
> +	- LS1028A: [arch/arm64]	[...]freescale/fsl-ls1028a.dtsi

This doesn't belong in bindings.

> +
> +
> +* ENETC nodes
> +
> +Defined in the SoC device tree as "pci" child nodes of the
> +"pci-host-ecam-generic" compatible "pcie" parent node also known
> +as the Integrated Endpoint Root Complex (IERC) SoC node.

The host controller attachment is also outside the scope of this 
binding.

> +
> +Structure - example (LS1028A):
> +
> +	pcie@1f0000000 {
> +		compatible = "pci-host-ecam-generic";
> +		device_type = "pci";
> +		...
> +		enetc_port0: pci@0,0 {

The node name 'pci' is reserved for bridges. This should match the 
device class if possible (ethernet).

> +			reg = <0x000000 0 0 0 0>;
> +		};
> +		enetc_port1: pci@0,1 {
> +			reg = <0x000100 0 0 0 0>;
> +		};
> +		...
> +	}
> +
> +Each ENETC node has a device number and a function number (expressed
> +by its "reg" property and pci node name, i.e. "pci@0,1" represents
> +device number 0 and functions number 1).  Only the standard pci "reg"
> +property is needed here.

There should be a compatible too.

> +For easy reference, each ENETC node is tagged by a handle having the
> +following format:
> +
> +	"enetc_port<idx>"   where, idx = 0 .. n-1;
> +			    n - #of available ENETC nodes (Ports) on
> +				the given SoC.

These are just source labels, so really they can be anything.

> +
> +NOTES
> +i. The SoC H/W Reference Manual provides a mapping of the ENETC Port
> +numbers to the PCIe Device Number/ Function Number.
> +Example (LS1028):
> +	All ENETC PFs (PCIe Physical Functions) have Device Number 0.
> +	Port 0 - PF0 (pci@0,0)
> +	Port 1 - PF1 (pci@0,1)
> +	Port 2 - PF2 (pci@0,2)
> +	Port 3 - PF6 (pci@0,6)
> +
> +ii. The SoC H/W Reference Manual also defines which ENETC Ports may have
> +external connections (external ports) and which ones are internally
> +connected to a on-chip L2 switch for instance (internal ports).
> +
> +
> +* Defining connections for ENETC nodes
> +
> +To define external connections for the external ENETC Ports on a given
> +board/platform, the board device tree should include the SoC device tree
> +and reference the external ports by their "enetc_port<idx>" handle.

SoC vs. board files are convention, but not really part of the binding 
ABI.

> +
> +Following cases arise, defining all possible connection bindings:
> +
> +1) The ENETC Port is connected to a MDIO configurable PHY:
> +
> +	In this case, the ENETC node should include a "mdio" sub-node
> +	that in turn should contain the "phy" node describing the
> +	external phy.  ENETC Port node structure (example):
> +
> +	&enetc_port0 {

Please just show the full DT example, not separate chunks.

> +		phy-handle = <&sgmii_phy0>;
> +		phy-connection-type = "sgmii";
> +
> +		mdio {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			sgmii_phy0: ethernet-phy@2 {
> +				reg = <0x2>;
> +			};
> +		};
> +	};
> +
> +	All properties are mandatory for this case, their bindings already
> +	defined (see ethernet.txt and phy.txt).
> +
> +2) The ENETC Port has a fixed-link connection:
> +
> +	In this case, the ENETC Port node defines a fixed link connection,
> +	with the following structure (example):
> +
> +	&enetc_port2 {
> +		fixed-link {
> +			speed = <1000>;
> +			full-duplex;
> +		};
> +	};
> +
> +	The "fixed-link" node properties are standard (as defined in
> +	fixed-link.txt).
> +	This connection type also applies to the internal ENETC Ports.
> -- 
> 2.7.4
> 

RE: [PATCH net-next v3 4/4] dt-bindings: net: freescale: enetc: Add connection bindings for ENETC ethernet nodes

[Claudiu Manoil]

>-----Original Message-----
>From: Rob Herring <robh@kernel.org>
>Sent: Saturday, February 23, 2019 1:38 AM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: Shawn Guo <shawnguo@kernel.org>; Leo Li <leoyang.li@nxp.com>; David S .
>Miller <davem@davemloft.net>; Alexandru Marginean
><alexandru.marginean@nxp.com>; linux-arm-kernel@lists.infradead.org;
>devicetree@vger.kernel.org; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org
>Subject: Re: [PATCH net-next v3 4/4] dt-bindings: net: freescale: enetc: Add
>connection bindings for ENETC ethernet nodes
>
>On Fri, Feb 22, 2019 at 05:04:19PM +0200, Claudiu Manoil wrote:
>> Define connection bindings (external PHY connections and internal
>> links) for the ENETC on-chip ethernet controllers.
>>
>> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
>> ---
>> v3 - added this patch to the set
>>
>>  .../devicetree/bindings/net/fsl-enetc.txt          | 109 +++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/net/fsl-enetc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt
>> b/Documentation/devicetree/bindings/net/fsl-enetc.txt
>> new file mode 100644
>> index 0000000..2fbb998
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
>> @@ -0,0 +1,109 @@
>> +* ENETC ethernet nodes - external connection bindings
>> +
>> +The ENETC ethernet controllers are PCIe integrated endpoints (IEPs),
>> +on-chip devices discoverable as standard PCIe endpoints, integrated
>> +into Freescale SoCs.  The ENETC devices are self contained, the
>> +information needed for device initialization is available in hardware
>> +(PCIe ECAM area).  However, depending on board design, their external
>> +connections are configurable.
>> +As usual for SoCs, device tree nodes may be used to define these
>> +external connections.  The rest of the document specifies how
>> +external connections for ENETC ethernet controllers may be defined
>> +via device tree nodes.
>> +
>> +Silicon (SoC) availability (<SoC name>: <SoC DT path/name>)
>> +	- LS1028A: [arch/arm64]	[...]freescale/fsl-ls1028a.dtsi
>
>This doesn't belong in bindings.
>
>> +
>> +
>> +* ENETC nodes
>> +
>> +Defined in the SoC device tree as "pci" child nodes of the
>> +"pci-host-ecam-generic" compatible "pcie" parent node also known as
>> +the Integrated Endpoint Root Complex (IERC) SoC node.
>
>The host controller attachment is also outside the scope of this binding.
>
>> +
>> +Structure - example (LS1028A):
>> +
>> +	pcie@1f0000000 {
>> +		compatible = "pci-host-ecam-generic";
>> +		device_type = "pci";
>> +		...
>> +		enetc_port0: pci@0,0 {
>
>The node name 'pci' is reserved for bridges. This should match the device class if
>possible (ethernet).
>
>> +			reg = <0x000000 0 0 0 0>;
>> +		};
>> +		enetc_port1: pci@0,1 {
>> +			reg = <0x000100 0 0 0 0>;
>> +		};
>> +		...
>> +	}
>> +
>> +Each ENETC node has a device number and a function number (expressed
>> +by its "reg" property and pci node name, i.e. "pci@0,1" represents
>> +device number 0 and functions number 1).  Only the standard pci "reg"
>> +property is needed here.
>
>There should be a compatible too.
[...]

Ok to simplifying the text and document strictly the enetc device nodes as
"ethernet" nodes, like "ethernet@<dev_no>,<fcn_no>" (i.e ethernet@0,1).
But what would be the compatible string needed for?
The ethernet device driver doesn't need it, probing is done by the pci system.
Is it ok to use a generic name for the compatible string, like, "fsl,enetc", just
to indicate that the relevant driver is located at ethernet/freescale/enetc/
dir in the source code? (under drivers/net, of course)

Thanks.
Claudiu