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

From: Andrew Lunn
Date: Mon Nov 10 2025 - 22:30:38 EST


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