On Thu, 9 Sept 2021 at 16:40, Ansuel Smith <[email protected]> wrote: > > > > > > > On 09/09/2021 01:04, Stefan Lippers-Hollmann wrote: > > > > > I'm not really in a position to give advice, but -imho- unless those > > > other targets have at least proof-of-concept code for using qca8k on > > > their devices /working/ and an intention to migrate to DSA for these > > > devices within reasonable time frame, I personally wouldn't overthink > > > this (yet). > > > > > > There is no problem with adding these patches for ipq806x first, and then > > > moving the patches from ipq806x to generic later, when there is something > > > tangible for ath79 or bcm53xx (as part of their PRs/ patch series to > > > migrate from swconfig to qca8k). > > > > In fact we are at this stage with the bcm53xx Meraki MX65[1] which is > > just about ready to go, but requires part of Ansuel's series which is > > currently destined for ipq806x only in his PR[2]. This may be held up > > while more devices are tested so my suggestion is to get the series > > into generic/backports so the MX65 can use it while testing continues > > on other platforms. Moving it later would mean having some duplication > > in the bcm53xx/ipq806x platform directories until then. Perhaps that is > > acceptable if it will only be temporary? > > > > The other, perhaps main question is whether reintroducing dsa.mk is the > > correct approach. Adding the kmod to the relevant platform's modules.mk > > or kernel/linux/modules/netdevices.mk are alternatives. > > > > I am happy to submit a patch for whichever option is preferred, though > > whether this should be done within my PR, as a new PR or on the mailing > > list I'm not sure. I also don't wish to interfere with Ansuel's work so > > would prefer to have the idea accepted by him first before doing > > anything. > > > > [1] https://github.com/openwrt/openwrt/pull/3996 > > [2] https://github.com/openwrt/openwrt/pull/4036 > > > > Matthew > > As long as we make a decision on what to do, everything is ok for me. > It seems redundant to merge qca8k for ipq806x and then do a pr > to move the patch to generic. At this point I would suggest to change > the current pr, move the qca8k patch to generic and create a specific pr > later to improve support for other targets. > Having the patch merged will reduce the review process as reviewers won't > have to check 20+ patches but instead only the related one to the target. > > In short my suggestion would be: > 1. split qca8k patch from the current ipq806x pr > 2. make a separate pr to add qca8k patch to generic (only for 5.10+ kernel) > 3. review and try to quickly merge the generic pr > 4. make separate pr to test qca8k on the specific target
I agree, there is no point in making the qca8k backports etc an ipq806x specific thing as devices in other targets use QCA8337 and QCA8237 switches as well. Regards, Robert > > That way we can selectively work on the changes required for the specific > target > starting from a base patch instead of referring to a pr and ask if > that change can > be included in the big pr. > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
