> Went through the patch:
> 
> Per-port UPDMEM slots referenced from the FOE and programmed
> through the notifier look correct; the slot range fits the 4-bit UPDMEM
> address and the 5-bit smac_id field, stays clear of the GDM port ids,
> and would only reach 0xf (the "keep original source MAC" marker) for
> an 8-port switch, which this SoC does not have.

do you have any chance to test it with offloading? I can't do it at the moment.

> 
> For the non-DSA variants, in our setup several service VLANs
> (voip/iptv/tr069/internet) are stacked on a single GDM port, each with
> its own MAC address. VLAN devices are visible neither to the notifier
> nor to airoha_set_macaddr(), and foe_entry_prepare() still collapses
> them to smac_id = port->id, so all of them would egress with the port
> base MAC. The two-airoha,eth-port multi-SerDES variant shares the same
> gap.

I guess you can modify the airoha_eth_even() logic in order to look at vlan too
but you need to implement the proper logic for the smac_id hw space.

Regards,
Lorenzo

> 
> What the VLAN case needs is the same identity-scoped treatment for
> these devices: a slot allocated per egress identity, programmed on
> their address events and referenced per flow instead of per port.
> 
> Lorenzo Bianconi <lorenzo@kernel.org> 于2026年10月14日周三 04:41写道：
> >
> > On Oct 14, 陈耀明 wrote:
> > > Yes, your analysis is correct: with the patch, the flow offloaded at t1
> > > reprograms the shared UPDMEM entry, so the flow egressing port0 starts
> > > using port1's L2 address. Our setup happens to carry a single IPv6
> > > identity per GDM port (the other services are IPv4), which is why the
> > > patch holds there -- it is a stopgap for that topology, as noted.
> > >
> > > On the second question: in the default DSA configuration user ports
> > > inherit the conduit address, so the conduit MAC as source is
> > > indistinguishable from the user port's own. It diverges once user ports
> > > carry their own addresses (nvmem-assigned or user-configured): the
> > > egress frame then differs from what the software path would emit, and
> > > upstream bridges learn the conduit MAC behind a user port. Whether that
> > > is a bug or a corner case is your call; per-netdev slots would cover
> > > either way.
> >
> > I have not tested it yet, but can you please check if the patch available at
> > [0] fixes the reported issue? Thanks.
> >
> > Regards,
> > Lorenzo
> >
> > [0] https://github.com/LorenzoBianconi/net-next/commit/486a5f13c62985d4333a231cc9aaec714e81fcd2
> >
> > >
> > > Lorenzo Bianconi <lorenzo@kernel.org> 于2026年10月13日周二 23:54写道：
> > > >
> > > > > The issue is reproducible in the upstream codebase, without any of the
> > > > > out-of-tree PON code -- the PON setup is just where I first hit it.
> > > > >
> > > > > Reproduction with mainline code only (airoha eth + the mt7530 MMIO DSA
> > > > > driver; the "airoha,en7581-switch" binding and driver are mainline,
> > > > > the DT node just needs to be added to a board file):
> > > > >
> > > > > - AN7581 board, switch node with its CPU port on GDM1. Use a DSA user
> > > > >   port as a routed WAN interface with its own MAC address.
> > > > >
> > > > > airoha_get_dsa_port() replaces the egress netdev with the conduit, so
> > > > > routed IPv6 FOE entries carry smac_id = conduit port id, and the PPE
> > > > > resolves the egress source MAC through UPDMEM[conduit]. That slot is
> > > > > only programmed by airoha_set_macaddr(), which never runs when a DSA
> > > > > slave address changes, so offloaded IPv6 frames leave the port with
> > > > > the conduit's MAC instead of the user port's. IPv4 is unaffected,
> > > > > since HNAPT entries store the MACs inline. The same shape appears on a
> > > > > GDM port with two "airoha,eth-port" children carrying different MAC
> > > > > LSBs, which the recent multi-SerDES series allows by design
> > > > > (REG_FE_MAC_LMIN/LMAX); for that variant the exposure starts with the
> > > > > series introducing multiple net_devices per GDM port.
> > > > >
> > > > > The posted patch only reprograms the shared per-port slot at offload
> > > > > time, so a later address change on any netdev of that port re-breaks
> > > > > offloaded IPv6 flows. It is a temporary patch for this setup; the
> > > > > final solution is up to the maintainers.
> > > >
> > > > I do not think the case you described is fixed with your patch. Let's consider
> > > > the following case:
> > > >
> > > > - time t0: you offload a flow rule for traffic egressing dsa port0
> > > > - time t1: you offload a flow rule for traffic egressing dsa port1
> > > >
> > > > Since the index written in REG_UPDMEM_CTRL() subfield is still the conduit port
> > > > ID, you are egressing traffic from port0 with L2 address of port1. Am I right,
> > > > or am I missing something?
> > > > Moreover, is it a bug if we use the conduit port L2 address as source mac
> > > > address for IPv6 traffic?
> > > >
> > > > Regards,
> > > > Lorenzo
> > > >
> > > > >
> > > > > A proper fix would probably give each netdev its own UPDMEM entry: the
> > > > > table is indexed by a 4-bit address (16 entries) while the FOE
> > > > > smac_id field is 5-bit with 0xf reserved for "keep original MAC", so
> > > > > there is room beyond the port ids. Slots could be programmed from
> > > > > airoha_set_macaddr() (always under RTNL, as you noted) plus a
> > > > > netdevice notifier for DSA slaves, and foe_entry_prepare() would only
> > > > > reference the slot -- removing both the race and the extra locking the
> > > > > current approach needs.
> > > > >
> > > > > Lorenzo Bianconi <lorenzo@kernel.org> 于2026年10月13日周二 15:36写道：
> > > > > >
> > > > > > > Ooo,  the new patch should be a dedicated leaf lock inside
> > > > > > > airoha_ppe_init_upd_mem().
> > > > > > > --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> > > > > > > +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> > > > > > > @@ -416,6 +416,19 @@
> > > > > > >    dsa_port);
> > > > > > >
> > > > > > >   smac_id = port->id;
> > > > > > > + /*
> > > > > > > + * Routed IPv6 entries resolve the egress source MAC
> > > > > > > + * through the UPDMEM table indexed by smac_id. The
> > > > > > > + * egress netdev can legally carry a different address
> > > > > > > + * than the GDM port itself: on PON setups the
> > > > > > > + * authentication MAC lives on the pon device while
> > > > > > > + * each service VLAN routes with its own address. Keep
> > > > > > > + * the table entry in sync with the source address this
> > > > > > > + * flow is actually going to use.
> > > > > >
> > > > > > Is the issue occurring just with PON or are you able to trigger the issue
> > > > > even
> > > > > > in the upstream codebase? I guess you should not post a fix for some code
> > > > > that
> > > > > > is not upstream yet. Moreover, in the PON setup, I guess the approach is
> > > > > still
> > > > > > broken if the user change the device mac address.
> > > > > >
> > > > > > > + */
> > > > > > > + if (type >= PPE_PKT_TYPE_IPV6_ROUTE_3T)
> > > > > > > + airoha_ppe_init_upd_mem(dev,
> > > > > > > + data->eth.h_source);
> > > > > > >   }
> > > > > > >   }
> > > > > > >
> > > > > > > @@ -1529,10 +1542,21 @@
> > > > > > >
> > > > > > >  void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev, const u8
> > > > > *addr)
> > > > > > >  {
> > > > > > > + static DEFINE_MUTEX(updmem_lock);
> > > > > > > +
> > > > > > >   struct airoha_gdm_port *port = dev->port;
> > > > > > >   struct airoha_eth *eth = dev->eth;
> > > > > > >   u32 val;
> > > > > > >
> > > > > > > + /*
> > > > > > > + * Routed IPv6 entries resolve the egress source MAC through the
> > > > > > > + * UPDMEM table indexed by smac_id; the ndo_open/ndo_set_mac_address
> > > > > > > + * writers hold flow_offload_mutex (QoS paths re-lock via
> > > > > > > + * airoha_set_macaddr()), so this lock also serializes the leaf
> > > > > > > + * against them.
> > > > > > > + */
> > > > > > > + mutex_lock(&updmem_lock);
> > > > > >
> > > > > > This is only required adding the above configuration since in the current
> > > > > > codebase airoha_ppe_init_upd_mem() is always running holding RTNL.
> > > > > >
> > > > > > Regards,
> > > > > > Lorenzo
> > > > > >
> > > > > > > +
> > > > > > >   val = (addr[2] << 24) | (addr[3] << 16) | (addr[4] << 8) | addr[5];
> > > > > > >   airoha_fe_wr(eth, REG_UPDMEM_DATA(0), val);
> > > > > > >   airoha_fe_wr(eth, REG_UPDMEM_CTRL(0),
> > > > > > > @@ -1545,6 +1569,8 @@
> > > > > > >       FIELD_PREP(PPE_UPDMEM_ADDR_MASK, port->id) |
> > > > > > >       FIELD_PREP(PPE_UPDMEM_OFFSET_MASK, 1) |
> > > > > > >       PPE_UPDMEM_WR_MASK | PPE_UPDMEM_REQ_MASK);
> > > > > > > +
> > > > > > > + mutex_unlock(&updmem_lock);
> > > > > > >  }
> > > > > > >
> > > > > > >  struct airoha_ppe_dev *airoha_ppe_get_dev(struct device *dev)