RE: [PATCH v5 net-next 04/15] net: enetc: add basic operations to the FDB table

[Wei Fang <wei.fang@nxp.com>]

> On 4/30/26 4:49 AM, Wei Fang wrote:
> > The FDB table is used for MAC learning lookups and MAC forwarding lookups.
> > Each table entry includes information such as a FID and MAC address that
> > may be unicast or multicast and a forwarding destination field containing
> > a port bitmap identifying the associated port(s) with the MAC address.
> > FDB table entries can be static or dynamic. Static entries are added from
> > software whereby dynamic entries are added either by software or by the
> > hardware as MAC addresses are learned in the datapath.
> >
> > The FDB table can only be managed by the command BD ring using table
> > management protocol version 2.0. Table management command operations
> Add,
> > Delete, Update and Query are supported. And the FDB table supports three
> > access methods: Entry ID, Exact Match Key Element and Search. This patch
> > adds the following basic supports to the FDB table.
> >
> > ntmp_fdbt_update_entry() - update the configuration element data of a
> > specified FDB entry
> >
> > ntmp_fdbt_delete_entry() - delete a specified FDB entry
> >
> > ntmp_fdbt_add_entry() - add an entry into the FDB table
> >
> > ntmp_fdbt_search_port_entry() - Search the FDB entry on the specified
> > port based on RESUME_ENTRY_ID.
> >
> > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > ---
> >  drivers/net/ethernet/freescale/enetc/ntmp.c   | 203
> +++++++++++++++++-
> >  .../ethernet/freescale/enetc/ntmp_private.h   |  61 +++++-
> >  include/linux/fsl/ntmp.h                      |  44 +++-
> >  3 files changed, 305 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c
> b/drivers/net/ethernet/freescale/enetc/ntmp.c
> > index c94a928622fd..4ed8d783a9a2 100644
> > --- a/drivers/net/ethernet/freescale/enetc/ntmp.c
> > +++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
> > @@ -1,7 +1,7 @@
> >  // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> >  /*
> >   * NETC NTMP (NETC Table Management Protocol) 2.0 Library
> > - * Copyright 2025 NXP
> > + * Copyright 2025-2026 NXP
> >   */
> >
> >  #include <linux/dma-mapping.h>
> > @@ -21,11 +21,15 @@
> >  /* Define NTMP Table ID */
> >  #define NTMP_MAFT_ID			1
> >  #define NTMP_RSST_ID			3
> > +#define NTMP_FDBT_ID			15
> >
> >  /* Generic Update Actions for most tables */
> >  #define NTMP_GEN_UA_CFGEU		BIT(0)
> >  #define NTMP_GEN_UA_STSEU		BIT(1)
> >
> > +/* Query Action: 0: Full query, 1: Only query entry ID */
> > +#define NTMP_QA_ENTRY_ID		1
> 
> Sashiko noted that the above comments looks inconsistent with the update
> code, where NTMP_QA_ENTRY_ID apparently uses a full query, and 0 just
> the entry ID.
> 

The definition is correct, 0 indicates a full query, 1 indicates just query the
entry ID. It seems you misunderstood Sashiko's comment. Below is the
comment from Sashiko.

Since this command uses the NTMP_QA_ENTRY_ID ('Only query entry ID') query
action, the hardware returns only a 4-byte entry ID at offset 0. However,
in struct fdbt_resp_query, the entry_id field is located at offset 4,
following the status field.

I would say this is a false positive. Below is the response data structure of a
full query. NTMP_QA_ENTRY_ID does not mean the hardware will return
only a 4-byte entry ID at offset 0, it indicates the fields after entry_id will
not be present in the response data, such as keye, cfge, acte and resv.

struct fdbt_resp_query {
	__le32 status;
	__le32 entry_id;
	struct fdbt_keye_data keye;
	struct fdbt_cfge_data cfge;
	u8 acte;
	u8 resv[3];
};