public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Emil Schulz Ostergaard <jensemil.schulzostergaard@microchip.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <UNGLinuxDriver@microchip.com>, <andrew@lunn.ch>,
	<olteanv@gmail.com>, <davem@davemloft.net>, <edumazet@google.com>,
	<pabeni@redhat.com>, <horms@kernel.org>, <robh@kernel.org>,
	<krzk+dt@kernel.org>, <conor+dt@kernel.org>,
	<woojung.huh@microchip.com>, <linux@armlinux.org.uk>,
	<Steen.Hegelund@microchip.com>, <daniel.machon@microchip.com>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH net-next v2 8/9] net: dsa: lan9645x: add mdb management
Date: Sun, 5 Apr 2026 23:20:46 +0200	[thread overview]
Message-ID: <041be3126e287a2e7c1b5d05c0f1116c5e4a4095.camel@microchip.com> (raw)
In-Reply-To: <20260329195637.2789256-1-kuba@kernel.org>

On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> Subject: net: dsa: lan9645x: add mdb management
> 
> Add support for dsa mdb callbacks. L2 multicast and IP multicast is
> handled differently. IP multicast stores the port group mask inline in
> the mac table. L2 multicast points to a PGID index, which encodes the
> port group mask.
> 
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c
> > new file mode 100644
> > index 000000000000..4cf92887a4eb
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c
> > @@ -0,0 +1,391 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (C) 2026 Microchip Technology Inc.
> > + */
> > +
> > +#include "lan9645x_main.h"
> 
> [ ... ]
> 
> > +static void lan9645x_mdb_encode_mac(unsigned char *mac,
> > +                                 struct lan9645x_mdb_entry *mdb_entry,
> > +                                 enum macaccess_entry_type type)
> > +{
> > +     ether_addr_copy(mac, mdb_entry->mac);
> > +
> > +     /* The HW encodes the portmask in the high bits of the mac for ip
> > +      * multicast entries, to save on the limited PGID resources.
> > +      *
> > +      * IPv4 Multicast DMAC: 0x01005Exxxxxx
> > +      * IPv6 Multicast DMAC: 0x3333xxxxxxxx
> > +      *
> > +      * which gives us 24 or 16 bits to encode the portmask.
> > +      */
> > +     if (type == ENTRYTYPE_MACV4) {
> > +             mac[0] = 0;
> > +             mac[1] = mdb_entry->ports >> 8;
> > +             mac[2] = mdb_entry->ports & 0xff;
> > +     } else if (type == ENTRYTYPE_MACV6) {
> > +             mac[0] = mdb_entry->ports >> 8;
> > +             mac[1] = mdb_entry->ports & 0xff;
> > +     }
> > +}
> 
> Does this code need to mask out BIT(CPU_PORT) from mdb_entry->ports?
> 
> For L2 multicast, the CPU port is explicitly stripped from the PGID portmask
> to avoid conflicting instructions, since CPU_PORT forwarding is handled by the
> cpu_copy flag. Here, the IP multicast portmask is encoded directly into the
> MAC address using the full mdb_entry->ports. Could this cause hardware to
> receive conflicting instructions (forwarding to port 9 and copying to the CPU
> extraction queue), leading to duplicate multicast packets for the CPU?
> 

No this is fine.

> [ ... ]
> 
> > +static struct lan9645x_pgid_entry *
> > +lan9645x_mdb_pgid_entry_create(struct lan9645x *lan9645x, u16 ports)
> > +{
> > +     struct lan9645x_pgid_entry *pgid_entry = NULL;
> > +     int index;
> > +
> > +     for (index = PGID_GP_START; index < PGID_GP_END; index++) {
> 
> Is it safe to start the search at PGID_GP_START (defined as CPU_PORT)?
> 
> Hardware uses ANA_PGID(DEST_IDX) to forward unicast traffic, and MAC table
> entries for the CPU have DEST_IDX = 9. When the first L2 multicast group is
> added, it appears this loop will allocate PGID index 9, overwriting the
> unicast portmask for the CPU port. Could this cause all unicast traffic
> destined for the CPU to be flooded to the external physical ports in the
> multicast group instead?
> 

No this is safe, PGID 9 is not used to forward anything to the CPU.

> > +             bool used = false;
> > +
> > +             list_for_each_entry(pgid_entry, &lan9645x->pgid_entries, list) {
> > +                     if (pgid_entry->index == index) {
> > +                             used = true;
> > +                             break;
> > +                     }
> > +             }
> > +
> > +             if (!used)
> > +                     return lan9645x_pgid_entry_alloc(lan9645x, index,
> > +                                                      ports);
> > +     }
> > +
> > +     return ERR_PTR(-ENOSPC);
> > +}
> 
> [ ... ]
> 
> > +static int __lan9645x_mdb_add(struct lan9645x *lan9645x, int chip_port,
> > +                           const unsigned char addr[ETH_ALEN], u16 vid,
> > +                           enum macaccess_entry_type type)
> > +{
> > +     struct lan9645x_pgid_entry *old_pgid, *new_pgid;
> > +     struct lan9645x_mdb_entry *mdb_entry;
> > +     unsigned char mac[ETH_ALEN];
> > +     int err, pgid_index;
> > +     bool cpu_copy;
> > +
> > +     mdb_entry = lan9645x_mdb_entry_lookup(lan9645x, addr, vid);
> > +     if (!mdb_entry) {
> > +             mdb_entry = lan9645x_mdb_entry_alloc(lan9645x, addr, vid);
> > +             if (IS_ERR(mdb_entry))
> > +                     return PTR_ERR(mdb_entry);
> > +     }
> > +
> > +     if (mdb_entry->ports & BIT(chip_port))
> > +             return 0;
> > +
> > +     mdb_entry->ports |= BIT(chip_port);
> > +
> > +     /* Encode mac for IP mc */
> > +     lan9645x_mdb_encode_mac(mac, mdb_entry, type);
> > +
> > +     /* Update PGID ptr for non-IP entries (L2 multicast) */
> > +     old_pgid = mdb_entry->pgid;
> > +     new_pgid = lan9645x_mdb_pgid_entry_get(lan9645x, mdb_entry, type);
> > +     if (IS_ERR(new_pgid)) {
> > +             /* Out of PGIDs or mem. Continue forwarding to old port
> > +              * group, or remove if fresh mdb_entry.
> > +              */
> > +             mdb_entry->ports &= ~BIT(chip_port);
> > +             if (!mdb_entry->ports)
> > +                     lan9645x_mdb_entry_dealloc(lan9645x, mdb_entry);
> > +
> > +             return PTR_ERR(new_pgid);
> > +     }
> > +     mdb_entry->pgid = new_pgid;
> > +
> > +     cpu_copy = !!(mdb_entry->ports & BIT(CPU_PORT));
> > +     pgid_index = lan9645x_mdb_pgid_index(mdb_entry, type);
> > +
> > +     /* Make sure to write on top of existing entry, so we do not disrupt
> > +      * flowing traffic.
> > +      */
> > +     err = lan9645x_mact_learn_cpu_copy(lan9645x, pgid_index, mac,
> > +                                        mdb_entry->vid, type, cpu_copy);
> > +     lan9645x_pgid_entry_put(lan9645x, old_pgid);
> > +     return err;
> > +}
> 
> What happens if lan9645x_mact_learn_cpu_copy() fails and returns an error?
> 
> The software MDB state (mdb_entry->ports and mdb_entry->pgid) is updated and
> the old PGID reference is dropped via lan9645x_pgid_entry_put() before
> verifying if the hardware MAC table update succeeds.
> 
> If the hardware update fails, the software state isn't rolled back, leaving
> them out of sync. Furthermore, the dropped old_pgid reference could allow the
> index to be reallocated to a new multicast group while the hardware still
> points to the old PGID index, potentially causing silent traffic cross-talk.
> 


I will change the mac table write error path, so hw/sw stay synced.


> > +
> > +static int __lan9645x_mdb_del(struct lan9645x *lan9645x, int chip_port,
> > +                           const unsigned char addr[ETH_ALEN], u16 vid,
> > +                           enum macaccess_entry_type type)
> > +{
> > +     struct lan9645x_pgid_entry *old_pgid, *new_pgid;
> > +     struct lan9645x_mdb_entry *mdb_entry;
> > +     unsigned char mac[ETH_ALEN];
> > +     int err, pgid_index;
> > +     bool cpu_copy;
> > +
> > +     mdb_entry = lan9645x_mdb_entry_lookup(lan9645x, addr, vid);
> > +     if (!mdb_entry)
> > +             return -ENOENT;
> > +
> > +     if (!(mdb_entry->ports & BIT(chip_port)))
> > +             return 0;
> > +
> > +     mdb_entry->ports &= ~BIT(chip_port);
> > +
> > +     /* Encode mac for IP mc */
> > +     lan9645x_mdb_encode_mac(mac, mdb_entry, type);
> > +
> > +     /* Update PGID ptr for non-IP entries (L2 multicast) */
> > +     old_pgid = mdb_entry->pgid;
> > +     new_pgid = lan9645x_mdb_pgid_entry_get(lan9645x, mdb_entry, type);
> > +     if (IS_ERR(new_pgid)) {
> > +             /* Continue forwarding to old port group. */
> > +             mdb_entry->ports |= BIT(chip_port);
> > +             return PTR_ERR(new_pgid);
> > +     }
> > +     mdb_entry->pgid = new_pgid;
> > +
> > +     if (!mdb_entry->ports) {
> > +             lan9645x_mact_forget(lan9645x, mac, mdb_entry->vid, type);
> > +             lan9645x_pgid_entry_put(lan9645x, old_pgid);
> > +             lan9645x_mdb_entry_dealloc(lan9645x, mdb_entry);
> > +             return 0;
> > +     }
> 
> Similar to the addition path above, if lan9645x_mact_forget() fails, its
> return value is ignored, and the software MDB entry and PGID are freed
> anyway. This could also lead to hardware/software state desynchronization.
> 
> > +
> > +     cpu_copy = !!(mdb_entry->ports & BIT(CPU_PORT));
> > +     pgid_index = lan9645x_mdb_pgid_index(mdb_entry, type);
> > +
> > +     err = lan9645x_mact_learn_cpu_copy(lan9645x, pgid_index, mac,
> > +                                        mdb_entry->vid, type, cpu_copy);
> > +     lan9645x_pgid_entry_put(lan9645x, old_pgid);
> > +     return err;
> > +}


  reply	other threads:[~2026-04-05 21:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 10:46 [PATCH net-next v2 0/9] net: dsa: add DSA support for the LAN9645x switch chip family Jens Emil Schulz Østergaard
2026-03-24 10:46 ` [PATCH net-next v2 1/9] net: dsa: add tag driver for LAN9645X Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-01  7:31     ` Jens Emil Schulz Ostergaard
2026-03-24 10:46 ` [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-01  8:16     ` Jens Emil Schulz Ostergaard
2026-03-24 10:46 ` [PATCH net-next v2 3/9] net: dsa: lan9645x: add autogenerated register macros Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-03-24 10:46 ` [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-01 11:46     ` Jens Emil Schulz Ostergaard
2026-03-24 10:46 ` [PATCH net-next v2 5/9] net: dsa: lan9645x: add bridge support Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-01 12:52     ` Jens Emil Schulz Ostergaard
2026-03-24 10:46 ` [PATCH net-next v2 6/9] net: dsa: lan9645x: add vlan support Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-01 14:44     ` Jens Emil Schulz Ostergaard
2026-03-24 10:46 ` [PATCH net-next v2 7/9] net: dsa: lan9645x: add mac table integration Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-01 15:00     ` Jens Emil Schulz Ostergaard
2026-03-24 10:46 ` [PATCH net-next v2 8/9] net: dsa: lan9645x: add mdb management Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski
2026-04-05 21:20     ` Jens Emil Schulz Ostergaard [this message]
2026-03-24 10:46 ` [PATCH net-next v2 9/9] net: dsa: lan9645x: add port statistics Jens Emil Schulz Østergaard
2026-03-29 19:56   ` Jakub Kicinski

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=041be3126e287a2e7c1b5d05c0f1116c5e4a4095.camel@microchip.com \
    --to=jensemil.schulzostergaard@microchip.com \
    --cc=Steen.Hegelund@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=daniel.machon@microchip.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    --cc=woojung.huh@microchip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox