Re: [PATCH net 1/2] net: dsa: let drivers offload 8021q uppers on standalone ports

Hi Jonas,

On Wed, Aug 12, 2026 at 10:24 AM Jonas Gorski <[email protected]> wrote:
> > One observation for the "is there another bit" question: on my
> > BCM53011 the running value of VLAN_CTRL5 is 0x10. That is bit 4, which
> > the driver never writes and has no name for. I do not know what it
> > does, and it may simply be the bootloader default, but it is a bit in
> > exactly the register you are asking about.
>
> Assuming you mean VLAN_CTRL2, this bit is described for BCM5325 as
> "When set to 1, GMRP,GVRP are checked by the
> VLAN's forward map" with a default of 0.

I did mean VLAN_CTRL5; both registers happen to read 0x10 here.
Broadcom's published MDK definitions for BCM53010 [1] name both bits:

VLAN_CTRL5 bit 4 is EGRESS_DIR_FRM_BYPASS_TRUNK_EN, a bypass for
trunking redirection of egress directed frames, unrelated to the miss
path. The same file gives DROP_VTABLE_MISS the exact text you quoted
for the newer chips (drop when set, forward to IMP when clear), and no
other option.

For VLAN_CTRL2, bit 4 is documented as reserved on this chip; the
GMRP/GVRP forward map check you quote from BCM5325 moved to bit 5
(EN_GMRP_GVRP_V_FWDMAP), which reads 0 here. So the set bit is a
reserved default, not the retained BCM5325 function. The remaining
VLAN_CTRL2 fields are GMRP/GVRP untag handling and a v_fwdmap bypass
for the management port, so nothing in it changes ingress
classification.

The same file also names what b53 calls VC0_VID_CHK_EN and
VC0_VID_HASH_VID: one two bit field, VLAN_LEARN_MODE (00 SVL, 11 IVL,
01 and 10 illegal settings). It selects how the ARL is hashed, not
how ingress frames are classified, which explains why clearing those
bits changed nothing in my measurement. (My intermediate test state
cleared only bit 6, which per this description is an illegal encoding;
the legal all clear SVL state behaved identically, so the conclusion
stands.) And the VID to PVID rewrite bits in VLAN_CTRL0 are documented
to act only on frames with VID 0, so on this chip they cannot reclassify
real tagged traffic; that rules out the last candidate for a tag-blind
mode here.

> One thing you could try is to mark all ports as WAN ports. The
> WAN_PORT_SEL register (page 0, offset 0x26, 16 bit) has a bitmask for
> wan ports.

I tried it today, and first read the register as is: WAN_PORT_SEL
reads 0x0000 on my BCM53011, three consistent reads. The kernel
driver never writes it on this generation (it uses offset 0x26 only
on BCM5325, as the protected port register there), so it has been
0x0000 through every measurement I have reported in this thread.

My earlier statement that BPDUs ingressing switch port 0 reach the CPU
was a counter attribution error. That probe read a +7 delta on the wan
netdev counter with no capture running (that image had no tcpdump),
while the BPDU source was a live bridge port on another router, a device
that also chatters IPv6 multicast. Today, with captures bracketing every
counter, BPDU class frames are delivered on none of the ports I probed:
crafted ones on lan2, on lan3 bridged and standalone, and on port 0,
plus real kernel STP hellos on port 0 itself, all zero, while the same
frames with a benign multicast destination deliver 10 of 10 to the CPU
on every port tried. So there is no WAN/LAN asymmetry and no special
port 0: with WAN_SELECT empty, everything trap classed aims at IMP0
exactly as the GMNGCFG text says, and IMP0 is down. Your description of
the port-5-only breakage was right, and it is worse than I previously
reported: STP delivery is dead on the WAN port too, not just the LAN
ports.

Then the experiment you suggested, on the live system, volatile write
with a timed revert armed: WAN_PORT_SEL set to 0x000c, marking the
two ports that had my test endpoints (lan2/port 2, lan3/port 3),
leaving the management port alone.

- No trap rescue appears: BPDUs into a WAN-marked port still deliver
  nothing, so the marking does not retarget the trap path at IMP1 on
  this topology.
- Isolation is exactly as the description implies: unicast between
  the two WAN-marked ports through the same vlan-unaware bridge went
  from 7/7 to 0/7, and even plain multicast to CPU delivery on the
  marked ports went from 10/10 to zero, consistent with "forwarded to
  the CPU port only" resolving to the dead IMP0 here.
- My management connection through a port I had not marked also
  dropped, and came back only when the timed revert fired. The
  effect is broader than the marked ports.

> So it may also isolate them from each other. Also out of curiosity,
> can you wan port talk with non-wan talks in a bridge? Because the
> description implies it should not.

The pair I could measure says no: the two WAN-marked ports in the same
bridge stopped talking to each other entirely, and on this port 5
topology they stopped talking to the CPU too. The BCM53010 text also
says port 5 can be selected as a WAN port only when IMP1 is disabled, so
the CPU port itself cannot be WAN marked on a topology like mine.

[1] https://github.com/Broadcom/OpenMDK/blob/master/cdk/PKG/chip/bcm53010/bcm53010_a0_defs.h

Best regards,
Semih