Hi Jupiter, On 3/29/22 07:16, JH wrote:
Hi, I could not understand why so many large WiFi chip vendors retreat to stop maintaining WiFi SDIO chips to mainline Linux kernel, and to settle it's chip support to out of the tree, use its own SDK and proprietary kernel tree to source.codeaurora.org or private repository which are not compatible to mainline stable kernel, the kernel configures are also different.
It is extremely rare to have vendors not have out-of-tree drivers or forked branches (I don't know of any, personally). Some vendors do end up upstreaming some of their patches in the end to reduce the amount of maintenance they have to do on their downstream drivers/kernel tree.
Upstreaming takes time, knowledge and soft (as in "communicating with people") skills that some vendors aren't willing to invest in. It's also usually not an urgent matter (as opposed to have *something* that works, so they can sell the product ASAP).
Also, quality of vendor (understand downstream) code is often subpar (to be polite) and would not be accepted as-is in Linux kernel upstream git repository.
Finally, it is also a strategical choice for vendors to have an out-of-tree driver so that people stuck with an older kernel can still use this driver/product. One simple example: a bad vendor sells you an SoC with BSP supporting kernel 4.4 (let's say). Now, you want to use a specific WiFi module with this SoC. Fortunately, there's upstream support for it, but only in 5.10 and later. Considering the number of changes between 4.4 and 5.10, you won't be able to easily backport the driver to work on 4.4. This means the WiFi module vendor loses you as a customer because you wont be able to use their solution.
Now, you could also have a nicer SoC vendor which provides you with a 5.10 kernel. However, there's an important fix available in 5.16 that isn't in the WiFi driver you have on 5.10. You could try to backport this yourself but not all customers of said WiFi vendor are skilled enough to do this. The WiFi vendor needs to provide support for backporting this for the customer and/or deal with unhappy customers.
However, with an out-of-tree driver with appropriate ifdefs everywhere to adapt for specific versions of the Linux kernel ABI, they have ONE driver that is known to work on many different Linux kernel versions. It also makes the maintenance of the driver much more simple for them. This also allows them to do releases much more often than the Linux kernel allows (one every 2-3 months). Considering the usually bad quality of code and maybe lack of proper reviews, you might end up with regressions and more importantly security issues that will never be discovered because less eyes will be on the code.
Out-of-tree drivers make sense in a self-feeding loop of vendors not upstreaming stuff because they need to support other vendors not upstreaming, even if they wanted to in the first place.
Finally, I've had to patch locally about 3-4 WiFi drivers and the changes weren't implemented by the vendor in the next releases. So you might just have issues other companies have fixed but it was never reported or fixed by the vendor. (Note that upstreaming does not necessarily fix this issue, it just makes it in theory less likely to happen since more people are supposed to use it than some vendor kernel).
Also, some vendors are historically reluctant to contribute anything to the upstream Linux kernel and the support of their hardware was added by hobbyists or one of their clients, bearing the costs themselves.
I looked at the following link, the mwifiex and mwifiex_sdio support the Marvell (NXP) 88W88 chipset, but only kernel 4.19 was able to build and to run, kernel 5 cannot support 88W88 chipset, any more.
You'd need to request the newer versions of mwifiex to NXP (which acquired Marvell some years ago) or patch it yourself. Welcome to the world of downstream support :)
Same to Qualcomm, the old Atheros WiFi modules are supported, the QCA-9377-3 chipset is in source.codeaurora.org only supported by old kernel 4.9. Given the OE/Yocto poky kernel build is based on a mainline stable kernel repository, how can I build kernel 5 for 88W88 chipset or QCA-9377-3 from source.codeaurora.org or private repository? Or which WiFi vendors are still well maintaining the WiFi chips for kernel 5, the only sensible solution is to switch WiFi SDIO chips? Appreciate your advice and comments.
Yocto only builds what you tell it to build. The company I work for provides[1] Yocto support for a vendor kernel based on Android-flavored 4.4 (note: though we do actually support and encourage using mainline, GPU/VPU support was - years ago - just not comparable between vendor and upstream kernels) for our System on Module, all of this on Honister (latest release of Yocto to date). You just need to create your own recipe (or adapt an existing one) to point to the BSP components your vendor gave you (or whatever you want to use) and build it. Nothing forces you to use linux-yocto 5.14 or whatever else.
[1] https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/tree/recipes-kernel/linux/linux-tsd_4.4.bb
Cheers, Quentin
