Wifi: Switch to mainline driver for RTL8723CS, RTL8811CU, RTL8821C, RTL8192EU from 6.10 onwards

[ColorfulRhino]

Description

In an effort to reduce wifi driver burdens AR-1745, I went through the 6.10 kernel to check if any third party wifi drivers can be removed.

The following drivers are part of the mainline kernel as of 6.10:

• RTL8723CS (driver: RTW88)
• RTL8723DS (driver: RTW88)
• RTL8811CU and RTL8821C (driver: RTW88)
• RTL8192EU (driver: RTL8XXXU)

I went through the Armbian forums, Jira and GiHub issues to see if anyone had used those drivers for these chips in the past and had reported issues. But I haven't found anything yet.

• RTL8723CS: Add to every board < 6.10
• RTL8723DS: Add to every board < 6.10, ALSO add to RockPi-S and Asus Tinkerboard Rev.2 regardless of kernel version (issue with RockPi-S reported by @brentr)
• RTL8192EU: Add to every board < 6.10, use RTL8XXXU mainline driver from 6.10 onwards
• RTL8811CU and RTL8821C: Add to every board < 6.10, ALSO add to BananaPi M4 Zero regardless of kernel version (@pyavitz reported issue)

This way, maintainers of these specific boards can decide when it's time to switch to a mainline driver.

Jira reference number AR-1745

How Has This Been Tested?

• Build success: ./compile.sh BOARD=nanopc-cm3588-nas BRANCH=edge RELEASE=trixie EXPERT=yes KERNEL_CONFIGURE=no BUILD_MINIMAL=no BUILD_DESKTOP=no
• Mainline drivers should be tested

RTL8821CU:

• @pyavitz USB dongle with this Wifi chip, used on the NanoPi M1 (Allwinner H3), kernel 6.9.3, has no issues with RTW88.
• @pyavitz onboard module module with this Wifi chip, used on BananaPi M4-ZERO (Allwinner H618), kernel 6.9.3, has a USB-related issue (https://paste.armbian.com/ocomoxuvom.yaml) with RTW88. Suspected cause is the immaturity of the H618. BSP and Mainline both suffer.

LOOKING FOR TESTERS:

Drivers for RTL8811CU, RTL8821C and RTL8192EU are available also in 6.9, so if you have a device with those chips, it would be very nice if you could test them with their respective kernel driver (RTW88 or RTL8XXXU). You may have to enable them in your board's kernel config.

If you have a board with a RTL8723DS chip, especially Asus Tinkerboard Rev.2, please test the RTW88 driver. If RockPi-S is the only board which broken RTL8723DS driver, we could switch most other boards to RTW88 for this chip.

Installation instructions for the latest RTW88 driver (also for older kernels, you don't need 6.9 or 6.10 to test this): https://github.com/lwfinger/rtw88/?tab=readme-ov-file#installation-guide

sudo apt-get update
sudo apt-get install make gcc linux-headers-$(uname -r) build-essential git

git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[ColorfulRhino]

Feel free to discuss if those drivers should better be tested in 6.10 already instead of 6.11 in case 6.11 will be a LTS release so these devices can be tested in the wild and if there are no complaints we can leave it enabled for the next current LTS kernel. As proposed by @SteeManMI in this comment: #6669 (comment).

[pyavitz]

I can only speak to the rtw88_8821cu. As of now, unless something has changed "I don't believe it has as of writing this" the BananaPi M4-ZERO has issues loading the driver. Although the problem sometimes arises using the github equivalent, it is far less frequent. I've yet to find the root cause. This happens on both BSP and Mainline.

I know that @adeepn has issues with rtw88_8822cs on the Jethub lineup. I think that has something to do with AP?

[pyavitz]

With that said; concerning rtw88_8821cu; if someone wants to make a judgement call and the BPI-M4-ZERO is holding up progress, feel free to do so. It isn't hard to install the github equivalent manually and blacklist rtw88.

[ColorfulRhino]

I can only speak to the rtw88_8821cu. As of now, unless something has changed "I don't believe it has as of writing this" the BananaPi M4-ZERO has issues loading the driver. Although the problem sometimes arises using the github equivalent, it is far less frequent. I've yet to find the root cause. This happens on both BSP and Mainline.

When did you last test it? There was a lot of activity on this driver recently: https://github.com/lwfinger/rtw88/commits/master/rtw8821c.c

The following commit lwfinger/rtw88@4c77cee from 3 weeks ago might have also fixed some stuff. If it does, we could include it as patch for RTW88.

wifi: rtw88: usb: Further limit the TX aggregation

Currently the number of frames sent to the chip in a single USB Request
Block is limited only by the size of the TX buffer, which is 20 KiB.
Testing reveals that as many as 13 frames get aggregated. This is more
than what any of the chips would like to receive. RTL8822CU, RTL8822BU,
and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame
per URB.

RTL8723DU in particular reliably malfunctions during a speed test. All
traffic seems to stop. Pinging the AP no longer works.

Fix this problem by limiting the number of frames sent to the chip in a
single URB according to what each chip likes.

Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames
per URB.

RTL8703B may or may not be found in USB devices. Declare that it wants
only 1 frame per URB, just in case.

Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
Signed-off-by: Bitterblue Smith [email protected]

---

I know that @adeepn has issues with rtw88_8822cs on the Jethub lineup. I think that has something to do with AP?

rtl88x2cs is not touched by this PR. Although it might alco have been fixed with the linked commit.

[adeepn]

I can only speak to the rtw88_8821cu. As of now, unless something has changed "I don't believe it has as of writing this" the BananaPi M4-ZERO has issues loading the driver. Although the problem sometimes arises using the github equivalent, it is far less frequent. I've yet to find the root cause. This happens on both BSP and Mainline.

When did you last test it? There was a lot of activity on this driver recently: https://github.com/lwfinger/rtw88/commits/master/rtw8821c.c

Feel free to dive deep into lkml.

https://lore.kernel.org/all/CAFBinCAsuCqEVJq-No-+D-T644mQ-qsez-Di-=s9gricOrk3wQ@mail.gmail.com/T/#t

https://lore.kernel.org/all/[email protected]/

and more.

The following commit lwfinger/rtw88@4c77cee from 3 weeks ago might have also fixed some stuff. If it does, we could include it as patch for RTW88.

this patch not accepted in mainline at this time.

I know that @adeepn has issues with rtw88_8822cs on the Jethub lineup. I think that has something to do with AP?

rtl88x2cs is not touched by this PR. Although it might alco have been fixed with the linked commit.

seems all sdio rtw88 card does not works with AP mode at all. and in my tests at least 8821cu, 8822cs works unstable with rtw88 drivers.

[pyavitz]

I'll run some tests; https://lore.kernel.org/linux-wireless/[email protected]/

[ColorfulRhino]

this patch not accepted in mainline at this time.

Which is why I proposed to add it as patch if it's useful :)

seems all sdio rtw88 card does not works with AP mode at all

If it's mostly AP mode holding up progress, it's debatable if supporting AP mode for those cheap Realtek chips is even in-scope for the Armbian project, if even nobody on mainline wants to support it properly. These aren't router-class chips after all and Armbian also isn't OpenWRT.
If people want a good and well-supported wifi AP mode chip on Armbian for whatever reason, I'd say just put an M.2 wifi card in your board.

I'll run some tests; https://lore.kernel.org/linux-wireless/[email protected]/

Thanks a lot!

[adeepn]

this patch not accepted in mainline at this time.

Which is why I proposed to add it as patch if it's useful :)

seems all sdio rtw88 card does not works with AP mode at all

If it's mostly AP mode holding up progress, it's debatable if supporting AP mode for those cheap Realtek chips is even in-scope for the Armbian project, if even nobody on mainline wants to support it properly. These aren't router-class chips after all and Armbian also isn't OpenWRT. If people want a good and well-supported wifi AP mode chip on Armbian for whatever reason, I'd say just put an M.2 wifi card in your board.

you cannot make decisions for everyone, as at least two developers have already expressed their opposition.
and you miss the second part: the performance and stability of the rtw88 driver.

in our case, the ideal situation turned out to be keeping both drivers in the system and using the modules blacklist to select a specific driver for operation.

we are, of course, monitoring the development of the rtw88 driver and will participate in its development where possible, but the situation is currently as described.

[ColorfulRhino]

you cannot make decisions for everyone

I am not, I am merely describing my opinion and reasoning to discuss this topic. Apologies if there is a misunderstanding. PRs are open for discussing.
These 3rd party drivers are a big maintenance burden, every kernel bump. See AR-1745. Strictly speaking, they are also a security risk since come from a 3rd party repository.

and you miss the second part: the performance and stability of the rtw88 driver.

Which is why I explicitly asked for testing and discussion. Since this driver-collection constantly get improved, it's always worth revisiting periodically.

in our case, the ideal situation turned out to be keeping both drivers in the system and using the modules blacklist to select a specific driver for operation.

See above, this doesn't reduce, but increase maintenance.

[adeepn]

I am not, I am merely describing my opinion and reasoning to discuss this topic. Apologies if there is a misunderstanding. PRs are open for discussing.

Yes, perhaps I got a bit hot-headed. I get a little nervous about anything that might affect the functionality of our equipment :)

These 3rd party drivers are a big maintenance burden, every kernel bump. See AR-1745. Strictly speaking, they are also a security risk since come from a 3rd party repository.

And the issue with rtw88 is indeed very complex. Currently, we (at JetHome) are prepared to support rtl88x2cs as long as our equipment with these modules continues to be produced and supported. Soon, we might add 8821cu to this list. So, please do not touch that either :)

Which is why I explicitly asked for testing and discussion. Since this driver-collection constantly get improved, it's always worth revisiting periodically.

in our case, the ideal situation turned out to be keeping both drivers in the system and using the modules blacklist to select a specific driver for operation.

See above, this doesn't reduce, but increase maintenance.

Regarding other drivers, I think it's worth looking at the list of SBCs in which they are used, and their support status. And if there's anyone to ask, ask them.
In terms of the idea of kernel and drivers development, I am still in favor of switching to rtw88 - more complaints about the drivers will mean more chances that they will be fixed, but in the near term, this could result in negative consequences for Armbian and for the SBCs themselves.

[pyavitz]

I can only speak to the rtw88_8821cu. As of now, unless something has changed "I don't believe it has as of writing this" the BananaPi M4-ZERO has issues loading the driver. Although the problem sometimes arises using the github equivalent, it is far less frequent. I've yet to find the root cause. This happens on both BSP and Mainline.

When did you last test it? There was a lot of activity on this driver recently: https://github.com/lwfinger/rtw88/commits/master/rtw8821c.c

The following commit lwfinger/rtw88@4c77cee from 3 weeks ago might have also fixed some stuff. If it does, we could include it as patch for RTW88.

wifi: rtw88: usb: Further limit the TX aggregation
Currently the number of frames sent to the chip in a single USB Request
Block is limited only by the size of the TX buffer, which is 20 KiB.
Testing reveals that as many as 13 frames get aggregated. This is more
than what any of the chips would like to receive. RTL8822CU, RTL8822BU,
and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame
per URB.
RTL8723DU in particular reliably malfunctions during a speed test. All
traffic seems to stop. Pinging the AP no longer works.
Fix this problem by limiting the number of frames sent to the chip in a
single URB according to what each chip likes.
Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames
per URB.
RTL8703B may or may not be found in USB devices. Declare that it wants
only 1 frame per URB, just in case.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
Signed-off-by: Bitterblue Smith [email protected]

I know that @adeepn has issues with rtw88_8822cs on the Jethub lineup. I think that has something to do with AP?

rtl88x2cs is not touched by this PR. Although it might alco have been fixed with the linked commit.

https://paste.armbian.com/ocomoxuvom.yaml
USB won't come back unless I pull the power.

[ColorfulRhino]

Yes, perhaps I got a bit hot-headed. I get a little nervous about anything that might affect the functionality of our equipment :)

No worries! 😄 Armbian does have a pretty good testing phase before every release, so any unintentional breaking of functionality should be caught in the testing process at the latest :)

And the issue with rtw88 is indeed very complex. Currently, we (at JetHome) are prepared to support rtl88x2cs as long as our equipment with these modules continues to be produced and supported. Soon, we might add 8821cu to this list. So, please do not touch that either :)

If you let me know, I can simply add an exception for Jethub devices. This way, most devices are using mainline while Jethub can keep using their inhouse drivers. Although to be honest if I was a board builder, I would probably build my own images to ensure that all the drivers are on board and working.
Maybe you can even contribute to the upstream driver so you don't havbe to maintain your own separate driver at all 😄

Regarding other drivers, I think it's worth looking at the list of SBCs in which they are used, and their support status. And if there's anyone to ask, ask them.

Yeah I tried to find information about this, but unfortunately there is no such list. I tried to search the forums, Jira and GitHub. Some boards even use different chips for different revisons. So I asked the whole community in this PR to test if they have a board that uses a chip with those drivers.

In terms of the idea of kernel and drivers development, I am still in favor of switching to rtw88 - more complaints about the drivers will mean more chances that they will be fixed, but in the near term, this could result in negative consequences for Armbian and for the SBCs themselves.

Agreed. It also would help the RTW88 developers if people report issues to find out where it failed and how it could to be improved.

[ColorfulRhino]

https://paste.armbian.com/ocomoxuvom.yaml
USB won't come back unless I pull the power.

Thanks! Did you test the driver from the repo at https://github.com/lwfinger/rtw88/ ? Or did you apply the commit as a patch on to mainline 6.10 or Linux-next?

If the latter, I believe folks at the mailing list would appreciate your input/bug report, especially if it's directly related to this commit/patch :)

[pyavitz]

https://paste.armbian.com/ocomoxuvom.yaml
USB won't come back unless I pull the power.

Thanks! Did you test the driver from the repo at https://github.com/lwfinger/rtw88/ ? Or did you apply the commit as a patch on to mainline 6.10 or Linux-next?

If the latter, I believe folks at the mailing list would appreciate your input/bug report, especially if it's directly related to this commit/patch :)

I applied it to 6.9.3. Personally I'm leaning towards this being an issue with maturity, as H618 is still under heavy development.

I've been using a dongle that requires the driver on an old NanoPi M1 for a long time now and haven't experienced any real problems.

patrick@speaker:~$ lsmod
Module                  Size  Used by
rfcomm                 40960  4
bnep                   16384  2
rtw88_8821cu           12288  0
rtw88_8821c            81920  1 rtw88_8821cu
rtw88_usb              16384  1 rtw88_8821cu
rtw88_core            131072  2 rtw88_usb,rtw88_8821c
btusb                  45056  0
btintel                28672  1 btusb
btrtl                  20480  1 btusb
mac80211              475136  2 rtw88_core,rtw88_usb
btbcm                  20480  1 btusb
bluetooth             450560  39 btrtl,btintel,bnep,btbcm,rfcomm,btusb
cfg80211              339968  2 rtw88_core,mac80211
ecdh_generic           12288  2 bluetooth
zram                   24576  8
ecc                    32768  1 ecdh_generic
rfkill                 24576  5 bluetooth,cfg80211
sun6i_msgbox           12288  0
arm_scpi               16384  0
ip_tables              24576  0
x_tables               20480  1 ip_tables

I use it as DIY bluetooth speaker, but I need to SSH in from time to time; hence the dongle.

[ColorfulRhino]

I applied it to 6.9.3. Personally I'm leaning towards this being an issue with maturity, as H618 is still under heavy development.

Ah I see. Maybe the patch doesn't work on its own or as you said it also may be a USB problem with the SoC.

You could try installing the fully up-to-date driver with these instructions https://github.com/lwfinger/rtw88/?tab=readme-ov-file#installation-guide and see if anything changes or if there are still USB issues.

Maybe you need to sudo apt-get install make gcc linux-headers-$(uname -r) build-essential git

If you've got headers and build tools install, it's basically just

git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install

[adeepn]

Yes, perhaps I got a bit hot-headed. I get a little nervous about anything that might affect the functionality of our equipment :)

No worries! 😄 Armbian does have a pretty good testing phase before every release, so any unintentional breaking of functionality should be caught in the testing process at the latest :)

😄😄😄 (i've actually here since 2021)

If you let me know, I can simply add an exception for Jethub devices. This way, most devices are using mainline while Jethub can keep using their inhouse drivers. Although to be honest if I was a board builder, I would probably build my own images to ensure that all the drivers are on board and working. Maybe you can even contribute to the upstream driver so you don't havbe to maintain your own separate driver at all 😄

Just don't touch anything around jethub without my approve/review. We already use our own infrastructure for building and deployment, while also supporting Armbian and other opensource projects as much as possible.

Regarding other drivers, I think it's worth looking at the list of SBCs in which they are used, and their support status. And if there's anyone to ask, ask them.

Yeah I tried to find information about this, but unfortunately there is no such list. I tried to search the forums, Jira and GitHub. Some boards even use different chips for different revisons. So I asked the whole community in this PR to test if they have a board that uses a chip with those drivers.

every supported board has maintainer/committer.

[pyavitz]

I applied it to 6.9.3. Personally I'm leaning towards this being an issue with maturity, as H618 is still under heavy development.

Ah I see. Maybe the patch doesn't work on its own or as you said it also may be a USB problem with the SoC.

You could try installing the fully up-to-date driver with these instructions https://github.com/lwfinger/rtw88/?tab=readme-ov-file#installation-guide and see if anything changes or if there are still USB issues.

Maybe you need to sudo apt-get install make gcc linux-headers-$(uname -r) build-essential git

If you've got headers and build tools install, it's basically just

git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install

I routinely check and download RTW88 patches. So when I say I applied this patch, it's in conjunction with the others available on lore. Those that have "and in some cases not" been accepted. I don't really see anything in Larry's repo that I'm not already using. Except the AU drivers they are working on.

[ColorfulRhino]

Just don't touch anything around jethub without my approve/review. We already use our own infrastructure for building and deployment, while also supporting Armbian and other opensource projects as much as possible.

I'll try to exclude Jethub from any changes and revise this PR. I assume changes affecting Jethub is mostly wifi related stuff anyways. Do those devices have their own BOARDFAMILY or what's the best way to specifically address Jethub boards only?

every supported board has maintainer/committer.

Yes. Let me know if you know a list which details all boards using wifi chips and their respective chip name :)

[ColorfulRhino]

I routinely check and download RTW88 patches. So when I say I applied this patch, it's in conjunction with the others available on lore. Those that have "and in some cases not" been accepted. I don't really see anything in Larry's repo that I'm not already using. Except the AU drivers they are working on.

Ah, understood. Thanks for the clarification!
So to boil it down, from your testing:

• You have a USB Wifi dongle which has the RTL8821cu chip
• Your NanoPi M1 (Allwinner H3) with the dongle plugged in works fine with the RTW88 driver
• Your BananaPi M4-ZERO (Allwinner H618) with the dongle plugged in, the RTW88 driver does not load because of some USB error

Is this correct? If so, yes I understand you leaning towards this being an issue with maturity of the Allwinner H618 👍

[pyavitz]

I routinely check and download RTW88 patches. So when I say I applied this patch, it's in conjunction with the others available on lore. Those that have "and in some cases not" been accepted. I don't really see anything in Larry's repo that I'm not already using. Except the AU drivers they are working on.

Ah, understood. Thanks for the clarification! So to boil it down, from your testing:

• You have a USB Wifi dongle which has the RTL8821cu chip
• Your NanoPi M1 (Allwinner H3) with the dongle plugged in works fine with the RTW88 driver
• Your BananaPi M4-ZERO (Allwinner H618) with the dongle plugged in, the RTW88 driver does not load because of some USB error

It is an onboard module over USB. Other than that, yes.

Is this correct? If so, yes I understand you leaning towards this being an issue with maturity of the Allwinner H618 👍

[rpardini]

This has been discussed in the past: There's also some very intricate interactions with firmware here that we're not equipped to handle yet.

Please no one take offense, but it's simply that JetHub's boards (that has shared the Armbian meson64 kernel with all other Amlogics since day 0, and has contributed enormously both to Armbian, u-boot and upstream Linux) needs to be kept working optimally.

We could consider splitting off an Amlogic kernel (hell, we've some 5 or 6 rk3588 kernels) just for "classic" out-of-tree drivers, but doing so will reduce collaboration in the long run; and who wants to rebase twice, etc.

So maybe we can work by identifying the chipsets that need to be kept, agreeing on a staggered release cycle for the kernels involved (meson64 only as far as I can see) so that out-of-tree can catch up (eg don't expect any out-of-tree to work against -rcX kernels before they get released).

[rpardini]

Heck, If I'm not mistaken, there's also interactions between those SDIO chipset and the clock phase issue. Taken together (AP-mode, performance, interactions with firmware, interactions with clock phase) this is as complex as it gets.

[ColorfulRhino]

So maybe we can work by identifying the chipsets that need to be kept, agreeing on a staggered release cycle for the kernels involved (meson64 only as far as I can see) so that out-of-tree can catch up (eg don't expect any out-of-tree to work against -rcX kernels before they get released).

I have updated the approach with a new commit. With this change, the following applies:

• RTL8723CS: Add to every board < 6.10
• RTL8723DS: Add to every board < 6.10, ALSO add to RockPi-S and Asus Tinkerboard Rev.2 regardless of kernel version
• RTL8192EU: Add to every board < 6.10, use RTL8XXXU mainline driver from 6.10 onwards
• RTL8811CU and RTL8821C: Add to every board < 6.10, ALSO add to BananaPi M4 Zero regardless of kernel version (@pyavitz reported issue)

This way, maintainers of these specific boards can decide when it's time to switch to a mainline driver.

Please have a look :)

(rtl88x2cs is not touched by this PR)

[pyavitz]

@ColorfulRhino

I should have been more clear. This should be: USB dongle with Wifi chip tested on the NanoPi M1.
RTL8821CU:

• @pyavitz USB dongle with Wifi chip, used on an NanoPi M1 (Allwinner H3), kernel 6.x.y, has no issues with RTW88.

---

Note for clarity
The BPI-M4-ZERO has an onboard module and continues to have issues with it. BSP and Mainline both suffer.

[ColorfulRhino]

I should have been more clear. This should be: USB dongle with Wifi chip tested on the NanoPi M1. RTL8821CU:

* @pyavitz USB dongle with Wifi chip, used on an NanoPi M1 (Allwinner H3), kernel 6.x.y, has no issues with RTW88.

Note for clarity The BPI-M4-ZERO has an onboard module and continues to have issues with it. BSP and Mainline both suffer.

Thanks for the clarification! I have updated the main post.

[ColorfulRhino]

If another board is found which needs one of those drivers in 6.10+, it can always be added.

[pyavitz]

I would also like to add that there is no consequence when including both RTW88 and the github equivalent, other than the time spent making sure it compiles and functions.

patrick@bpim4zero:~$ lsmod | grep 8821cu
8821cu               2265088  0
rtw88_8821cu           12288  0
rtw88_8821c            86016  1 rtw88_8821cu
rtw88_usb              16384  1 rtw88_8821cu
cfg80211              360448  3 8821cu,rtw88_core,mac80211
patrick@bpim4zero:~$ dmesg | grep 8821cu
[    8.073278] rtw_8821cu 3-1:1.2: Firmware version 24.11.0, H2C version 12
[    8.560844] usbcore: registered new interface driver rtw_8821cu
[    9.079653] usbcore: registered new interface driver rtl8821cu

If both drivers are present, RTW88 has priority and registers first.

[ColorfulRhino]

If both drivers are present, RTW88 has priority and registers first.

Yes, this is true. The goal of this PR is mostly to aid maintainability.
Let's say someone is bumping rk3588 to 6.11, which would be the first, while all other boards/families are still on 6.9 or 6.10 waiting for their maintainers to bump. When the 3rd party drivers are added to every board, this first bump will likely introduce lots of hiccups and incompatibilities concerning those wifi drivers, even though in this case rk3588 boards aren't even using these drivers.

This PR at least reduces this amount of fixing needed and gives the maintainers for the respective board or board family the time to bump, in some case fix and then test the new kernel version on their device. This way they can also take the chance to directly compare and see if the new kernel has improved the compatibility for their boards wifi chip.

[brentr]

@ColorfulRhino
Four days ago, you wrote:

If it's mostly AP mode holding up progress, it's debatable if supporting AP mode for those cheap Realtek chips is even in-scope for the Armbian project, if even nobody on mainline wants to support it properly. These aren't router-class chips after all and Armbian also isn't OpenWRT.
If people want a good and well-supported wifi AP mode chip on Armbian for whatever reason, I'd say just put an M.2 wifi card in your board.

I was unaware that the RTW88 had difficulties with AP mode.
The embedded system we have recently developed requires the RockPi-S to function simultaneously as an AP and WiFi Client. The vendor driver seems to have no problems with this.

Lots of embedded boxes that are not routers (or smartphones) function as WiFi APs.
Just for fun, here's a list of some I personally own:

1. A Samsung clothes drier
2. A fish finding sonar
3. Enphase Envoy (solar array monitor)
4. Electric car charger

[ColorfulRhino]

I was unaware that the RTW88 had difficulties with AP mode.

I didn't check on how many cards this statement might apply, but I can imagine the experience may vary chip by chip. I can only make a guess, but I think AP mode is low priority for mainline since normal end-users (who don't develop a product) with these cheap chips usually use them in client mode to connect their device to the internet.

The embedded system we have recently developed requires the RockPi-S to function simultaneously as an AP and WiFi Client. The vendor driver seems to have no problems with this.

No worries, I have heard your problem. The vendor driver will be there for the RockPi-S for an indefinite period :)

build/lib/functions/compilation/patch/drivers_network.sh

Line 393 in 4331f50

if linux-version compare "${version}" ge 5.0 && (linux-version compare "${version}" le 6.9 || [[ "$BOARD" == rockpi-s || "$BOARD" == tinkerboard-2 ]]); then

Feel free to check back with the mainline driver from time to time, maybe you'll even be able to contribute to the code or tell the specific source of the issue and proposed solution to the devs 😄

I seems like a solution for the RockPi-S might not be too far off, if someone is willing to help. From the issue you sent earlier, lwfinger said:

The reason for poor performance is that rtw88 only copies the MAC from EFUSE and ignores the calibration data, thus the performance problem. If one of you will dig into the vendor driver and tell me what data needs to be copied, then I can prepare a patch.

[adeepn]

I didn't check on how many cards this statement might apply

on all with sdio at least https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/