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

[Jonas Gorski]

Hi,

On Thu, Aug 6, 2026 at 9:31 AM Semih Baskan <strst.gs@xxxxxxxxx> wrote:
>
> Since v5.15, a standalone port on a b53 switch cannot receive its own
> tagged traffic: the switch VID lookup is always active, an 8021q
> upper's VID never reaches the VLAN table, and every tagged frame
> resolves to an empty member set and is discarded. The common victim is
> a VLAN-tagged PPPoE WAN, where the PADI goes out and the tagged PADO
> never reaches the CPU.
>
> My first attempt disabled the VLAN table while not filtering:
>
>   https://lore.kernel.org/all/20260805072641.402-1-strst.gs@xxxxxxxxx/
>
> Jonas pointed out that this moves the ARL to shared VLAN learning and
> desynchronizes the hardware table from the bridge fdb, and I withdrew
> it. I then measured the alternatives on an RT-N18U (BCM53011 rev 5),
> with the outbound direction of the same link as a positive control on
> every run:
>
>   - With the table enabled, no ingress VID check setting delivers the
>     frame: VC4_NO_ING_VID_CHK, VC4_ING_VID_VIO_FWD and
>     VC4_ING_VID_VIO_TO_IMP all give 0, and clearing VC0_DROP_VID_MISS
>     changes nothing. The frame does not die at ingress admission, it
>     dies when forwarding resolves the VID against an empty member set.

Note that this is working on switches other than bcm5301x (at least on
bcm63268 and bcm53115), so this seems to be a bcm5301x specific issue.
Unfortunately I do not have a device with such a switch. Though it
only works for standalone ports, it does not allow forwarding between
ports.

Though this isn't the first time a bcm5310x issue showed up with
packets not properly trapped to CPU. Rafal, Florian, did you ever
figure out the issue?

It feels like there is something missing with the CPU port
configuration. Which port are you using as CPU port?

I see several device trees in-tree using port 5, but according to the
register definitions in OpenMDK, the only valid port for both BRCM_HDR
and GLOBAL_CONFIG's FRM_MGMT_PORT is imp0 / port 8 [1].

So I now wonder if using port 5 as CPU port only appears to work (i.e.
enabling the header does), but anything that is supposed to trap to
CPU tries to forward to 8, which is disabled. Or does not forward at
all, because the FRM_MGMT_PORT is configured to an invalid value.

In addition to that, I see that b53_brcm_hdr_setup() does not clear
GC_FRM_MGMT_PORT_M, so if it defaults/was programmed to anything
before, it may become a wrong value.

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

>   - With the table disabled, a static fdb entry with VID 100 is lost
>     from the hardware ARL no matter how the driver drives the ARL
>     registers: keeping ARLTBL_IVL_SVL_SELECT at IVL does not preserve
>     it, and neither does additionally keeping the VID learning bits in
>     VLAN_CTRL0 set.

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 (it also has some additional dependencies
which aren't implemented in b53, so this is essentially dead code).

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

Best regards,
Jonas