From: Frank Li <Frank.li@oss.nxp.com>
To: Claudiu Manoil <claudiu.manoil@nxp.com>
Cc: netdev@vger.kernel.org, s32@nxp.com,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Wei Fang <wei.fang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v1 1/5] net: enetc: Add pseudo-MAC support for ENETCv4 Ports via a DT overlay
Date: Fri, 9 Oct 2026 21:26:09 -0500 [thread overview]
Message-ID: <asmiQded6KfagAcZ@SMW015318> (raw)
In-Reply-To: <5c38f45b9ff1d73c6942d42e23940ecd9ab7b71f.1791548316.git.claudiu.manoil@nxp.com>
On Fri, Oct 09, 2026 at 03:40:30PM +0300, Claudiu Manoil wrote:
> [You don't often get email from claudiu.manoil@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> ENETCv4 has special internal links when connected to the on-chip NETC
> switch via internal switch ports, called pseudo-MAC links. These
> pseudo-MACs are proprietary, they don't implement any standard IEEE
> interface (like MII), and can be modeled as fixed links with the link
> speed determined at boot time by the Port PCR[PSPEED] register
> configuration.
>
> We also need to be able to probe the ENETCv4 Ports featuring pseudo-MACs
> as pure PCI devices, i.e. without any "ethernet" DT node representation.
> The typical use case for this consists in a board with NETC connected
> via PCI to another host which probes the ENETC. Note that in this
> scenario, the pseudo-MAC ENETCs are connected internally to a NETC
> switch that is not owned by Linux.
>
> Since such a port has no "ethernet" DT node, its fixed link has to be
> synthesized at probe time. Rather than hand-building a named software
> node, describe the fixed link with a self-contained device-tree overlay,
> following the approach used by the Microchip lan966x PCI driver. The
> overlay is compiled from enetc4_pseudo_mac.dtso into a .dtbo blob and
> embedded in the driver via the kernel's dtbo wrapping
> (__dtbo_*_begin/_end symbols).
>
> The overlay fragment uses an empty target-path, so it is grafted onto
> the base node passed to of_overlay_fdt_apply(), i.e. the PCI function's
> own dynamic OF node (created by the PCI core when
> CONFIG_PCI_DYNAMIC_OF_NODES is enabled). The fixed-link node is therefore
> spliced directly onto the ENETC netdev's fwnode, exactly as if it had
> come from static DT, and phylink picks it up through dev_fwnode().
>
> The overlay only adds a new fixed-link node; it deliberately does not add
> a phy-mode property. A device-tree overlay may only add new nodes (which
> are tracked with the OF_OVERLAY flag and freed cleanly on removal), not
> new properties onto an already-live node such as the PCI function's
> dynamic OF node. The phy-mode is instead set programmatically by the driver
> (pf->if_mode) before the overlay is applied.
>
> The pseudo-MAC overlay path is selected when the port has no OF node, or
> when it only has the empty PCI-synthesized node (OF_DYNAMIC), which
> carries no fixed-link description. Ports described by static DT take the
> regular of_get_phy_mode() path instead.
>
> The overlay blob is applied unmodified, it only selects fixed-link
> mode and carries the duplex setting; its 'speed' cell is a placeholder.
> The real operating speed is sourced live from PCR[PSPEED] through the
> phylink get_fixed_state callback, which lets the driver override the
> fixed-link state at link time. The overlay is removed on teardown and on
> the probe error unwind.
>
> The driver gains a build dependency on OF_OVERLAY. In addition, the
> node-less pseudo-MAC path has a runtime dependency on
> CONFIG_PCI_DYNAMIC_OF_NODES: that is what makes the PCI core synthesize
> the per-function OF node (of_pci_make_dev_node()) that the overlay is
> applied onto. This is intentionally not a hard Kconfig dependency, since
> the ENETC4 driver also serves regular ports described by static DT; when
> PCI_DYNAMIC_OF_NODES is absent the PCI function has no of_node and the
> pseudo-MAC probe path fails gracefully with a clear -ENODEV error.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
> drivers/net/ethernet/freescale/enetc/Makefile | 1 +
> drivers/net/ethernet/freescale/enetc/enetc.h | 1 +
> .../net/ethernet/freescale/enetc/enetc4_pf.c | 98 +++++++++++++++++--
> .../freescale/enetc/enetc4_pseudo_mac.dtso | 32 ++++++
Not sure why need dt overlay here, there are already dymatic update dts by
of_changeset_* API, like of_changeset_create_node().
Frank
next prev parent reply other threads:[~2026-10-10 2:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 12:40 [PATCH net-next v1 0/5] net: enetc: S32N79 pseudo-MAC (PPM) networking support Claudiu Manoil
2026-10-09 12:40 ` [PATCH net-next v1 1/5] net: enetc: Add pseudo-MAC support for ENETCv4 Ports via a DT overlay Claudiu Manoil
2026-10-10 2:26 ` Frank Li [this message]
2026-10-12 7:37 ` Claudiu Manoil
2026-10-10 12:49 ` sashiko-bot
2026-10-09 12:40 ` [PATCH net-next v1 2/5] net: enetc: Enable probing of version 4.4 devices Claudiu Manoil
2026-10-10 2:01 ` Wei Fang
2026-10-12 7:45 ` Claudiu Manoil
2026-10-13 2:23 ` Wei Fang
2026-10-09 12:40 ` [PATCH net-next v1 3/5] arm64: dts: s32n79: add NETC IEP18 ECAM node for ENETC PPM ports Claudiu Manoil
2026-10-10 12:49 ` sashiko-bot
2026-10-09 12:40 ` [PATCH net-next v1 4/5] arm64: dts: s32n79-rdb: enable NETC IEP18 Claudiu Manoil
2026-10-09 12:40 ` [PATCH net-next v1 5/5] PCI: Create OF node for NXP ENETC pseudo-MAC functions Claudiu Manoil
2026-10-09 15:29 ` Bjorn Helgaas
2026-10-10 12:49 ` sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-10-10 13:13 [PATCH net-next v1 1/5] net: enetc: Add pseudo-MAC support for ENETCv4 Ports via a DT overlay netdev-bot+sashiko
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=asmiQded6KfagAcZ@SMW015318 \
--to=frank.li@oss.nxp.com \
--cc=andrew+netdev@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@kernel.org \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=s32@nxp.com \
--cc=saravanak@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.