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
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.
Therefore, we need to set the external PHY address for ENETCs, so that
its port MDIO can only access its own 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 the EMDIO function, so it must uses its port
MDIO to access and manage its PHY.

In DTS, when the PHY node is a child node of EMDIO, ENETC will use EMDIO
to access the PHY. If ENETC wants to use port MDIO, it only needs to add
a mdio child node to the ENETC node.

Different from the external MDIO interface, each ENETC has an internal
MDIO interface for managing on-die PHY (PCS) if it has PCS layer. The
internal MDIO interface is controlled by the internal MDIO registers of
the ENETC port.

---
v2 changes:
Improve the commit message.
v1 link: https://lore.kernel.org/imx/20251030091538.581541-1-wei.fang@nxp.com/
---

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

On Wed, Nov 05, 2025 at 12:33:41PM +0800, Wei Fang wrote:
> >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
> 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.
> Therefore, we need to set the external PHY address for ENETCs, so that
> its port MDIO can only access its own 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 the EMDIO function, so it must uses its port
> MDIO to access and manage its PHY.

I think i'm slowly starting to understand this. But i'm still missing
some parts.

What prevents a guest OS from setting the wrong value in its ENETC
port MDIO and then accessing any PHY on the physical bus?

I assume there is a hypervisor doing this enforcement? But if there is
a hypervisor doing this enforcement, why does the ENETC port MDIO need
programming? The hypervisor will block it from accessing anything it
should not be able to access. A normal MDIO bus scan will find just
the devices it is allowed to access.

I also think the architecture is wrong. Why is the MAC driver messing
around with the ENETC Port MDIO hardware? I assume the ENETC port MDIO
bus driver knows it is a ENETC port MDIO device it is driving? It
should be the one looking at the device tree description of its bus,
checking it has one and only one device described on the bus, and
programming itself with the device the hypervisor will let through.
Not that i think this is actually necessary, let the hypervisor
enforce it...

	Andrew

On Wed,  5 Nov 2025 12:33:41 +0800 Wei Fang wrote:
> v2 changes:
> Improve the commit message.
> v1 link: https://lore.kernel.org/imx/20251030091538.581541-1-wei.fang@nxp.com/

Andrew, is the explanation good enough? 

If the feature is inherently not safe to use with existing Linux
locking scheme we can't support it upstream..

On Mon, Nov 10, 2025 at 06:13:06PM -0800, Jakub Kicinski wrote:
> On Wed,  5 Nov 2025 12:33:41 +0800 Wei Fang wrote:
> > v2 changes:
> > Improve the commit message.
> > v1 link: https://lore.kernel.org/imx/20251030091538.581541-1-wei.fang@nxp.com/
> 
> Andrew, is the explanation good enough? 

Not really. I'm still confused.

Let me ask more questions.

	Andrew