[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220818145556.ieg37btfny3o2i4q@skbuf>
Date: Thu, 18 Aug 2022 14:55:56 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Michael Walle <michael@...le.cc>
CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Shawn Guo <shawnguo@...nel.org>, Leo Li <leoyang.li@....com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH devicetree 0/3] NXP LS1028A DT changes for multiple switch
CPU ports
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/20220523104256.3556016-1-olteanv@gmail.com/
> > 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.
Powered by blists - more mailing lists