* RE: [PATCH v2 7/9] wifi: rtw89: switch to using FIELD_GET_SIGNED()
From: Ping-Ke Shih @ 2026-04-29 0:40 UTC (permalink / raw)
To: Yury Norov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Jonathan Cameron, David Lechner, Johannes Berg, David Laight,
Nuno Sá, Andy Shevchenko, Richard Cochran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexandre Belloni, Yury Norov, Rasmus Villemoes, Hans de Goede,
Linus Walleij, Sakari Ailus, Salah Triki, Achim Gratz,
Ben Collins, x86@kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-rtc@vger.kernel.org
In-Reply-To: <20260427214127.406067-8-ynorov@nvidia.com>
Yury Norov <ynorov@nvidia.com> wrote:
> Switch from sign_extend32(FIELD_GET()) to the dedicated
> FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* RE: [PATCH v2 7/9] wifi: rtw89: switch to using FIELD_GET_SIGNED()
From: Ping-Ke Shih @ 2026-04-29 0:39 UTC (permalink / raw)
To: David Laight, Andy Shevchenko
Cc: Yury Norov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Jonathan Cameron, David Lechner, Johannes Berg, Nuno Sá,
Andy Shevchenko, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-rtc@vger.kernel.org
In-Reply-To: <20260428114342.0d674fd8@pumpkin>
David Laight <david.laight.linux@gmail.com> wrote:
>
> On Tue, 28 Apr 2026 10:10:22 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Mon, Apr 27, 2026 at 05:41:24PM -0400, Yury Norov wrote:
> > > Switch from sign_extend32(FIELD_GET()) to the dedicated
> > > FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
> >
> > ...
> >
> > > for (i = 0; i < ADDC_T_AVG; i++) {
> > > tmp = rtw89_phy_read32_mask(rtwdev, R_DBG32_D, MASKDWORD);
> > > - dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > > - dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > > + dc_re += FIELD_GET_SIGNED(0xfff000, tmp);
> > > + dc_im += FIELD_GET_SIGNED(0xfff, tmp);
> >
> > In the same driver the GENMASK() is being used, why not doing it here while at it?
>
> To me those bit masks look more readable than the GENMASK() calls would be.
Either way is fine to me. As we rewrite these into rtw89, using GENMASK()
can be easier to check if vendor driver defines the masks correctly, no
overlap.
Ping-Ke
^ permalink raw reply
* Re: [PATCH 0/9] Support for block device NVMEM providers
From: Andrew Lunn @ 2026-04-29 1:05 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-mmc, devicetree, linux-kernel, linux-arm-msm,
linux-block, linux-wireless, ath10k, linux-bluetooth, netdev,
daniel
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
> Note that this is currently limited to eMMC-backed block devices, as
> only the eMMC core associates a firmware node with the block device
> (add_disk_fwnode). This can be easily extended in the future to
> support additional block drivers.
Would this be
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/mmc/core/block.c#L2641
Looking at that function, mmc_blk_alloc_req() i don't see it doing
anything different between an eMMC and MMC.
An eMMC you don't expect to go away, since it is soldered
down. However an MMC can be ejected. Is the code prepared for that?
Andrew
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers
From: Ping-Ke Shih @ 2026-04-29 2:52 UTC (permalink / raw)
To: Christos Longros, Ping-Ke Shih
Cc: linux-wireless, linux-kernel, Christos Longros
In-Reply-To: <20260329073857.113081-1-chris.longros@gmail.com>
Christos Longros <chris.longros@gmail.com> wrote:
> rtw89 stores an ieee80211_hw pointer via pci_set_drvdata() at probe
> time, but io_error_detected() and io_resume() retrieve it as a
> net_device pointer. This causes netif_device_detach/attach to
> operate on an ieee80211_hw struct, reading and writing at wrong
> offsets. The adjacent io_slot_reset() already does it correctly.
>
> Use ieee80211_stop_queues/wake_queues instead, consistent with
> every other queue stop/start path in the driver.
>
> Tested on RTL8852CE by calling the handlers from a test module
> before and after the fix.
>
> Signed-off-by: Christos Longros <chris.longros@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
7068c379cf9a wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v2] rtlwifi: rtl8821ae: Remove dead code in rtl8821ae_update_hal_rate_table()
From: Ping-Ke Shih @ 2026-04-29 2:55 UTC (permalink / raw)
To: Chelsy Ratnawat, pkshih
Cc: colin.i.king, johannes.berg, bhelgaas, arnd, linux-wireless,
Chelsy Ratnawat
In-Reply-To: <20260407123427.14612-1-chelsyratnawat2001@gmail.com>
Chelsy Ratnawat <chelsyratnawat2001@gmail.com> wrote:
> The variable 'mimo_ps' is initialized to IEEE80211_SMPS_OFF and never
> modified throughout the function. This makes the condition checking for
> IEEE80211_SMPS_STATIC always evaluate to false, rendering the entire
> if-branch unreachable dead code.
>
> The error was reported by Coverity Scan.
>
> Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
d603f2cfa623 wifi: rtlwifi: rtl8821ae: Remove dead code in rtl8821ae_update_hal_rate_table()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers
From: Ping-Ke Shih @ 2026-04-29 2:58 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: timlee
In-Reply-To: <20260413065926.17027-1-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Chin-Yen Lee <timlee@realtek.com>
>
> rtw88 stores an ieee80211_hw pointer via pci_set_drvdata() at probe
> time, but io_error_detected() and io_resume() retrieve it as a
> net_device pointer. This causes netif_device_detach/attach to
> operate on an ieee80211_hw struct, reading and writing at wrong
> offsets.
>
> Use ieee80211_stop_queues/wake_queues instead, consistent with
> every other queue stop/start path in the driver.
>
> Fixes: cdb82c80b934 ("wifi: rtw88: pci: add PCI Express error handling")
> Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
706183dbef4a wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next 1/3] wifi: rtl8xxxu: validate action frame size before using in rtl8xxxu_dump_action()
From: Ping-Ke Shih @ 2026-04-29 3:02 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: Jes.Sorensen
In-Reply-To: <20260414062229.21047-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> The rtl8xxxu_dump_action() is to print action frames when turning on
> debug mask. Validate the skb->len size to prevent potential broken in
> monitor mode injection.
>
> Compile tested only.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
3 patch(es) applied to rtw-next branch of rtw.git, thanks.
26769329c40a wifi: rtl8xxxu: validate action frame size before using in rtl8xxxu_dump_action()
c9f10419c38e wifi: rtlwifi: validate action frame size in rtl_action_proc()
043f09bb78dd wifi: rtlwifi: validate action frame size before using in _rtl_pci_tx_isr()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()
From: Ping-Ke Shih @ 2026-04-29 3:08 UTC (permalink / raw)
To: Panagiotis Petrakopoulos, pkshih
Cc: linux-wireless, Panagiotis Petrakopoulos, Oleksandr Havrylov
In-Reply-To: <20260415052959.14844-1-npetrakopoulos2003@gmail.com>
Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com> wrote:
> It was recently reported that rtw_fw_adaptivity_result()
> in fw.c dereferences rtwdev->chip->edcca_th without
> a NULL check. The issue is that devices with the
> 8821CE chip don't define edcca_th in their chip
> info. As a result, when rtw_fw_adaptivity_result()
> tries to dereference it, the kernel triggers an oops.
>
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c. Placing
> the check at the function entry avoids logging any
> garbage values.
>
> This change does not address the root cause for
> this behavior, but it prevents the NULL dereference
> and the resulting oops while a more permanent solution
> is developed.
>
> Tested on a 8822CE chip which defines edcca_th, so
> this issue is not present on it, but it still uses
> this driver and I can verify there are no regressions.
>
> Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
> Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
> Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
1 patch applied to rtw-next branch of rtw.git, thanks.
d5e6f353 [v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v3] wifi: rtw89: phy: increase RF calibration timeouts for USB transport
From: Ping-Ke Shih @ 2026-04-29 3:11 UTC (permalink / raw)
To: Louis Kotze, pkshih
Cc: linux-wireless, linux-kernel, rtl8821cerfe2, lucid_duck,
Louis Kotze
In-Reply-To: <20260416045536.817930-1-loukot@gmail.com>
Louis Kotze <loukot@gmail.com> wrote:
> USB transport adds significant latency to H2C/C2H round-trips used
> by RF calibration. The existing timeout values were designed for PCIe
> and are too tight for USB, causing "failed to wait RF DACK",
> "failed to wait RF TSSI" and similar errors on USB adapters.
>
> Apply a 4x timeout multiplier when the device uses USB transport.
> The multiplier is applied in rtw89_phy_rfk_report_wait() so all
> calibrations benefit without changing any call sites or PCIe
> timeout values.
>
> The 4x multiplier was chosen based on measured data from two
> independent testers (RTL8922AU, 6GHz MLO and 2.4/5GHz):
>
> Calibration PCIe timeout Max measured (USB) 4x timeout
> PRE_NTFY 5ms 1ms 20ms
> DACK 58ms 72ms 232ms
> RX_DCK 128ms 374ms 512ms
> TSSI normal 20ms 24ms 80ms
> TSSI scan 6ms 14ms 24ms
> TXGAPK 54ms 18ms 216ms
> IQK 84ms 53ms 336ms
> DPK 34ms 30ms 136ms
>
> Tested with RTL8922AU on 6GHz MLO (5GHz + 6GHz simultaneous):
> 25 connect/disconnect cycles with zero failures.
>
> The 4x multiplier was also verified under adverse host conditions
> on 5GHz. 5 cycles per scenario, stress-ng as the load generator,
> max observed time per calibration:
>
> Calibration PCIe 4x Baseline CPU stress Mem stress Combined
> PRE_NTFY 5 20 0 0 0 1
> DACK 58 232 71 (!) 71 (!) 71 (!) 71 (!)
> RX_DCK 128 512 23 22 22 23
> IQK 84 336 53 53 53 53
> DPK 34 136 23 23 26 23
> TSSI 20 80 6 9 14 9
> TXGAPK 54 216 16 16 16 16
>
> Legend: (!) = exceeds PCIe budget but within 4x budget.
>
> Two observations from that matrix:
>
> 1. DACK exceeds the stock PCIe budget (58ms) in baseline on 5GHz
> on this hardware. Without the 4x multiplier, DACK fails
> -ETIMEDOUT deterministically on every connect, no stress
> needed. This is the condition the patch addresses.
>
> 2. Calibration times appear dominated by USB transport round-trip
> latency rather than host load, though hardware and external
> component factors may also contribute. DACK stays at 71ms
> across all four scenarios. Host-side stress has essentially
> zero effect on observed calibration duration. Bumping the
> multiplier above 4x would not address a failure mode that
> this stress matrix produces.
>
> Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> Link: https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/evidence/crash-2026-04-11
> Signed-off-by: Louis Kotze <loukot@gmail.com>
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8922AU (BrosTrend BE6500)
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852AU (D-Link DWA-X1850 A1)
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852AU (D-Link DWA-X1850 B1)
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852BU (BrosTrend AX4L)
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852CU (EDUP AX5400)
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
5055188134c3 wifi: rtw89: phy: increase RF calibration timeouts for USB transport
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH] wifi: rtlwifi: fix typos in comments
From: Ping-Ke Shih @ 2026-04-29 3:15 UTC (permalink / raw)
To: Hugo Villeneuve, Ping-Ke Shih
Cc: hugo, Hugo Villeneuve, linux-wireless, linux-kernel
In-Reply-To: <20260417200520.3919437-1-hugo@hugovil.com>
Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Fix typos in rtl8821ae_card_disable() comments.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
718c023ffe41 wifi: rtlwifi: fix typos in comments in rtl8821ae_card_disable()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next v2 01/11] wifi: rtw89: usb: Support 2 bulk in endpoints
From: Ping-Ke Shih @ 2026-04-29 3:41 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org; +Cc: Ping-Ke Shih
In-Reply-To: <3d30c8d1-fa25-48d0-b27d-7d634c5aa005@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> RTL8912AU has 2 bulk in endpoints, not 1, so raise the limit.
>
> The second bulk-in is for USB interrupt mode for SER (system error
> recovery) flow. SER is not currently implemented for USB devices in
> rtw89.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
11 patch(es) applied to rtw-next branch of rtw.git, thanks.
8d722eeac1a7 wifi: rtw89: usb: Support 2 bulk in endpoints
6f4621340312 wifi: rtw89: Fix rtw89_usb_ops_mac_lv1_rcvy() for RTL8922AU
0cc43249ea97 wifi: rtw89: Fix rtw89_usb_ops_mac_pre_init() for RTL8922AU
0df7f0c22d96 wifi: rtw89: Fix rtw89_usb_ops_mac_post_init() for RTL8922AU
32cee8a9bb66 wifi: rtw89: usb: Enable RX aggregation for RTL8922AU
c3dfef1e3552 wifi: rtw89: Fix rtw8922a_pwr_{on,off}_func() for USB
c423ed43c93c wifi: rtw89: Let hfc_param_ini have separate settings for USB 2/3
bd87e927006c wifi: rtw89: Add rtw8922a_hfc_param_ini_usb{2,3}
abe23df7c89f wifi: rtw89: Add rtw8922a_dle_mem_usb{2,3}
6bb58cd6e176 wifi: rtw89: Add rtw8922au.c
f07d1009e972 wifi: rtw89: Enable the new rtw89_8922au module
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH 09/10] carl9170: fw: enable DFS radar detection
From: John Scott @ 2026-04-29 4:46 UTC (permalink / raw)
To: Masi Osmani, Christian Lamparter; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AM7PPF5613FA0B6E8DE143A385080A72F139444A@AM7PPF5613FA0B6.EURP251.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 4857 bytes --]
Hello,
I have a question about how this fits into the wireless regulatory status quo, as someone who doesn't understand the code too well but is interested.
Currently it appears ath9k guards radar detection behind a Kconfig option, and the details look important:
> config ATH9K_DFS_CERTIFIED
> bool "Atheros DFS support for certified platforms"
> depends on ATH9K && CFG80211_CERTIFICATION_ONUS
> default n
> help
> This option enables DFS support for initiating radiation on
> ath9k. There is no way to dynamically detect if a card was DFS
> certified and as such this is left as a build time option. This
> option should only be enabled by system integrators that can
> guarantee that all the platforms that their kernel will run on
> have obtained appropriate regulatory body certification for a
> respective Atheros card by using ath9k on the target shipping
> platforms.
>
> This is currently only a placeholder for future DFS support,
> as DFS support requires more components that still need to be
> developed. At this point enabling this option won't do anything
> except increase code size.
(I think that last paragraph is out of date—my understanding is ath9k has supported DFS for a while, at least when used in tandem with wpa_supplicant, but I've not had the pleasure to try that yet.)
I see this option depends on CFG80211_CERTIFICATION_ONUS, which, indeed, is an affirmation from the kernel configurator that this will be used in such a conforming environment. Does carl9170 need to do something similar before turning this on? From the several AR9170 NICs I have in my collection, none of them have FCC approval for radar detection as far as I know. (Does anyone know of any?)
Perhaps the sentiment of Linux Wireless folks is different now—I think ath9k was the original prototype for radar detection, anyway—but could this be a problem?
On Thu, 2026-03-12, Masi Osmani wrote:
> Enable DFS (Dynamic Frequency Selection) radar detection on the
> AR9170. The hardware has radar detection registers (RADAR_0,
> RADAR_1, RADAR_EXT) and the firmware already sends
> CARL9170_RSP_RADAR events, but the driver never programmed the
> detection parameters and only logged a "please report" message.
>
> Changes:
> - Program radar detection pulse parameters in phy.c when the
> current channel has IEEE80211_CHAN_RADAR set. Values are
> based on ath9k defaults for FCC/ETSI compliance.
I see cfg80211.h says
> @IEEE80211_CHAN_RADAR: Radar detection is required on this channel.
so this *appears* to affirm my mild concern that this patch is intended to permit initiating radiation on such channels. Is that right?
> - Advertise radar_detect_widths in the interface combination
> (fw.c) for 20 MHz noHT, 20 MHz HT, and 40 MHz HT.
> - Replace the old "please report" message with a call to
> ieee80211_radar_detected() so mac80211 can trigger the
> proper DFS state machine (channel switch / CAC).
>
> Signed-off-by: Masi Osmani <mas-i@hotmail.de>
> ---
> drivers/net/wireless/ath/carl9170/fw.c | 3 ++
> drivers/net/wireless/ath/carl9170/phy.c | 45 +++++++++++++++++++++++++
> drivers/net/wireless/ath/carl9170/rx.c | 7 ++--
> 3 files changed, 50 insertions(+), 5 deletions(-)
Thus it appears no Kconfig changes were made and your changes don't guard radar detection behind a suitable preprocessor directive.
By the way, I notice in include/net/mac80211.h
/**
* struct ieee80211_conf - configuration of the device
*
* This struct indicates how the driver shall configure the hardware.
* ...
* [bool] @radar_enabled: whether radar detection is enabled
*/
Is this .radar_enabled member something that should be checked or used as part of these changes? I don't know anymore about this code than the plain meaning of the words, but I thought I'd ask: a patch to enable radar detection seems like it ought to access such an object named "radar_enabled" at some point, right?
P.S. Although I don't have access to formal industrial testing equipment, I'm in Central Indiana, USA and I already have a couple creative ideas to put radar detection to the test, at least to assess effectiveness of the implementation. Perhaps comrades from my local Linux Users Group could join me (field trip!), if I do some more research to ascertain the frequency bands used. "It doesn't hurt to ask" 🙂
There are legitimate circumstances where DFS/radar detection can be enabled even if the FCC Part 15 certification wasn't performed for the hardware—such as when operating under rules other than conventional FCC Part 15 (some amateur radio licensees, limited non-commercial usage and experimentation). So even putting this behind something like a "CARL9170_DFS_CERTIFIED" would still be neat if we could show its usefulness
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 411 bytes --]
^ permalink raw reply
* Re: [PATCHv3 ath-next] wifi: ath11k: use kzalloc_flex
From: Rameshkumar Sundaram @ 2026-04-29 4:54 UTC (permalink / raw)
To: Rosen Penev, linux-wireless
Cc: Jeff Johnson, Kees Cook, Gustavo A. R. Silva,
open list:QUALCOMM ATHEROS ATH11K WIRELESS DRIVER, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260428205017.26288-1-rosenp@gmail.com>
On 4/29/2026 2:20 AM, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
>
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation before any potential accesses.
> kzalloc_flex does this anyway for GCC >= 15.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Jose Ignacio Tornos Martinez @ 2026-04-29 5:14 UTC (permalink / raw)
To: baochen.qiang
Cc: ath11k, jjohnson, jtornosm, linux-kernel, linux-wireless, stable
In-Reply-To: <c0d2b6df-4109-4c93-b229-7eb2d3fca6a7@oss.qualcomm.com>
Hello Baochen,
As I try to comment in the commit description, the warning is not at
the intialization, but comes up when the device is unbinded after a
problem at the initialization stage, because due to the problem the
buffers were released (probe). Later after the problem, if the unbinding
is commanded the buffers are released again.
Setting to NUll after releasing avoids the double free.
The easiest way to reproduce it is to run in a VM the default upstream
kernel (that is always failing on VMs) and just unbind the device
(ath11k_pci).
The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
("wifi: ath12k: fix warning when unbinding"), and I have seen the same problem
is also happening for ath11k driver.
Thanks
Best regards
José Ignacio
^ permalink raw reply
* Re: [PATCH rtw-next 01/16] wifi: rtw89: 8922d: fix typo rx_freq_frome_ie
From: Ping-Ke Shih @ 2026-04-29 5:24 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless
Cc: leo.li, gary.chang, echuang, wenjie.tsai, phhuang, isaiah,
kevin_yang, mh_chen
In-Reply-To: <20260420034051.17666-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> The commit 127ea8d0b068 ("wifi: rtw89: fix typo "frome" -> "from" in rx_freq_frome_ie")
> change the struct field to correct the typo, but miss to fix this for
> RTL8922D because it is submitting at the same time.
>
> As RTL8922D is not enabled yet, this build error doesn't appear.
>
> Fix it accordingly.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
16 patch(es) applied to rtw-next branch of rtw.git, thanks.
d6a3aac6ed5d wifi: rtw89: 8922d: fix typo rx_freq_frome_ie
fdf0eb355182 wifi: rtw89: 8852a: refine power save to lower latency
3da737c77764 wifi: rtw89: debug: disable hw_scan for latency-sensitive scenarios
bd2d1abf74e4 wifi: rtw89: debug: disable inactive power save to reduce bus overhead
e3ed82f19f13 wifi: rtw89: phy: support static PD level setting
08fdcb529df6 wifi: rtw89: Correct data type for scan index to avoid infinite loop
72b781d3bdd3 wifi: rtw89: 8852bt: configure support_noise field explicitly
ae3d327515f2 wifi: rtw89: add IO offload support via firmware
63586e841cf3 wifi: rtw89: offload DMAC and CMAC init IO to firmware
850216ff7d12 wifi: rtw89: use firmware offload for PHY and RF batch register writes
89058548dd14 wifi: rtw89: 8832cu: Add ID 2c7c:8206 for RTL8832CU
8beba37615f2 wifi: rtw89: use struct to fill C2H recv ack
6a9b4babeb9b wifi: rtw89: check scan C2H event recv ack instead of C2H event done ack
602b58bb45b2 wifi: rtw89: suspend DIG when remain-on-channel
2da590b9ccf5 wifi: rtw89: chan: introduce new helper to get entity current configuration
b465bc7e18a7 wifi: rtw89: 8922d: update RF calibration flow for MLD
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v3] wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer
From: Ping-Ke Shih @ 2026-04-29 5:33 UTC (permalink / raw)
To: Tristan Madani, Ping-Ke Shih
Cc: Bitterblue Smith, Johannes Berg, linux-wireless, Tristan Madani
In-Reply-To: <20260421111434.3389674-1-tristmd@gmail.com>
Tristan Madani <tristmd@gmail.com> wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit
> descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both
> firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478),
> causing an out-of-bounds read from the pre-allocated DMA buffer when
> skb_put_data copies new_len bytes. The USB transport already validates
> this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the
> PCIe path does not.
>
> Add a check that new_len does not exceed the DMA buffer size.
>
> Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
6e76e9ed273d wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v3] wifi: rtw89: add bounds check on firmware mac_id in link lookup
From: Ping-Ke Shih @ 2026-04-29 5:43 UTC (permalink / raw)
To: Tristan Madani, Ping-Ke Shih
Cc: Johannes Berg, linux-wireless, Tristan Madani
In-Reply-To: <20260421111442.3395411-1-tristmd@gmail.com>
Tristan Madani <tristmd@gmail.com> wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The mac_id field in RX descriptors is 8 bits wide (0-255), but
> assoc_link_on_macid[] has only RTW89_MAX_MAC_ID_NUM (128) entries.
> While the driver currently assigns mac_id values below 128, the
> descriptor value comes from firmware and is not validated before use
> as an array index. Add a defensive bounds check in
> rtw89_assoc_link_rcu_dereference() to guard against out-of-range
> firmware values.
>
> Fixes: 144c6cd24b35 ("wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
6d88244bb129 wifi: rtw89: add bounds check on firmware mac_id in link lookup
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next 1/3] wifi: rtw89: pci: no need to wait CLK ready for RTL8922DE
From: Ping-Ke Shih @ 2026-04-29 5:48 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: dian_syuan0116
In-Reply-To: <20260424072552.59220-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> The bit is to wait for CLK ready when entering PCIE L1SS. However, a
> certain host might not enable CLK for a situation, causing device state
> stuck and trigger PCIE SER. Unset this bit as default like earlier chips.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
3 patch(es) applied to rtw-next branch of rtw.git, thanks.
329e9fff98f8 wifi: rtw89: pci: no need to wait CLK ready for RTL8922DE
1e53b826d5f8 wifi: rtw89: disable HTC field in AP mode
d1fba5522868 wifi: rtw89: disable CSI STBC for VHT 160MHz
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: drop stray 'static' from fast-RX rx_result
From: Zhao Li @ 2026-04-29 5:49 UTC (permalink / raw)
To: Jeff Johnson
Cc: linux-wireless, Felix Fietkau, Johannes Berg, linux-kernel,
stable
In-Reply-To: <17d5b91c-026f-4539-a39a-cfd976860273@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 07:23:30AM -0700, Jeff Johnson wrote:
> Is this an identity you commonly use? Note that anonymous
> contributions are not allowed:
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Apologies for the truncated From line. My full name is Zhao Li; I
sign other kernel contributions the same way. For DCO purposes,
please treat this patch as:
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
I will use the full name on resends and follow-up patches. Thanks
for the review.
--
Zhao Li
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor
From: Ping-Ke Shih @ 2026-04-29 5:55 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org; +Cc: Ping-Ke Shih
In-Reply-To: <04da7398-cedb-425a-a810-5772ab10139d@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Bit 28 of double word 2 in the RX descriptor indicates if the packet is
> a normal 802.11 frame, or a message from the wifi firmware to the
> driver (Card 2 Host).
>
> Commit f5678bfe1cdc ("rtlwifi: rtl8821ae: Replace local bit manipulation
> macros") mistakenly made the driver look for this bit in double word 1,
> causing packet loss and Bluetooth coexistence problems.
>
> Fixes: f5678bfe1cdc ("rtlwifi: rtl8821ae: Replace local bit manipulation macros")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
83d38df69291 wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Ping-Ke Shih @ 2026-04-29 5:59 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
Cc: Ping-Ke Shih, Jes Sorensen, art1310
In-Reply-To: <092f18cd-f3a6-4e3b-b0de-1cb23615e86b@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Some devices malfunction when connected to a network with 40 MHz channel
> width, because they don't support that.
>
> RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
> this (and some other capabilities) to the driver. Get this information
> from the hardware and advertise 40 MHz support only when the hardware
> can handle it. We assume the other chips can always handle it.
>
> RTL8710BU needs a different way to retrieve this information, which will
> be implemented some other time.
>
> Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default")
> Cc: stable@vger.kernel.org
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Failed to apply patch:
error: sha1 information is lacking or useless (drivers/net/wireless/realtek/rtl8xxxu/8188e.c).
error: could not build fake ancestor
Patch failed at 0001 wifi: rtl8xxxu: Detect the maximum supported channel width
Set patchset state to Changes Requested
[rtw-next] wifi: rtl8xxxu: Detect the maximum supported channel width
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v11 00/22] wifi: nxpwifi: create nxpwifi to support iw61x
From: Francesco Dolcini @ 2026-04-29 6:03 UTC (permalink / raw)
To: Jeff Chen
Cc: linux-wireless, linux-kernel, ulf.hansson, johannes, francesco,
wyatt.hsu, s.hauer
In-Reply-To: <20260428194021.785252-1-jeff.chen_1@nxp.com>
Hello Jeff
On Wed, Apr 29, 2026 at 03:39:59AM +0800, Jeff Chen wrote:
> This series adds a new full-MAC Wi-Fi driver `nxpwifi` to support NXP
> IW611/IW612 chip family. These chips are tri-radio single-chip solutions
> with Wi-Fi 6(1x1, 2.4/5 GHz), Bluetooth 5.4, and IEEE 802.15.4.
> Communication with the external host is via SDIO interface. The driver is
> tested on i.MX8M Mini EVK in both STA and AP mode.
...
> Change history:
>
> v11:
> - Added MMC core support for NXP IW61x base SDIO card ID, ensuring that the
> MMC_QUIRK_BLKSZ_FOR_BYTE_MODE quirk is applied at the card level rather
> than from the SDIO function driver.
> This addresses the IW61x SDIO identification behavior, where the base card
> reports one ID during initial bus scan while the WLAN function reports a
> different ID, and aligns quirk handling with upstream MMC architecture.
>
> - Cleaned up legacy ioctl-style command usage in cfg80211 paths by removing
> direct nxpwifi_send_cmd() invocations and routing these operations through
> explicit driver helper functions. This reduces duplicated control logic,
> clarifies command ownership, and aligns nxpwifi with the expected
> cfg80211-based control flow.
b4 diff 20260428194021.785252-1-jeff.chen_1@nxp.com is not working for
me, I guess because you renamed the series, take care of this in the
future, thanks.
Francesco
^ permalink raw reply
* Re: [PATCH wireless-next 1/2] wifi: cfg80211/mac80211: change memory allocation for link_sinfo structure
From: Sarika Sharma @ 2026-04-29 6:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <59fa69de18211d2f17d346d22f2d07bbe72c157c.camel@sipsolutions.net>
On 28-04-2026 15:01, Johannes Berg wrote:
> On Tue, 2026-04-28 at 14:39 +0530, Sarika Sharma wrote:
>>
>> +int cfg80211_alloc_link_sinfo_stats(struct link_station_info **link_sinfo,
>
> really?
>
> johannes
So, this helper API I introduced in cfg80211 since struct
link_station_info is defined and primarily used
there. Keeping allocation and lifetime management in cfg80211 ensures
consistent ownership and cleanup once the link_station_info is consumed.
Please let me know if I understood your concern correctly, or if you
were referring to something else in this patch.
^ permalink raw reply
* Re: [PATCH wireless-next 1/2] wifi: cfg80211/mac80211: change memory allocation for link_sinfo structure
From: Johannes Berg @ 2026-04-29 6:16 UTC (permalink / raw)
To: Sarika Sharma; +Cc: linux-wireless
In-Reply-To: <3945df66-0f90-4371-a85d-26cd220dfc56@oss.qualcomm.com>
On Wed, 2026-04-29 at 11:38 +0530, Sarika Sharma wrote:
>
> On 28-04-2026 15:01, Johannes Berg wrote:
> > On Tue, 2026-04-28 at 14:39 +0530, Sarika Sharma wrote:
> > >
> > > +int cfg80211_alloc_link_sinfo_stats(struct link_station_info **link_sinfo,
> >
> > really?
> >
> > johannes
>
> So, this helper API I introduced in cfg80211 since struct
> link_station_info is defined and primarily used
> there. Keeping allocation and lifetime management in cfg80211 ensures
> consistent ownership and cleanup once the link_station_info is consumed.
>
> Please let me know if I understood your concern correctly, or if you
> were referring to something else in this patch.
Hah, right. I was merely thinking of returning an error and using a
double-pointer for assignment. There are better ways of doing that.
johannes
^ permalink raw reply
* [PATCH wireless-next v2] wifi: cfg80211: indicate (Re)Association frame encryption to userspace
From: Kavita Kavita @ 2026-04-29 6:25 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita
In SME-in-driver mode, the driver handles the entire (re)association
exchange. Userspace (e.g., wpa_supplicant) currently has no explicit
indication of whether the (re)association exchange was encrypted,
making it difficult to distinguish EPP (Enhanced Privacy Protection,
IEEE 802.11bi) associations from non-EPP associations.
When (Re)Association frame encryption is used, the (Re)Association
Response frame must contain a Key Delivery element as specified in
IEEE P802.11bi/D4.0, Table 9-65. Userspace must process this element
only when the (Re)Association Response frame is actually encrypted.
Processing it unconditionally for unencrypted frames leads to incorrect
behavior. Without an explicit indication from the driver, userspace
cannot determine whether encryption was used and whether the Key
Delivery element is valid.
Add a new flag attribute NL80211_ATTR_ASSOC_ENCRYPTED and a
corresponding field "assoc_encrypted" in cfg80211_connect_resp_params.
The driver sets this flag to indicate that the (Re)Association
Request/Response frames are transmitted encrypted over the air.
Pass the flag to userspace via NL80211_CMD_CONNECT event.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
Changes in v2:
- This is a continuation of the previous series:
"[PATCH wireless-next 0/2] wifi: cfg80211/mac80211: indicate
(Re)Association frame encryption in SME-in-driver mode".
Now sending as a single patch.
- Dropped the patch 2/2, as there is no current use case for passing
assoc_encrypted when both NL80211_CMD_ASSOCIATE and
NL80211_CMD_CONNECT are indicated.
- Removed redundant NLA_REJECT entry and Updated commit message.
---
include/net/cfg80211.h | 4 ++++
include/uapi/linux/nl80211.h | 9 +++++++++
net/wireless/nl80211.c | 4 +++-
net/wireless/sme.c | 1 +
4 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index a40ab36b8edb..2fa8c1132bfb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -8838,6 +8838,9 @@ struct cfg80211_fils_resp_params {
* @links.status: per-link status code, to report a status code that's not
* %WLAN_STATUS_SUCCESS for a given link, it must also be in the
* @valid_links bitmap and may have a BSS pointer (which is then released)
+ * @assoc_encrypted: The driver should set this flag to indicate that the
+ * (Re)Association Request/Response frames are transmitted encrypted over
+ * the air.
*/
struct cfg80211_connect_resp_params {
int status;
@@ -8847,6 +8850,7 @@ struct cfg80211_connect_resp_params {
size_t resp_ie_len;
struct cfg80211_fils_resp_params fils;
enum nl80211_timeout_reason timeout_reason;
+ bool assoc_encrypted;
const u8 *ap_mld_addr;
u16 valid_links;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 072b383d7d3c..e26d65c1b737 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3142,6 +3142,13 @@ enum nl80211_commands {
* association response etc., since it's abridged in the beacon. Used
* for START_AP etc.
*
+ * @NL80211_ATTR_ASSOC_ENCRYPTED: Flag attribute, used only with the
+ * %NL80211_CMD_CONNECT event in SME-in-driver mode. The driver should
+ * set this flag to indicate that both the (Re)Association Request frame
+ * and the corresponding (Re)Association Response frame are transmitted
+ * encrypted over the air. Enhanced Privacy Protection (EPP), as defined
+ * in IEEE P802.11bi/D4.0, mandates this encryption.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3735,6 +3742,8 @@ enum nl80211_attrs {
NL80211_ATTR_NAN_MAX_CHAN_SWITCH_TIME,
NL80211_ATTR_NAN_PEER_MAPS,
+ NL80211_ATTR_ASSOC_ENCRYPTED,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cf236307cca9..b96f2f7f67d2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -20660,7 +20660,9 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
(cr->fils.pmk &&
nla_put(msg, NL80211_ATTR_PMK, cr->fils.pmk_len, cr->fils.pmk)) ||
(cr->fils.pmkid &&
- nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))))
+ nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))) ||
+ (cr->assoc_encrypted &&
+ nla_put_flag(msg, NL80211_ATTR_ASSOC_ENCRYPTED)))
goto nla_put_failure;
if (cr->valid_links) {
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 86e2ccaa678c..b451df3096dd 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1066,6 +1066,7 @@ void cfg80211_connect_done(struct net_device *dev,
}
ev->cr.status = params->status;
ev->cr.timeout_reason = params->timeout_reason;
+ ev->cr.assoc_encrypted = params->assoc_encrypted;
spin_lock_irqsave(&wdev->event_lock, flags);
list_add_tail(&ev->list, &wdev->event_list);
base-commit: 7baf5857e15d722776898510a10546d6b2f18645
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox