Add Linux kernel 6.18 compatibility

[Lucid-Duck]

• Replace EXTRA_CFLAGS with ccflags-y (removed in 6.15)
• Replace del_timer_sync with timer_delete_sync (removed in 6.15)
• Replace from_timer with timer_container_of (renamed in 6.16)
• Rename hmac_sha256 to rtw_hmac_sha256 (kernel symbol conflict)
• Add radio_idx parameter to cfg80211 callbacks (6.14+)
• Fix halrf/ include paths for phydm_precomp.h
• Add D-Link DWA-182 device ID (2001:3321)

Tested on Fedora 43 with kernel 6.18.3-200.fc43.x86_64

[Copilot]

Pull request overview

This pull request adds Linux kernel 6.18 compatibility to the RTL8821AU WiFi driver by updating various kernel APIs that changed between versions 6.14-6.18.

Changes:

• Replaced deprecated EXTRA_CFLAGS with ccflags-y throughout the Makefile (removed in kernel 6.15)
• Updated timer APIs: del_timer_sync → timer_delete_sync, from_timer → timer_container_of (kernel 6.15-6.16)
• Added radio_idx parameter to cfg80211 callbacks for kernel 6.14+
• Fixed include paths in halrf/ directory to use relative paths (../phydm_precomp.h)
• Renamed hmac_sha256 functions to rtw_hmac_sha256 to avoid kernel symbol conflicts
• Added USB device ID for D-Link DWA-182 (2001:3321)

Reviewed changes

Copilot reviewed 28 out of 28 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
Makefile	Replaced EXTRA_CFLAGS with ccflags-y and EXTRA_LDFLAGS with ldflags-y for kernel 6.15+ compatibility
include/osdep_service_linux.h	Updated timer APIs with version checks for kernels 6.16+ (timer_container_of, timer_delete_sync)
os_dep/linux/ioctl_cfg80211.c	Added radio_idx parameter to cfg80211 callbacks for kernel 6.14+
os_dep/linux/usb_intf.c	Added D-Link DWA-182 USB device ID
hal/phydm/halrf/*.c	Fixed include paths to use ../phydm_precomp.h
hal/phydm/halrf/*.h	Updated include paths to be relative within halrf directory
hal/phydm/txbf/*.c	Fixed include paths to use ../phydm_precomp.h
core/crypto/sha256.h	Renamed hmac_sha256 functions to rtw_hmac_sha256 to avoid kernel conflicts
core/crypto/sha256.c	Implemented function name changes with updated documentation
core/crypto/sha256-prf.c	Updated function calls to use rtw_hmac_sha256_vector

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Incorrect usage of timer_container_of macro. The first argument should be the variable name to be declared, the second should be the pointer to the timer structure, and the third should be the field name. This line should be: _timer *ptimer = timer_container_of(in_timer, _timer, timer); Similar to how container_of and from_timer work, the first parameter is the containing structure type, second is the pointer to the member, and third is the member field name.

Suggested change

	_timer *ptimer = timer_container_of(ptimer, in_timer, timer);
	_timer *ptimer = timer_container_of(in_timer, _timer, timer);

[Copilot]

The Makefile changes replace EXTRA_CFLAGS with ccflags-y, but also changes USER_EXTRA_CFLAGS to USER_ccflags-y on line 1. This variable name change may break existing build systems or user configurations that set USER_EXTRA_CFLAGS as an environment variable or build parameter. Consider keeping USER_EXTRA_CFLAGS for backward compatibility.

[Copilot]

While ldflags-y is the correct modern replacement for EXTRA_LDFLAGS in kernel module builds, ensure that this change is compatible with the minimum kernel version supported by this driver. If the driver needs to support kernels older than when ldflags-y was introduced, conditional handling may be needed.

Suggested change

	ldflags-y += --strip-debug
	ldflags-y += --strip-debug
	EXTRA_LDFLAGS += --strip-debug

[Copilot]

The timer_delete_sync and timer_delete functions were introduced in kernel 6.15 as replacements for del_timer_sync and del_timer. These changes should be wrapped in version checks to maintain compatibility with older kernels. Consider adding conditional compilation similar to other version-dependent code in this file.

[morrownr]

Hi @Lucid-Duck

Let me suggest that we make a deal.

I'll review this PR with the intention to merge it if you agree to take a look at the new code in the kernel with AI with the intention to create PR's if any reports appear to need patches and you teach me how to use Co-Pilot or other AI to review driver code. If you agree, I can create an issue over in rtw88 (see below) for us to communicate.

Here is my agenda: I see it as a good thing to get Linux wifi driver coders of all experience levels over to working on the modern Wireless API's. We used the following repo for development of the Realtek WiFi 5 USB mac80211 drivers:

https://github.com/lwfinger/rtw88

My intention was to stop api updates on this driver with kernel 6.14 as that is when the new driver was fully in mainline and the above repo allows users to install said in-kernel driver on kernels all the way back to 5.4. My thoughts were that this should be adequate support and it would encourage moving to the future with a dev model that supports regular end users which should encourage non-technical users to adopt Linux.

@morrownr

[Lucid-Duck]

Hi @morrownr

That sounds good to me, and I appreciate the offer.

I’m very much in agreement with the goal of moving people toward the in-kernel mac80211 drivers and away from long-term reliance on legacy out-of-tree code. My initial work on rtw88 came from trying to understand why this particular device behaved so poorly with the in-kernel rtw88 driver, not from any desire to keep the older driver alive indefinitely.

I’m happy to take a look at reports or issues that come up around rtw88 and help triage or propose patches where it makes sense. I’m still learning the internals, so I’d approach that carefully and keep changes small and well-justified.

On the AI side, I’m not doing anything exotic. I treat it as an accelerated code-reading and pattern-matching tool, similar to a very fast grep plus a second set of eyes. All changes still go through manual reasoning, builds, and testing on real hardware. I’m happy to walk through how I use it for review and exploration if that’s useful.

Opening an issue in the rtw88 repo for coordination makes sense to me.

Thanks again for taking the time to review the PR.

[dubhater]

Tested on Fedora 43 with kernel 6.18.3-200.fc43.x86_64

I wonder, what did that testing look like?

[Lucid-Duck]

Tested on Fedora 43 with kernel 6.18.3-200.fc43.x86_64

I wonder, what did that testing look like?

Testing on Fedora was iterative and focused on basic bring-up after each change.

On Fedora 43 (kernel 6.18.3-200.fc43.x86_64):

• Applied a small set of compatibility changes

• Rebuilt the driver (make -j)

• Installed and updated module dependencies (make install, depmod -a)

• Loaded the module (modprobe 8821au)

• Verified device enumeration (lsusb shows 2001:3321)

• Verified interface creation (ip link show)

• Checked driver state and capabilities (modinfo 8821au, iw list)

This cycle was repeated across multiple reboots and physical replug cycles to confirm consistent behavior. Testing was limited to basic functionality and stability rather than performance or extended runtime use.

[dubhater]

All right. Well, your testing missed something.

[a5a5aa555oo]

The ID 2001:3321 belongs to D-Link DWA-X1850, a 802.11ax (Wi-Fi 6) adapter using RTL8832AU chip. It is really weird you said this RTL8821AU driver worked for that device.

[Lucid-Duck]

The ID 2001:3321 belongs to D-Link DWA-X1850, a 802.11ax (Wi-Fi 6) adapter using RTL8832AU chip. It is really weird you said this RTL8821AU driver worked for that device.

The identification was based on direct register reads and driver behavior, not solely on the USB ID.

On this device, chip version registers and init paths match RTL8821AU/8812A-class silicon, and the 8821au driver brings the device up successfully on bare metal.

I agree the VID/PID association is confusing, and it’s possible this ID is reused across multiple D-Link products or revisions. If there’s a definitive way to distinguish between 8821AU and 8832AU at runtime, I’m happy to add that to the notes.

[dubhater]

What does lsusb -tv say?

[morrownr]

@Lucid-Duck

On this device, chip version registers and init paths match RTL8821AU/8812A-class silicon, and the 8821au driver brings the device up successfully on bare metal.

Respectfully, I don't buy this. I noticed the addition of a VID/PID when I took an initial look at the PR and I thought that was strange because we are talking about a 13 year old chip. I haven't seen a new VID/PID for the rtl8821/11au chip in years..because nobody is coming out with new adapters with this chip and have not for years. You can still buy some adapters with this chip.

I agree with @a5a5aa555oo , the VID/PID is a D-Link specific ID and it shows to be in a WiFi 6 product with the rtl8852/32au chip. The driver in this repo is not going to work with that chip. No way. The only thing I can think of is that you have multiple wifi devices in your system and there is confusion going on. It happens.

Like @dubhater , I would to see the result of:

lsusb -tv

[Lucid-Duck]

You were right. I rechecked the physical label on the device:

Model: DWA-X1850A1

FCC ID: KA2WAX1850A1

This is a DWA-X1850 (RTL8832AU), not a DWA-182. I misidentified the hardware.
I've pushed a commit removing the device ID from the 8821au driver. The kernel compatibility patches themselves should still be valid.
For anyone else with this device: it works with https://github.com/morrownr/rtw89.

Apologies for the confusion.

[Lucid-Duck]

Hey, re-reading your earlier message — sounds like you're winding down 8821au support anyway. I've moved on to rtw89 upstream (patches on linux-wireless now). Still happy to chat about the AI stuff if you're interested.

[morrownr]

@Lucid-Duck

Yes, I have trying to move users of these older drivers over to the newer rtw88 USB drivers. I'm leaving this driver up just in case someone can make use of it but have message posted letting folks know about the rtw88 repo and the in-kernel drivers.

On another subject, I tested the following patch today:

https://patchwork.kernel.org/project/linux-wireless/patch/20260125222235.36565-1-lucid_duck@justthetip.ca/

I sent a reply back saying that the twpower reading that I saw after applying the patch is not correct but sometimes messages don't make it. What do you think about me creating a new issue/thread over in USB-WiFi where we can discuss this topic as this txpower thing really needs to be fixed?