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@xxxxxxxxx/ > > 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.
