Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Wei Fang <wei.fang@nxp.com>
Cc: claudiu.manoil@nxp.com, vladimir.oltean@nxp.com,
	xiaoning.wang@nxp.com, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, aziz.sellami@nxp.com, imx@lists.linux.dev,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95
Date: Tue, 11 Nov 2025 04:30:19 +0100	[thread overview]
Message-ID: <4ef9d041-2572-4a8d-9eb8-ddc2c05be102@lunn.ch> (raw)
In-Reply-To: <20251105043344.677592-1-wei.fang@nxp.com>

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

  parent reply	other threads:[~2025-11-11  3:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05  4:33 [PATCH v2 net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95 Wei Fang
2025-11-05  4:33 ` [PATCH v2 net-next 1/3] net: enetc: set external MDIO PHY address for i.MX95 ENETC Wei Fang
2025-11-05  4:33 ` [PATCH v2 net-next 2/3] net: enetc: set external MDIO PHY address for i.MX94 ENETC Wei Fang
2025-11-05  4:33 ` [PATCH v2 net-next 3/3] net: enetc: add port MDIO support for ENETC v4 Wei Fang
2025-11-11  2:13 ` [PATCH v2 net-next 0/3] net: enetc: add port MDIO support for both i.MX94 and i.MX95 Jakub Kicinski
2025-11-11  3:06   ` Andrew Lunn
2025-11-11  3:30 ` Andrew Lunn [this message]
2025-11-11  5:29   ` Wei Fang
2025-11-11 13:15     ` Andrew Lunn
2025-11-11 14:20       ` Wei Fang
2025-11-13  1:41         ` Wei Fang
2025-11-18  2:19 ` Wei Fang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ef9d041-2572-4a8d-9eb8-ddc2c05be102@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=andrew+netdev@lunn.ch \
    --cc=aziz.sellami@nxp.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=imx@lists.linux.dev \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=wei.fang@nxp.com \
    --cc=xiaoning.wang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox