[PATCH rtw-next] wifi: rtw89: allocate rfe_data with kvzalloc

[PATCH rtw-next] wifi: rtw89: allocate rfe_data with kvzalloc

[rcfa]

struct rtw89_rfe_data holds the TX power tables from the firmware
file's elements and is 1190784 bytes, so kzalloc() asks for an order-9
(2 MiB) contiguous block. On a host that has been up for a while there
may be none, and probing a USB adapter that is plugged in then fails:

  kworker/12:1: page allocation failure: order:9, mode:0x40dc0(GFP_KERNEL|__GFP_ZERO|__GFP_COMP)
  ...
  failed to recognize firmware elements
  failed to setup chip information
  probe with driver rtw89_8922au_git failed with error -12

Only the CPU reads the tables, so allocate them with kvzalloc() and
free them with kvfree().

Tested on an RTL8922AU (a USB 2 adapter) with the out-of-tree copy of
this driver (morrownr/rtw89, which carries rtw-next as of 2026-11-05;
hence the module name above), kernel 7.2.15. The failure came from
replugging the adapter after 16 hours of uptime, when the Normal zone
had no free block of order 8 or above. With this change the driver
probes, connects and unloads cleanly. A test build that always used
vzalloc() for rfe_data, to exercise the fallback path, put the tables in
vmalloc space (1196032 bytes in /proc/vmallocinfo), showed the same
debugfs txpwr_table as the unchanged driver on the same association,
passed traffic and unloaded without warnings.

The problem was found with Claude Code (Claude Opus 5.5) while testing
the driver, and this change and changelog were written in the same
session.

Fixes: 5ee7b2ea07cc ("wifi: rtw89: load TX power related tables from FW elements")
Signed-off-by: rcfa <kernel@cubiculum.net>
---
 drivers/net/wireless/realtek/rtw89/core.c | 2 +-
 drivers/net/wireless/realtek/rtw89/fw.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
index 58ee5efc3b5e..ec5d47cfe2ef 100644
--- a/drivers/net/wireless/realtek/rtw89/core.c
+++ b/drivers/net/wireless/realtek/rtw89/core.c
@@ -7730,7 +7730,7 @@ EXPORT_SYMBOL(rtw89_alloc_ieee80211_hw);
 void rtw89_free_ieee80211_hw(struct rtw89_dev *rtwdev)
 {
 	kfree(rtwdev->ops);
-	kfree(rtwdev->rfe_data);
+	kvfree(rtwdev->rfe_data);
 	release_firmware(rtwdev->fw.req.firmware);
 	ieee80211_free_hw(rtwdev->hw);
 }
diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index ea7dba077f5d..55548bd82498 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -1283,7 +1283,7 @@ int rtw89_fw_recognize_txpwr_from_elm(struct rtw89_dev *rtwdev,
 		return 1;
 
 	if (!rtwdev->rfe_data) {
-		rtwdev->rfe_data = kzalloc_obj(*rtwdev->rfe_data);
+		rtwdev->rfe_data = kvzalloc_obj(*rtwdev->rfe_data);
 		if (!rtwdev->rfe_data)
 			return -ENOMEM;
 	}

base-commit: dc16902cad9c6b08df9395a510c7be44fbab545d
-- 
2.53.0

RE: [PATCH rtw-next] wifi: rtw89: allocate rfe_data with kvzalloc

[Ping-Ke Shih]

rcfa <kernel@cubiculum.net> wrote:
> struct rtw89_rfe_data holds the TX power tables from the firmware
> file's elements and is 1190784 bytes, so kzalloc() asks for an order-9
> (2 MiB) contiguous block. On a host that has been up for a while there
> may be none, and probing a USB adapter that is plugged in then fails:
> 
>   kworker/12:1: page allocation failure: order:9, mode:0x40dc0(GFP_KERNEL|__GFP_ZERO|__GFP_COMP)
>   ...
>   failed to recognize firmware elements
>   failed to setup chip information
>   probe with driver rtw89_8922au_git failed with error -12

Below commit messages are not necessary except to 
"Tested on an RTL8922AU (a USB 2 adapter)"

> 
> Only the CPU reads the tables, so allocate them with kvzalloc() and
> free them with kvfree().
> 
> Tested on an RTL8922AU (a USB 2 adapter) with the out-of-tree copy of
> this driver (morrownr/rtw89, which carries rtw-next as of 2026-11-05;
> hence the module name above), kernel 7.2.15. The failure came from
> replugging the adapter after 16 hours of uptime, when the Normal zone
> had no free block of order 8 or above. With this change the driver
> probes, connects and unloads cleanly. A test build that always used
> vzalloc() for rfe_data, to exercise the fallback path, put the tables in
> vmalloc space (1196032 bytes in /proc/vmallocinfo), showed the same
> debugfs txpwr_table as the unchanged driver on the same association,
> passed traffic and unloaded without warnings.
> 
> The problem was found with Claude Code (Claude Opus 5.5) while testing
> the driver, and this change and changelog were written in the same
> session.
> 
> Fixes: 5ee7b2ea07cc ("wifi: rtw89: load TX power related tables from FW elements")
> Signed-off-by: rcfa <kernel@cubiculum.net>

Use your real name.