fix: failing builds for kernel versions >= 6.13/14/15

[natimerry]

c65ed43 fixes builds for kernel versions 6.13 and is based on the patch from #110

91d168f fixes builds for kernel versions 6.14 by updating cfg80211_rtw_get_txpower

[liaten]

Thanks! Your changes helped me

[xlmnxp]

@lwfinger this MR fix building the module in Linux 6.13 and above
I think it better be merged

[lonyelon]

Guys, stop pinging Larry, he sadly passed away last year:

• https://pubs.geoscienceworld.org/msa/ammin/article/109/10/1839/648646/Memorial-of-Larry-Wayne-Finger-1940-2024
• https://lore.kernel.org/linux-wireless/ds6wc3svkyre4p2rwg4f76o67xndazaeoyjwblhuzichscyxoz@5ttdvbymxr55/T/#mfd2f4928e0e013c10375ca766035c1385e18f8e0

If any of you want to take over the repo and keep it alive, you are welcome to fork it, but do not expect a merge here.

[xlmnxp]

Guys, stop pinging Larry, he sadly passed away last year:

• https://pubs.geoscienceworld.org/msa/ammin/article/109/10/1839/648646/Memorial-of-Larry-Wayne-Finger-1940-2024
• https://lore.kernel.org/linux-wireless/ds6wc3svkyre4p2rwg4f76o67xndazaeoyjwblhuzichscyxoz@5ttdvbymxr55/T/#mfd2f4928e0e013c10375ca766035c1385e18f8e0

If any of you want to take over the repo and keep it alive, you are welcome to fork it, but do not expect a merge here.

That sad, RIP
I didn't know 😕

[lonyelon]

I sent a ticket to GitHub, should have done it last year but I thought someone was to take over. Let's see if we can at least get a warning in the README.

[Davidooff]

Thx man. Rip Larry

[natimerry]

I sent a ticket to GitHub, should have done it last year but I thought someone was to take over. Let's see if we can at least get a warning in the README.

Thanks for the information. I'm really sorry to hear we lost him.

I will be maintaining my fork for the foreseeable future, I am keeping this issue open for visibility.

[Davidooff]

[david@archlinux rtl8852au]$ make
#rm -f .symvers.8852au
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/6.15.2-arch1-1/build M=/home/david/rtl8852au modules
make[1]: Entering directory '/usr/lib/modules/6.15.2-arch1-1/build'
make[2]: Entering directory '/home/david/rtl8852au'
CC [M] core/rtw_security.o
In file included from ././include/drv_types.h:52,
from core/rtw_security.c:17:
core/rtw_security.c: In function ‘rtw_tkip_encrypt’:
././include/rtw_security.h:337:26: error: ‘union pn48’ has no member named ‘byte’
337 | dot11txpn.byte.TSC0 = iv[2];
| ^
core/rtw_security.c:744:17: note: in expansion of macro ‘GET_TKIP_PN’
744 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:338:26: error: ‘union pn48’ has no member named ‘byte’
338 | dot11txpn.byte.TSC1 = iv[0];
| ^
core/rtw_security.c:744:17: note: in expansion of macro ‘GET_TKIP_PN’
744 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:339:26: error: ‘union pn48’ has no member named ‘byte’
339 | dot11txpn.byte.TSC2 = iv[4];
| ^
core/rtw_security.c:744:17: note: in expansion of macro ‘GET_TKIP_PN’
744 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:340:26: error: ‘union pn48’ has no member named ‘byte’
340 | dot11txpn.byte.TSC3 = iv[5];
| ^
core/rtw_security.c:744:17: note: in expansion of macro ‘GET_TKIP_PN’
744 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:341:26: error: ‘union pn48’ has no member named ‘byte’
341 | dot11txpn.byte.TSC4 = iv[6];
| ^
core/rtw_security.c:744:17: note: in expansion of macro ‘GET_TKIP_PN’
744 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:342:26: error: ‘union pn48’ has no member named ‘byte’
342 | dot11txpn.byte.TSC5 = iv[7];
| ^
core/rtw_security.c:744:17: note: in expansion of macro ‘GET_TKIP_PN’
744 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
core/rtw_security.c: In function ‘rtw_tkip_decrypt’:
././include/rtw_security.h:337:26: error: ‘union pn48’ has no member named ‘byte’
337 | dot11txpn.byte.TSC0 = iv[2];
| ^
core/rtw_security.c:842:25: note: in expansion of macro ‘GET_TKIP_PN’
842 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:338:26: error: ‘union pn48’ has no member named ‘byte’
338 | dot11txpn.byte.TSC1 = iv[0];
| ^
core/rtw_security.c:842:25: note: in expansion of macro ‘GET_TKIP_PN’
842 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:339:26: error: ‘union pn48’ has no member named ‘byte’
339 | dot11txpn.byte.TSC2 = iv[4];
| ^
core/rtw_security.c:842:25: note: in expansion of macro ‘GET_TKIP_PN’
842 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:340:26: error: ‘union pn48’ has no member named ‘byte’
340 | dot11txpn.byte.TSC3 = iv[5];
| ^
core/rtw_security.c:842:25: note: in expansion of macro ‘GET_TKIP_PN’
842 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:341:26: error: ‘union pn48’ has no member named ‘byte’
341 | dot11txpn.byte.TSC4 = iv[6];
| ^
core/rtw_security.c:842:25: note: in expansion of macro ‘GET_TKIP_PN’
842 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
././include/rtw_security.h:342:26: error: ‘union pn48’ has no member named ‘byte’
342 | dot11txpn.byte.TSC5 = iv[7];
| ^
core/rtw_security.c:842:25: note: in expansion of macro ‘GET_TKIP_PN’
842 | GET_TKIP_PN(iv, dot11txpn);
| ^~~~~~~~~~~
make[4]: *** [/usr/lib/modules/6.15.2-arch1-1/build/scripts/Makefile.build:203: core/rtw_security.o] Error 1
make[3]: *** [/usr/lib/modules/6.15.2-arch1-1/build/Makefile:2003: .] Error 2
make[2]: *** [/usr/lib/modules/6.15.2-arch1-1/build/Makefile:248: __sub-make] Error 2
make[2]: Leaving directory '/home/david/rtl8852au'
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.15.2-arch1-1/build'
make: *** [Makefile:639: modules] Error 2

[natimerry]

@Davidooff

So this is a breaking change with archlinux dropping some flags off their kernel config. So the only way to get this working is using something like the cachyos kernel or fedora kernel and stuff.

I think I can fix it but its work im not willing to put in and will direct my time to try get rtl8852au support in rtw89 (which attempts broader compatibility) after I start with university.

[natimerry]

Furthermore I have 0 experience in network devices so its gonna be a learning curve for me

[Calychas]

Hey! Thanks for the amazing work!
Just letting you know that I encountered the same issue as Davidooff for Liquorix 6.15.2 and stock 6.15.3

[dubhater]

So this is a breaking change with archlinux dropping some flags off their kernel config. So the only way to get this working is using something like the cachyos kernel or fedora kernel and stuff.

@natimerry Are they aware they broke some drivers? (It's not just this one.)

[dmanlfc]

If you add -I$(@D)/core/crypto -I$(@D)/os_dep/linux to the USER_EXTRA_CFLAGS you can compile further however there are still errors.

core/rtw_scan.c: In function ‘_rtw_wait_scan_done’:
core/rtw_scan.c:215:17: error: implicit declaration of function ‘rtw_cfg80211_get_is_roch’ [-Werror=implicit-function-declaration]
  215 |         while ((rtw_cfg80211_get_is_roch(adapter) == _TRUE || check_fwstate(pmlmepriv, WIFI_UNDER_SURVEY))
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~
core/rtw_scan.c: At top level:
core/rtw_scan.c:2100:34: error: field ‘channel’ has incomplete type
 2100 |         struct ieee80211_channel channel;
      |                                  ^~~~~~~
core/rtw_scan.c: In function ‘roch_ready_cb’:
core/rtw_scan.c:2839:26: error: ‘_adapter’ {aka ‘struct _ADAPTER’} has no member named ‘cfg80211_rochinfo’
 2839 |                 &padapter->cfg80211_rochinfo;
      |                          ^~
core/rtw_scan.c:2849:9: error: implicit declaration of function ‘rtw_cfg80211_ready_on_channel’ [-Werror=implicit-function-declaration]
 2849 |         rtw_cfg80211_ready_on_channel(
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from core/rtw_scan.c:15:
core/rtw_scan.c: In function ‘p2p_roch_complete_cb’:
././include/drv_types.h:1731:48: error: ‘_adapter’ {aka ‘struct _ADAPTER’} has no member named ‘wdev_data’
 1731 | #define adapter_wdev_data(adapter) (&((adapter)->wdev_data))
      |                                                ^~
core/rtw_scan.c:2880:44: note: in expansion of macro ‘adapter_wdev_data’
 2880 |         struct rtw_wdev_priv *pwdev_priv = adapter_wdev_data(padapter);
      |                                            ^~~~~~~~~~~~~~~~~
core/rtw_scan.c:2882:26: error: ‘_adapter’ {aka ‘struct _ADAPTER’} has no member named ‘cfg80211_rochinfo’
 2882 |                 &padapter->cfg80211_rochinfo;
      |                          ^~
core/rtw_scan.c:2905:9: error: implicit declaration of function ‘rtw_cfg80211_set_is_roch’ [-Werror=implicit-function-declaration]
 2905 |         rtw_cfg80211_set_is_roch(padapter, _FALSE);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~
core/rtw_scan.c:2906:27: error: invalid use of undefined type ‘struct cfg80211_roch_info’
 2906 |         pcfg80211_rochinfo->ro_ch_wdev = NULL;
      |                           ^~
core/rtw_scan.c:2907:9: error: implicit declaration of function ‘rtw_cfg80211_set_last_ro_ch_time’ [-Werror=implicit-function-declaration]
 2907 |         rtw_cfg80211_set_last_ro_ch_time(padapter);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
core/rtw_scan.c:2912:9: error: implicit declaration of function ‘rtw_cfg80211_remain_on_channel_expired’ [-Werror=implicit-function-declaration]
 2912 |         rtw_cfg80211_remain_on_channel_expired(scan_priv->wdev
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
core/rtw_scan.c: In function ‘p2p_roch_start_cb’:
core/rtw_scan.c:2946:39: error: ‘_adapter’ {aka ‘struct _ADAPTER’} has no member named ‘cfg80211_rochinfo’
 2946 |         pcfg80211_rochinfo = &padapter->cfg80211_rochinfo;
      |                                       ^~
core/rtw_scan.c:2965:27: error: invalid use of undefined type ‘struct cfg80211_roch_info’
 2965 |         pcfg80211_rochinfo->ro_ch_wdev = scan_priv->wdev;
      |                           ^~
core/rtw_scan.c:2966:27: error: invalid use of undefined type ‘struct cfg80211_roch_info’
 2966 |         pcfg80211_rochinfo->remain_on_ch_cookie = scan_priv->cookie;
      |                           ^~
core/rtw_scan.c:2967:27: error: invalid use of undefined type ‘struct cfg80211_roch_info’
 2967 |         pcfg80211_rochinfo->duration = scan_priv->duration;
      |                           ^~
core/rtw_scan.c:2969:40: error: invalid use of undefined type ‘struct cfg80211_roch_info’
 2969 |         _rtw_memcpy(&pcfg80211_rochinfo->remain_on_ch_channel,
      |                                        ^~
core/rtw_scan.c:2970:45: error: invalid application of ‘sizeof’ to incomplete type ‘struct ieee80211_channel’
 2970 |                 &scan_priv->channel, sizeof(struct ieee80211_channel));
      |                                             ^~~~~~
core/rtw_scan.c:2974:27: error: invalid use of undefined type ‘struct cfg80211_roch_info’
 2974 |         pcfg80211_rochinfo->restore_channel = scan_priv->restore_ch;
      |                           ^~
core/rtw_scan.c: In function ‘roch_complete_cb’:
core/rtw_scan.c:3003:26: error: ‘_adapter’ {aka ‘struct _ADAPTER’} has no member named ‘cfg80211_rochinfo’
 3003 |                 &padapter->cfg80211_rochinfo;
      |                          ^~
cc1: some warnings being treated as errors
make[4]: *** [/x86_64/build/linux-6.15.3/scripts/Makefile.build:203: core/rtw_scan.o] Error 1
make[4]: *** Waiting for unfinished jobs....

[natimerry]

So this is a breaking change with archlinux dropping some flags off their kernel config. So the only way to get this working is using something like the cachyos kernel or fedora kernel and stuff.

@natimerry Are they aware they broke some drivers? (It's not just this one.)

I dont think so, however this one is fixed by not throwing errors on a bunch of warnings. Is there any channel to report it to them?

@dubhater

[dmanlfc]

builds now, thanks @natimerry

[natimerry]

builds now, thanks @natimerry

All thanks to @a5a5aa555oo

[dubhater]

@natimerry Here: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/new

[natimerry]

@dubhater can you link me some of the other drivers that fail to build, I will make a issue referencing those too tonight then

[dubhater]

Now that I looked for them, I can only find reports about #include <drv_types.h> (bad code? should it be #include "drv_types.h"?) and reports where the kernel is 6.15 but not the official Arch kernel.

[a5a5aa555oo]

So this is a breaking change with archlinux dropping some flags off their kernel config.

@dubhater

This is incorret. I have found the causes why this driver can't be built on Arch Linux and fixed it yesterday. I don't think Arch Linux's kernel 6.15 is problematic.

[natimerry]

Hey @a5a5aa555oo

In this case, the driver built successfully under Cachy, Fedora, and Ubuntu kernels—only Arch Linux failed to build it until your patch. This suggests there may have been a configuration switch or packaging change specific to Arch. Even though the issue may now be fixed, I’d still like to report it to understand the rationale behind the change. If it turns out to be a regression, it could be affecting other out-of-tree drivers as well, and possibly should be reverted.

As for the specific build failure with this driver: it was entirely due to my oversight—I was still using EXTRA_CFLAGS, which I should have replaced. That said, Arch must have dropped support for EXTRA_CFLAGS, which is likely why the build was breaking only there.

To clarify, I understand that its not the kernel completely removing support for the driver and rather changing how the kernel doesn't accept EXTRA_CFLAGS, and I woild raise an issue to understand this breakage and report some drivers (especially older and unmantained ones) will break because of this

[natimerry]

Now that I looked for them, I can only find reports about #include <drv_types.h> (bad code? should it be #include "drv_types.h"?) and reports where the kernel is 6.15 but not the official Arch kernel.

@dubhater

I think this driver hit the same issue—EXTRA_CFLAGS was used to set an include path, but since that's ignored by the kernel build system now (at least on Arch), the path never makes it to the compiler. Switching to ccflags-y resolves it.

Again I think its worth raising an issue to atleast get the rationale for this change.

[a5a5aa555oo]

Arch must have dropped support for EXTRA_CFLAGS, which is likely why the build was breaking only there.

Correct!!!

torvalds/linux@e966ad0

Actually the support for EXTRA_CFLAGS has been removed since 6.15, but I guess the kernel maintainers of CachyOS decided not to merge the patch above for compatibility reason, so on CachyOS, both ccflags-y and EXTRA_FLAGS are effective.

But, unfortunately on Arch Linux, kernel 6.15 doesn't support EXTRA_CFLAGS anymore, this is why the driver failed to build on Arch.

[natimerry]

Arch must have dropped support for EXTRA_CFLAGS, which is likely why the build was breaking only there.

Correct!!!

torvalds/linux@e966ad0

Actually the support for EXTRA_CFLAGS has been removed since 6.15, but I guess the kernel maintainers of CachyOS decided not to merge that patch for compatibility reason, so on CachyOS, both ccflags-y and EXTRA_FLAGS are effective.

But, unfortunately on Arch Linux, kernel 6.15 doesn't support EXTRA_CFLAGS anymore, this is why the driver failed to build on Arch.

So its completely removed. Apologies for not being able to search for it myself, im on a mobile phone.

Anyhow in this case there's no real point in reporting stuff to Arch and rather just port drivers with this problem (to be fair drivers still using EXTRA_CFLAGS will probably have bigger issues) to use ccflags-y

[LMS5413]

Now that I looked for them, I can only find reports about #include <drv_types.h> (bad code? should it be #include "drv_types.h"?) and reports where the kernel is 6.15 but not the official Arch kernel.

@dubhater

I think this driver hit the same issue—EXTRA_CFLAGS was used to set an include path, but since that's ignored by the kernel build system now (at least on Arch), the path never makes it to the compiler. Switching to ccflags-y resolves it.

Again I think its worth raising an issue to atleast get the rationale for this change.

Same issue in Fedora 42

[a5a5aa555oo]

@LMS5413

Try the driver in @natimerry's repo. https://github.com/natimerry/rtl8852au

[LMS5413]

@LMS5413

Try the driver in @natimerry's repo. https://github.com/natimerry/rtl8852au

It's works! Thanks

[andrewjwhite149]

This PR fixed my issues on 6.14. Thanks!

[bayunquan]

Guys, stop pinging Larry, he sadly passed away last year:

* https://pubs.geoscienceworld.org/msa/ammin/article/109/10/1839/648646/Memorial-of-Larry-Wayne-Finger-1940-2024

* https://lore.kernel.org/linux-wireless/ds6wc3svkyre4p2rwg4f76o67xndazaeoyjwblhuzichscyxoz@5ttdvbymxr55/T/#mfd2f4928e0e013c10375ca766035c1385e18f8e0

If any of you want to take over the repo and keep it alive, you are welcome to fork it, but do not expect a merge here.

RIP Larry

[ferjorosa]

Hi, just in case is useful for anyone. I was able to make it work thanks to Sonnet 4.5 with the following changes (included a README for explainability):

dwa-x1850...ferjorosa:rtl8852au:dwa-x1850

[peter-avila]

Guys, stop pinging Larry, he sadly passed away last year:

• https://pubs.geoscienceworld.org/msa/ammin/article/109/10/1839/648646/Memorial-of-Larry-Wayne-Finger-1940-2024
• https://lore.kernel.org/linux-wireless/ds6wc3svkyre4p2rwg4f76o67xndazaeoyjwblhuzichscyxoz@5ttdvbymxr55/T/#mfd2f4928e0e013c10375ca766035c1385e18f8e0

If any of you want to take over the repo and keep it alive, you are welcome to fork it, but do not expect a merge here.

Oh no. RIP.

[peter-avila]

c65ed43 fixes builds for kernel versions 6.13 and is based on the patch from #110

91d168f fixes builds for kernel versions 6.14 by updating cfg80211_rtw_get_txpower

Thanks for this. I rebuilt a device on Debian Trixie on 6.12 and it didn't build. I just updated it on my local copy and was about to make a PR, lol. I should have checked first. It would have saved so much time, lol.