Re: Question about qca8k dsa driver and path to follow
> > > Is there any situation where the user would need to decide whether DSA or > > swconfig should be used, assuming both are working? A kmod may be > > Just a side note on this: > Having a user choice between drivers should not be a development goal by any > means here. > If it happens "by accident" due to other changes, there is nothing to say > against it. > But experience tells it's hard enough to properly support one configuration, > so we definitely should not invest work in providing a choice here just for > its own sake (always referring to different drivers on a single device, of > course). > > Best > > Adrian > > I see your point. Anyway with some early test it looks like having both the qca8k driver and the swconfig driver cause some slowdown as the swconfig driver is init unconditionally (no compatible check) and try to probe and wait for a timeout in scanning the switch. So with the introduction of qca8k for a target we will have to drop the swconfig driver totally or slowdown (that looks like stall) will occur. Anyway the basepatch pr is having positive effects and we tested that on a ath79 device with positive results (only one problem with vlan that was caused by a bad configuration) > > justified for devices having issues supporting the DSA driver. Another > option > > is to have DSA/non-DSA subtargets but there seems to be pushback against > > this. > > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Question about qca8k dsa driver and path to follow
> Is there any situation where the user would need to decide whether DSA or > swconfig should be used, assuming both are working? A kmod may be Just a side note on this: Having a user choice between drivers should not be a development goal by any means here. If it happens "by accident" due to other changes, there is nothing to say against it. But experience tells it's hard enough to properly support one configuration, so we definitely should not invest work in providing a choice here just for its own sake (always referring to different drivers on a single device, of course). Best Adrian > justified for devices having issues supporting the DSA driver. Another option > is to have DSA/non-DSA subtargets but there seems to be pushback against > this. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
Il giorno gio 9 set 2021 alle ore 22:20 Ansuel Smith ha scritto: > > Il giorno gio 9 set 2021 alle ore 22:19 Rafał Miłecki > ha scritto: > > > > wt., 7 wrz 2021 o 18:53 Ansuel Smith napisał(a): > > > I currently have a pr open [1] to migrate ipq806x to > > > dsa driver > > > > Can you paste a missing link, please? > > > > -- > > Rafał > > Yes sorry i was referring to this. > https://github.com/openwrt/openwrt/pull/4036 Anyway we have now https://github.com/openwrt/openwrt/pull/4528 with the qca8k patches in generic. Think merging/reviewing that is the first step for all of this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
Il giorno gio 9 set 2021 alle ore 22:19 Rafał Miłecki ha scritto: > > wt., 7 wrz 2021 o 18:53 Ansuel Smith napisał(a): > > I currently have a pr open [1] to migrate ipq806x to > > dsa driver > > Can you paste a missing link, please? > > -- > Rafał Yes sorry i was referring to this. https://github.com/openwrt/openwrt/pull/4036 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
wt., 7 wrz 2021 o 18:53 Ansuel Smith napisał(a): > I currently have a pr open [1] to migrate ipq806x to > dsa driver Can you paste a missing link, please? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
On Thu, 9 Sept 2021 at 16:40, Ansuel Smith 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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
> > > 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
Hi On 2021-09-07, Ansuel Smith wrote: > I am writing this to ask for some help/direction on what path we > should follow for > the qca8k driver. I currently have a pr open [1] to migrate ipq806x to > dsa driver > (qca8k) but some other devs reported that the same switch is also used by > other > targets. (ath79, bcm53xx) > It was suggested to move the entire patchset for qca8k to generic > patch dir and start > and adding the required patch to make qca8k work on the other target. [...] 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). Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
On 07/09/2021 17:48, ansuelsmth at gmail.com (Ansuel Smith) wrote: > > Problem is that excluding ipq806x, not every device uses the qca8k > switch and including > that by default seems wrong. It was suggested to compile that as a > module (with optionally > the dsa subsistem as a kmod) so the driver (and dsa) can be installed > only on the required > devices. So the idea is to reintroduce the dsa.mk kernel modules > makefile used some time ago > for the mvebu target. dsa.mk was removed with the reasoning that "Targets that need switch drivers should select them in their kernel config." There are a few cases where this isn't appropriate since the switch used is not commonly used with that target. This has now come up with the bcm53xx Meraki MX65 which has a QCA8337 switch and thus needs a qca8k kmod. There are several devices where their switch swconfig driver is a kmod so the same issue will arise, for example the Ubiquiti ES-8XP (ATH79) with a BCM53128 switch. > > In short the main concerns are: > 1. Is it right to move qca8k patch to generic? > 2. Should we move it to a kmod with the dsa subsystem or compile the > driver built-in ? For 1 and 2 (the kmod option) I see no reason not to do this. In the case of the MX65, we can justify doing this immediately since the device has been tested extensively, so the driver will be used on one platform with expectation of more platforms in the very near future. I would therefore propose submitting your upstream series to backports-5.10. For dsa.mk we can enable by target if necessary. What do you think? > Also another concern would be: > 1. Can we consider moving the ar8227 swconfig driver to kmod? > That would make the transition easier since we will be able to include > both the required > nodes in the dts and make the user decide what to use. (by > removing/installing the required > kmod). Is there any situation where the user would need to decide whether DSA or swconfig should be used, assuming both are working? A kmod may be justified for devices having issues supporting the DSA driver. Another option is to have DSA/non-DSA subtargets but there seems to be pushback against this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
