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

[Wei Fang]

> > 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.
> 
> And this is done by the host OS. The guest OS has no access to this
> register?
> 

Yes, the IERB block is only assigned to the host OS, guest OS cannot
access it. And IERB registers cannot be set at run time, because the
block will be locked after the pre-initialization, unlock it will cause
the entire NETC being reset.

> The host OS is using DT, following the phandle from the MAC to the PHY
> to find the address of the PHY. So is the MAC and PHY also probed in
> the host OS, because it is listed in DT? When the guest OS is
> provisioned, is the host driver of the MAC and PHY unbound? A DT blob
> for the guest is constructed from the host DT blob, taking out all the
> parts the guest is not allowed to access?
> 

For Harpoon (running RTOS on cortex-a using jailhouse), we use specific
device trees for the host OS where we disable the devices owned by the
inmates, so host OS does not probe the ENETC and the PHY driver. The
inmate uses a separate DTS, which contains only the hardware resources
allocated to it.

> > > 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;
> 
> And i assume the hypervisor like block is limiting the guest to only
> access this MDIO bus?

Yes, the guest can only use this MDIO bus to access the external PHY.

> But why do this here? The DT blob passed to the
> guest should have the correct base address, so when it probes the MDIO
> bus it should already have the correct address?

These port MDIO registers are ENETC's own registers used for MDIO
access. See enetc_mdio_rd() and enetc_mdio_wr() in
drivers/net/ethernet/freescale/enetc/enetc_mdio.c for more details.

They are used to set the PHY address that the MDIO bus needs to
access, the MDIO format (C22 or C45), and the PHY register value
​​that needs to be set. They just like the FEC_MII_DATA register in the
FEC driver. There is no need to add such a base address to the DT.

BTW, the port MDIO bus has already been supported in the enetc
driver since LS1028A, the difference is that the base address is
changed on ENETC v4, so we need to correct the base address for
ENETC v4.