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

[Wei Fang]

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

There is an Integrated Endpoint Register Block (IERB) module inside the
NETC, it is used to set some pre-initialization for ENETC, switch and other
functions. And this module is controlled by the host OS. In IERB, each
ENETC has a corresponding LaBCR register, where
LaBCR[MDIO_PHYAD_PRTAD] represents the address of the external PHY
of that ENETC. If the PHY address accessed by the ENETC using port MDIO
does not match LaBCR[MDIO_PHYAD_PRTAD], the MDIO access is invalid.
Therefore, the Guest OS cannot access the PHY of other ENETCs using
port MDIO.

What patch 1 and patch 2 do is configure LaBCR[MDIO_PHYAD_PRTAD] for
each ENETC.

> 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

The MAC driver (enetc) only simply changes the base address of its port
MDIO registers, see patch 3:

mdio_priv->mdio_base = ENETC4_EMDIO_BASE;

Patch 1 and patch 2 are not changes to the MAC driver, but rather to
the netc-blk-ctrl driver, which manages the IERB module. We need to
program the address of each ENETC's external PHY into this
hypervisor-like module.

> 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