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 <claudiu.manoil@nxp.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Clark Wang <xiaoning.wang@nxp.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	Aziz Sellami <aziz.sellami@nxp.com>,
	"imx@lists.linux.dev" <imx@lists.linux.dev>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@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 14:15:37 +0100	[thread overview]
Message-ID: <d43743aa-715d-43b3-b00d-96433a85f5fa@lunn.ch> (raw)
In-Reply-To: <PAXPR04MB85106ADEC082E1E8C36DA65188CFA@PAXPR04MB8510.eurprd04.prod.outlook.com>

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

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?

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

	Andrew

  reply	other threads:[~2025-11-11 13:15 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
2025-11-11  5:29   ` Wei Fang
2025-11-11 13:15     ` Andrew Lunn [this message]
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=d43743aa-715d-43b3-b00d-96433a85f5fa@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