Which vendors maintain SDIO WiFi in mainline stable kernel

Which vendors maintain SDIO WiFi in mainline stable kernel

[Jupiter]

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

Which vendors maintain SDIO WiFi in mainline stable kernel

[Jupiter]

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

Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

[Federico Pellegrin]

[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]

Hi Jupiter,
I cannot help you on the specific chip you ask, but responding to the
second part of your question I have quite good experience with Microchip
WILC1000/3000 on SDIO which, after a part separate repo and then staging,
is now in mailine from quite some time:
https://github.com/torvalds/linux/tree/master/drivers/net/wireless/microchip/wilc1000
I had also some mixed experience (seemed to be arch releated) otherwise
also with SDIO/SPI of SiLabs which is currently in mainline staging:
https://github.com/torvalds/linux/tree/master/drivers/staging/wfx
These chips are at least currently still on the market (modulo shortage
problems), not sure about their projected lifespan (I guess something hard
to foresee).

Cheers,
Federico


Il giorno mar 29 mar 2022 alle ore 08:16 JH <jupiter.hce@gmail.com> ha
scritto:

> 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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#163735):
> https://lists.openembedded.org/g/openembedded-core/message/163735
> Mute This Topic: https://lists.openembedded.org/mt/90102949/5117409
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> fede@evolware.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 4019 bytes --]

Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

[Quentin Schulz]

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

Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

[Quentin Schulz]

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

Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

[Fabio Estevam]

Hi Jupiter,

On Tue, Mar 29, 2022 at 3:16 AM JH <jupiter.hce@gmail.com> 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.

Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

[Fabio Estevam]

Hi Jupiter,

On Tue, Mar 29, 2022 at 3:16 AM JH <jupiter.hce@gmail.com> 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.