Question about qca8k dsa driver and path to follow

[Matthew Hagan]

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.