DSA for ipq8064 target?

@robimarko @hnyman I notice that recently mvebu switched to dsa and I wonder if we can do the same for the ipq8064 since the qca8k driver should be enough mature in kernel 5.4 and we have a way to deny upgrade if swconfig firmware is detected.

What do you think about this change?

I am for it as it makes each port present as physical interface

To my very limited knowledge, qca8k currently does not cover the case of MAC addresses encoded in ASCII (uboot-env) so far, if that's true this change would break nbg6817 and ea8500.

root@nbg6817:~# fw_printenv ethaddr | sed s/..\:..\:..$/XX\:XX\:XX/
ethaddr=60:31:97:XX:XX:XX

a quick patch shouldn't be a problem (or a script to change the uboot env and set the right one)

I'm wrong that qca8k only supports the dedicated qca8337 switch?

Its supports QCA8337 and QCA8334 switches and their N versions

I'm by no means an expert, but I think VLAN support might need some attention as part of any move to qca8k. According to the notes from the recent virtual dev meeting (http://lists.infradead.org/pipermail/openwrt-adm/2020-July/001610.html) a swconfig to DSA transition will only be done if the DSA driver supports VLANs (and qca8k currently does not). It looks like there has been some recent work towards adding VLAN support to qca8k upstream, but I don't know how feasible it would be to backport to OpenWrt's 5.4 kernel?
https://patchwork.ozlabs.org/project/netdev/patch/20200721171624.GK23489@earth.li/
https://patchwork.ozlabs.org/project/netdev/patch/20200726145611.GA31479@earth.li/

If the api has not changed, we can backport the patch

I am hesitant as long as it is not feature-complete and does not have proper support in LuCI.
(Jow has made an initial proposal for DSA support there, but I haven't played with it myself.)

1 Like