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.
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.
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.
https://wireless.wiki.kernel.org/en/users/drivers
Thank you very much.
Kind regards,
jupiter
Hi Jupiter,
On Tue, Mar 29, 2022 at 3:16 AM JH <[email protected]> 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.
>
> 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.
> 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.
The QCA9377 is well supported in the mainline kernel by the ath10k driver:
drivers/net/wireless/ath/ath10k/
Just use 5.10 or 5.15 stable tree and there will be no need to use an
out-of-tree driver for QCA9377.
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