* Re: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Bitterblue Smith @ 2026-02-13 23:23 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <f9652882eeb042f89463e0fa864f1412@realtek.com>
On 11/02/2026 04:03, Ping-Ke Shih wrote:
>
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> On 10/02/2026 08:44, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>> On 09/02/2026 10:19, Ping-Ke Shih wrote:
>>>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>>> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
>>>>>> NetworkManager?) triggers a scan every five minutes. During these scans
>>>>>> mac80211 transmits many QoS Null frames in quick succession. Because
>>>>>> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
>>>>>> asks the firmware to report the TX ACK status for each of these frames.
>>>>>> Sometimes the firmware can't process the TX status requests quickly
>>>>>> enough, they add up, it only processes some of them, and then marks
>>>>>> every subsequent TX status report with the wrong number.
>>>>>
>>>>> Does it mean number of reports is correct? But with incorrect sequence number?
>>>>> Then, you just ignore checking 'sn' but assume 'st' is correct.
>>>>>
>>>>
>>>> The number of reports is correct most of the time. Only when the firmware
>>>> is overwhelmed (?) it doesn't provide every report, but later it recovers.
>>>>
>>>
>>> I was not aware that this happened while scanning, so we might apply this loose
>>> checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
>>> If TX report is because of re-key, it can still use original rule.
>>>
>>> [...]
>>>
>>
>> We can't do that because the sequence number is permanently messed up.
>
> Indeed...
>
>>
>> I thought about ignoring IEEE80211_TX_CTL_REQ_TX_STATUS on null frames
>> sent during scans, but unfortunately the last 2 or 3 QOS Null frames
>> are sent after RTW_FLAG_SCANNING is unset, and they still trigger the
>> problem.
>>
>> While poking around today I noticed that only non-QOS null frames are
>> treated like management frames. QOS null frames are treated like data
>> frames. So I tried this change:
>>
>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
>> index 783975acdcff..ea83daa9d60d 100644
>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
>> @@ -424,7 +424,7 @@ void rtw_tx_pkt_info_update(struct rtw_dev *rtwdev,
>> pkt_info->mac_id = rtwvif->mac_id;
>> }
>>
>> - if (ieee80211_is_mgmt(fc) || ieee80211_is_nullfunc(fc))
>> + if (ieee80211_is_mgmt(fc) || ieee80211_is_any_nullfunc(fc))
>> rtw_tx_mgmt_pkt_info_update(rtwdev, pkt_info, sta, skb);
>> else if (ieee80211_is_data(fc))
>> rtw_tx_data_pkt_info_update(rtwdev, pkt_info, sta, skb);
>>
>> With this I can't trigger the problem anymore. The sequence numbers
>> are normal every time. Well, it's too soon to be sure, so I will keep
>> testing for a few days.
>
> Good finding. Please keep testing it.
>
Still no problem two days later.
> FYI. Having the lunar New Year next week, I will not reply your mail soon.
>
Have a good holiday!
>>
>>>>
>>>>>>
>>>>>> The symptom is that after a while the warning "failed to get tx report
>>>>>> from firmware" appears every five minutes.
>>>>>>
>>>>>> This problem apparently happens only with the older RTL8723D, RTL8821A,
>>>>>> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
>>>>>> number reported by these chips and match the reports with the requests
>>>>>> in the order they come in.
>>>>>>
>>>>>> Tested with RTL8821AU and RTL8723DU.
>>>>>>
>>>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>>>> ---
>>>>>> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
>>>>>> index c04ff31d0f1e..98215ecc884a 100644
>>>>>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
>>>>>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
>>>>>> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
>>>>>> spin_lock_irqsave(&tx_report->q_lock, flags);
>>>>>> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
>>>>>> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
>>>>>> - if (*n == sn) {
>>>>>> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
>>>>>
>>>>> Can we only limit to USB devices (or non-PCI devices)?
>>>>>
>>>>
>>>> I don't think so. RTL8821AE also has this problem. I didn't mention it
>>>> in the commit message because support for RTL8821AE in rtw88 is
>>>> unofficial. (I modified rtw88_pci to handle the older generation, see
>>>> the use_new_trx_flow=false code path in rtlwifi.)
>>>
>>> How about official RTL8723DE?
>>>
>>
>> I don't have RTL8723DE. I can try with RTL8723DS, although it's annoying
>> to use. (The host is some kind of single board computer. It has only a
>> serial interface and when I connect that to my laptop it makes the
>> touchpad slow for some reason.)
>
> I found a RTL8723DE and tested scan during connection over 10 times
> (with local modification to print TX-sn/RX-sn).
> I'd say RTL8723DE doesn't have this problem.
>
It can take hours, although with RTL8821AE it happens in just a few
minutes.
>>
>>>>
>>>>>> __skb_unlink(cur, &tx_report->queue);
>>>>>> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
>>>>>> break;
>>>>>> --
>>>>>> 2.52.0
>>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Bitterblue Smith @ 2026-02-13 23:29 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <f9652882eeb042f89463e0fa864f1412@realtek.com>
On 11/02/2026 04:03, Ping-Ke Shih wrote:
>
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> On 10/02/2026 08:44, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>> On 09/02/2026 10:19, Ping-Ke Shih wrote:
>>>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>>> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
>>>>>> NetworkManager?) triggers a scan every five minutes. During these scans
>>>>>> mac80211 transmits many QoS Null frames in quick succession. Because
>>>>>> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
>>>>>> asks the firmware to report the TX ACK status for each of these frames.
>>>>>> Sometimes the firmware can't process the TX status requests quickly
>>>>>> enough, they add up, it only processes some of them, and then marks
>>>>>> every subsequent TX status report with the wrong number.
>>>>>
>>>>> Does it mean number of reports is correct? But with incorrect sequence number?
>>>>> Then, you just ignore checking 'sn' but assume 'st' is correct.
>>>>>
>>>>
>>>> The number of reports is correct most of the time. Only when the firmware
>>>> is overwhelmed (?) it doesn't provide every report, but later it recovers.
>>>>
>>>
>>> I was not aware that this happened while scanning, so we might apply this loose
>>> checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
>>> If TX report is because of re-key, it can still use original rule.
>>>
>>> [...]
>>>
>>
>> We can't do that because the sequence number is permanently messed up.
>
> Indeed...
>
>>
>> I thought about ignoring IEEE80211_TX_CTL_REQ_TX_STATUS on null frames
>> sent during scans, but unfortunately the last 2 or 3 QOS Null frames
>> are sent after RTW_FLAG_SCANNING is unset, and they still trigger the
>> problem.
>>
>> While poking around today I noticed that only non-QOS null frames are
>> treated like management frames. QOS null frames are treated like data
>> frames. So I tried this change:
>>
>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
>> index 783975acdcff..ea83daa9d60d 100644
>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
>> @@ -424,7 +424,7 @@ void rtw_tx_pkt_info_update(struct rtw_dev *rtwdev,
>> pkt_info->mac_id = rtwvif->mac_id;
>> }
>>
>> - if (ieee80211_is_mgmt(fc) || ieee80211_is_nullfunc(fc))
>> + if (ieee80211_is_mgmt(fc) || ieee80211_is_any_nullfunc(fc))
>> rtw_tx_mgmt_pkt_info_update(rtwdev, pkt_info, sta, skb);
>> else if (ieee80211_is_data(fc))
>> rtw_tx_data_pkt_info_update(rtwdev, pkt_info, sta, skb);
>>
>> With this I can't trigger the problem anymore. The sequence numbers
>> are normal every time. Well, it's too soon to be sure, so I will keep
>> testing for a few days.
>
> Good finding. Please keep testing it.
>
Still no problem two days later.
> FYI. Having the lunar New Year next week, I will not reply your mail soon.
>
Have a good holiday!
>>
>>>>
>>>>>>
>>>>>> The symptom is that after a while the warning "failed to get tx report
>>>>>> from firmware" appears every five minutes.
>>>>>>
>>>>>> This problem apparently happens only with the older RTL8723D, RTL8821A,
>>>>>> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
>>>>>> number reported by these chips and match the reports with the requests
>>>>>> in the order they come in.
>>>>>>
>>>>>> Tested with RTL8821AU and RTL8723DU.
>>>>>>
>>>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>>>> ---
>>>>>> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
>>>>>> index c04ff31d0f1e..98215ecc884a 100644
>>>>>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
>>>>>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
>>>>>> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
>>>>>> spin_lock_irqsave(&tx_report->q_lock, flags);
>>>>>> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
>>>>>> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
>>>>>> - if (*n == sn) {
>>>>>> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
>>>>>
>>>>> Can we only limit to USB devices (or non-PCI devices)?
>>>>>
>>>>
>>>> I don't think so. RTL8821AE also has this problem. I didn't mention it
>>>> in the commit message because support for RTL8821AE in rtw88 is
>>>> unofficial. (I modified rtw88_pci to handle the older generation, see
>>>> the use_new_trx_flow=false code path in rtlwifi.)
>>>
>>> How about official RTL8723DE?
>>>
>>
>> I don't have RTL8723DE. I can try with RTL8723DS, although it's annoying
>> to use. (The host is some kind of single board computer. It has only a
>> serial interface and when I connect that to my laptop it makes the
>> touchpad slow for some reason.)
>
> I found a RTL8723DE and tested scan during connection over 10 times
> (with local modification to print TX-sn/RX-sn).
> I'd say RTL8723DE doesn't have this problem.
>
It can take hours, although with RTL8821AE it happens in just a few
minutes.
>>
>>>>
>>>>>> __skb_unlink(cur, &tx_report->queue);
>>>>>> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
>>>>>> break;
>>>>>> --
>>>>>> 2.52.0
>>>>>
>>>
>
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: add basic hwmon temperature reporting
From: Maharaja Kennadyrajan @ 2026-02-14 3:59 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Maharaja Kennadyrajan, Aishwarya R
Add initial thermal support by wiring up a per-radio (pdev) hwmon temperature
sensor backed by the existing WMI pdev temperature command and event.
When userspace reads the sysfs file temp1_input, the driver sends
WMI_PDEV_GET_TEMPERATURE_CMDID (tag WMI_TAG_PDEV_GET_TEMPERATURE_CMD) and waits
for the corresponding WMI_PDEV_TEMPERATURE_EVENTID
(tag WMI_TAG_PDEV_TEMPERATURE_EVENT) to get the temperature and pdev_id.
Export the reported value in millidegrees Celsius as required by hwmon.
The temperature reported is per-radio (pdev). In a multi-radio wiphy under a
single phy, a separate hwmon device is created for each radio.
Sample command and output:
$ cat /sys/devices/pci0000:00/.../ieee80211/phyX/hwmonY/temp1_input
$ 50000
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Co-developed-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/Makefile | 1 +
drivers/net/wireless/ath/ath12k/core.c | 13 +++
drivers/net/wireless/ath/ath12k/core.h | 3 +
drivers/net/wireless/ath/ath12k/mac.c | 5 +
drivers/net/wireless/ath/ath12k/thermal.c | 122 ++++++++++++++++++++++
drivers/net/wireless/ath/ath12k/thermal.h | 44 ++++++++
drivers/net/wireless/ath/ath12k/wmi.c | 57 +++++-----
7 files changed, 214 insertions(+), 31 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath12k/thermal.c
create mode 100644 drivers/net/wireless/ath/ath12k/thermal.h
diff --git a/drivers/net/wireless/ath/ath12k/Makefile b/drivers/net/wireless/ath/ath12k/Makefile
index 3ba1236956cc..3b39b2c33307 100644
--- a/drivers/net/wireless/ath/ath12k/Makefile
+++ b/drivers/net/wireless/ath/ath12k/Makefile
@@ -32,6 +32,7 @@ ath12k-$(CONFIG_ATH12K_TRACING) += trace.o
ath12k-$(CONFIG_PM) += wow.o
ath12k-$(CONFIG_ATH12K_COREDUMP) += coredump.o
ath12k-$(CONFIG_NL80211_TESTMODE) += testmode.o
+ath12k-$(CONFIG_THERMAL) += thermal.o
# for tracing framework to find trace.h
CFLAGS_trace.o := -I$(src)
diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 9d6c50a94e64..9dca1a0af73e 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -863,11 +863,22 @@ static int ath12k_core_pdev_create(struct ath12k_base *ab)
return ret;
}
+ ret = ath12k_thermal_register(ab);
+ if (ret) {
+ ath12k_err(ab, "could not register thermal device: %d\n", ret);
+ goto err_dp_pdev_free;
+ }
+
return 0;
+
+err_dp_pdev_free:
+ ath12k_dp_pdev_free(ab);
+ return ret;
}
static void ath12k_core_pdev_destroy(struct ath12k_base *ab)
{
+ ath12k_thermal_unregister(ab);
ath12k_dp_pdev_free(ab);
}
@@ -1361,6 +1372,7 @@ static int ath12k_core_reconfigure_on_crash(struct ath12k_base *ab)
mutex_lock(&ab->core_lock);
ath12k_link_sta_rhash_tbl_destroy(ab);
+ ath12k_thermal_unregister(ab);
ath12k_dp_pdev_free(ab);
ath12k_ce_cleanup_pipes(ab);
ath12k_wmi_detach(ab);
@@ -1502,6 +1514,7 @@ static void ath12k_core_pre_reconfigure_recovery(struct ath12k_base *ab)
complete(&ar->vdev_delete_done);
complete(&ar->bss_survey_done);
complete_all(&ar->regd_update_completed);
+ complete_all(&ar->thermal.wmi_sync);
wake_up(&ar->dp.tx_empty_waitq);
idr_for_each(&ar->txmgmt_idr,
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 990934ec92fc..760c76d6f0f4 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -36,6 +36,7 @@
#include "coredump.h"
#include "cmn_defs.h"
#include "dp_cmn.h"
+#include "thermal.h"
#define SM(_v, _f) (((_v) << _f##_LSB) & _f##_MASK)
@@ -757,6 +758,8 @@ struct ath12k {
s8 max_allowed_tx_power;
struct ath12k_pdev_rssi_offsets rssi_info;
+
+ struct ath12k_thermal thermal;
};
struct ath12k_hw {
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 68431a0e128e..d1db1285449c 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -14792,6 +14792,11 @@ static void ath12k_mac_setup(struct ath12k *ar)
init_completion(&ar->mlo_setup_done);
init_completion(&ar->completed_11d_scan);
init_completion(&ar->regd_update_completed);
+ init_completion(&ar->thermal.wmi_sync);
+ mutex_init(&ar->thermal.read_lock);
+
+ ar->thermal.temperature = 0;
+ ar->thermal.hwmon_dev = NULL;
INIT_DELAYED_WORK(&ar->scan.timeout, ath12k_scan_timeout_work);
wiphy_work_init(&ar->scan.vdev_clean_wk, ath12k_scan_vdev_clean_work);
diff --git a/drivers/net/wireless/ath/ath12k/thermal.c b/drivers/net/wireless/ath/ath12k/thermal.c
new file mode 100644
index 000000000000..33d3e70b2df9
--- /dev/null
+++ b/drivers/net/wireless/ath/ath12k/thermal.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: BSD-3-Clause-Clear
+/*
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/device.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/sysfs.h>
+#include <linux/thermal.h>
+#include "core.h"
+#include "debug.h"
+
+static ssize_t ath12k_thermal_temp_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct ath12k *ar = dev_get_drvdata(dev);
+ unsigned long time_left;
+ int ret, temperature;
+
+ guard(wiphy)(ath12k_ar_to_hw(ar)->wiphy);
+ guard(mutex)(&ar->thermal.read_lock);
+
+ if (ar->ah->state != ATH12K_HW_STATE_ON)
+ return -ENETDOWN;
+
+ reinit_completion(&ar->thermal.wmi_sync);
+ ret = ath12k_wmi_send_pdev_temperature_cmd(ar);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to read temperature %d\n", ret);
+ return ret;
+ }
+
+ if (test_bit(ATH12K_FLAG_CRASH_FLUSH, &ar->ab->dev_flags))
+ return -ESHUTDOWN;
+
+ time_left = wait_for_completion_timeout(&ar->thermal.wmi_sync,
+ ATH12K_THERMAL_SYNC_TIMEOUT_HZ);
+ if (!time_left) {
+ ath12k_warn(ar->ab, "failed to synchronize thermal read\n");
+ return -ETIMEDOUT;
+ }
+
+ spin_lock_bh(&ar->data_lock);
+ temperature = ar->thermal.temperature;
+ spin_unlock_bh(&ar->data_lock);
+
+ /* display in millidegree celsius */
+ return sysfs_emit(buf, "%d\n", temperature * 1000);
+}
+
+void ath12k_thermal_event_temperature(struct ath12k *ar, int temperature)
+{
+ spin_lock_bh(&ar->data_lock);
+ ar->thermal.temperature = temperature;
+ spin_unlock_bh(&ar->data_lock);
+ complete_all(&ar->thermal.wmi_sync);
+}
+
+static SENSOR_DEVICE_ATTR_RO(temp1_input, ath12k_thermal_temp, 0);
+
+static struct attribute *ath12k_hwmon_attrs[] = {
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(ath12k_hwmon);
+
+int ath12k_thermal_register(struct ath12k_base *ab)
+{
+ struct ath12k *ar;
+ int i, j, ret;
+
+ if (!IS_REACHABLE(CONFIG_HWMON))
+ return 0;
+
+ for (i = 0; i < ab->num_radios; i++) {
+ ar = ab->pdevs[i].ar;
+ if (!ar)
+ continue;
+
+ ar->thermal.hwmon_dev =
+ hwmon_device_register_with_groups(&ar->ah->hw->wiphy->dev,
+ "ath12k_hwmon", ar,
+ ath12k_hwmon_groups);
+ if (IS_ERR(ar->thermal.hwmon_dev)) {
+ ret = PTR_ERR(ar->thermal.hwmon_dev);
+ ar->thermal.hwmon_dev = NULL;
+ ath12k_err(ar->ab, "failed to register hwmon device: %d\n",
+ ret);
+ for (j = i - 1; j >= 0; j--) {
+ ar = ab->pdevs[i].ar;
+ if (!ar)
+ continue;
+
+ hwmon_device_unregister(ar->thermal.hwmon_dev);
+ ar->thermal.hwmon_dev = NULL;
+ }
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+void ath12k_thermal_unregister(struct ath12k_base *ab)
+{
+ struct ath12k *ar;
+ int i;
+
+ for (i = 0; i < ab->num_radios; i++) {
+ ar = ab->pdevs[i].ar;
+ if (!ar)
+ continue;
+
+ if (ar->thermal.hwmon_dev) {
+ hwmon_device_unregister(ar->thermal.hwmon_dev);
+ ar->thermal.hwmon_dev = NULL;
+ }
+ }
+}
diff --git a/drivers/net/wireless/ath/ath12k/thermal.h b/drivers/net/wireless/ath/ath12k/thermal.h
new file mode 100644
index 000000000000..a853af5f2441
--- /dev/null
+++ b/drivers/net/wireless/ath/ath12k/thermal.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: BSD-3-Clause-Clear */
+/*
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _ATH12K_THERMAL_
+#define _ATH12K_THERMAL_
+
+#include <linux/mutex.h>
+
+#define ATH12K_THERMAL_SYNC_TIMEOUT_HZ (5 * HZ)
+
+struct ath12k_thermal {
+ struct completion wmi_sync;
+
+ /* temperature value in Celsius degree protected by data_lock. */
+ int temperature;
+ struct device *hwmon_dev;
+ /* Serialize concurrent sysfs reads to avoid completion races */
+ struct mutex read_lock;
+};
+
+#if IS_REACHABLE(CONFIG_THERMAL)
+int ath12k_thermal_register(struct ath12k_base *ab);
+void ath12k_thermal_unregister(struct ath12k_base *ab);
+void ath12k_thermal_event_temperature(struct ath12k *ar, int temperature);
+#else
+static inline int ath12k_thermal_register(struct ath12k_base *ab)
+{
+ return 0;
+}
+
+static inline void ath12k_thermal_unregister(struct ath12k_base *ab)
+{
+}
+
+static inline void ath12k_thermal_event_temperature(struct ath12k *ar,
+ int temperature)
+{
+}
+
+#endif
+#endif /* _ATH12K_THERMAL_ */
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 7617fc3a2479..69f2dbcfca63 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -6778,31 +6778,6 @@ static int ath12k_pull_peer_assoc_conf_ev(struct ath12k_base *ab, struct sk_buff
return 0;
}
-static int
-ath12k_pull_pdev_temp_ev(struct ath12k_base *ab, struct sk_buff *skb,
- const struct wmi_pdev_temperature_event *ev)
-{
- const void **tb;
- int ret;
-
- tb = ath12k_wmi_tlv_parse_alloc(ab, skb, GFP_ATOMIC);
- if (IS_ERR(tb)) {
- ret = PTR_ERR(tb);
- ath12k_warn(ab, "failed to parse tlv: %d\n", ret);
- return ret;
- }
-
- ev = tb[WMI_TAG_PDEV_TEMPERATURE_EVENT];
- if (!ev) {
- ath12k_warn(ab, "failed to fetch pdev temp ev");
- kfree(tb);
- return -EPROTO;
- }
-
- kfree(tb);
- return 0;
-}
-
static void ath12k_wmi_op_ep_tx_credits(struct ath12k_base *ab)
{
/* try to send pending beacons first. they take priority */
@@ -8811,25 +8786,45 @@ static void
ath12k_wmi_pdev_temperature_event(struct ath12k_base *ab,
struct sk_buff *skb)
{
+ const struct wmi_pdev_temperature_event *ev;
struct ath12k *ar;
- struct wmi_pdev_temperature_event ev = {};
+ const void **tb;
+ int temp;
+ u32 pdev_id;
+
+ tb = ath12k_wmi_tlv_parse_alloc(ab, skb, GFP_ATOMIC);
+ if (IS_ERR(tb)) {
+ ath12k_warn(ab, "failed to parse tlv: %ld\n", PTR_ERR(tb));
+ return;
+ }
- if (ath12k_pull_pdev_temp_ev(ab, skb, &ev) != 0) {
- ath12k_warn(ab, "failed to extract pdev temperature event");
+ ev = tb[WMI_TAG_PDEV_TEMPERATURE_EVENT];
+ if (!ev) {
+ ath12k_warn(ab, "failed to fetch pdev temp ev\n");
+ kfree(tb);
return;
}
+ temp = a_sle32_to_cpu(ev->temp);
+ pdev_id = le32_to_cpu(ev->pdev_id);
+
+ kfree(tb);
+
ath12k_dbg(ab, ATH12K_DBG_WMI,
- "pdev temperature ev temp %d pdev_id %d\n", ev.temp, ev.pdev_id);
+ "pdev temperature ev temp %d pdev_id %u\n",
+ temp, pdev_id);
rcu_read_lock();
- ar = ath12k_mac_get_ar_by_pdev_id(ab, le32_to_cpu(ev.pdev_id));
+ ar = ath12k_mac_get_ar_by_pdev_id(ab, pdev_id);
if (!ar) {
- ath12k_warn(ab, "invalid pdev id in pdev temperature ev %d", ev.pdev_id);
+ ath12k_warn(ab, "invalid pdev id %u in pdev temperature ev\n",
+ pdev_id);
goto exit;
}
+ ath12k_thermal_event_temperature(ar, temp);
+
exit:
rcu_read_unlock();
}
base-commit: 37a93dd5c49b5fda807fd204edf2547c3493319c
--
2.34.1
^ permalink raw reply related
* [PATCH] wifi: iwlwifi: mld: stop mac80211 TX queues on firmware error
From: Cole Leavitt @ 2026-02-14 6:07 UTC (permalink / raw)
To: Miri Korenblit, Johannes Berg
Cc: linux-wireless, linux-kernel, stable, Cole Leavitt
When firmware encounters an error in the iwlmld driver, nothing prevents
mac80211 from continuing to feed TX packets. The mvm driver uses atomic
status bits (IWL_MVM_STATUS_HW_RESTART_REQUESTED) checked in its TX path
to gate transmissions, but the mld driver has no equivalent check --
iwl_mld_tx_from_txq() only checks mld_txq->status.stop_full.
This allows TX to proceed while firmware is unresponsive, causing
spinlock contention and soft lockups lasting 22-26 seconds.
Add ieee80211_stop_queues() in both iwl_mld_nic_error() and
iwl_mld_sw_reset() to stop TX at the mac80211 level when a restart will
follow, and add the corresponding ieee80211_wake_queues() in
iwl_mld_restart_cleanup() to resume TX after recovery.
The stop in iwl_mld_nic_error() is placed inside the conditional that
sets in_hw_restart to ensure queues are only stopped when a restart will
actually follow, avoiding a permanent TX stall on error paths where no
restart occurs (e.g. IWL_ERR_TYPE_RESET_HS_TIMEOUT with
!fw_status.running). The stop in iwl_mld_sw_reset() is unconditional
since that path always sets in_hw_restart.
Tested on ThinkPad P16 Gen3 with Intel BE200 (WiFi7) running kernel
6.19.0-rc8.
Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
Cc: stable@vger.kernel.org
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
---
drivers/net/wireless/intel/iwlwifi/mld/mac80211.c | 2 ++
drivers/net/wireless/intel/iwlwifi/mld/mld.c | 5 ++++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index df8221277d51..552888538e16 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -558,6 +558,8 @@ iwl_mld_restart_cleanup(struct iwl_mld *mld)
iwl_mld_cleanup_sta, NULL);
iwl_mld_ftm_restart_cleanup(mld);
+
+ ieee80211_wake_queues(mld->hw);
}
static
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mld.c b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
index 495e9d8f3af6..ed44c10c08a1 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mld.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
@@ -672,8 +672,10 @@ iwl_mld_nic_error(struct iwl_op_mode *op_mode,
* setting doesn't matter if we're going to be unbound either.
*/
if (type != IWL_ERR_TYPE_RESET_HS_TIMEOUT &&
- mld->fw_status.running)
+ mld->fw_status.running) {
+ ieee80211_stop_queues(mld->hw);
mld->fw_status.in_hw_restart = true;
+ }
}
static void iwl_mld_dump_error(struct iwl_op_mode *op_mode,
@@ -703,6 +705,7 @@ static bool iwl_mld_sw_reset(struct iwl_op_mode *op_mode,
* had a NIC error both were already done.
*/
iwl_mld_report_scan_aborted(mld);
+ ieee80211_stop_queues(mld->hw);
mld->fw_status.in_hw_restart = true;
/* Do restart only in the following conditions are met:
base-commit: 66af8ac52d10ea229d5755b8700e2fe86fc037f7
--
2.52.0
^ permalink raw reply related
* Re: [PATCH wireless-next 1/2] wifi: mac80211: set band information for NULL packets only for non-MLO stations
From: Suraj P Kizhakkethil @ 2026-02-14 7:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <67b8cc599e923433eec6c8baff72583c47a53cfd.camel@sipsolutions.net>
On 08-Jan-26 5:49 PM, Johannes Berg wrote:
> Technically "AP MLD" ;)
Sure, Johannes. I have updated and sent out the next version.
>
> But I was more wondering about the use of "MLD connections", which seems
> odd to me (vs. "MLO connections")? Connections between MLDs? MLD is an
> entity, MLO is the mode of operation?
>
>> + if (ieee80211_vif_is_mld(&sdata->vif))
>> + info->control.flags |= IEEE80211_TX_CTRL_MLO_LINK_UNSPEC;
> I don't see why it should be set conditionally, it should be ignored
> anyway by non-MLO drivers? Or maybe if you'd want it zero for t hose
> then do that explicitly?
>
> I'm really commenting here because it gets messy in the next patch, see
> also there.
>
> johannes
Thanks for the reply, Johannes. I have made the changes and sent out the
next version. Sorry for the delayed response.
^ permalink raw reply
* Re: [PATCH wireless-next 2/2] wifi: mac80211: set addr2/addr3 to link address for NULL packets to non-MLO stations
From: Suraj P Kizhakkethil @ 2026-02-14 7:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Sriram R, Rameshkumar Sundaram
In-Reply-To: <557aea3a06c79c2d2e04649e43b48e0733d26347.camel@sipsolutions.net>
On 08-Jan-26 5:50 PM, Johannes Berg wrote:
> On Thu, 2025-11-27 at 19:35 +0530, Suraj P Kizhakkethil wrote:
>> - if (ieee80211_vif_is_mld(&sdata->vif))
>> - info->control.flags |= IEEE80211_TX_CTRL_MLO_LINK_UNSPEC;
>> + if (ieee80211_vif_is_mld(&sdata->vif)) {
>> + if (sta->sta.mlo)
>> + info->control.flags |=
>> + IEEE80211_TX_CTRL_MLO_LINK_UNSPEC;
>> + else
>> + info->control.flags |=
>> + u32_encode_bits(link_id,
>> + IEEE80211_TX_CTRL_MLO_LINK);
>> + }
> This whole conditional logic is now pretty messy, and we (and the
> compiler, for warnings) have to track that link_id is actually
> initialized on all paths, which seems unlikely to always go right ...
>
> I think you should set link_id = IEEE80211_LINK_UNSPECIFIED or the link
> according to the logic earlier, and then just always u32_encode_bits()
> unconditionally.
Thanks, I have incorporated the changes and sent out the next version.
Sorry for the delayed response.
^ permalink raw reply
* [BUG] Potential Null Pointer Dereference in ieee80211_chsw_switch_vifs Function
From: 冯嘉仪 @ 2026-02-14 12:59 UTC (permalink / raw)
To: johannes
Cc: davem, edumazet, kuba, pabeni, linux-wireless, netdev,
linux-kernel
Dear Maintainer,
Our team recently developed a null-pointer-dereference (NPD) vulnerability detection tool, and we used it to scan the Linux Kernel (version 6.9.6). After manual review, we identified a potentially vulnerable code snippet that could lead to a null-pointer dereference bug. We would appreciate your expert insight to confirm whether this vulnerability could indeed pose a risk to the system.
Vulnerability Description:
File: net/mac80211/chan.c
In the function ieee80211_chsw_switch_vifs, we found the following line of code:
vif_chsw[i].old_ctx = &old_ctx->conf;
The issue arises because the old_ctx pointer may be passed as NULL in certain situations. Since old_ctx is NULL, accessing &old_ctx->conf in the statement could result in a null-pointer dereference.
Proposed Fix:
To prevent the potential null-pointer dereference, we suggest adding a NULL check for the old_ctx pointer before attempting to dereference &old_ctx->conf in the line.
Request for Review:
We would appreciate your expert insight to confirm whether this vulnerability indeed poses a risk to the system, and if the proposed fix is appropriate. If there are reasons why this issue does not present a real risk (e.g., the NULL check is redundant or unnecessary), we would be grateful for clarification.
Thank you for your time and consideration.
^ permalink raw reply
* [BUG] Potential Null Pointer Dereference in ieee80211_process_neg_ttlm_req Function
From: 冯嘉仪 @ 2026-02-14 13:02 UTC (permalink / raw)
To: johannes
Cc: davem, edumazet, kuba, pabeni, linux-wireless, netdev,
linux-kernel
Dear Maintainer,
Our team recently developed a null-pointer-dereference (NPD) vulnerability detection tool, and we used it to scan the Linux Kernel (version 6.9.6). After manual review, we identified a potentially vulnerable code snippet that could lead to a null-pointer dereference bug. We would appreciate your expert insight to confirm whether this vulnerability could indeed pose a risk to the system.
Vulnerability Description:
File: net/mac80211/mlme.c
In the function ieee80211_process_neg_ttlm_req, we found the following line of code:
BUILD_BUG_ON(ARRAY_SIZE(direction) != ARRAY_SIZE(elems->ttlm));
The issue arises because the elems pointer may be passed as NULL in certain situations. Since elems is NULL, accessing elems->ttlm in the statement could result in a null-pointer dereference.
Proposed Fix:
To prevent the potential null-pointer dereference, we suggest adding a NULL check for the elems pointer before attempting to dereference elems->ttlm in the line.
Request for Review:
We would appreciate your expert insight to confirm whether this vulnerability indeed poses a risk to the system, and if the proposed fix is appropriate. If there are reasons why this issue does not present a real risk (e.g., the NULL check is redundant or unnecessary), we would be grateful for clarification.
Thank you for your time and consideration.
^ permalink raw reply
* [BUG] Potential Null Pointer Dereference in ieee80211_rx_mgmt_beacon Function
From: 冯嘉仪 @ 2026-02-14 13:04 UTC (permalink / raw)
To: johannes
Cc: davem, edumazet, kuba, pabeni, linux-wireless, netdev,
linux-kernel
Dear Maintainer,
Our team recently developed a null-pointer-dereference (NPD) vulnerability detection tool, and we used it to scan the Linux Kernel (version 6.9.6). After manual review, we identified a potentially vulnerable code snippet that could lead to a null-pointer dereference bug. We would appreciate your expert insight to confirm whether this vulnerability could indeed pose a risk to the system.
Vulnerability Description:
File: net/mac80211/mlme.c
In the function ieee80211_rx_mgmt_beacon, we found the following line of code:
ieee80211_rx_our_beacon(bssid, ifmgd->assoc_data->link[0].bss)) {
The issue arises because the bssid pointer may be passed as NULL in certain situations. The statement passes the bssid pointer to ieee80211_rx_our_beacon without any check, but ieee80211_rx_our_beacon might contain a dereference operation on the bssid pointer, which could result in a null-pointer dereference.
Proposed Fix:
To prevent the potential null-pointer dereference, we suggest adding a NULL check for the bssid pointer before attempting to pass the pointer to ieee80211_rx_our_beacon.
Request for Review:
We would appreciate your expert insight to confirm whether this vulnerability indeed poses a risk to the system, and if the proposed fix is appropriate. If there are reasons why this issue does not present a real risk (e.g., the NULL check is redundant or unnecessary), we would be grateful for clarification.
Thank you for your time and consideration.
^ permalink raw reply
* [BUG] Potential Null Pointer Dereference in ieee80211_rx_mgmt_beacon Function
From: 冯嘉仪 @ 2026-02-14 13:06 UTC (permalink / raw)
To: johannes
Cc: davem, edumazet, kuba, pabeni, linux-wireless, netdev,
linux-kernel
Dear Maintainer,
Our team recently developed a null-pointer-dereference (NPD) vulnerability detection tool, and we used it to scan the Linux Kernel (version 6.9.6). After manual review, we identified a potentially vulnerable code snippet that could lead to a null-pointer dereference bug. We would appreciate your expert insight to confirm whether this vulnerability could indeed pose a risk to the system.
Vulnerability Description:
File: net/mac80211/mlme.c
In the function ieee80211_rx_mgmt_beacon, we found the following line of code:
!ieee80211_rx_our_beacon(bssid, link->conf->bss))
The issue arises because the bssid pointer may be passed as NULL in certain situations. The statement passes the bssid pointer to ieee80211_rx_our_beacon without any check, but ieee80211_rx_our_beacon might contain a dereference operation on the bssid pointer, which could result in a null-pointer dereference.
Proposed Fix:
To prevent the potential null-pointer dereference, we suggest adding a NULL check for the bssid pointer before attempting to pass the pointer to ieee80211_rx_our_beacon.
Request for Review:
We would appreciate your expert insight to confirm whether this vulnerability indeed poses a risk to the system, and if the proposed fix is appropriate. If there are reasons why this issue does not present a real risk (e.g., the NULL check is redundant or unnecessary), we would be grateful for clarification.
Thank you for your time and consideration.
^ permalink raw reply
* Re: iwlmld iwl_mld_change_vif_links can return un-initilized 'err'
From: Ben Greear @ 2026-02-14 17:15 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Miri Korenblit
In-Reply-To: <5ffe48af-e02d-4d02-b669-6a9d6797b956@candelatech.com>
On 2/14/26 09:11, Ben Greear wrote:
> Hello,
>
> I believe this method:
>
> static int
> iwl_mld_change_vif_links(struct ieee80211_hw *hw,
>
> Can return un-initialized 'err' in case that this return path is taken:
>
> if (WARN_ON(!iwl_mld_error_before_recovery(mld)))
> return err;
>
> I saw this warning hit, and then later kernel crashed with some debugfs
> dentry being bogus, but not sure that is actually related.
>
> Probably err should be initialized to -EINVAL at top of the method.
>
> Thanks,
> Ben
>
I guess in case that error path is interesting, looks like FW stopped
communicating and that is probably what caused the warning:
Likely at least some of this logging is from our own patches, FYI.
[ 159.220486] wlan17: ieee80211_vif_set_links: new_links=0x4; dormant_links=0x0
[ 159.220511] iwlwifi 0000:25:00.0: Failed to send flush command (-5)
[ 159.222763] wlan17: associated
[ 159.224559] wlan18: RX AssocResp from 8a:88:81:84:d9:81 (capab=0x1511 status=0 aid=192)
[ 159.224563] wlan18: ieee80211_vif_set_links: new_links=0x4; dormant_links=0x0
[ 159.224565] wlan18: [link 2] local address 82:fa:ed:e5:1d:de, AP link address 8e:88:a1:84:d9:81 (assoc)
[ 159.224576] wlan18: ieee80211_vif_set_links: new_links=0x4; dormant_links=0x0
[ 159.225503] iwlwifi 0000:25:00.0: Failed to remove station. Id=1
[ 159.226598] wlan18: associated
[ 159.230293] iwlwifi 0000:25:00.0: Failed to send LINK_CONFIG_CMD (action:2): -5
[ 159.236374] iwlwifi 0000:25:00.0: Failed to send PHY_CONTEXT_CMD ret = -5
[ 159.241885] wlan2: ieee80211_vif_set_links: new_links=0x0; dormant_links=0x0
[ 159.254418] iwlwifi 0000:25:00.0: Failed to send LINK_CONFIG_CMD (action:3): -5
[ 159.260503] iwlwifi 0000:25:00.0: Failed to send LINK_CONFIG_CMD (action:1): -5
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* iwlmld iwl_mld_change_vif_links can return un-initilized 'err'
From: Ben Greear @ 2026-02-14 17:11 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Miri Korenblit
Hello,
I believe this method:
static int
iwl_mld_change_vif_links(struct ieee80211_hw *hw,
Can return un-initialized 'err' in case that this return path is taken:
if (WARN_ON(!iwl_mld_error_before_recovery(mld)))
return err;
I saw this warning hit, and then later kernel crashed with some debugfs
dentry being bogus, but not sure that is actually related.
Probably err should be initialized to -EINVAL at top of the method.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] wifi: iwlwifi: prevent NAPI processing after firmware error
From: Cole Leavitt @ 2026-02-14 18:10 UTC (permalink / raw)
To: greearb, johannes.berg, miriam.rachel.korenblit
Cc: linux-wireless, Cole Leavitt
In-Reply-To: <c6f886d4-b9ed-48a6-9723-a738af055b64@candelatech.com>
After a firmware error is detected and STATUS_FW_ERROR is set, NAPI can
still be actively polling or get scheduled from a prior interrupt. The
NAPI poll functions (both legacy and MSIX variants) have no check for
STATUS_FW_ERROR and will continue processing stale RX ring entries from
dying firmware. This can dispatch TX completion notifications containing
corrupt SSN values to iwl_mld_handle_tx_resp_notif(), which passes them
to iwl_trans_reclaim(). If the corrupt SSN causes reclaim to walk TX
queue entries that were already freed by a prior correct reclaim, the
result is an skb use-after-free or double-free.
The race window opens when the MSIX IRQ handler schedules NAPI (lines
2319-2321 in rx.c) before processing the error bit (lines 2382-2396),
or when NAPI is already running on another CPU from a previous interrupt
when STATUS_FW_ERROR gets set on the current CPU.
Add STATUS_FW_ERROR checks to both NAPI poll functions to prevent
processing stale RX data after firmware error, and add early-return
guards in the TX response and compressed BA notification handlers as
defense-in-depth. Each check uses WARN_ONCE to log if the race is
actually hit, which aids diagnosis of the hard-to-reproduce skb
use-after-free reported on Intel BE200.
Note that _iwl_trans_pcie_gen2_stop_device() already calls
iwl_pcie_rx_napi_sync() to quiesce NAPI during device teardown, but that
runs much later in the restart sequence. These checks close the window
between error detection and device stop.
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
---
Tested on Intel BE200 (FW 101.6e695a70.0) by forcing NMI via debugfs.
The WARN_ONCE fires reliably:
iwlwifi: NAPI MSIX poll[0] invoked after FW error
WARNING: drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c:1058
at iwl_pcie_napi_poll_msix+0xff/0x130 [iwlwifi], CPU#22
Confirming NAPI poll is invoked after STATUS_FW_ERROR is set. Without
this patch, that poll processes stale RX ring data from dead firmware.
drivers/net/wireless/intel/iwlwifi/mld/tx.c | 19 ++++++++++++++++++
.../wireless/intel/iwlwifi/pcie/gen1_2/rx.c | 20 +++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/tx.c b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
index 3b4b575aadaa..3e99f3ded9bc 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
@@ -1071,6 +1071,18 @@ void iwl_mld_handle_tx_resp_notif(struct iwl_mld *mld,
bool mgmt = false;
bool tx_failure = (status & TX_STATUS_MSK) != TX_STATUS_SUCCESS;
+ /* Firmware is dead — the TX response may contain corrupt SSN values
+ * from a dying firmware DMA. Processing it could cause
+ * iwl_trans_reclaim() to free the wrong TX queue entries, leading to
+ * skb use-after-free or double-free.
+ */
+ if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: TX resp notif (sta=%d txq=%d) after FW error\n",
+ sta_id, txq_id);
+ return;
+ }
+
if (IWL_FW_CHECK(mld, tx_resp->frame_count != 1,
"Invalid tx_resp notif frame_count (%d)\n",
tx_resp->frame_count))
@@ -1349,6 +1361,13 @@ void iwl_mld_handle_compressed_ba_notif(struct iwl_mld *mld,
u8 sta_id = ba_res->sta_id;
struct ieee80211_link_sta *link_sta;
+ if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: BA notif (sta=%d) after FW error\n",
+ sta_id);
+ return;
+ }
+
if (!tfd_cnt)
return;
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
index 619a9505e6d9..ba18d35fa55d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
@@ -1015,6 +1015,18 @@ static int iwl_pcie_napi_poll(struct napi_struct *napi, int budget)
trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
trans = trans_pcie->trans;
+ /* Stop processing RX if firmware has crashed. Stale notifications
+ * from dying firmware (e.g. TX completions with corrupt SSN values)
+ * can cause use-after-free in reclaim paths.
+ */
+ if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: NAPI poll[%d] invoked after FW error\n",
+ rxq->id);
+ napi_complete_done(napi, 0);
+ return 0;
+ }
+
ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n",
@@ -1042,6 +1054,14 @@ static int iwl_pcie_napi_poll_msix(struct napi_struct *napi, int budget)
trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
trans = trans_pcie->trans;
+ if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: NAPI MSIX poll[%d] invoked after FW error\n",
+ rxq->id);
+ napi_complete_done(napi, 0);
+ return 0;
+ }
+
ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n", rxq->id, ret,
budget);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] wifi: iwlwifi: prevent NAPI processing after firmware error
From: Cole Leavitt @ 2026-02-14 18:33 UTC (permalink / raw)
To: greearb
Cc: johannes.berg, miriam.rachel.korenblit, linux-wireless,
Cole Leavitt
In-Reply-To: <5be8a502-d53a-4cce-821f-202368c44f6d@candelatech.com>
Ben,
Good catch on both fronts.
On the build_tfd dangling pointer -- you're right. The failure path at
line 775 leaves entries[idx].skb/cmd pointing at caller-owned objects
(set at lines 763-764). The caller gets -1 and presumably frees the
skb, so entries[idx].skb becomes a dangling pointer. While write_ptr
not advancing means current unmap paths won't iterate to that index,
it's a latent UAF waiting for a flush path change or future code to
touch it. Two NULL stores inside a held spinlock cost nothing. I think
this should go upstream as its own patch.
On the TOCTOU question -- this is the part I spent the most time on.
The window you're asking about is: firmware starts producing corrupt
completion data *before* STATUS_FW_ERROR gets set. Our NAPI/TX handler
checks can't help there because the flag isn't set yet.
The primary guard in that window is iwl_txq_used() in
iwl_pcie_reclaim(). It validates that the firmware's SSN falls within
[read_ptr, write_ptr). This catches wild values -- out-of-range SSNs,
wraparound corruption, etc.
What it can't catch is an in-range corrupt SSN -- e.g., firmware says
reclaim up to index 15 when legitimate is 8, but write_ptr is 20.
That passes bounds checking and the reclaim loop frees skbs for
entries still in-flight (active DMA). The NULL skb WARN_ONCE in the
loop catches double-reclaim but not first-time over-reclaim.
The complete fix for this would be a per-entry generation counter --
tag each entry on submit, validate on reclaim. But that adds per-entry
overhead on the TX hot path to protect against a condition (firmware
producing corrupt completions) that is already terminal. I think the
right trade-off is:
1. Your build_tfd NULL fix (eliminates one dangling pointer class)
2. STATUS_FW_ERROR checks in NAPI poll + TX handlers (this series --
shrinks the detection window to near-zero)
3. The existing iwl_txq_used() bounds check (catches most corrupt
SSNs)
Together these make the damage window small enough that a per-entry
generation scheme isn't justified -- by the time firmware is sending
corrupt SSNs, we're in dump-and-reset territory anyway.
That said, if you're seeing corruption patterns in your customer
testing where a valid-looking-but-wrong SSN gets through before
FW_ERROR fires, I'd be very interested in the traces. That would
change the cost/benefit on the generation counter approach.
Thanks,
Cole
^ permalink raw reply
* [PATCH] wifi: iwlwifi: prevent NAPI processing after firmware error
From: Cole Leavitt @ 2026-02-14 18:41 UTC (permalink / raw)
To: johannes.berg, miriam.rachel.korenblit
Cc: greearb, linux-wireless, stable, Cole Leavitt
In-Reply-To: <20260214181018.6091-1-cole@unwrap.rs>
After a firmware error is detected and STATUS_FW_ERROR is set, NAPI can
still be actively polling or get scheduled from a prior interrupt. The
NAPI poll functions (both legacy and MSIX variants) have no check for
STATUS_FW_ERROR and will continue processing stale RX ring entries from
dying firmware. This can dispatch TX completion notifications containing
corrupt SSN values to iwl_mld_handle_tx_resp_notif(), which passes them
to iwl_trans_reclaim(). If the corrupt SSN causes reclaim to walk TX
queue entries that were already freed by a prior correct reclaim, the
result is an skb use-after-free or double-free.
The race window opens when the MSIX IRQ handler schedules NAPI (lines
2319-2321 in rx.c) before processing the error bit (lines 2382-2396),
or when NAPI is already running on another CPU from a previous interrupt
when STATUS_FW_ERROR gets set on the current CPU.
Add STATUS_FW_ERROR checks to both NAPI poll functions to prevent
processing stale RX data after firmware error, and add early-return
guards in the TX response and compressed BA notification handlers as
defense-in-depth. Each check uses WARN_ONCE to log if the race is
actually hit, which aids diagnosis of the hard-to-reproduce skb
use-after-free reported on Intel BE200.
Note that _iwl_trans_pcie_gen2_stop_device() already calls
iwl_pcie_rx_napi_sync() to quiesce NAPI during device teardown, but that
runs much later in the restart sequence. These checks close the window
between error detection and device stop.
Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
Cc: stable@vger.kernel.org
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
---
drivers/net/wireless/intel/iwlwifi/mld/tx.c | 19 ++++++++++++++++++
.../wireless/intel/iwlwifi/pcie/gen1_2/rx.c | 20 +++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/tx.c b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
index 3b4b575aadaa..3e99f3ded9bc 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
@@ -1071,6 +1071,18 @@ void iwl_mld_handle_tx_resp_notif(struct iwl_mld *mld,
bool mgmt = false;
bool tx_failure = (status & TX_STATUS_MSK) != TX_STATUS_SUCCESS;
+ /* Firmware is dead — the TX response may contain corrupt SSN values
+ * from a dying firmware DMA. Processing it could cause
+ * iwl_trans_reclaim() to free the wrong TX queue entries, leading to
+ * skb use-after-free or double-free.
+ */
+ if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: TX resp notif (sta=%d txq=%d) after FW error\n",
+ sta_id, txq_id);
+ return;
+ }
+
if (IWL_FW_CHECK(mld, tx_resp->frame_count != 1,
"Invalid tx_resp notif frame_count (%d)\n",
tx_resp->frame_count))
@@ -1349,6 +1361,13 @@ void iwl_mld_handle_compressed_ba_notif(struct iwl_mld *mld,
u8 sta_id = ba_res->sta_id;
struct ieee80211_link_sta *link_sta;
+ if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: BA notif (sta=%d) after FW error\n",
+ sta_id);
+ return;
+ }
+
if (!tfd_cnt)
return;
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
index 619a9505e6d9..ba18d35fa55d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
@@ -1015,6 +1015,18 @@ static int iwl_pcie_napi_poll(struct napi_struct *napi, int budget)
trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
trans = trans_pcie->trans;
+ /* Stop processing RX if firmware has crashed. Stale notifications
+ * from dying firmware (e.g. TX completions with corrupt SSN values)
+ * can cause use-after-free in reclaim paths.
+ */
+ if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: NAPI poll[%d] invoked after FW error\n",
+ rxq->id);
+ napi_complete_done(napi, 0);
+ return 0;
+ }
+
ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n",
@@ -1042,6 +1054,14 @@ static int iwl_pcie_napi_poll_msix(struct napi_struct *napi, int budget)
trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
trans = trans_pcie->trans;
+ if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: NAPI MSIX poll[%d] invoked after FW error\n",
+ rxq->id);
+ napi_complete_done(napi, 0);
+ return 0;
+ }
+
ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n", rxq->id, ret,
budget);
--
2.52.0
^ permalink raw reply related
* [PATCH v3] wifi: iwlwifi: prevent NAPI processing after firmware error
From: Cole Leavitt @ 2026-02-14 18:43 UTC (permalink / raw)
To: johannes.berg, miriam.rachel.korenblit
Cc: greearb, linux-wireless, stable, Cole Leavitt
In-Reply-To: <20260214181018.6091-1-cole@unwrap.rs>
After a firmware error is detected and STATUS_FW_ERROR is set, NAPI can
still be actively polling or get scheduled from a prior interrupt. The
NAPI poll functions (both legacy and MSIX variants) have no check for
STATUS_FW_ERROR and will continue processing stale RX ring entries from
dying firmware. This can dispatch TX completion notifications containing
corrupt SSN values to iwl_mld_handle_tx_resp_notif(), which passes them
to iwl_trans_reclaim(). If the corrupt SSN causes reclaim to walk TX
queue entries that were already freed by a prior correct reclaim, the
result is an skb use-after-free or double-free.
The race window opens when the MSIX IRQ handler schedules NAPI (lines
2319-2321 in rx.c) before processing the error bit (lines 2382-2396),
or when NAPI is already running on another CPU from a previous interrupt
when STATUS_FW_ERROR gets set on the current CPU.
Add STATUS_FW_ERROR checks to both NAPI poll functions to prevent
processing stale RX data after firmware error, and add early-return
guards in the TX response and compressed BA notification handlers as
defense-in-depth. Each check uses WARN_ONCE to log if the race is
actually hit, which aids diagnosis of the hard-to-reproduce skb
use-after-free reported on Intel BE200.
Note that _iwl_trans_pcie_gen2_stop_device() already calls
iwl_pcie_rx_napi_sync() to quiesce NAPI during device teardown, but that
runs much later in the restart sequence. These checks close the window
between error detection and device stop.
Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
Cc: stable@vger.kernel.org
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
---
Changes since v1:
- Added Fixes: tag and Cc: stable@vger.kernel.org
Tested on Intel BE200 (FW 101.6e695a70.0) by forcing NMI via debugfs.
The WARN_ONCE fires reliably:
iwlwifi: NAPI MSIX poll[0] invoked after FW error
WARNING: drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c:1058
at iwl_pcie_napi_poll_msix+0xff/0x130 [iwlwifi], CPU#22
Confirming NAPI poll is invoked after STATUS_FW_ERROR is set. Without
this patch, that poll processes stale RX ring data from dead firmware.
drivers/net/wireless/intel/iwlwifi/mld/tx.c | 19 ++++++++++++++++++
.../wireless/intel/iwlwifi/pcie/gen1_2/rx.c | 20 +++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/tx.c b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
index 3b4b575aadaa..3e99f3ded9bc 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
@@ -1071,6 +1071,18 @@ void iwl_mld_handle_tx_resp_notif(struct iwl_mld *mld,
bool mgmt = false;
bool tx_failure = (status & TX_STATUS_MSK) != TX_STATUS_SUCCESS;
+ /* Firmware is dead — the TX response may contain corrupt SSN values
+ * from a dying firmware DMA. Processing it could cause
+ * iwl_trans_reclaim() to free the wrong TX queue entries, leading to
+ * skb use-after-free or double-free.
+ */
+ if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: TX resp notif (sta=%d txq=%d) after FW error\n",
+ sta_id, txq_id);
+ return;
+ }
+
if (IWL_FW_CHECK(mld, tx_resp->frame_count != 1,
"Invalid tx_resp notif frame_count (%d)\n",
tx_resp->frame_count))
@@ -1349,6 +1361,13 @@ void iwl_mld_handle_compressed_ba_notif(struct iwl_mld *mld,
u8 sta_id = ba_res->sta_id;
struct ieee80211_link_sta *link_sta;
+ if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: BA notif (sta=%d) after FW error\n",
+ sta_id);
+ return;
+ }
+
if (!tfd_cnt)
return;
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
index 619a9505e6d9..ba18d35fa55d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
@@ -1015,6 +1015,18 @@ static int iwl_pcie_napi_poll(struct napi_struct *napi, int budget)
trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
trans = trans_pcie->trans;
+ /* Stop processing RX if firmware has crashed. Stale notifications
+ * from dying firmware (e.g. TX completions with corrupt SSN values)
+ * can cause use-after-free in reclaim paths.
+ */
+ if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: NAPI poll[%d] invoked after FW error\n",
+ rxq->id);
+ napi_complete_done(napi, 0);
+ return 0;
+ }
+
ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n",
@@ -1042,6 +1054,14 @@ static int iwl_pcie_napi_poll_msix(struct napi_struct *napi, int budget)
trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
trans = trans_pcie->trans;
+ if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
+ WARN_ONCE(1,
+ "iwlwifi: NAPI MSIX poll[%d] invoked after FW error\n",
+ rxq->id);
+ napi_complete_done(napi, 0);
+ return 0;
+ }
+
ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n", rxq->id, ret,
budget);
--
2.52.0
^ permalink raw reply related
* [PATCH] wifi: iwlwifi: Clean dangling pointer in tx path
From: greearb @ 2026-02-14 19:05 UTC (permalink / raw)
To: linux-wireless; +Cc: miriam.rachel.korenblit, Ben Greear
From: Ben Greear <greearb@candelatech.com>
If iwl_txq_gen2_build_tfd fails, we return -1, which will cause calling
code to dispose of the skb one way or another. Remove any reference to
that skb from the txq entries so that nothing will try to access it
later.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/tx-gen2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/tx-gen2.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/tx-gen2.c
index df0545f09da95..f6db315658764 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/tx-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/tx-gen2.c
@@ -773,6 +773,8 @@ int iwl_txq_gen2_tx(struct iwl_trans *trans, struct sk_buff *skb,
tfd = iwl_txq_gen2_build_tfd(trans, txq, dev_cmd, skb, out_meta);
if (!tfd) {
+ txq->entries[idx].skb = NULL;
+ txq->entries[idx].cmd = NULL;
spin_unlock(&txq->lock);
return -1;
}
--
2.47.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] wifi: rtw89: ser: enable error IMR after recovering from L1
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable; +Cc: Zong-Zhe Yang, Ping-Ke Shih, Sasha Levin, linux-wireless
From: Zong-Zhe Yang <kevin_yang@realtek.com>
[ Upstream commit f4de946bdb379f543e3a599f8f048d741ad4a58e ]
After recovering from L1, explicitly enable error IMR to ensure next
L1 SER (system error recovery) can work normally.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
That's a different change (about FW event mode). The current commit is
standalone - it fixes the error IMR not being re-enabled after L1
recovery, which is an independent fix.
### Verdict
**This is a real bug fix**: After L1 SER recovery, error interrupts are
not re-enabled, preventing the device from detecting subsequent hardware
errors. This leaves the WiFi adapter in a degraded state where the next
error will render it non-functional.
**Meets stable criteria**:
- Fixes a real bug (error recovery mechanism broken after first L1
recovery)
- Small and contained change
- Low risk (calls existing, well-tested function at appropriate recovery
point)
- Affects real users (any user with rtw89 devices that experience L1
errors)
**Concerns for backport**:
- The struct change adds a new function pointer - this is structural but
necessary
- The patch should apply cleanly to recent stable trees that have the
rtw89 gen architecture
- Older stable trees may not have the `rtw89_mac_gen_def` infrastructure
at all
The fix is small, focused on a real bug in error recovery, and the risk
of regression is very low since it calls an existing function that's
already used during initialization.
**YES**
drivers/net/wireless/realtek/rtw89/mac.c | 1 +
drivers/net/wireless/realtek/rtw89/mac.h | 1 +
drivers/net/wireless/realtek/rtw89/mac_be.c | 1 +
drivers/net/wireless/realtek/rtw89/ser.c | 10 ++++++++++
4 files changed, 13 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c
index d78fbe73e3657..b4c292c7e829d 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.c
+++ b/drivers/net/wireless/realtek/rtw89/mac.c
@@ -7184,6 +7184,7 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_ax = {
.check_mac_en = rtw89_mac_check_mac_en_ax,
.sys_init = sys_init_ax,
.trx_init = trx_init_ax,
+ .err_imr_ctrl = err_imr_ctrl_ax,
.hci_func_en = rtw89_mac_hci_func_en_ax,
.dmac_func_pre_en = rtw89_mac_dmac_func_pre_en_ax,
.dle_func_en = dle_func_en_ax,
diff --git a/drivers/net/wireless/realtek/rtw89/mac.h b/drivers/net/wireless/realtek/rtw89/mac.h
index 0007229d67537..a4ed1c545609e 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.h
+++ b/drivers/net/wireless/realtek/rtw89/mac.h
@@ -1019,6 +1019,7 @@ struct rtw89_mac_gen_def {
enum rtw89_mac_hwmod_sel sel);
int (*sys_init)(struct rtw89_dev *rtwdev);
int (*trx_init)(struct rtw89_dev *rtwdev);
+ void (*err_imr_ctrl)(struct rtw89_dev *rtwdev, bool en);
void (*hci_func_en)(struct rtw89_dev *rtwdev);
void (*dmac_func_pre_en)(struct rtw89_dev *rtwdev);
void (*dle_func_en)(struct rtw89_dev *rtwdev, bool enable);
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index 556e5f98e8d41..9b9e646487346 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -2601,6 +2601,7 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_be = {
.check_mac_en = rtw89_mac_check_mac_en_be,
.sys_init = sys_init_be,
.trx_init = trx_init_be,
+ .err_imr_ctrl = err_imr_ctrl_be,
.hci_func_en = rtw89_mac_hci_func_en_be,
.dmac_func_pre_en = rtw89_mac_dmac_func_pre_en_be,
.dle_func_en = dle_func_en_be,
diff --git a/drivers/net/wireless/realtek/rtw89/ser.c b/drivers/net/wireless/realtek/rtw89/ser.c
index f99e179f7ff9f..7fdc69578da31 100644
--- a/drivers/net/wireless/realtek/rtw89/ser.c
+++ b/drivers/net/wireless/realtek/rtw89/ser.c
@@ -431,6 +431,14 @@ static void hal_send_m4_event(struct rtw89_ser *ser)
rtw89_mac_set_err_status(rtwdev, MAC_AX_ERR_L1_RCVY_EN);
}
+static void hal_enable_err_imr(struct rtw89_ser *ser)
+{
+ struct rtw89_dev *rtwdev = container_of(ser, struct rtw89_dev, ser);
+ const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
+
+ mac->err_imr_ctrl(rtwdev, true);
+}
+
/* state handler */
static void ser_idle_st_hdl(struct rtw89_ser *ser, u8 evt)
{
@@ -552,6 +560,8 @@ static void ser_do_hci_st_hdl(struct rtw89_ser *ser, u8 evt)
break;
case SER_EV_MAC_RESET_DONE:
+ hal_enable_err_imr(ser);
+
ser_state_goto(ser, SER_IDLE_ST);
break;
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] wifi: ath11k: Fix failure to connect to a 6 GHz AP
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable
Cc: Qian Zhang, Baochen Qiang, Jeff Johnson, Sasha Levin, jjohnson,
linux-wireless, ath11k
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Qian Zhang <qian.zhang@oss.qualcomm.com>
[ Upstream commit 0bc8c48de6f06c0cac52dde024ffda4433de6234 ]
STA fails to connect to a 6 GHz AP with the following errors:
ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1
wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING)
ath11k_reg_handle_chan_list() treats the update as redundant and
returns -EINVAL. That causes the connection attempt to fail.
Avoid unnecessary validation during association. Apply the regulatory
redundant check only when the power type is IEEE80211_REG_UNSET_AP,
which only occurs during core initialization.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260108034607.812885-1-qian.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The key prerequisite is `e3d373ec4f02b` which added the 6 GHz regulatory
type support and the `power_type` parameter to
`ath11k_reg_handle_chan_list()`. This was merged in v6.9 cycle. For
stable trees that don't have this function signature, the patch wouldn't
apply anyway (and wouldn't be needed since 6 GHz support wouldn't exist
in the same form).
### Summary
**What the fix does**: Narrows a regulatory update redundancy check to
only apply during core initialization (`IEEE80211_REG_UNSET_AP`), not
during association with a 6 GHz AP. Also fixes a memory leak on the
early-return path by properly calling `ath11k_reg_reset_info()`.
**Why it matters for stable users**: Without this fix, users with ath11k
WiFi cards (WCN6855, etc.) cannot connect to 6 GHz WiFi 6E access points
at all. This is a complete connectivity failure, not a subtle
performance issue.
**Meets stable criteria**:
- Obviously correct and tested on real hardware
- Fixes a real, user-visible bug (WiFi connection failure)
- Fixes an important issue (complete loss of 6 GHz WiFi connectivity)
- Small and contained (5 lines of logic in 1 file)
- Does not introduce new features
- Also fixes a memory leak (bonus)
**Risk assessment**: Very low. The change is conservative — it only
narrows an existing condition. The worst case scenario is that the
redundancy check doesn't fire during association, which is the correct
behavior since the regulatory update should be processed during
association.
**Dependencies**: Requires `e3d373ec4f02b` (6 GHz regulatory type
support) in the stable tree. This limits backport to 6.9+ stable trees,
but for those trees this fix is important.
**YES**
drivers/net/wireless/ath/ath11k/reg.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/ath/ath11k/reg.c
index d62a2014315a0..49b79648752cf 100644
--- a/drivers/net/wireless/ath/ath11k/reg.c
+++ b/drivers/net/wireless/ath/ath11k/reg.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: BSD-3-Clause-Clear
/*
* Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
- * Copyright (c) 2021-2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
#include <linux/rtnetlink.h>
@@ -926,8 +926,11 @@ int ath11k_reg_handle_chan_list(struct ath11k_base *ab,
*/
if (ab->default_regd[pdev_idx] && !ab->new_regd[pdev_idx] &&
!memcmp((char *)ab->default_regd[pdev_idx]->alpha2,
- (char *)reg_info->alpha2, 2))
- goto retfail;
+ (char *)reg_info->alpha2, 2) &&
+ power_type == IEEE80211_REG_UNSET_AP) {
+ ath11k_reg_reset_info(reg_info);
+ return 0;
+ }
/* Intersect new rules with default regd if a new country setting was
* requested, i.e a default regd was already set during initialization
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.1] wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable
Cc: Bitterblue Smith, Ping-Ke Shih, Sasha Levin, linux-wireless
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
[ Upstream commit 44d1f624bbdd2d60319374ba85f7195a28d00c90 ]
rtw8822b_set_antenna() can be called from userspace when the chip is
powered off. In that case a WARNING is triggered in
rtw8822b_config_trx_mode() because trying to read the RF registers
when the chip is powered off returns an unexpected value.
Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when
the chip is powered on.
------------[ cut here ]------------
write RF mode table fail
WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]
CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1
Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021
RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]
Call Trace:
<TASK>
rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b]
rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb]
ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3]
nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? netdev_run_todo+0x63/0x550
genl_family_rcv_msg_doit+0xfc/0x160
genl_rcv_msg+0x1aa/0x2b0
? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? __pfx_genl_rcv_msg+0x10/0x10
netlink_rcv_skb+0x59/0x110
genl_rcv+0x28/0x40
netlink_unicast+0x285/0x3c0
? __alloc_skb+0xdb/0x1a0
netlink_sendmsg+0x20d/0x430
____sys_sendmsg+0x39f/0x3d0
? import_iovec+0x2f/0x40
___sys_sendmsg+0x99/0xe0
? refill_obj_stock+0x12e/0x240
__sys_sendmsg+0x8a/0xf0
do_syscall_64+0x81/0x970
? do_syscall_64+0x81/0x970
? ksys_read+0x73/0xf0
? do_syscall_64+0x81/0x970
? count_memcg_events+0xc2/0x190
? handle_mm_fault+0x1d7/0x2d0
? do_user_addr_fault+0x21a/0x690
? exc_page_fault+0x7e/0x1a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
---[ end trace 0000000000000000 ]---
Link: https://github.com/lwfinger/rtw88/issues/366
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/fb9a3444-9319-4aa2-8719-35a6308bf568@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis of commit: wifi: rtw88: 8822b: Avoid WARNING in
rtw8822b_config_trx_mode()
### 1. COMMIT MESSAGE ANALYSIS
The commit message is very clear and well-documented:
- **Problem**: `rtw8822b_set_antenna()` can be called from userspace
(via `iw` tool through nl80211/cfg80211/mac80211 path) when the WiFi
chip is powered off.
- **Symptom**: A `WARNING` is triggered in `rtw8822b_config_trx_mode()`
because reading RF registers while the chip is powered off returns
unexpected values.
- **Solution**: Only call `rtw8822b_config_trx_mode()` when the chip is
powered on (checked via `RTW_FLAG_POWERON` flag).
- **Evidence**: Full stack trace included showing the WARNING triggered
from userspace via `iw` command.
- **Link**: Bug report at https://github.com/lwfinger/rtw88/issues/366 —
real users reported this issue.
### 2. CODE CHANGE ANALYSIS
The change is minimal and surgical — a single conditional check:
```c
- rtw8822b_config_trx_mode(rtwdev, antenna_tx, antenna_rx, false);
+ if (test_bit(RTW_FLAG_POWERON, rtwdev->flags))
+ rtw8822b_config_trx_mode(rtwdev, antenna_tx, antenna_rx,
false);
```
This is a 2-line change (net +1 line) that:
- Wraps the call to `rtw8822b_config_trx_mode()` with a power-on state
check
- Uses the existing `RTW_FLAG_POWERON` flag — no new infrastructure
needed
- The antenna_tx/antenna_rx values are still saved to `hal->antenna_tx`
and `hal->antenna_rx` regardless of power state, so the configuration
will be applied when the chip powers on
### 3. CLASSIFICATION
- **Bug fix**: YES — fixes a WARNING triggered from userspace
- **Feature addition**: NO
- **Type**: Fixes improper state handling when userspace interacts with
the driver while hardware is powered off
### 4. SCOPE AND RISK ASSESSMENT
- **Lines changed**: 2 lines (1 removed, 2 added)
- **Files touched**: 1 file
(`drivers/net/wireless/realtek/rtw88/rtw8822b.c`)
- **Complexity**: Extremely low — trivial conditional guard
- **Risk of regression**: Very low. The only scenario where behavior
changes is when the chip is powered off, and in that case, trying to
configure RF registers was already broken (producing the WARNING). The
antenna settings are saved to HAL state regardless, so they'll be
applied at power-on.
- **Subsystem**: WiFi driver (rtw88) — a commonly used Realtek WiFi
driver
### 5. USER IMPACT
- **Who is affected**: Users of rtw88 8822b-based WiFi adapters (common
in many laptops)
- **Trigger**: Simply running `iw` commands to set antenna configuration
while the interface is down
- **Severity**: WARNING in kernel log, potentially confusing to users,
and the WARNING mechanism in the driver indicates an unexpected state
that could have further consequences
- **Real-world**: Bug was reported by actual users on GitHub issue
tracker
### 6. STABILITY INDICATORS
- **Acked-by**: Ping-Ke Shih (Realtek maintainer for this driver)
- **Signed-off-by**: Both the author and the subsystem maintainer
- **Bug report link**: Real user-reported issue with reproduction steps
### 7. DEPENDENCY CHECK
- The fix uses `RTW_FLAG_POWERON` and `test_bit()`, both of which have
been present in the rtw88 driver for a long time (since the driver's
introduction)
- No dependencies on other commits
- The `rtw8822b_set_antenna()` function and `rtw8822b_config_trx_mode()`
have been stable for many kernel versions
- This will apply cleanly to any stable tree that has the rtw88 driver
### 8. STABLE KERNEL CRITERIA
1. **Obviously correct and tested**: YES — the logic is trivially
correct: don't access hardware registers when hardware is off
2. **Fixes a real bug**: YES — a WARNING triggered from userspace
3. **Important issue**: YES — kernel WARNING from userspace interaction,
reproducible
4. **Small and contained**: YES — 2-line change in 1 file
5. **No new features**: CORRECT — pure bug fix
6. **Applies cleanly**: Very likely — minimal change to stable code
### Summary
This is a textbook stable backport candidate: a tiny, obviously correct
fix for a user-triggered WARNING in a commonly used WiFi driver. The fix
is minimal (2 lines), well-understood, properly reviewed by the
subsystem maintainer, and addresses a real user-reported issue. The risk
of regression is negligible.
**YES**
drivers/net/wireless/realtek/rtw88/rtw8822b.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
index 89b6485b229a8..4d88cc2f41485 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
@@ -1005,7 +1005,8 @@ static int rtw8822b_set_antenna(struct rtw_dev *rtwdev,
hal->antenna_tx = antenna_tx;
hal->antenna_rx = antenna_rx;
- rtw8822b_config_trx_mode(rtwdev, antenna_tx, antenna_rx, false);
+ if (test_bit(RTW_FLAG_POWERON, rtwdev->flags))
+ rtw8822b_config_trx_mode(rtwdev, antenna_tx, antenna_rx, false);
return 0;
}
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] wifi: rtw89: 8922a: add digital compensation for 2GHz
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable; +Cc: Po-Hao Huang, Ping-Ke Shih, Sasha Levin, linux-wireless
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Po-Hao Huang <phhuang@realtek.com>
[ Upstream commit 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0 ]
This fixes transmit power too low under 2GHz connection. Previously
we missed the settings of 2GHz, add the according calibrated tables.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260117044157.2392958-10-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### Commit Message Analysis
The commit says it "fixes transmit power too low under 2GHz connection"
by adding previously "missed" calibration tables for the 2GHz band. The
subject says "add digital compensation for 2GHz" — this is framed as
adding missing functionality rather than fixing a clear crash/corruption
bug.
### Code Change Analysis
Let me examine the changes in detail:
1. **New data tables added**: Three new static const arrays
(`rtw8922a_digital_pwr_comp_2g_s0_val`,
`rtw8922a_digital_pwr_comp_2g_s1_val`) containing calibration values
for 2GHz band, for path 0 (s0) and path 1 (s1). These are ~37 lines
of pure data.
2. **Function signature change**: `rtw8922a_set_digital_pwr_comp()`
changes the `bool enable` parameter to `u8 band`. This is a semantic
change — previously, for 2GHz, the function would write zeros to all
registers (effectively disabling compensation). Now it writes band-
specific calibration values.
3. **Logic change in `rtw8922a_set_digital_pwr_comp()`**: Previously, if
`enable` was false (2GHz band), all registers were set to 0 (`val =
enable ? digital_pwr_comp[i] : 0`). Now, the function always writes
calibration data, selecting the appropriate table based on band and
path.
4. **Logic change in `rtw8922a_digital_pwr_comp()`**: The `bool enable =
chan->band_type != RTW89_BAND_2G` is replaced with `u8 band =
chan->band_type`, and the band is passed through to the set function.
### Bug Assessment
The original code had a real functional deficiency: on 2GHz, digital
power compensation was completely disabled (all zeros written),
resulting in "transmit power too low." This means:
- **Real user impact**: WiFi connections on 2.4GHz band would have poor
signal/throughput on the RTW8922A chip
- **This is a bug fix**: The 2GHz compensation data was supposed to be
there but was missing. The existing code structure (with
enable/disable logic) was a workaround for having no 2GHz tables
### Scope and Risk Assessment
- **Files changed**: 1 file (rtw8922a.c)
- **Lines added**: ~47 lines of data tables + ~15 lines of logic changes
- **Lines removed**: ~10 lines
- **Scope**: Entirely contained within the RTW8922A WiFi driver
- **Risk**: Low — the change only affects the RTW8922A chip on 2GHz
band. The 5GHz/6GHz paths continue to use the same tables as before.
The logic is straightforward table selection based on band and path.
### Stable Kernel Criteria Check
1. **Obviously correct and tested**: The change is from the Realtek
driver maintainers themselves, adding calibration data they would
have tested. The logic is simple table selection.
2. **Fixes a real bug**: Yes — transmit power too low on 2GHz is a real
functional bug affecting WiFi connectivity.
3. **Important issue**: This affects basic WiFi functionality on 2.4GHz
for users of this chip. Low TX power means poor range, throughput,
and possibly connection drops.
4. **Small and contained**: Yes — single driver file, straightforward
table data addition and selection logic.
5. **No new features**: This restores intended functionality rather than
adding new capability. The driver already supported 2GHz band; it
just had wrong/missing calibration data.
### Concerns
- **RTW8922A is a newer chip**: This is a WiFi 7 (802.11be) chip. Need
to verify it exists in stable trees. The file `rtw8922a.c` was added
relatively recently, so it may not be present in older stable branches
(e.g., 6.1.y, 5.15.y). However, if it is present in a given stable
tree, this fix is clearly needed.
- **No explicit Fixes: tag**: Expected for candidates under review.
- **Data tables are large**: But they're static const data with zero
risk of runtime regression.
- **The `enable` parameter removal**: The old `val = enable ?
digital_pwr_comp[i] : 0` path (writing zeros for 2GHz) is completely
removed. This is the intended behavior change — from "disable on 2GHz"
to "use proper 2GHz tables."
### Verdict
This fixes a real functional bug (low transmit power on 2.4GHz WiFi) for
users of the RTW8922A chip. The fix is contained within a single driver,
adds only calibration data tables and simple selection logic, and comes
from the chip vendor's driver team. While it's a relatively new driver,
for any stable tree that contains this driver, the fix would be
important — 2.4GHz WiFi with too-low TX power is essentially broken for
many use cases.
The change is low-risk, driver-specific, and fixes a real user-facing
problem. It meets stable kernel criteria.
**YES**
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 57 +++++++++++++++----
1 file changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
index 4bcf20612a455..52da0fa02da01 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
@@ -1770,6 +1770,32 @@ static int rtw8922a_ctrl_rx_path_tmac(struct rtw89_dev *rtwdev,
}
#define DIGITAL_PWR_COMP_REG_NUM 22
+static const u32 rtw8922a_digital_pwr_comp_2g_s0_val[][DIGITAL_PWR_COMP_REG_NUM] = {
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010000, 0x00000101,
+ 0x01010101, 0x02020201, 0x02010000, 0x03030202, 0x00000303,
+ 0x03020101, 0x06060504, 0x01010000, 0x06050403, 0x01000606,
+ 0x05040202, 0x07070706},
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010100, 0x00000101,
+ 0x01000000, 0x01010101, 0x01010000, 0x02020202, 0x00000404,
+ 0x03020101, 0x04040303, 0x02010000, 0x03030303, 0x00000505,
+ 0x03030201, 0x05050303},
+};
+
+static const u32 rtw8922a_digital_pwr_comp_2g_s1_val[][DIGITAL_PWR_COMP_REG_NUM] = {
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x01010000, 0x01010101, 0x00000101,
+ 0x01010100, 0x01010101, 0x01010000, 0x02020202, 0x01000202,
+ 0x02020101, 0x03030202, 0x02010000, 0x05040403, 0x01000606,
+ 0x05040302, 0x07070605},
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010100, 0x00000101,
+ 0x01010000, 0x02020201, 0x02010100, 0x03030202, 0x01000404,
+ 0x04030201, 0x05050404, 0x01010100, 0x04030303, 0x01000505,
+ 0x03030101, 0x05050404},
+};
+
static const u32 rtw8922a_digital_pwr_comp_val[][DIGITAL_PWR_COMP_REG_NUM] = {
{0x012C0096, 0x044C02BC, 0x00322710, 0x015E0096, 0x03C8028A,
0x0BB80708, 0x17701194, 0x02020100, 0x03030303, 0x01000303,
@@ -1784,7 +1810,7 @@ static const u32 rtw8922a_digital_pwr_comp_val[][DIGITAL_PWR_COMP_REG_NUM] = {
};
static void rtw8922a_set_digital_pwr_comp(struct rtw89_dev *rtwdev,
- bool enable, u8 nss,
+ u8 band, u8 nss,
enum rtw89_rf_path path)
{
static const u32 ltpc_t0[2] = {R_BE_LTPC_T0_PATH0, R_BE_LTPC_T0_PATH1};
@@ -1792,14 +1818,25 @@ static void rtw8922a_set_digital_pwr_comp(struct rtw89_dev *rtwdev,
u32 addr, val;
u32 i;
- if (nss == 1)
- digital_pwr_comp = rtw8922a_digital_pwr_comp_val[0];
- else
- digital_pwr_comp = rtw8922a_digital_pwr_comp_val[1];
+ if (nss == 1) {
+ if (band == RTW89_BAND_2G)
+ digital_pwr_comp = path == RF_PATH_A ?
+ rtw8922a_digital_pwr_comp_2g_s0_val[0] :
+ rtw8922a_digital_pwr_comp_2g_s1_val[0];
+ else
+ digital_pwr_comp = rtw8922a_digital_pwr_comp_val[0];
+ } else {
+ if (band == RTW89_BAND_2G)
+ digital_pwr_comp = path == RF_PATH_A ?
+ rtw8922a_digital_pwr_comp_2g_s0_val[1] :
+ rtw8922a_digital_pwr_comp_2g_s1_val[1];
+ else
+ digital_pwr_comp = rtw8922a_digital_pwr_comp_val[1];
+ }
addr = ltpc_t0[path];
for (i = 0; i < DIGITAL_PWR_COMP_REG_NUM; i++, addr += 4) {
- val = enable ? digital_pwr_comp[i] : 0;
+ val = digital_pwr_comp[i];
rtw89_phy_write32(rtwdev, addr, val);
}
}
@@ -1808,7 +1845,7 @@ static void rtw8922a_digital_pwr_comp(struct rtw89_dev *rtwdev,
enum rtw89_phy_idx phy_idx)
{
const struct rtw89_chan *chan = rtw89_chan_get(rtwdev, RTW89_CHANCTX_0);
- bool enable = chan->band_type != RTW89_BAND_2G;
+ u8 band = chan->band_type;
u8 path;
if (rtwdev->mlo_dbcc_mode == MLO_1_PLUS_1_1RF) {
@@ -1816,10 +1853,10 @@ static void rtw8922a_digital_pwr_comp(struct rtw89_dev *rtwdev,
path = RF_PATH_A;
else
path = RF_PATH_B;
- rtw8922a_set_digital_pwr_comp(rtwdev, enable, 1, path);
+ rtw8922a_set_digital_pwr_comp(rtwdev, band, 1, path);
} else {
- rtw8922a_set_digital_pwr_comp(rtwdev, enable, 2, RF_PATH_A);
- rtw8922a_set_digital_pwr_comp(rtwdev, enable, 2, RF_PATH_B);
+ rtw8922a_set_digital_pwr_comp(rtwdev, band, 2, RF_PATH_A);
+ rtw8922a_set_digital_pwr_comp(rtwdev, band, 2, RF_PATH_B);
}
}
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.18] wifi: rtw89: pci: validate sequence number of TX release report
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable; +Cc: Ping-Ke Shih, Sasha Levin, linux-wireless
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Ping-Ke Shih <pkshih@realtek.com>
[ Upstream commit 957eda596c7665f2966970fd1dcc35fe299b38e8 ]
Hardware rarely reports abnormal sequence number in TX release report,
which will access out-of-bounds of wd_ring->pages array, causing NULL
pointer dereference.
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U
6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1)
Call Trace:
<IRQ>
rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)]
rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)]
net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759
handle_softirqs+0xbe/0x290 kernel/softirq.c:601
? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)]
__local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423
</IRQ>
<TASK>
rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)]
? irq_thread+0xa7/0x340 kernel/irq/manage.c:0
irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314
? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202
? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220
kthread+0xea/0x110 kernel/kthread.c:376
? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287
? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
To prevent crash, validate rpp_info.seq before using.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260110022019.2254969-2-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### Commit Message Analysis
The commit message is crystal clear about the bug:
- **Hardware rarely reports abnormal sequence numbers** in TX release
reports
- This causes **out-of-bounds access** on `wd_ring->pages` array
- Results in a **NULL pointer dereference** (kernel crash)
- A full crash trace is provided, showing this is a **reproducible,
real-world bug**
The crash trace shows it occurs in an IRQ context
(`rtw89_pci_release_tx` → `rtw89_pci_napi_poll` → `net_rx_action`),
meaning when this bug triggers, it crashes the system during normal
network operation.
### Code Change Analysis
The fix is extremely small and surgical — it adds a **bounds check** on
`rpp_info.seq` before it's used to index into the `wd_ring->pages`
array:
```c
if (unlikely(rpp_info.seq >= RTW89_PCI_TXWD_NUM_MAX)) {
rtw89_warn(rtwdev, "invalid seq %d\n", rpp_info.seq);
return;
}
```
This is placed right before the line:
```c
txwd = &wd_ring->pages[rpp_info.seq];
```
Without this check, an out-of-bounds `seq` value from the hardware leads
to accessing memory beyond the `pages` array, causing a NULL pointer
dereference (or potentially worse — arbitrary memory access).
The only other change is adding `unlikely()` to an existing check on
`rpp_info.txch == RTW89_TXCH_CH12`, which is a minor optimization hint
and completely safe.
### Bug Classification
This is a textbook **out-of-bounds array access / NULL pointer
dereference** fix:
- The `seq` value comes from hardware (parsed from the TX release report
via `parse_rpp`)
- Hardware can occasionally provide invalid/corrupt values
- No validation was performed before using `seq` as an array index
- Result: kernel crash (BUG: kernel NULL pointer dereference)
### Stable Kernel Criteria Assessment
1. **Obviously correct and tested**: Yes — it's a simple bounds check
before array access. The author (Realtek maintainer) clearly
understands the code.
2. **Fixes a real bug**: Yes — NULL pointer dereference causing kernel
crash, with a full stack trace demonstrating the issue.
3. **Important issue**: Yes — kernel crash/oops during normal WiFi
operation.
4. **Small and contained**: Yes — adds 4 lines of bounds checking code,
changes 1 line (adding `unlikely()`), in a single file.
5. **No new features**: Correct — pure bug fix.
6. **Applies cleanly**: The change is self-contained with no
dependencies on other commits.
### Risk Assessment
**Risk: Very Low**
- The fix only adds a validation check that returns early on invalid
input
- It cannot introduce regressions — it only rejects values that would
have caused a crash anyway
- The `RTW89_PCI_TXWD_NUM_MAX` constant is already used elsewhere in the
driver for allocating the `pages` array, so it's the correct bound
- Single file, single function, minimal change
**Benefit: High**
- Prevents kernel crashes for rtw89 WiFi users
- The rtw89 driver supports popular Realtek WiFi chips (RTW8852A,
RTW8852B, RTW8852C, etc.) used in many laptops
- The crash occurs during normal WiFi operation when hardware reports a
bad sequence number
### Author and Trust
- **Ping-Ke Shih** is the Realtek WiFi driver maintainer — highly
trusted for rtw89 changes
- The commit includes a detailed crash trace demonstrating the real-
world impact
- The kernel version in the trace (6.1.145) suggests this was actually
hit on a stable kernel
### Dependencies
None. The fix is completely self-contained. `RTW89_PCI_TXWD_NUM_MAX` is
already defined in the driver.
### Summary
This is an ideal stable backport candidate: a small, obviously correct
bounds check that prevents a kernel NULL pointer dereference crash in a
widely-used WiFi driver. It has zero regression risk, fixes a real bug
that users hit in production, and is authored by the subsystem
maintainer.
**YES**
drivers/net/wireless/realtek/rtw89/pci.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
index a66fcdb0293b6..093960d7279f8 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -604,11 +604,16 @@ static void rtw89_pci_release_rpp(struct rtw89_dev *rtwdev, void *rpp)
info->parse_rpp(rtwdev, rpp, &rpp_info);
- if (rpp_info.txch == RTW89_TXCH_CH12) {
+ if (unlikely(rpp_info.txch == RTW89_TXCH_CH12)) {
rtw89_warn(rtwdev, "should no fwcmd release report\n");
return;
}
+ if (unlikely(rpp_info.seq >= RTW89_PCI_TXWD_NUM_MAX)) {
+ rtw89_warn(rtwdev, "invalid seq %d\n", rpp_info.seq);
+ return;
+ }
+
tx_ring = &rtwpci->tx.rings[rpp_info.txch];
wd_ring = &tx_ring->wd_ring;
txwd = &wd_ring->pages[rpp_info.seq];
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-5.10] wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable
Cc: Ziyi Guo, Stanislaw Gruszka, Johannes Berg, Sasha Levin,
linux-wireless
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Ziyi Guo <n7l8m4@u.northwestern.edu>
[ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ]
il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex.
However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating
that callers must hold this lock.
All other callers of il_set_tx_power() properly acquire the mutex:
- il_bg_scan_completed() acquires mutex at common.c:1683
- il_mac_config() acquires mutex at common.c:5006
- il3945_commit_rxon() and il4965_commit_rxon() are called via work
queues that hold the mutex (like il4965_bg_alive_start)
Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in
the sysfs store function to fix the missing lock protection.
Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### Commit Message Analysis
The commit message is clear and well-documented. It identifies a
specific bug: `il4965_store_tx_power()` calls `il_set_tx_power()`
without holding `il->mutex`, but `il_set_tx_power()` requires this lock
(enforced via `lockdep_assert_held`). The message also documents that
all other callers properly acquire the mutex, making this the only call
site that's missing the protection.
### Code Change Analysis
The fix is minimal and surgical — exactly 2 lines added:
```c
mutex_lock(&il->mutex);
ret = il_set_tx_power(il, val, false);
mutex_unlock(&il->mutex);
```
This is a sysfs store handler (`il4965_store_tx_power`), which can be
triggered from userspace by writing to the `tx_power` sysfs attribute.
Without the mutex:
1. **lockdep warning**: The `lockdep_assert_held(&il->mutex)` in
`il_set_tx_power()` will fire a warning/splat every time a user
writes to this sysfs file.
2. **Race condition**: `il_set_tx_power()` modifies driver state that is
also accessed by other code paths (scan completion, mac80211 config,
rxon commits) which all hold the mutex. Without the mutex, concurrent
access from sysfs and these other paths could corrupt driver state,
potentially leading to firmware errors, crashes, or undefined
behavior.
### Classification
This is a **synchronization bug fix** — missing mutex protection around
a function that requires it. It falls squarely into the "race condition"
and "missing locking" categories of stable-worthy fixes.
### Scope and Risk Assessment
- **Lines changed**: 2 (adding mutex_lock/unlock)
- **Files touched**: 1
- **Risk**: Extremely low. Adding mutex protection around a single
function call in a sysfs handler is about as safe as it gets. The
mutex is already used throughout the driver, and all other callers of
`il_set_tx_power()` already hold it. There's no risk of deadlock since
this is a sysfs store handler (not called from any context that
already holds the mutex).
- **Subsystem**: iwlegacy wireless driver — a mature, legacy Intel WiFi
driver
### User Impact
- Any user with iwlegacy hardware who writes to the `tx_power` sysfs
attribute will trigger a lockdep splat (if lockdep is enabled) and
potentially experience a race condition
- The race could lead to corrupted driver state, firmware errors, or
crashes
- The sysfs interface is a user-facing control, so this is a realistic
trigger path
### Stability Indicators
- **Acked-by**: Stanislaw Gruszka (iwlegacy maintainer) — strong signal
- **Committed by**: Johannes Berg (Intel wireless maintainer) — strong
signal
- The fix pattern (adding mutex around a call that requires it) is well-
understood and obviously correct
### Dependency Check
This commit is completely self-contained. It adds standard
mutex_lock/unlock calls around an existing function call. No other
patches are needed. The iwlegacy driver and this specific code path have
existed in stable kernels for a very long time.
### Conclusion
This is a textbook stable backport candidate:
- **Obviously correct**: The function requires the mutex (has lockdep
assertion), all other callers hold it, this one doesn't — the fix adds
the missing lock
- **Fixes a real bug**: Missing synchronization causing potential races
and lockdep warnings
- **Small and contained**: 2 lines added, 1 file changed
- **No new features**: Pure bug fix
- **Low risk**: Standard locking pattern, well-tested by maintainer
review
- **Acked by subsystem maintainer**: Confirms the fix is appropriate
**YES**
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
index 3588dec75ebdd..57fa866efd9f8 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
@@ -4606,7 +4606,9 @@ il4965_store_tx_power(struct device *d, struct device_attribute *attr,
if (ret)
IL_INFO("%s is not in decimal form.\n", buf);
else {
+ mutex_lock(&il->mutex);
ret = il_set_tx_power(il, val, false);
+ mutex_unlock(&il->mutex);
if (ret)
IL_ERR("failed setting tx power (0x%08x).\n", ret);
else
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.6] wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6H
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable
Cc: Hsiu-Ming Chang, Ping-Ke Shih, Sasha Levin, linux-wireless
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Hsiu-Ming Chang <cges30901@gmail.com>
[ Upstream commit 77653c327e11c71c5363b18a53fbf2b92ed21da4 ]
Add support for Mercusys MU6H AC650 High Gain Wireless Dual Band USB
Adapter V1.30. It is based on RTL8811CU, usb device ID is 2c4e:0105.
Signed-off-by: Hsiu-Ming Chang <cges30901@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251205003245.5762-1-cges30901@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis: Adding USB Device ID for Mercusys MU6H to rtw8821cu driver
### Commit Message Analysis
The commit adds a USB device ID (vendor: 0x2c4e, product: 0x0105) for
the Mercusys MU6H AC650 High Gain Wireless Dual Band USB Adapter to the
existing rtw8821cu driver. The device is based on the RTL8811CU chipset.
### Code Change Analysis
The change is a **two-line addition** to the USB device ID table in
`drivers/net/wireless/realtek/rtw88/rtw8821cu.c`:
```c
{ USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0105, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Mercusys */
```
This follows the exact same pattern as every other entry in the table
(D-Link, Edimax, and the various Realtek-branded variants). The entry
uses the same `rtw8821c_hw_spec` hardware specification structure,
meaning the driver already fully supports this chipset — it just needs
to know about this particular vendor/product ID combination.
### Classification
This is a **new device ID addition** to an existing driver — one of the
explicitly listed exceptions that IS appropriate for stable backporting.
From the stable rules:
> **NEW DEVICE IDs (Very Common):** Adding PCI IDs, USB IDs, ACPI IDs,
etc. to existing drivers. These are trivial one-line additions that
enable hardware support. Rule: The driver must already exist in stable;
only the ID is new.
### Risk Assessment
- **Risk: Extremely low.** This is a pure data addition — a new entry in
a USB ID matching table. It cannot affect any existing functionality.
- **Scope: Minimal.** Two lines added, one file changed, no logic
changes.
- **Regression potential: Zero.** The new ID only matches a specific USB
device (0x2c4e:0x0105). No other device is affected.
### User Impact
- Users with this specific Mercusys MU6H adapter cannot use it at all
without this ID entry. With the entry, the existing (and already
working) rtw8821cu driver will automatically bind to the device.
- This is a consumer WiFi adapter, so real users on stable kernels would
benefit from this backport.
### Stability Indicators
- Acked-by the Realtek maintainer (Ping-Ke Shih)
- The pattern is identical to existing entries
- The rtw88 driver and rtw8821cu sub-driver already exist in stable
trees
### Dependencies
- None. This is a completely self-contained change.
### Conclusion
This is a textbook example of a device ID addition that should be
backported to stable. It enables hardware support for a specific USB
WiFi adapter using an already-existing, well-tested driver. The change
is trivial, zero-risk, and directly benefits users who own this device.
**YES**
drivers/net/wireless/realtek/rtw88/rtw8821cu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821cu.c b/drivers/net/wireless/realtek/rtw88/rtw8821cu.c
index 7a0fffc359e25..8cd09d66655db 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821cu.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821cu.c
@@ -37,6 +37,8 @@ static const struct usb_device_id rtw_8821cu_id_table[] = {
.driver_info = (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Edimax */
{ USB_DEVICE_AND_INTERFACE_INFO(0x7392, 0xd811, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Edimax */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0105, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* Mercusys */
{},
};
MODULE_DEVICE_TABLE(usb, rtw_8821cu_id_table);
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.18] wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N)
From: Sasha Levin @ 2026-02-14 21:22 UTC (permalink / raw)
To: patches, stable; +Cc: Zenm Chen, Ping-Ke Shih, Sasha Levin, linux-wireless
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: Zenm Chen <zenmchen@gmail.com>
[ Upstream commit 3116f287b81fe777a00b93ab07ec3c270093b185 ]
Add the ID 0db0:f0c8 to the table to support an additional RTL8832BU
adapter: MSI AX1800 Nano (GUAX18N).
Compile tested only.
Link: https://github.com/morrownr/rtl8852bu-20250826/pull/2
Signed-off-by: Zenm Chen <zenmchen@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260112004358.5516-1-zenmchen@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### Commit Overview
This commit adds a single USB device ID (`0x0db0:0xf0c8`) to the
`rtw_8852bu_id_table` in the rtw89 wireless driver to support the MSI
AX1800 Nano (GUAX18N) USB WiFi adapter, which uses the RTL8832BU
chipset.
### Classification: New Device ID Addition
This falls squarely into the **"NEW DEVICE IDs"** exception category for
stable backports:
- It adds a USB device ID to an **existing, already-supported driver**
(rtw89/rtw8852bu)
- The driver infrastructure is already in place; only the ID mapping is
new
- The same `rtw89_8852bu_info` driver_info structure is used, identical
to all other entries in the table
### Code Change Analysis
- **Size**: +2 lines (one `USB_DEVICE_AND_INTERFACE_INFO` entry)
- **Scope**: Single file, single table entry addition
- **Pattern**: Identical to every other entry in the table — `{
USB_DEVICE_AND_INTERFACE_INFO(vendor, product, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&rtw89_8852bu_info }`
- **Risk**: Essentially zero. The new entry only matches when the
specific USB device (`0x0db0:0xf0c8`) is present. It cannot affect any
other hardware or code path.
### User Impact
- Without this ID, users with the MSI AX1800 Nano adapter cannot use it
with the in-kernel rtw89 driver on stable kernels
- WiFi adapter support is a common and important need for end users
- The vendor (MSI, vendor ID `0x0db0`) already has another device
(`0x6931`) in the same table, confirming this is a known hardware
vendor for this chipset
### Risk Assessment
- **Risk**: Negligible — a device ID table addition cannot cause
regressions for existing users
- **Benefit**: Enables hardware support for a real commercial WiFi
adapter
- **Dependencies**: None — requires only that the rtw8852bu driver
exists in the stable tree
### Stability Considerations
- The commit note says "Compile tested only," which is typical for
device ID additions where the submitter may not have all test
infrastructure but the change is trivially correct by inspection
- The patch was accepted by the subsystem maintainer (Ping-Ke Shih from
Realtek)
### Dependency Check
The rtw8852bu USB driver needs to exist in the target stable tree. This
driver was added relatively recently, so this backport is only
applicable to stable branches that already contain the rtw89 USB
support.
### Conclusion
This is a textbook device ID addition — the most common and least risky
type of stable backport. It's a trivial 2-line addition that enables
real hardware for real users with zero regression risk.
**YES**
drivers/net/wireless/realtek/rtw89/rtw8852bu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852bu.c b/drivers/net/wireless/realtek/rtw89/rtw8852bu.c
index 980d17ef68d0a..84cd3ec971f98 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852bu.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852bu.c
@@ -54,6 +54,8 @@ static const struct usb_device_id rtw_8852bu_id_table[] = {
.driver_info = (kernel_ulong_t)&rtw89_8852bu_info },
{ USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0x6931, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&rtw89_8852bu_info },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0xf0c8, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&rtw89_8852bu_info },
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3327, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&rtw89_8852bu_info },
{ USB_DEVICE_AND_INTERFACE_INFO(0x3574, 0x6121, 0xff, 0xff, 0xff),
--
2.51.0
^ 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