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

[Ping-Ke Shih <pkshih@realtek.com>]

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.