[PATCH net] net: dsa: b53: skip EAP mode setup on Northstar SoCs when using port 5 or 7

[PATCH net] net: dsa: b53: skip EAP mode setup on Northstar SoCs when using port 5 or 7

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

Northstar devices have 3 CPU ports. This design was meant for dual IMP
setups when WAN traffic goes to port 5 (IMP1) and LAN traffic goes to
port 8 (IMP0). While all 3 ports support Broadcom header some features
are not available for ports 5 and 7. Trying to set EAP mode when using
those ports breaks standalone ports.

Fixes: 4227ea91e265 ("net: dsa: b53: prevent standalone from trying to forward to other ports")
Cc: Semih Baskan <strst.gs@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
This fixes a regression. A very similar fix was carried by OpenWrt for
about half a year now.

A recent discussion in
[PATCH net 0/2] net: dsa: b53: fix 8021q uppers on standalone ports
allowed understanding the issue a bit better so I decided to send an
upstream PATCH finally.

 drivers/net/dsa/b53/b53_common.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 3f5b9592794d..4b4a9258ecd4 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -332,6 +332,21 @@ static void b53_set_eap_mode(struct b53_device *dev, int port, int mode)
 {
 	u64 eap_conf;
 
+	/*
+	 * Northstar devices (SoCs with BCM53011 / BCM53012) have 3 Ethernet
+	 * controllers connected to 3 switch ports: 5 (IMP1), 7 and 8 (IMP0).
+	 * Each of those ports can be used as CPU one as all support Broadcom
+	 * header but ports 5 and 7 have some limitations.
+	 *
+	 * Setting EAP_MODE_SIMPLIFIED with port 5/7 used as CPU port breaks
+	 * standalone ports, see:
+	 * https://lore.kernel.org/netdev/ce4d9b7b-aaf6-4796-94fb-8c3d6a1dcd4d@gmail.com/
+	 */
+	if (is5301x(dev) && !dsa_is_cpu_port(dev->ds, B53_CPU_PORT)) {
+		dev_warn_once(dev->dev, "skipping EAP setup because of not using CPU port 8\n");
+		return;
+	}
+
 	if (is5325(dev) || is5365(dev) || dev->chip_id == BCM5389_DEVICE_ID)
 		return;
 
-- 
2.51.0

Re: [PATCH net] net: dsa: b53: skip EAP mode setup on Northstar SoCs when using port 5 or 7

[Semih Baskan]

Tested on an Asus RT-N18U (BCM53011 rev 5, CPU port 5). A build with
4227ea91e265 active and no workaround reproduces the regression: a
standalone port stops receiving entirely while its egress keeps working.
Untagged traffic on the wan port counted 9 frames out, all 9 arrived at
the peer, and 0 came back in. With this patch on the same build the port
receives again, untagged and tagged both, and the "skipping EAP setup
because of not using CPU port 8" line appears exactly once in dmesg.

Note on the setup: both builds also included my pending b53 standalone
VLAN series, the same on both sides, so the only difference between them
is this patch. The tagged test passes only because that series is
present; on plain mainline the tagged direction still fails for the
unrelated reason that series addresses. The untagged result does not
involve the series and shows this patch's effect on its own.

Tested-by: Semih Baskan <strst.gs@gmail.com>

Re: [PATCH net] net: dsa: b53: skip EAP mode setup on Northstar SoCs when using port 5 or 7

[Jonas Gorski]

On Sun, Aug 9, 2026 at 11:39 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Northstar devices have 3 CPU ports. This design was meant for dual IMP
> setups when WAN traffic goes to port 5 (IMP1) and LAN traffic goes to
> port 8 (IMP0). While all 3 ports support Broadcom header some features
> are not available for ports 5 and 7. Trying to set EAP mode when using
> those ports breaks standalone ports.
>
> Fixes: 4227ea91e265 ("net: dsa: b53: prevent standalone from trying to forward to other ports")
> Cc: Semih Baskan <strst.gs@gmail.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> This fixes a regression. A very similar fix was carried by OpenWrt for
> about half a year now.
>
> A recent discussion in
> [PATCH net 0/2] net: dsa: b53: fix 8021q uppers on standalone ports
> allowed understanding the issue a bit better so I decided to send an
> upstream PATCH finally.
>
>  drivers/net/dsa/b53/b53_common.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
> index 3f5b9592794d..4b4a9258ecd4 100644
> --- a/drivers/net/dsa/b53/b53_common.c
> +++ b/drivers/net/dsa/b53/b53_common.c
> @@ -332,6 +332,21 @@ static void b53_set_eap_mode(struct b53_device *dev, int port, int mode)
>  {
>         u64 eap_conf;
>
> +       /*
> +        * Northstar devices (SoCs with BCM53011 / BCM53012) have 3 Ethernet
> +        * controllers connected to 3 switch ports: 5 (IMP1), 7 and 8 (IMP0).
> +        * Each of those ports can be used as CPU one as all support Broadcom
> +        * header but ports 5 and 7 have some limitations.
> +        *
> +        * Setting EAP_MODE_SIMPLIFIED with port 5/7 used as CPU port breaks
> +        * standalone ports, see:
> +        * https://lore.kernel.org/netdev/ce4d9b7b-aaf6-4796-94fb-8c3d6a1dcd4d@gmail.com/
> +        */
> +       if (is5301x(dev) && !dsa_is_cpu_port(dev->ds, B53_CPU_PORT)) {
> +               dev_warn_once(dev->dev, "skipping EAP setup because of not using CPU port 8\n");

We should print a bit fat warning at probe time, since this is
essentially a broken device tree configuration.

EAP isn't the only feature not working, anything that relies on trap
to CPU is broken. E.g STP also won't work, likely (if ever
implemented) bonding would not work (LACP frames won't be correctly
trapped), I assume LLDP would be broken, and any other protocols that
rely on reserved multicast addresses as well.

So we should strongly encourage users to fix the device tree and use
port 8 as CPU port.

Also can you try to move the CPU port on all devices you have access
to and send patches for that where it works successfully?

Best regards,
Jonas

Re: [PATCH net] net: dsa: b53: skip EAP mode setup on Northstar SoCs when using port 5 or 7

[Andrew Lunn]

On Sun, Aug 09, 2026 at 12:39:58PM +0200, Jonas Gorski wrote:
> On Sun, Aug 9, 2026 at 11:39 AM Rafał Miłecki <zajec5@gmail.com> wrote:
> >
> > From: Rafał Miłecki <rafal@milecki.pl>
> >
> > Northstar devices have 3 CPU ports. This design was meant for dual IMP
> > setups when WAN traffic goes to port 5 (IMP1) and LAN traffic goes to
> > port 8 (IMP0). While all 3 ports support Broadcom header some features
> > are not available for ports 5 and 7. Trying to set EAP mode when using
> > those ports breaks standalone ports.

> > +       /*
> > +        * Northstar devices (SoCs with BCM53011 / BCM53012) have 3 Ethernet
> > +        * controllers connected to 3 switch ports: 5 (IMP1), 7 and 8 (IMP0).
> > +        * Each of those ports can be used as CPU one as all support Broadcom
> > +        * header but ports 5 and 7 have some limitations.
> > +        *
> > +        * Setting EAP_MODE_SIMPLIFIED with port 5/7 used as CPU port breaks
> > +        * standalone ports, see:
> > +        * https://lore.kernel.org/netdev/ce4d9b7b-aaf6-4796-94fb-8c3d6a1dcd4d@gmail.com/
> > +        */
> > +       if (is5301x(dev) && !dsa_is_cpu_port(dev->ds, B53_CPU_PORT)) {
> > +               dev_warn_once(dev->dev, "skipping EAP setup because of not using CPU port 8\n");
> 
> We should print a bit fat warning at probe time, since this is
> essentially a broken device tree configuration.

I was wondering how we got here, is it a device tree problem, but the
commit message is a bit vague.

I agree, for a DT problem, it should be reported at probe. After that,
the driver can do its best, but should be quiet.

> EAP isn't the only feature not working, anything that relies on trap
> to CPU is broken. E.g STP also won't work, likely (if ever
> implemented) bonding would not work (LACP frames won't be correctly
> trapped), I assume LLDP would be broken, and any other protocols that
> rely on reserved multicast addresses as well.
> 
> So we should strongly encourage users to fix the device tree and use
> port 8 as CPU port.
> 
> Also can you try to move the CPU port on all devices you have access
> to and send patches for that where it works successfully?

I agree. This should be changed into a patchset.

1. Move the warning into probe
2. Update the binding .yaml to indicate such a setup is invalid.
3. Fix all in tree .dts{i} files to make the new warning go away.

If there are any boards which cannot be fixed because the correct CPU
port is not wired up, we need to think further about what needs to
happen.

    Andrew

---
pw-bot: cr

Re: [PATCH net] net: dsa: b53: skip EAP mode setup on Northstar SoCs when using port 5 or 7

[Florian Fainelli]

On 8/9/2026 8:00 AM, Andrew Lunn wrote:
> On Sun, Aug 09, 2026 at 12:39:58PM +0200, Jonas Gorski wrote:
>> On Sun, Aug 9, 2026 at 11:39 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>>>
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> Northstar devices have 3 CPU ports. This design was meant for dual IMP
>>> setups when WAN traffic goes to port 5 (IMP1) and LAN traffic goes to
>>> port 8 (IMP0). While all 3 ports support Broadcom header some features
>>> are not available for ports 5 and 7. Trying to set EAP mode when using
>>> those ports breaks standalone ports.
> 
>>> +       /*
>>> +        * Northstar devices (SoCs with BCM53011 / BCM53012) have 3 Ethernet
>>> +        * controllers connected to 3 switch ports: 5 (IMP1), 7 and 8 (IMP0).
>>> +        * Each of those ports can be used as CPU one as all support Broadcom
>>> +        * header but ports 5 and 7 have some limitations.
>>> +        *
>>> +        * Setting EAP_MODE_SIMPLIFIED with port 5/7 used as CPU port breaks
>>> +        * standalone ports, see:
>>> +        * https://lore.kernel.org/netdev/ce4d9b7b-aaf6-4796-94fb-8c3d6a1dcd4d@gmail.com/
>>> +        */
>>> +       if (is5301x(dev) && !dsa_is_cpu_port(dev->ds, B53_CPU_PORT)) {
>>> +               dev_warn_once(dev->dev, "skipping EAP setup because of not using CPU port 8\n");
>>
>> We should print a bit fat warning at probe time, since this is
>> essentially a broken device tree configuration.
> 
> I was wondering how we got here, is it a device tree problem, but the
> commit message is a bit vague.
> 
> I agree, for a DT problem, it should be reported at probe. After that,
> the driver can do its best, but should be quiet.
> 
>> EAP isn't the only feature not working, anything that relies on trap
>> to CPU is broken. E.g STP also won't work, likely (if ever
>> implemented) bonding would not work (LACP frames won't be correctly
>> trapped), I assume LLDP would be broken, and any other protocols that
>> rely on reserved multicast addresses as well.
>>
>> So we should strongly encourage users to fix the device tree and use
>> port 8 as CPU port.
>>
>> Also can you try to move the CPU port on all devices you have access
>> to and send patches for that where it works successfully?
> 
> I agree. This should be changed into a patchset.

Also agree here, using ports 5 and 7 likely stemmed from limited 
understanding at the time, given all of these ports are internal and are 
all functional, there should really be no reason not to use port 8 
unconditionally as the IMP port, it's the most capable and it has no 
limitations.

> 
> 1. Move the warning into probe
> 2. Update the binding .yaml to indicate such a setup is invalid.
> 3. Fix all in tree .dts{i} files to make the new warning go away.

Sounds good to me.

> 
> If there are any boards which cannot be fixed because the correct CPU
> port is not wired up, we need to think further about what needs to
> happen.

I don't think that can happen.
-- 
Florian