Since v5.15, a standalone port on a bcm5301x 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 a tagged frame with a
missing VID is forwarded only toward the IMP0 management port, which the
in-tree bcm5301x topology leaves disabled, so it never reaches the CPU.
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@gmail.com/

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 the miss control bit
    VC5_DROP_VTABLE_MISS already sits in its non-drop state, whose only
    delivery target is the disabled IMP0. The frame does not die at
    ingress admission, it dies on the miss path behind it.
  - 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.
  - The VID to PVID rewrite bit (CHANGE_1Q_VID) does deliver such a
    frame, but only by rewriting the VID to the PVID, which destroys the
    VID the upper is keyed on.

So on this hardware, delivering the frame and keeping VID-keyed ARL
entries are mutually exclusive unless the VID is in the table. This
series therefore programs the table, narrowed to what is actually
needed: a standalone port only needs the VIDs its 8021q uppers use,
which is one table write per upper instead of entries for all 4096
VIDs.

I looked for a fix inside b53 first. The one existing way to have the
upper VIDs delivered to the driver, ds->needs_standalone_vlan_filtering,
does not work here. It was measured insufficient, because f089652b6b16
makes .port_vlan_add skip the hardware write while not filtering, and
its other effect is one b53 cannot take: with vlan_filtering_is_global,
the forced vlan_filtering=1 in dsa_port_reset_vlan_filtering() would
flip the whole switch into VLAN filtering when any port leaves a
VLAN-unaware bridge. hellcreek relies on exactly those semantics, so
patch 1 adds a narrower opt-in that only delivers the VIDs and leaves
vlan_filtering alone, and patch 2 uses it in b53 and programs entries
that carry standalone members, masked so bridge VLANs stay without
effect while not filtering.

Tested on the RT-N18U: the standalone upper receives 7 of 7 probe frames
with vlan_filtering staying 0, the static fdb entry with a VID now
survives a vlan_filtering toggle since the table enable and the ARL mode
are never touched, uppers keep working across bridge join and leave and
across a vlan_filtering toggle including on ports that were bridged
while the toggle happened, deleting an upper or bridging its port
verifiably stops delivery of that VID to the CPU, and the PPPoE session
establishes. 802.1ad uppers keep working as software VLANs, since this
switch does not parse 0x88a8, and stacked QinQ over an offloaded upper
works too.

Changes in v3:
 - patch 2: BCM5325 and BCM5365 are left out of the opt-in, which now
   gets set after chip detection. Both forward a VLAN table miss, so
   their standalone uppers already work, and their tables hold only 16
   and 256 entries, so v2 made b53_vlan_prepare() refuse an upper whose
   VID lies beyond the table. The message no longer claims such uppers
   fail loudly.
 - patch 1: unchanged.

Changes in v2:
 - patch 1's commit message rewritten after Vladimir Oltean's review.
 - the delivery failure is scoped to bcm5301x in both messages; Jonas
   Gorski observed that other family members still deliver unknown
   VIDs, and the programmed entries are correct there as well.
 - the cover's description of the miss path corrected per the v1
   thread register discussion, and the measured alternatives extended
   with the CHANGE_1Q_VID result.
 - patch 1: the conduit change path no longer skips ports that sit
   under a bridge; with the permanent feature bit their uppers are
   offloaded too, so their CPU port VLANs must move with the conduit.
   Not reachable on b53, which has no .port_change_conduit.
 - patch 2: code unchanged.

v2: https://lore.kernel.org/all/20260826171526.391-1-strst.gs@gmail.com/
v1: https://lore.kernel.org/all/20260806073119.387-1-strst.gs@gmail.com/

Semih Baskan (2):
  net: dsa: let drivers offload 8021q uppers on standalone ports
  net: dsa: b53: offload 8021q uppers on standalone ports

 drivers/net/dsa/b53/b53_common.c | 119 ++++++++++++++++++++++++++-----
 include/net/dsa.h                |   3 +
 net/dsa/port.c                   |  22 ++++--
 net/dsa/user.c                   |   4 +-
 4 files changed, 122 insertions(+), 26 deletions(-)

-- 
2.53.0.windows.1

Hi,

On Mon, Aug 31, 2026 at 10:52 AM Semih Baskan <strst.gs@gmail.com> wrote:
>
> Since v5.15, a standalone port on a bcm5301x 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 a tagged frame with a
> missing VID is forwarded only toward the IMP0 management port, which the
> in-tree bcm5301x topology leaves disabled, so it never reaches the CPU.
> The common victim is a VLAN-tagged PPPoE WAN, where the PADI goes out
> and the tagged PADO never reaches the CPU.

I really don't agree with the framing here. The subject essentially
claims that uppers don't work in general, but that is not true at all.
They don't work for devices with a *broken* device tree configuration.

So this is a work-around for broken configuration.

Also this is an incomplete fix, because it still won't work 100%, and
there is no way to fix this from within the driver, the device tree
needs to be fixed. E.g. with the (assumed) disabled EAP mode on
stand-alone ports, you will have the issue that the switch will drop
any frames with destination MACs that match a learned entry on a
bridged port.

I really think we should just fix up the in-tree device trees and then
complain loudly about the broken configuration on probe in case there
are out of tree device trees with the broken configuration. I mean it
was broken since v5.15 and wasn't noticed until recently, so it
doesn't seem affect many users.

Best regards,
Jonas

Hi Jonas,

On Mon, Aug 31, 2026 at 12:34 PM Jonas Gorski <jonas.gorski@gmail.com> wrote:
> I really think we should just fix up the in-tree device trees and then
> complain loudly about the broken configuration on probe in case there
> are out of tree device trees with the broken configuration.

I agree, fixing this up in the device tree is the more robust way.
In the meantime OpenWrt can carry these patches as a band aid for
the affected boards.

Best regards,
Semih

On 8/31/2026 3:17 AM, Semih Baskan wrote:
> Hi Jonas,
> 
> On Mon, Aug 31, 2026 at 12:34 PM Jonas Gorski <jonas.gorski@gmail.com> wrote:
>> I really think we should just fix up the in-tree device trees and then
>> complain loudly about the broken configuration on probe in case there
>> are out of tree device trees with the broken configuration.
> 
> I agree, fixing this up in the device tree is the more robust way.
> In the meantime OpenWrt can carry these patches as a band aid for
> the affected boards.

But you control exact how the DTS gets distributed in OpenWrt, why not 
just fix all of the DTSes there and have the users confirm that using 
port 8 as the IMP works?

Don't get me wrong, I am very appreciative that you spent a decent 
amount of time trying to come up with some sort of solution.

Thanks
-- 
Florian

Hi Florian,

On Tue, Sep 1, 2026 at 3:24 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> But you control exact how the DTS gets distributed in OpenWrt, why not
> just fix all of the DTSes there and have the users confirm that using
> port 8 as the IMP works?
>
> Don't get me wrong, I am very appreciative that you spent a decent
> amount of time trying to come up with some sort of solution.

Thank you. Yes, that is what I am planning to do. Port 8 as the IMP
is already confirmed on my board, tagged RX and PPPoE come back with
no driver changes. Next week I will start with my own board in
OpenWrt and hope owners of the other bcm53xx devices can confirm
theirs.

Best regards,
Semih