dpaa2-eth registers every DPNI as a physical devlink port without a
port number, so all the DPAA2 interfaces report the same
phys_port_name "p0", including the DPNIs that have no DPMAC behind
them.

Patch 1 uses the DPMAC id as the physical port number. The attributes
of a registered devlink port cannot change, so when the DPNI endpoint
changes at runtime a warning says the number is stale until the DPNI
is rebound.

Patch 2 registers the DPNIs without a DPMAC as virtual ports. They
have no phys_port_name, so "p<dpmac id>" is unique.

With both patches, udev can name an interface using its DPMAC, for
instance:

  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="fsl_dpaa2_eth", \
    ATTR{phys_port_name}=="p3", NAME="dpmac3"

Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
Vincent Jardin (2):
      dpaa2-eth: use the DPMAC id as the devlink physical port number
      dpaa2-eth: DPNIs without a DPMAC should be virtual devlink ports

 .../ethernet/freescale/dpaa2/dpaa2-eth-devlink.c   | 35 +++++++++++++++++++++-
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c   |  2 ++
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h   |  1 +
 3 files changed, 37 insertions(+), 1 deletion(-)
---
base-commit: 944ae66642b726bd6b25ae71b1e9ff88a0e0bdb0
change-id: 20260923-for-upstream-dpaa2_ports-04087b33bb8f

Best regards,
-- 
Vincent Jardin <vjardin@free.fr>

On Wed, Sep 23, 2026 at 02:57:59PM +0200, Vincent Jardin via B4 Relay wrote:
> dpaa2-eth registers every DPNI as a physical devlink port without a
> port number, so all the DPAA2 interfaces report the same
> phys_port_name "p0", including the DPNIs that have no DPMAC behind
> them.
> 
> Patch 1 uses the DPMAC id as the physical port number. The attributes
> of a registered devlink port cannot change, so when the DPNI endpoint
> changes at runtime a warning says the number is stale until the DPNI
> is rebound.
> 
> Patch 2 registers the DPNIs without a DPMAC as virtual ports. They
> have no phys_port_name, so "p<dpmac id>" is unique.
> 
> With both patches, udev can name an interface using its DPMAC, for
> instance:
> 
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="fsl_dpaa2_eth", \
>     ATTR{phys_port_name}=="p3", NAME="dpmac3"

Is consistent naming the end goal? Because renaming can already be done
for DPAA2 network interfaces based on the of_node. I usually have
something like below in my udev rules file:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="fsl_dpaa2_eth", \
	ENV{OF_FULLNAME}=="/soc/fsl-mc@80c000000/dpmacs/ethernet@1", NAME="endpmac1"

Anyhow, I will give the series a spin tomorrow.

Ioana

Hi Ioana,

> Is consistent naming the end goal? Because renaming can already be done
> for DPAA2 network interfaces based on the of_node. I usually have
> something like below in my udev rules file:
> 
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="fsl_dpaa2_eth", \
> 	ENV{OF_FULLNAME}=="/soc/fsl-mc@80c000000/dpmacs/ethernet@1", NAME="endpmac1"

It was the root of my initial investigation, but I need more:
  - I need to have an attribute that I can use from the userland to name and
    rename many times, so in between it I would need something to rely with
  - cosmetic: just have a propver devlink

> Anyhow, I will give the series a spin tomorrow.

Thanks: it should not hurt, and devlink should be more coherent then.

best regards,
  Vincent