netdev - RE: [PATCH 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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PAXPR04MB8510D431ACAF445F8E516A0288C7A@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Mon, 3 Nov 2025 02:11:19 +0000
From: Wei Fang <wei.fang@....com>
To: Andrew Lunn <andrew@...n.ch>
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>,
	"kuba@...nel.org" <kuba@...nel.org>, "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 net-next 0/3] net: enetc: add port MDIO support for both
 i.MX94 and i.MX95

> > > > What we get from the DT is the external PHY address, just like the mdio
> > > > driver, this external PHY address based on the board, ENETC needs to
> > > > know its external PHY address so that its port MIDO can work properly.
> > >
> > > So i don't get this. MDIO is just a bus, two lines. It can have up to
> > > 32 devices on it. The bus master should not need to have any idea what
> > > devices are on it, it just twiddles the lines as requested.
> > >
> > > Why does it need to know the external PHY address? In general, the
> > > only thing which needs to know the PHY address is phylib.
> > >
> >
> > >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 and
> > control 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. That is
> > why we need to set the external PHY address for ENETCs, so that its port
> > MDIO can only access its 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 EMDIO, so it must uses its port MDIO to access and
> > manage its PHY.
> 
> So you have up to 32 virtual MDIO busses stacked on top of one

Theoretically, there are up to 33 virtual MDIO buses, 32 port MDIO +
1 'EMDIO function'. The EMDIO function can access all the PHYs on
the physical MDUO bus.

> physical MDIO bus. When creating the virtual MDIO bus, you need to
> tell it what address it should allow through and which it should
> block?
> 

Correct, ENETC can only access its own PHY when using its port MDIO.

> If what i'm saying is correct, please make the commit message a lot
> easier to understand.
> 

Okay, I will improve the commit message.

> But this is still broken. Linux has no restrictions on the number of
> PHYs on an MDIO bus. It also does not limit the MDIO bus to only
> PHYs. It could be an Ethernet switch on the bus, using a number of
> addresses on the bus. So its not an address you need to program into
> the virtual MDIO bus, it is a bitmap of addresses.
> 

No, as I aforementioned, the 'EMDIO function' can access all the PHYs
on the physical MDIO bus, so for a third-party switch, we can use the
EMDIO function to manage all the PHYs of the switch. Of course, this
requires that both the EMDIO function and switch be controlled by the
same OS.

For NETC switch, each switch user port also has its port MDIO, the switch
can use port MDIO or the EMDIO function to manage its PHYs.