Re: [PATCH net 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[Semih Baskan]

Hi Jonas,

> If you are using port 5 as CPU port, can you try switching to port 8 / gmac2?

You are right. I tested it today on the RT-N18U and switching the CPU
port to port 8 makes tagged standalone RX work on an unpatched driver,
with nothing in the VLAN table. Details below.

User ports attach to port 5 (gmac0) here, as in every bcm5301x device
tree in-tree. I enabled port@8 (gmac2) as the only CPU port in the dts,
left the driver completely stock, and rebuilt:

  - the board comes up with the whole management path over gmac2, so
    the port 8 to gmac2 path works on BCM47081,
  - the tagged probe that always failed on port 5 delivers 7 of 7
    (outbound positive control 7 of 7, delivery attributed to eth2 by
    interface counters, eth0 stayed at 0),
  - the PPPoE session from the original report establishes.

I also instrumented b53_brcm_hdr_setup() to read back GLOBAL_CONFIG,
and the register documentation in OpenMDK explains the mechanism you
suspected. GMNGCFG.FRM_MNGP on bcm53010 [1]:

  00 = no IMP port
  01 = reserved
  10 = IMP0 only: all traffic to CPU from LAN and WAN ports goes to IMP0
  11 = dual IMP: LAN-port CPU traffic goes to IMP0, WAN-port traffic to
       IMP1, and "In polar, IMP0 is Port 8 and IMP1 is Port 5."

With CPU port 5 the driver ORs GC_FRM_MGMT_PORT_M, which is the field
mask, so the register reads back 0xc2: FRM_MNGP=11, dual IMP. In that
mode the tagged frames reach the CPU on neither IMP: I also tested an
intermediate build with port@8 enabled as a second CPU port while the
user ports stayed on port 5, which is what plain bcm-ns.dtsi describes
since it does not disable port@7/8, and delivery still failed with the
gmac2 counters at zero. With port 8 as the only CPU port the driver
programs 0x82: FRM_MNGP=10, IMP0 only, and delivery works. So your
no-clear observation is correct and the value it produces is worse
than a stale leftover: the port 5 branch cannot program anything
better, because there is no "IMP1 only" encoding, and LAN-class
management traps can never arrive on port 5 on this chip.

One smaller register note: BRCM_HDR_CTRL on bcm53010 does have per-port
bits (bit0 port 8, bit1 port 5, bit2 port 7) [1], so the Broadcom header
itself is valid on port 5. That is why tagging works there at all; the
port-8-only limitation is in the IMP routing, not the header.

A data point that fits the same picture: with CPU on port 5, BPDUs sent
into switch port 0 do reach the CPU. Port 0 is WAN-class in the chip's
management routing, so its traps go to IMP1, port 5. The trap
destination depends on the port class, which is probably why this
half-works and has been so confusing historically.

> ARLTBL_IVL_SVL_SELECT is only implemented on bcm5302x / bcm58xx /
> bcm53134 (and maybe some other newer switches), so no wonder it
> doesn't do anything for you

Thanks, noted. That makes the second measurement stronger rather than
weaker: on this chip there is no knob at all that preserves VID-keyed
ARL entries with the table disabled.

One property of the port 8 setup worth knowing before anyone reads it
as the fix: delivery is indiscriminate. After deleting the 8021q upper
I still see the tagged frames of that VID on the CPU with tcpdump.
Every unknown VID from the wire reaches the CPU, always, which is the
pre-5.15 behavior with its unfiltered nature included. The series
delivers only the VIDs that uppers subscribe, and stops delivering when
they go away.

So as I see it there are two valid fixes on different timescales.
Moving bcm5301x device trees to gmac2 fixes the trap path at the root,
but it changes the conduit for every board, needs per-board validation,
and cannot go to stable. The series fixes the deployed port 5 topology
selectively and is backportable. They do not conflict; the VLAN entries
are correct and harmless under either CPU port. I am happy to help test
a device tree migration on the RT-N18U if you want to pursue that
separately.

Also for completeness: a runtime test of your suggestion via conduit
reassignment is not possible, b53 does not implement
port_change_conduit, so I tested through the device tree.

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

Best regards,
Semih