Re: [PATCH net-next v2 2/5] net: enetc: Enable probing of version 4.4 devices

Re: [PATCH net-next v2 2/5] net: enetc: Enable probing of version 4.4 devices

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The patch enables ENETC v4.4 (S32N79) by adding ENETC_REV_4_4
  entries to enetc_info[], including { ENETC_REV_4_4,…

--

net: enetc: Enable probing of version 4.4 devices

This commit adds the ENETC_REV_4_4 revision define. It also adds
enetc_info[] entries for v4.4 devices, as found on S32N79 SoCs. Both PF
device IDs (0xe101 and 0xe110) map to enetc4_ppm_data, and the 0xef00
VF ID maps to enetc4_vf_data.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
> index c6571b5cc8425..be7795d4e0c66 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> @@ -3862,6 +3862,18 @@ static const struct enetc_platform_info enetc_info[] = {

[ ... ]

> +	{ .revision = ENETC_REV_4_4,
> +	  .dev_id = NXP_ENETC_VF_DEV_ID,
> +	  .data = &enetc4_vf_data,
> +	},
>  };

[Severity: Medium]
With this entry, v4.4 VFs probe with enetc4_vf_data and get
enetc_vf_ethtool_ops, which sets .get_ts_info = enetc_get_ts_info. Was the
second revision-keyed table in enetc_get_phc_index_by_pdev() in
enetc_ethtool.c meant to be updated as well? It only knows about the older
revisions:

drivers/net/ethernet/freescale/enetc/enetc_ethtool.c:enetc_get_phc_index_by_pdev() {
    ...
	switch (si->revision) {
	case ENETC_REV_1_0:
		devfn = PCI_DEVFN(0, 4);
		break;
	case ENETC_REV_4_1:
		devfn = PCI_DEVFN(24, 0);
		break;
	case ENETC_REV_4_3:
		devfn = PCI_DEVFN(0, 1);
		break;
	default:
		return -1;
	}
    ...
}

On a v4.4 VF, enetc_vf_get_revision() computes si->revision as
(pdev->revision << 8) | ip_mn, which gives 0x0404. VFs have no OF node,
since the PCI fixup in this series only covers 0xe101/0xe110. So
enetc_get_phc_index() always falls back to the by-pdev lookup:

enetc_get_ts_info()
  enetc_get_phc_index()
    if (!np) return enetc_get_phc_index_by_pdev(si);
      default: return -1;
  goto timestamp_tx_sw;

As a result, ethtool -T on a v4.4 VF reports only
SOF_TIMESTAMPING_TX_SOFTWARE and no PHC, even with CONFIG_PTP_NETC_V4_TIMER
enabled.

enetc_hwtstamp_set() is gated only by enetc_ptp_clock_is_enabled():

	if (!enetc_ptp_clock_is_enabled(priv->si))
		return -EOPNOTSUPP;

So it still enables ENETC_F_TX_TSTAMP / ENETC_F_RX_TSTAMP on the same VF.
That leaves ethtool and the hwtstamp path disagreeing, and PTP userspace
has no PHC to pair with the hardware timestamps.

When REV_4_1 and REV_4_3 were enabled, each got a timer devfn in this
switch. Does the S32N79 NETC timer sit on the same PCI bus as the ENETC
functions?

If it does, should a REV_4_4 case with the right devfn be added here? If
it doesn't, should hardware timestamping be refused for v4.4 VFs, so that
ndo_hwtstamp_set and get_ts_info report the same thing?

The PFs use enetc4_ppm_data and enetc4_ppm_ethtool_ops, which have no
.get_ts_info, so the ethtool half of this does not apply to them.

>  
>  int enetc_get_driver_data(struct enetc_si *si)

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1791908694.git.claudiu.manoil%40nxp.com

[PATCH net-next v2 0/5] net: enetc: S32N79 pseudo-MAC (PPM) networking support

[Claudiu Manoil]

This series adds networking support for the ENETCv4.4 pseudo-MAC (PPM)
ports found on the NXP S32N79 SoC. On S32N79, the ENETCv4 ports are
not wired to any external PHY/MII; instead they are internal "pseudo-MAC"
links into the on-chip NETC switch. These links are proprietary, expose
no standard IEEE interface, and run at a speed fixed at boot time by the
Port PCR[PSPEED] register.

A key use case is a port that has no "ethernet" DT node at all: NETC is
reached over PCI from a host that probes the ENETC, while the internal
NETC switch it connects to is not owned by Linux. Such a port must have
its fixed link synthesized at probe time.

The driver synthesizes the fixed link directly in C using an of_changeset:
of_changeset_create_node() adds a "fixed-link" subnode onto the PCI
function's dynamic OF node (CONFIG_PCI_DYNAMIC_OF_NODES), with the "speed"
property read from PCR[PSPEED] at probe time and "full-duplex" set.
phylink then picks up the fixed-link node through dev_fwnode().

The series touches three subsystems:
  - net/enetc:  pseudo-MAC fixed-link support + probing of 4.4 devices
  - arm64 dts:  NETC IEP18 ECAM node on S32N79 and its RDB board enable
  - PCI:        a quirk creating the OF node for the ENETC PMAC functions

Because this is primarily a networking feature and the pieces are
interdependent at runtime, it would be most convenient to merge the
whole series through the netdev tree.

Patch 1 has a runtime (not Kconfig) dependency on
CONFIG_PCI_DYNAMIC_OF_NODES; absent that, the pseudo-MAC probe path
fails gracefully with -ENODEV.

v2:
 - Switched patch 1 from a DT overlay blob (of_overlay_fdt_apply() + a
   .dtso compiled to .dtbo) to of_changeset_create_node(), per review
   feedback. This drops the embedded overlay externs, the Makefile
   .dtbo wrapping, and the OF_OVERLAY Kconfig dependency. The operating
   speed is now baked directly into the changeset-created fixed-link
   node (read once from PCR[PSPEED] at probe time); the phylink
   get_fixed_state callback is no longer needed and was removed.
 - Patch 2: described why there are two ENETC PF IDs in the commit
   message, as per review.
 - Patch 3: replaced the 'msi-parent' stub property with 'msi-map', as
   per H/W spec.
 - Patch 5: reworded the commit message to match patch 1's fixed-link
   approach (no functional change); added Bjorn's Acked-by.
v1: initial submission.

Claudiu Manoil (5):
  net: enetc: Add pseudo-MAC support for ENETCv4 Ports via a fixed-link
    node
  net: enetc: Enable probing of version 4.4 devices
  arm64: dts: s32n79: add NETC IEP18 ECAM node for ENETC PPM ports
  arm64: dts: s32n79-rdb: enable NETC IEP18
  PCI: Create OF node for NXP ENETC pseudo-MAC functions

 arch/arm64/boot/dts/freescale/s32n79-rdb.dts  |   4 +
 arch/arm64/boot/dts/freescale/s32n79.dtsi     |  24 ++++
 drivers/net/ethernet/freescale/enetc/enetc.c  |  12 ++
 drivers/net/ethernet/freescale/enetc/enetc.h  |   1 +
 .../net/ethernet/freescale/enetc/enetc4_pf.c  | 113 +++++++++++++++++-
 .../net/ethernet/freescale/enetc/enetc_hw.h   |   1 +
 .../freescale/enetc/enetc_pf_common.c         |  41 ++++++-
 .../freescale/enetc/enetc_pf_common.h         |   1 +
 drivers/pci/quirks.c                          |   2 +
 9 files changed, 190 insertions(+), 9 deletions(-)

-- 
2.34.1

[PATCH net-next v2 2/5] net: enetc: Enable probing of version 4.4 devices

[Claudiu Manoil]

The ENETC v4.4 devices are present on S32N79 SoCs and feature only
Pseudo-MAC ENETC ports, whose PFs use either the 0xe101 or the 0xe110
PCI device ID, and the VFs answer to the usual device ID of 0xef00.

While the ENETC PF instances are usually designated by the 0xe101 ID,
in newer IP versions the 0xe110 ID was introduced to indicate the
power-on reset default NETC switch management interface. These IDs
do not indicate any functional difference between the designated
ENETC instances, and can be interchanged and re-assigned at boot time
(i.e. from firmware).

Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2:
 - Described why there are two ENETC PF IDs in the commit message, as per
   review.

 drivers/net/ethernet/freescale/enetc/enetc.c    | 12 ++++++++++++
 drivers/net/ethernet/freescale/enetc/enetc_hw.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index c6571b5cc842..be7795d4e0c6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -3862,6 +3862,18 @@ static const struct enetc_platform_info enetc_info[] = {
 	  .dev_id = NXP_ENETC_VF_DEV_ID,
 	  .data = &enetc4_vf_data,
 	},
+	{ .revision = ENETC_REV_4_4,
+	  .dev_id = NXP_ENETC_PPM_DEV_ID,
+	  .data = &enetc4_ppm_data,
+	},
+	{ .revision = ENETC_REV_4_4,
+	  .dev_id = NXP_ENETC_PF_DEV_ID,
+	  .data = &enetc4_ppm_data,
+	},
+	{ .revision = ENETC_REV_4_4,
+	  .dev_id = NXP_ENETC_VF_DEV_ID,
+	  .data = &enetc4_vf_data,
+	},
 };
 
 int enetc_get_driver_data(struct enetc_si *si)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 2c9d9042eb0b..64789bd0f33e 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -414,6 +414,7 @@ enum enetc_bdr_type {TX, RX};
 #define ENETC_REV_1_0		0x0100
 #define ENETC_REV_4_1		0X0401
 #define ENETC_REV_4_3		0x0403
+#define ENETC_REV_4_4		0x0404
 
 #define ENETC_G_EIPBRR1		0x0bfc
 #define ENETC_G_EPFBLPR(n)	(0xd00 + 4 * (n))
-- 
2.34.1

RE: [PATCH net-next v2 2/5] net: enetc: Enable probing of version 4.4 devices

[Wei Fang]

> +	{ .revision = ENETC_REV_4_4,
> +	  .dev_id = NXP_ENETC_PPM_DEV_ID,
> +	  .data = &enetc4_ppm_data,
> +	},

You have reused driver data of the i.MX94, which has a system clock
frequency of 333 MHz. However, for the S32N7, I think its system
clock frequency to be 500 MHz. And the system clock frequency is
used for DIM. Therefore, you'd better to add the new driver data
for S32N7.

> +	{ .revision = ENETC_REV_4_4,
> +	  .dev_id = NXP_ENETC_PF_DEV_ID,
> +	  .data = &enetc4_ppm_data,
> +	},
> +	{ .revision = ENETC_REV_4_4,
> +	  .dev_id = NXP_ENETC_VF_DEV_ID,
> +	  .data = &enetc4_vf_data,
> +	},
>  };
> 
>  int enetc_get_driver_data(struct enetc_si *si)
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> index 2c9d9042eb0b..64789bd0f33e 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> @@ -414,6 +414,7 @@ enum enetc_bdr_type {TX, RX};
>  #define ENETC_REV_1_0		0x0100
>  #define ENETC_REV_4_1		0X0401
>  #define ENETC_REV_4_3		0x0403
> +#define ENETC_REV_4_4		0x0404
> 
>  #define ENETC_G_EIPBRR1		0x0bfc
>  #define ENETC_G_EPFBLPR(n)	(0xd00 + 4 * (n))
> --
> 2.34.1

RE: [PATCH net-next v2 2/5] net: enetc: Enable probing of version 4.4 devices

[Claudiu Manoil]

NXP Confidential
> From: Wei Fang <wei.fang@nxp.com>
> Sent: Thursday, October 15, 2026 4:42 AM
[...]
> Subject: RE: [PATCH net-next v2 2/5] net: enetc: Enable probing of version 4.4
> devices
>
> > +   { .revision = ENETC_REV_4_4,
> > +     .dev_id = NXP_ENETC_PPM_DEV_ID,
> > +     .data = &enetc4_ppm_data,
> > +   },
>
> You have reused driver data of the i.MX94, which has a system clock
> frequency of 333 MHz. However, for the S32N7, I think its system
> clock frequency to be 500 MHz. And the system clock frequency is
> used for DIM. Therefore, you'd better to add the new driver data
> for S32N7.
>

Ok, wanted to deal with the NETC frequency of S32N79 later, but I'll
look into adding this info in v3.  This is not a functional issue, the driver
still works with the 'old' frequency, but it may affect indeed the performance
of interrupt coalescing.