[PATCH V2 RFC 2/2] ARM: dts: BCM5301X: change Luxul XWR-3150 CPU port from 5 do 8

Vladimir Oltean olteanv at gmail.com
Tue Aug 11 14:46:54 PDT 2026


On Tue, Aug 11, 2026 at 09:36:58PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal at milecki.pl>
> 
> Northstar devices have 3 CPU ports (each connected to a different
> Ethernet interface). This design was meant for dual IMP setups when
> WAN traffic goes to port 5 and LAN traffic goes to port 8.
> 
> For practical reasons we label only one of those ports as "cpu" (the
> rest remains disabled). It's because of Linux behaviour (and it's
> probably a bad thing since DT shouldn't "care" that that).

Did you see ds->ops->preferred_default_local_cpu_port()? You can define
all CPU ports in the device tree as such, and let the driver select
among them.

> So far the choice of "cpu" port was based on how vendor decided to setup
> given device originally: which of three Ethernet interfaces got MAC
> assigned and which port was used by vendor original firmware.
> 
> Most vendors decided to use CPU port 5 & relevant Ethernet interface.
> The problem is that only switch port 8 provides full functionality.
> 
> Change the choice of "cpu" port to 8 and make the third Ethernet
> interface (connected to port 8) use MAC designed for the first Ethernet
> interface (connected to port 5). This makes Linux use switch in a
> feature full way.
> 
> Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
> ---
> This seems to be a slight abuse of DT. Instead of describing hardware we
> make it steer Linux into using a more appropriate switch port. This
> isn't strictly a setback on its own. It's a change from one choice to
> another.
> 
> I'm not sure about that MAC however. We say that the third Ethernet
> interface should use MAC that was designed for the first one.

So the NVMEM is not provisioned for multiple MAC addresses for gmac0 and
gmac2? Can they ever be used simultaneously? Even so, I'm not sure
whether that would cause any problems (depending on whether the switch
supports address learning on IMP ports, it might not). Do you have a
specific concern?

> Is all of that acceptable?
> 
>  .../arm/boot/dts/broadcom/bcm47094-luxul-xwr-3150-v1.dts | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/broadcom/bcm47094-luxul-xwr-3150-v1.dts b/arch/arm/boot/dts/broadcom/bcm47094-luxul-xwr-3150-v1.dts
> index 8e487f60a2cc..7969f0f331b5 100644
> --- a/arch/arm/boot/dts/broadcom/bcm47094-luxul-xwr-3150-v1.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm47094-luxul-xwr-3150-v1.dts
> @@ -81,6 +81,11 @@ &gmac0 {
>  	nvmem-cell-names = "mac-address";
>  };
>  
> +&gmac2 {
> +	nvmem-cells = <&et0macaddr 0>;
> +	nvmem-cell-names = "mac-address";
> +};
> +
>  &pcie_bridge0 {
>  	wifi at 0,0 {
>  		compatible = "brcm,bcm4366-fmac", "brcm,bcm4329-fmac";
> @@ -136,7 +141,7 @@ port at 4 {
>  		};
>  
>  		port at 5 {
> -			label = "cpu";

label = "cpu" doesn't really do anything and just confuses things.
Labels are only defined for user ports. Please remove this property as a
follow-up (or preparatory) change.

> +			status = "disabled";
>  		};
>  
>  		port at 7 {
> @@ -144,7 +149,7 @@ port at 7 {
>  		};
>  
>  		port at 8 {
> -			status = "disabled";
> +			label = "cpu";
>  		};
>  	};
>  };
> -- 
> 2.51.0
> 



More information about the linux-arm-kernel mailing list