From: Simon Horman <horms@kernel.org>
Sent: Monday, November 9, 2026 7:37 PM
To: Claudiu Manoil <claudiu.manoil@nxp.com>
[...]
Subject: Re: [PATCH net-next v3 2/5] net: enetc: Enable probing of version 4.4
devices
On Tue, Nov 03, 2026 at 04:09:08PM +0200, Claudiu Manoil wrote:
quoted
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>
---
v3:
- Added sysclk_freq info for the v4.4 ENETC devices.
v2:
- Described why there are two ENETC PF IDs in the commit message, as per
review.
I realise this was forwarded somewhere by an automation, but it seems not to
the full CC list, so I'm reproducing it here:
commit 6de2e15f2fb313f3ab9a84d0bfd5a867de11c72c
Author: Claudiu Manoil [off-list ref]
net: enetc: Enable probing of version 4.4 devices
This commit adds driver data and platform info entries for ENETC v4.4 PF and
VF devices on S32N79 SoCs with a 500 MHz system clock frequency.
Will add this line to the commit message.
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c
b/drivers/net/ethernet/freescale/enetc/enetc.c
> index c6571b5cc8425..b989823859ff2 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
[...]
Can probing ENETC v4.4 on an 8-core S32N79 SoC overflow priv->int_vector[] in
enetc_int_vector_init()?
I already have a downstream 'fix' for this, where int_vector is allocated dynamically.
I'm going to include it in the v4 patchset. Since this issue only affects the new chip
(S32N79), it's not a 'net' kind of fix.
[...]
Link:
[...]
This does seem to be a legitimate concern to me, and I think it warrants a v4.
There is also a review of patch 1/5, here, which I think warrants investigation too.
Link:
[...]
Thanks for sharing the links, I wasn't aware that Sashiko already scrutinized v3.
Regards
Claudiu