[PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Wei Fang]

For the external PHY devices, NETC provide external MDIO interface to
manage them. ENETC can use a set of MDIO registers provided by EMDIO to
access its PHY, which is a method currently supported by the driver. It
also can use its own set of MDIO registers to access its PHY, but the
premise is that its corresponding LaBCR[MDIO_PHYAD_PRTAD] needs to be
set correctly, which indicates its PHY address.

Similar to the external MDIO registers, each ENETC has a set of internal
MDIO registers to access its on-die PHY (PCS), so internal MDIO support
is also added.

Aziz Sellami (1):
  net: enetc: set external MDIO PHY address for i.MX95 ENETC

Wei Fang (2):
  net: enetc: set external MDIO PHY address for i.MX94 ENETC
  net: enetc: add port MDIO support for ENETC v4

 .../net/ethernet/freescale/enetc/enetc4_hw.h  |   6 +
 .../freescale/enetc/enetc_pf_common.c         |  14 ++-
 .../ethernet/freescale/enetc/netc_blk_ctrl.c  | 111 +++++++++++++++++-
 3 files changed, 128 insertions(+), 3 deletions(-)

-- 
2.34.1

[PATCH net-next 1/3] net: enetc: set external MDIO PHY address for i.MX95 ENETC

[Wei Fang]

From: Aziz Sellami <aziz.sellami@nxp.com>

When configuring the PHY as port EMDIO (by putting an mdio node as a
child of the enetc port) the ierb needs to be configured with the right
phy address. And since the configuration is harmless for the central
EMDIO mode (current default behavior for i.MX 95 EVKs), put the
configuration there anyway for code simplicity.

Signed-off-by: Aziz Sellami <aziz.sellami@nxp.com>
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 .../ethernet/freescale/enetc/netc_blk_ctrl.c  | 57 ++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
index d7aee3c934d3..1d499276465f 100644
--- a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
+++ b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
@@ -67,6 +67,9 @@
 #define IERB_EMDIOFAUXR			0x344
 #define IERB_T0FAUXR			0x444
 #define IERB_ETBCR(a)			(0x300c + 0x100 * (a))
+#define IERB_LBCR(a)			(0x1010 + 0x40 * (a))
+#define  LBCR_MDIO_PHYAD_PRTAD(addr)	(((addr) & 0x1f) << 8)
+
 #define IERB_EFAUXR(a)			(0x3044 + 0x100 * (a))
 #define IERB_VFAUXR(a)			(0x4004 + 0x40 * (a))
 #define FAUXR_LDID			GENMASK(3, 0)
@@ -322,6 +325,58 @@ static int netc_unlock_ierb_with_warm_reset(struct netc_blk_ctrl *priv)
 				 1000, 100000, true, priv->prb, PRB_NETCRR);
 }
 
+static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
+{
+	struct netc_blk_ctrl *priv = platform_get_drvdata(pdev);
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *phy_node;
+	int bus_devfn, err;
+	u32 addr;
+
+	/* Update the port EMDIO PHY address through parsing phy properties.
+	 * This is needed when using the port EMDIO but it's harmless when
+	 * using the central EMDIO. So apply it on all cases.
+	 */
+	for_each_child_of_node_scoped(np, child) {
+		for_each_child_of_node_scoped(child, gchild) {
+			if (!of_device_is_compatible(gchild, "pci1131,e101"))
+				continue;
+
+			bus_devfn = netc_of_pci_get_bus_devfn(gchild);
+			if (bus_devfn < 0)
+				return bus_devfn;
+
+			phy_node = of_parse_phandle(gchild, "phy-handle", 0);
+			if (!phy_node)
+				continue;
+
+			err = of_property_read_u32(phy_node, "reg", &addr);
+			of_node_put(phy_node);
+			if (err)
+				return err;
+
+			switch (bus_devfn) {
+			case IMX95_ENETC0_BUS_DEVFN:
+				netc_reg_write(priv->ierb, IERB_LBCR(0),
+					       LBCR_MDIO_PHYAD_PRTAD(addr));
+				break;
+			case IMX95_ENETC1_BUS_DEVFN:
+				netc_reg_write(priv->ierb, IERB_LBCR(1),
+					       LBCR_MDIO_PHYAD_PRTAD(addr));
+				break;
+			case IMX95_ENETC2_BUS_DEVFN:
+				netc_reg_write(priv->ierb, IERB_LBCR(2),
+					       LBCR_MDIO_PHYAD_PRTAD(addr));
+				break;
+			default:
+				break;
+			}
+		}
+	}
+
+	return 0;
+}
+
 static int imx95_ierb_init(struct platform_device *pdev)
 {
 	struct netc_blk_ctrl *priv = platform_get_drvdata(pdev);
@@ -349,7 +404,7 @@ static int imx95_ierb_init(struct platform_device *pdev)
 	/* NETC TIMER */
 	netc_reg_write(priv->ierb, IERB_T0FAUXR, 7);
 
-	return 0;
+	return imx95_enetc_mdio_phyaddr_config(pdev);
 }
 
 static int imx94_get_enetc_id(struct device_node *np)
-- 
2.34.1

[PATCH net-next 2/3] net: enetc: set external MDIO PHY address for i.MX94 ENETC

[Wei Fang]

LaBCR[MDIO_PHYAD_PRTAD] indicates link external MDIO PHY's address for
clause 22 and external MDIO port address for clause 45. Each ENETC port
or switch port has a corresponding LaBCR register. Once this field is
configured with the correct PHY address, the switch port or ENETC port
can use its own a set of MDIO registers to access and control its
external PHY. Currently, this patch only configures the PHY address for
ENETCs, because the switch support is not added yet.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 .../ethernet/freescale/enetc/netc_blk_ctrl.c  | 74 ++++++++++++++++---
 1 file changed, 64 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
index 1d499276465f..4617cbc70f5a 100644
--- a/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
+++ b/drivers/net/ethernet/freescale/enetc/netc_blk_ctrl.c
@@ -325,13 +325,29 @@ static int netc_unlock_ierb_with_warm_reset(struct netc_blk_ctrl *priv)
 				 1000, 100000, true, priv->prb, PRB_NETCRR);
 }
 
+static int netc_get_phy_addr(struct device_node *np)
+{
+	struct device_node *phy_node;
+	u32 addr;
+	int err;
+
+	phy_node = of_parse_phandle(np, "phy-handle", 0);
+	if (!phy_node)
+		return 0;
+
+	err = of_property_read_u32(phy_node, "reg", &addr);
+	of_node_put(phy_node);
+	if (err)
+		return err;
+
+	return addr;
+}
+
 static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
 {
 	struct netc_blk_ctrl *priv = platform_get_drvdata(pdev);
 	struct device_node *np = pdev->dev.of_node;
-	struct device_node *phy_node;
-	int bus_devfn, err;
-	u32 addr;
+	int bus_devfn, addr;
 
 	/* Update the port EMDIO PHY address through parsing phy properties.
 	 * This is needed when using the port EMDIO but it's harmless when
@@ -346,14 +362,15 @@ static int imx95_enetc_mdio_phyaddr_config(struct platform_device *pdev)
 			if (bus_devfn < 0)
 				return bus_devfn;
 
-			phy_node = of_parse_phandle(gchild, "phy-handle", 0);
-			if (!phy_node)
-				continue;
+			addr = netc_get_phy_addr(gchild);
+			if (addr < 0)
+				return addr;
 
-			err = of_property_read_u32(phy_node, "reg", &addr);
-			of_node_put(phy_node);
-			if (err)
-				return err;
+			/* The default value of LaBCR[MDIO_PHYAD_PRTAD ] is
+			 * 0, so no need to set the register.
+			 */
+			if (!addr)
+				continue;
 
 			switch (bus_devfn) {
 			case IMX95_ENETC0_BUS_DEVFN:
@@ -479,6 +496,39 @@ static int imx94_enetc_update_tid(struct netc_blk_ctrl *priv,
 	return 0;
 }
 
+static int imx94_enetc_mdio_phyaddr_config(struct netc_blk_ctrl *priv,
+					   struct device_node *np)
+{
+	int bus_devfn, addr;
+
+	bus_devfn = netc_of_pci_get_bus_devfn(np);
+	if (bus_devfn < 0)
+		return bus_devfn;
+
+	addr = netc_get_phy_addr(np);
+	if (addr <= 0)
+		return addr;
+
+	switch (bus_devfn) {
+	case IMX94_ENETC0_BUS_DEVFN:
+		netc_reg_write(priv->ierb, IERB_LBCR(IMX94_ENETC0_LINK),
+			       LBCR_MDIO_PHYAD_PRTAD(addr));
+		break;
+	case IMX94_ENETC1_BUS_DEVFN:
+		netc_reg_write(priv->ierb, IERB_LBCR(IMX94_ENETC1_LINK),
+			       LBCR_MDIO_PHYAD_PRTAD(addr));
+		break;
+	case IMX94_ENETC2_BUS_DEVFN:
+		netc_reg_write(priv->ierb, IERB_LBCR(IMX94_ENETC2_LINK),
+			       LBCR_MDIO_PHYAD_PRTAD(addr));
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
 static int imx94_ierb_init(struct platform_device *pdev)
 {
 	struct netc_blk_ctrl *priv = platform_get_drvdata(pdev);
@@ -493,6 +543,10 @@ static int imx94_ierb_init(struct platform_device *pdev)
 			err = imx94_enetc_update_tid(priv, gchild);
 			if (err)
 				return err;
+
+			err = imx94_enetc_mdio_phyaddr_config(priv, gchild);
+			if (err)
+				return err;
 		}
 	}
 
-- 
2.34.1

[PATCH net-next 3/3] net: enetc: add port MDIO support for ENETC v4

[Wei Fang]

The NETC IP provides two ways for ENETC to access the external PHY, one
is the external MDIO interface is controlled by EMDIO module, and EMDIO
provides a way for different ENETCs to share a set of MDIO signals to
access their PHYs. And this EMDIO support has been added in the commit
a52201fb9caa ("net: enetc: add i.MX95 EMDIO support"). The other way
is that each ENETC has its set of MDIO registers to access and control
its PHY.

In addition, each ENETC has one internal MDIO interface for managing
on-die PHY (PCS). So add port internal and external MDIO support for
ENETC v4.

Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc4_hw.h   |  6 ++++++
 .../net/ethernet/freescale/enetc/enetc_pf_common.c | 14 ++++++++++++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
index ebea4298791c..3ed0f7a02767 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
@@ -170,6 +170,9 @@
 /* Port MAC 0/1 Maximum Frame Length Register */
 #define ENETC4_PM_MAXFRM(mac)		(0x5014 + (mac) * 0x400)
 
+/* Port internal MDIO base address, use to access PCS */
+#define ENETC4_PM_IMDIO_BASE		0x5030
+
 /* Port MAC 0/1 Pause Quanta Register */
 #define ENETC4_PM_PAUSE_QUANTA(mac)	(0x5054 + (mac) * 0x400)
 
@@ -198,6 +201,9 @@
 #define   SSP_1G			2
 #define  PM_IF_MODE_ENA			BIT(15)
 
+/* Port external MDIO Base address, use to access off-chip PHY */
+#define ENETC4_EMDIO_BASE		0x5c00
+
 /**********************ENETC Pseudo MAC port registers************************/
 /* Port pseudo MAC receive octets counter (64-bit) */
 #define ENETC4_PPMROCR			0x5080
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
index 9c634205e2a7..76263b8566bb 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
@@ -176,7 +176,12 @@ static int enetc_mdio_probe(struct enetc_pf *pf, struct device_node *np)
 	bus->parent = dev;
 	mdio_priv = bus->priv;
 	mdio_priv->hw = &pf->si->hw;
-	mdio_priv->mdio_base = ENETC_EMDIO_BASE;
+
+	if (is_enetc_rev1(pf->si))
+		mdio_priv->mdio_base = ENETC_EMDIO_BASE;
+	else
+		mdio_priv->mdio_base = ENETC4_EMDIO_BASE;
+
 	snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
 
 	err = of_mdiobus_register(bus, np);
@@ -221,7 +226,12 @@ static int enetc_imdio_create(struct enetc_pf *pf)
 	bus->phy_mask = ~0;
 	mdio_priv = bus->priv;
 	mdio_priv->hw = &pf->si->hw;
-	mdio_priv->mdio_base = ENETC_PM_IMDIO_BASE;
+
+	if (is_enetc_rev1(pf->si))
+		mdio_priv->mdio_base = ENETC_PM_IMDIO_BASE;
+	else
+		mdio_priv->mdio_base = ENETC4_PM_IMDIO_BASE;
+
 	snprintf(bus->id, MII_BUS_ID_SIZE, "%s-imdio", dev_name(dev));
 
 	err = mdiobus_register(bus);
-- 
2.34.1

Re: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Andrew Lunn]

> Similar to the external MDIO registers, each ENETC has a set of internal
> MDIO registers to access its on-die PHY (PCS), so internal MDIO support
> is also added.

Any reason to not just hard code it to 0?
What is the reset default?

DT describes hardware, not configuration. So getting this from DT
seems wrong.

    Andrew

RE: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Wei Fang]

> > Similar to the external MDIO registers, each ENETC has a set of internal
> > MDIO registers to access its on-die PHY (PCS), so internal MDIO support
> > is also added.
> 
> Any reason to not just hard code it to 0?
> What is the reset default?
> 

For internal MDIO interface, the PHY address is fixed and we do not
get the internal PHY address from the DT. The only part of this patch
set related to internal MDIO is changing the base of the IMDIO register.
See patch 3:

-       mdio_priv->mdio_base = ENETC_PM_IMDIO_BASE;
+
+       if (is_enetc_rev1(pf->si))
+               mdio_priv->mdio_base = ENETC_PM_IMDIO_BASE;
+       else
+               mdio_priv->mdio_base = ENETC4_PM_IMDIO_BASE;

> DT describes hardware, not configuration. So getting this from DT
> seems wrong.
> 

What we get from the DT is the external PHY address, just like the mdio
driver, this external PHY address based on the board, ENETC needs to
know its external PHY address so that its port MIDO can work properly.
So I do not think this is a configuration.

Re: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Andrew Lunn]

> What we get from the DT is the external PHY address, just like the mdio
> driver, this external PHY address based on the board, ENETC needs to
> know its external PHY address so that its port MIDO can work properly.

So i don't get this. MDIO is just a bus, two lines. It can have up to
32 devices on it. The bus master should not need to have any idea what
devices are on it, it just twiddles the lines as requested.

Why does it need to know the external PHY address? In general, the
only thing which needs to know the PHY address is phylib.

	Andrew

RE: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Wei Fang]

> > What we get from the DT is the external PHY address, just like the mdio
> > driver, this external PHY address based on the board, ENETC needs to
> > know its external PHY address so that its port MIDO can work properly.
> 
> So i don't get this. MDIO is just a bus, two lines. It can have up to
> 32 devices on it. The bus master should not need to have any idea what
> devices are on it, it just twiddles the lines as requested.
> 
> Why does it need to know the external PHY address? In general, the
> only thing which needs to know the PHY address is phylib.
> 

From the hardware perspective, NETC IP has only one external master MDIO
interface (eMDIO) for managing external PHYs. The 'EMDIO function' and the
ENETC port MDIO are all virtual ports of the eMDIO.

The difference is that 'EMDIO function' is a 'global port', it can access and
control all the PHYs on the eMDIO, so it provides a means for different
software modules to share a single set of MDIO signals to access their PHYs.

But for ENETC port MDIO, each ENETC can access its set of registers to
initiate accesses on the MDIO and the eMDIO arbitrates between them,
completing one access before proceeding with the next. It is required that
each ENETC port MDIO has exclusive access and control of its PHY. That is
why we need to set the external PHY address for ENETCs, so that its port
MDIO can only access its PHY. If the PHY address accessed by the port
MDIO is different from the preset PHY address, the MDIO access will be
invalid.

Normally, all ENETCs use the interfaces provided by the 'EMDIO function'
to access their PHYs, provided that the ENETC and EMDIO are on the same
OS. If an ENETC is assigned to a guest OS, it will not be able to use the
interfaces provided by EMDIO, so it must uses its port MDIO to access and
manage its PHY.

Re: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Andrew Lunn]

On Sat, Nov 01, 2025 at 12:24:42AM +0000, Wei Fang wrote:
> > > What we get from the DT is the external PHY address, just like the mdio
> > > driver, this external PHY address based on the board, ENETC needs to
> > > know its external PHY address so that its port MIDO can work properly.
> > 
> > So i don't get this. MDIO is just a bus, two lines. It can have up to
> > 32 devices on it. The bus master should not need to have any idea what
> > devices are on it, it just twiddles the lines as requested.
> > 
> > Why does it need to know the external PHY address? In general, the
> > only thing which needs to know the PHY address is phylib.
> > 
> 
> >From the hardware perspective, NETC IP has only one external master MDIO
> interface (eMDIO) for managing external PHYs. The 'EMDIO function' and the
> ENETC port MDIO are all virtual ports of the eMDIO.
> 
> The difference is that 'EMDIO function' is a 'global port', it can access and
> control all the PHYs on the eMDIO, so it provides a means for different
> software modules to share a single set of MDIO signals to access their PHYs.
> 
> But for ENETC port MDIO, each ENETC can access its set of registers to
> initiate accesses on the MDIO and the eMDIO arbitrates between them,
> completing one access before proceeding with the next. It is required that
> each ENETC port MDIO has exclusive access and control of its PHY. That is
> why we need to set the external PHY address for ENETCs, so that its port
> MDIO can only access its PHY. If the PHY address accessed by the port
> MDIO is different from the preset PHY address, the MDIO access will be
> invalid.
> 
> Normally, all ENETCs use the interfaces provided by the 'EMDIO function'
> to access their PHYs, provided that the ENETC and EMDIO are on the same
> OS. If an ENETC is assigned to a guest OS, it will not be able to use the
> interfaces provided by EMDIO, so it must uses its port MDIO to access and
> manage its PHY.

So you have up to 32 virtual MDIO busses stacked on top of one
physical MDIO bus. When creating the virtual MDIO bus, you need to
tell it what address it should allow through and which it should
block?

If what i'm saying is correct, please make the commit message a lot
easier to understand.

But this is still broken. Linux has no restrictions on the number of
PHYs on an MDIO bus. It also does not limit the MDIO bus to only
PHYs. It could be an Ethernet switch on the bus, using a number of
addresses on the bus. So its not an address you need to program into
the virtual MDIO bus, it is a bitmap of addresses.

	Andrew

RE: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Wei Fang]

> > > > What we get from the DT is the external PHY address, just like the mdio
> > > > driver, this external PHY address based on the board, ENETC needs to
> > > > know its external PHY address so that its port MIDO can work properly.
> > >
> > > So i don't get this. MDIO is just a bus, two lines. It can have up to
> > > 32 devices on it. The bus master should not need to have any idea what
> > > devices are on it, it just twiddles the lines as requested.
> > >
> > > Why does it need to know the external PHY address? In general, the
> > > only thing which needs to know the PHY address is phylib.
> > >
> >
> > >From the hardware perspective, NETC IP has only one external master MDIO
> > interface (eMDIO) for managing external PHYs. The 'EMDIO function' and the
> > ENETC port MDIO are all virtual ports of the eMDIO.
> >
> > The difference is that 'EMDIO function' is a 'global port', it can access and
> > control all the PHYs on the eMDIO, so it provides a means for different
> > software modules to share a single set of MDIO signals to access their PHYs.
> >
> > But for ENETC port MDIO, each ENETC can access its set of registers to
> > initiate accesses on the MDIO and the eMDIO arbitrates between them,
> > completing one access before proceeding with the next. It is required that
> > each ENETC port MDIO has exclusive access and control of its PHY. That is
> > why we need to set the external PHY address for ENETCs, so that its port
> > MDIO can only access its PHY. If the PHY address accessed by the port
> > MDIO is different from the preset PHY address, the MDIO access will be
> > invalid.
> >
> > Normally, all ENETCs use the interfaces provided by the 'EMDIO function'
> > to access their PHYs, provided that the ENETC and EMDIO are on the same
> > OS. If an ENETC is assigned to a guest OS, it will not be able to use the
> > interfaces provided by EMDIO, so it must uses its port MDIO to access and
> > manage its PHY.
> 
> So you have up to 32 virtual MDIO busses stacked on top of one

Theoretically, there are up to 33 virtual MDIO buses, 32 port MDIO +
1 'EMDIO function'. The EMDIO function can access all the PHYs on
the physical MDUO bus.

> physical MDIO bus. When creating the virtual MDIO bus, you need to
> tell it what address it should allow through and which it should
> block?
> 

Correct, ENETC can only access its own PHY when using its port MDIO.

> If what i'm saying is correct, please make the commit message a lot
> easier to understand.
> 

Okay, I will improve the commit message.

> But this is still broken. Linux has no restrictions on the number of
> PHYs on an MDIO bus. It also does not limit the MDIO bus to only
> PHYs. It could be an Ethernet switch on the bus, using a number of
> addresses on the bus. So its not an address you need to program into
> the virtual MDIO bus, it is a bitmap of addresses.
> 

No, as I aforementioned, the 'EMDIO function' can access all the PHYs
on the physical MDIO bus, so for a third-party switch, we can use the
EMDIO function to manage all the PHYs of the switch. Of course, this
requires that both the EMDIO function and switch be controlled by the
same OS.

For NETC switch, each switch user port also has its port MDIO, the switch
can use port MDIO or the EMDIO function to manage its PHYs.

Re: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Andrew Lunn]

> > So you have up to 32 virtual MDIO busses stacked on top of one
> 
> Theoretically, there are up to 33 virtual MDIO buses, 32 port MDIO +
> 1 'EMDIO function'. The EMDIO function can access all the PHYs on
> the physical MDIO bus.

The EMDIO function sound dangerous. All the locking and PHY drivers
assume they have exclusive access to a devices on the bus. Bad things
will happen if they don't. And given how infrequently MDIO is
typically used, such bugs are going to be hard to find.

You might want to make the 32 port MDIOs and the EMDIO mutually
exclusive, so you can eliminate those potential bugs.

	   Andrew

RE: [PATCH net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95

[Wei Fang]

> > > So you have up to 32 virtual MDIO busses stacked on top of one
> >
> > Theoretically, there are up to 33 virtual MDIO buses, 32 port MDIO +
> > 1 'EMDIO function'. The EMDIO function can access all the PHYs on
> > the physical MDIO bus.
> 
> The EMDIO function sound dangerous. All the locking and PHY drivers
> assume they have exclusive access to a devices on the bus. Bad things
> will happen if they don't. And given how infrequently MDIO is
> typically used, such bugs are going to be hard to find.
> 
> You might want to make the 32 port MDIOs and the EMDIO mutually
> exclusive, so you can eliminate those potential bugs.
> 

When the PHY node is a child node of the ENETC node, ENETC will use
its port MDIO. When the PHY node is a child node of EMDIO, ENETC
will use EMDIO to access its PHY. Therefore, the DTS configuration
ensures mutual exclusion.