Question about qca8k dsa driver and path to follow

[Ansuel Smith]

>
>
> 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

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.