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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <PAXPR04MB8510284B67712788C5F169F988CDA@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Thu, 13 Nov 2025 01:41:59 +0000
From: Wei Fang <wei.fang@....com>
To: Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>
CC: Claudiu Manoil <claudiu.manoil@....com>, Vladimir Oltean
	<vladimir.oltean@....com>, Clark Wang <xiaoning.wang@....com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>, Aziz Sellami <aziz.sellami@....com>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 net-next 0/3] net: enetc: add port MDIO support for
 both i.MX94 and i.MX95

Hi Andrew,

Do you still have any questions about this series?

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