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(-)
--
2.34.1
In order for the LS1028A based boards to benefit from support for
multiple CPU ports, the second DSA master and its associated CPU port
must be enabled in the device trees. This does not change the default
CPU port from the current port 4.
Signed-off-by: Vladimir Oltean <[email protected]>
---
.../dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts | 8 ++++++++
.../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 8 ++++++++
3 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
index 52ef2e8e5492..73eb6061c73e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
@@ -59,6 +59,10 @@ &enetc_port2 {
status = "okay";
};
+&enetc_port3 {
+ status = "okay";
+};
+
&i2c3 {
eeprom@57 {
compatible = "atmel,24c32";
@@ -107,6 +111,10 @@ &mscc_felix_port4 {
status = "okay";
};
+&mscc_felix_port5 {
+ status = "okay";
+};
+
&sata {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
index 37c20cb6c152..113b1df74bf8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
@@ -39,6 +39,10 @@ &enetc_port2 {
status = "okay";
};
+&enetc_port3 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -62,3 +66,7 @@ &mscc_felix_port1 {
&mscc_felix_port4 {
status = "okay";
};
+
+&mscc_felix_port5 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 7285bdcf2302..e33725c60169 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -151,6 +151,10 @@ &enetc_port2 {
status = "okay";
};
+&enetc_port3 {
+ status = "okay";
+};
+
&esdhc {
sd-uhs-sdr104;
sd-uhs-sdr50;
@@ -281,6 +285,10 @@ &mscc_felix_port4 {
status = "okay";
};
+&mscc_felix_port5 {
+ status = "okay";
+};
+
&optee {
status = "okay";
};
--
2.34.1
Since the CPU port 4 of the switch is hardwired inside the SoC to go to
the enetc port 2, this shouldn't be something that the board files need
to set (but whether that CPU port is used or not is another discussion).
So move the DSA "ethernet" property to the common dtsi.
Signed-off-by: Vladimir Oltean <[email protected]>
---
.../boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts | 1 -
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts | 1 -
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 1 -
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 1 +
4 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
index 6b575efd84a7..52ef2e8e5492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
@@ -104,7 +104,6 @@ &mscc_felix_port3 {
};
&mscc_felix_port4 {
- ethernet = <&enetc_port2>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
index 330e34f933a3..37c20cb6c152 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
@@ -60,6 +60,5 @@ &mscc_felix_port1 {
};
&mscc_felix_port4 {
- ethernet = <&enetc_port2>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index e0cd1516d05b..7285bdcf2302 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -278,7 +278,6 @@ &mscc_felix_port3 {
};
&mscc_felix_port4 {
- ethernet = <&enetc_port2>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 5627dd7734f3..3da105119d82 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -1157,6 +1157,7 @@ mscc_felix_port4: port@4 {
reg = <4>;
phy-mode = "internal";
status = "disabled";
+ ethernet = <&enetc_port2>;
fixed-link {
speed = <2500>;
--
2.34.1
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/[email protected]/
>
>> > 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
Am 2022-08-18 16:05, schrieb Vladimir Oltean:
> Since the CPU port 4 of the switch is hardwired inside the SoC to go to
> the enetc port 2, this shouldn't be something that the board files need
> to set (but whether that CPU port is used or not is another
> discussion).
>
> So move the DSA "ethernet" property to the common dtsi.
>
> Signed-off-by: Vladimir Oltean <[email protected]>
> ---
> .../boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts | 1 -
> arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts | 1 -
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 1 -
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 1 +
> 4 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git
> a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> index 6b575efd84a7..52ef2e8e5492 100644
> ---
> a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> +++
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dts
> @@ -104,7 +104,6 @@ &mscc_felix_port3 {
> };
>
> &mscc_felix_port4 {
> - ethernet = <&enetc_port2>;
> status = "okay";
> };
>
> diff --git
> a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
> index 330e34f933a3..37c20cb6c152 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dts
> @@ -60,6 +60,5 @@ &mscc_felix_port1 {
> };
>
> &mscc_felix_port4 {
> - ethernet = <&enetc_port2>;
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index e0cd1516d05b..7285bdcf2302 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -278,7 +278,6 @@ &mscc_felix_port3 {
> };
>
> &mscc_felix_port4 {
> - ethernet = <&enetc_port2>;
> status = "okay";
> };
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 5627dd7734f3..3da105119d82 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -1157,6 +1157,7 @@ mscc_felix_port4: port@4 {
> reg = <4>;
> phy-mode = "internal";
> status = "disabled";
> + ethernet = <&enetc_port2>;
same here, status should probably the last one.
except from that:
Acked-by: Michael Walle <[email protected]>
>
> fixed-link {
> speed = <2500>;
Am 2022-08-18 16:05, schrieb Vladimir Oltean:
> In order for the LS1028A based boards to benefit from support for
> multiple CPU ports, the second DSA master and its associated CPU port
> must be enabled in the device trees. This does not change the default
> CPU port from the current port 4.
>
> Signed-off-by: Vladimir Oltean <[email protected]>
Acked-by: Michael Walle <[email protected]>
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
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/[email protected]/
> > 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.