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