[devicetree,0/3] NXP LS1028A DT changes for multiple switch CPU ports

Message

Vladimir Oltean Aug. 18, 2022, 2:05 p.m. UTC

The Ethernet switch embedded within the NXP LS1028A has 2 Ethernet ports
towards the host, for local packet termination. In current device trees,
only the first port is enabled. Enabling the second port allows having a
higher termination throughput.

Care has been taken that this change does not produce regressions when
using updated device trees with old kernels that do not support multiple
DSA CPU ports. The only difference for old kernels will be the
appearance of a new net device (for &enetc_port3) which will not be very
useful for much of anything.

Vladimir Oltean (3):
  arm64: dts: ls1028a: move DSA CPU port property to the common SoC dtsi
  arm64: dts: ls1028a: mark enetc port 3 as a DSA master too
  arm64: dts: ls1028a: enable swp5 and eno3 for all boards

 .../dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts  | 9 ++++++++-
 .../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts | 9 ++++++++-
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts        | 9 ++++++++-
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi           | 2 ++
 4 files changed, 26 insertions(+), 3 deletions(-)

Comments

Michael Walle Aug. 18, 2022, 2:49 p.m. UTC | #1

Am 2022-08-18 16:05, schrieb Vladimir Oltean:
> The Ethernet switch embedded within the NXP LS1028A has 2 Ethernet 
> ports
> towards the host, for local packet termination. In current device 
> trees,
> only the first port is enabled. Enabling the second port allows having 
> a
> higher termination throughput.

Is it used automatically or does the userspace has to configure 
something?

> Care has been taken that this change does not produce regressions when
> using updated device trees with old kernels that do not support 
> multiple
> DSA CPU ports. The only difference for old kernels will be the
> appearance of a new net device (for &enetc_port3) which will not be 
> very
> useful for much of anything.

Mh, I don't understand. Does it now cause regressions or not? I mean
besides that there is a new unused interface?

I was just thinking of that systemready stuff where the u-boot might
supply its (newer) device tree to an older kernel, i.e. an older debian
or similar.

-michael

Vladimir Oltean Aug. 18, 2022, 2:55 p.m. UTC | #2

On Thu, Aug 18, 2022 at 04:49:49PM +0200, Michael Walle wrote:
> Is it used automatically or does the userspace has to configure something?

DSA doesn't yet support multiple CPU ports, but even when it will, the
second DSA master still won't be used automatically. If you want more
details about the proposed UAPI to use the second CPU port, see here:
https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/

> > Care has been taken that this change does not produce regressions when
> > using updated device trees with old kernels that do not support multiple
> > DSA CPU ports. The only difference for old kernels will be the
> > appearance of a new net device (for &enetc_port3) which will not be very
> > useful for much of anything.
> 
> Mh, I don't understand. Does it now cause regressions or not? I mean
> besides that there is a new unused interface?

It didn't cause regressions until kernel 5.13 when commit adb3dccf090b
("net: dsa: felix: convert to the new .change_tag_protocol DSA API")
happened, then commit 00fa91bc9cc2 ("net: dsa: felix: fix tagging
protocol changes with multiple CPU ports") fixed that regression and was
backported to the linux-5.15.y stable branch AFAIR. So at least kernels
5.15 and newer should work properly with the new device trees.

> I was just thinking of that systemready stuff where the u-boot might
> supply its (newer) device tree to an older kernel, i.e. an older debian
> or similar.
> 
> -michael

Yeah, I hear you, I'm doing my best to make the driver work with a
one-size-fits-all device tree, both ways around.

Michael Walle Aug. 18, 2022, 3:05 p.m. UTC | #3

Am 2022-08-18 16:55, schrieb Vladimir Oltean:
> On Thu, Aug 18, 2022 at 04:49:49PM +0200, Michael Walle wrote:
>> Is it used automatically or does the userspace has to configure 
>> something?
> 
> DSA doesn't yet support multiple CPU ports, but even when it will, the
> second DSA master still won't be used automatically. If you want more
> details about the proposed UAPI to use the second CPU port, see here:
> https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
> 
>> > Care has been taken that this change does not produce regressions when
>> > using updated device trees with old kernels that do not support multiple
>> > DSA CPU ports. The only difference for old kernels will be the
>> > appearance of a new net device (for &enetc_port3) which will not be very
>> > useful for much of anything.
>> 
>> Mh, I don't understand. Does it now cause regressions or not? I mean
>> besides that there is a new unused interface?
> 
> It didn't cause regressions until kernel 5.13 when commit adb3dccf090b
> ("net: dsa: felix: convert to the new .change_tag_protocol DSA API")
> happened, then commit 00fa91bc9cc2 ("net: dsa: felix: fix tagging
> protocol changes with multiple CPU ports") fixed that regression and 
> was
> backported to the linux-5.15.y stable branch AFAIR. So at least kernels
> 5.15 and newer should work properly with the new device trees.

Thanks for the details!

>> I was just thinking of that systemready stuff where the u-boot might
>> supply its (newer) device tree to an older kernel, i.e. an older 
>> debian
>> or similar.
>> 
>> -michael
> 
> Yeah, I hear you, I'm doing my best to make the driver work with a
> one-size-fits-all device tree, both ways around.

TBH I don't really care much, I was merely curious what to expect.

-michael