Question about qca8k dsa driver and path to follow

[Robert Marko]

On Thu, 9 Sept 2021 at 16:40, Ansuel Smith <ansuelsmth at gmail.com> 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
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel