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

[Florian Fainelli <florian.fainelli@broadcom.com>]

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