* [PATCH 11/12] carl9170: skip cross-band channel changes during software scan
From: Masi Osmani @ 2026-03-15 22:56 UTC (permalink / raw)
To: chunkeey; +Cc: linux-wireless, Masi Osmani
The carl9170 relies on mac80211 software scanning because it does not
implement a hw_scan callback. During a scan, mac80211 iterates all
supported channels across both bands, calling carl9170_op_config()
with IEEE80211_CONF_CHANGE_CHANNEL for each one.
Every channel change triggers a full baseband cold reset, RF bank
re-initialisation and AGC calibration via the firmware RF_INIT command
with a 200 ms timeout. Cross-band switches (2.4 GHz <-> 5 GHz) are
especially expensive and error-prone: the AGC calibration frequently
times out (firmware returns error code 2), leaving the PHY in a
degraded state. Subsequent channel changes -- even within the same
band -- then also fail, and after three consecutive failures the
driver restarts the device, causing a multi-second connectivity gap.
When the adapter is associated on a specific band, scanning channels
on the other band produces no useful roaming candidates for the
current BSS. Add sw_scan_start/sw_scan_complete callbacks to track
the scanning state and skip cross-band channel changes while a
software scan is in progress. Intentional cross-band association
changes (e.g. roaming from 2.4 GHz to 5 GHz on a dual-band SSID)
are not affected because they occur outside the scanning window.
Tested on Fritz\!WLAN N (AR9170) with 2.4 GHz association and
concurrent full-band scans: no channel change failures, no device
restarts, no PHY corruption.
Signed-off-by: Masi Osmani <mas-i@hotmail.de>
---
drivers/net/wireless/ath/carl9170/carl9170.h | 1 +
drivers/net/wireless/ath/carl9170/main.c | 42 +++++++++++++++++++
2 files changed, 43 insertions(+)
--- a/drivers/net/wireless/ath/carl9170/carl9170.h 2026-03-15 23:51:23.598565789 +0100
+++ b/drivers/net/wireless/ath/carl9170/carl9170.h 2026-03-15 23:51:39.769123563 +0100
@@ -333,6 +333,7 @@ struct ar9170 {
/* PHY */
struct ieee80211_channel *channel;
unsigned int num_channels;
+ bool scanning;
int noise[4];
unsigned int chan_fail;
unsigned int total_chan_fail;
--- a/drivers/net/wireless/ath/carl9170/main.c 2026-03-15 23:51:23.597355728 +0100
+++ b/drivers/net/wireless/ath/carl9170/main.c 2026-03-15 23:52:02.845563524 +0100
@@ -916,6 +916,33 @@ static int carl9170_op_config(struct iee
enum nl80211_channel_type channel_type =
cfg80211_get_chandef_type(&hw->conf.chandef);
+ /*
+ * Skip cross-band channel changes during software scan.
+ *
+ * mac80211 sw_scan iterates all channels including the
+ * other band. Each channel change requires a full BB
+ * cold reset and AGC calibration via the firmware RF_INIT
+ * command (200 ms timeout). Cross-band switches
+ * frequently cause AGC calibration timeouts (firmware
+ * returns error 2), leaving the PHY in a degraded state
+ * that cascades into failures on subsequent intra-band
+ * channel changes and ultimately triggers a device
+ * restart after three consecutive failures.
+ *
+ * When associated, scanning the other band yields no
+ * useful roaming candidates for the current BSS. Skip
+ * the channel change so mac80211 advances to the next
+ * scan channel harmlessly.
+ */
+ if (ar->scanning && ar->channel &&
+ hw->conf.chandef.chan->band != ar->channel->band) {
+ wiphy_dbg(ar->hw->wiphy,
+ "skip cross-band scan: %d MHz -> %d MHz\n",
+ ar->channel->center_freq,
+ hw->conf.chandef.chan->center_freq);
+ goto out;
+ }
+
/* adjust slot time for 5 GHz */
err = carl9170_set_slot_time(ar);
if (err)
@@ -954,6 +981,27 @@ out:
return err;
}
+static void carl9170_op_sw_scan_start(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ const u8 *mac_addr)
+{
+ struct ar9170 *ar = hw->priv;
+
+ mutex_lock(&ar->mutex);
+ ar->scanning = true;
+ mutex_unlock(&ar->mutex);
+}
+
+static void carl9170_op_sw_scan_complete(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif)
+{
+ struct ar9170 *ar = hw->priv;
+
+ mutex_lock(&ar->mutex);
+ ar->scanning = false;
+ mutex_unlock(&ar->mutex);
+}
+
static u64 carl9170_op_prepare_multicast(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list)
{
@@ -1723,6 +1771,8 @@ static const struct ieee80211_ops carl91
.add_interface = carl9170_op_add_interface,
.remove_interface = carl9170_op_remove_interface,
.config = carl9170_op_config,
+ .sw_scan_start = carl9170_op_sw_scan_start,
+ .sw_scan_complete = carl9170_op_sw_scan_complete,
.prepare_multicast = carl9170_op_prepare_multicast,
.configure_filter = carl9170_op_configure_filter,
.conf_tx = carl9170_op_conf_tx,
^ permalink raw reply
* [PATCH 12/12] carl9170: rx: handle zeroed PLCP CCK rate as corrupted frame
From: Masi Osmani @ 2026-03-15 22:56 UTC (permalink / raw)
To: chunkeey; +Cc: linux-wireless, Masi Osmani
In-Reply-To: <20260315225609.61791-1-mas-i@hotmail.de>
The firmware occasionally delivers frames tagged as CCK modulation
with a zeroed PLCP rate byte (plcp[0] == 0x00). This typically
happens after PHY state degradation from a failed channel change or
from RF noise on weak signals.
Currently these frames fall through to the default case and produce
a rate-limited wiphy_err log:
ieee80211 phy3: invalid plcp cck rate (0).
The frame is garbage regardless of the log level. Handle plcp[0]
== 0x00 as a dedicated case: increment the rx_dropped counter
(visible via debugfs) and return -EINVAL silently. Downgrade the
remaining default case log from wiphy_err to wiphy_dbg so that
genuinely unexpected PLCP values can still be investigated via
dynamic debug without polluting normal dmesg output.
Signed-off-by: Masi Osmani <mas-i@hotmail.de>
---
drivers/net/wireless/ath/carl9170/rx.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/carl9170/rx.c 2026-03-15 23:51:23.599698582 +0100
+++ b/drivers/net/wireless/ath/carl9170/rx.c 2026-03-15 23:52:21.041912498 +0100
@@ -372,9 +372,18 @@ static int carl9170_rx_mac_status(struct
case AR9170_RX_PHY_RATE_CCK_11M:
status->rate_idx = 3;
break;
+ case 0x00:
+ /*
+ * Zeroed PLCP rate byte: the firmware delivered a
+ * corrupted frame, typically after PHY degradation
+ * from a failed channel change or from RF noise on
+ * weak signals. Drop silently.
+ */
+ ar->rx_dropped++;
+ return -EINVAL;
default:
if (net_ratelimit()) {
- wiphy_err(ar->hw->wiphy, "invalid plcp cck "
+ wiphy_dbg(ar->hw->wiphy, "invalid plcp cck "
"rate (%x).\n", head->plcp[0]);
}
^ permalink raw reply
* Re: [PATCH 2/2] wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling
From: Nick @ 2026-03-15 23:56 UTC (permalink / raw)
To: Satadru Pramanik
Cc: Sean Wang, nbd, lorenzo.bianconi, linux-wireless, linux-mediatek,
Sean Wang, stable
In-Reply-To: <CAFrh3J_4N5j9eZAgbP0gzj5gTGVABat9-4xWZBicKMfgL85LRA@mail.gmail.com>
> >> > From: Sean Wang <sean.wang@mediatek.com>
> >> >
> >> > mt7925u uses different reset/status registers from mt7921u. Reusing the
> >> > mt7921u register set causes the WFSYS reset to fail.
> >> >
> >> > Add a chip-specific descriptor in mt792xu_wfsys_reset() to select the
> >> > correct registers and fix mt7925u failing to initialize after a warm
> >> > reboot.
> >> >
> >> > Fixes: d28e1a48952e ("wifi: mt76: mt792x: introduce mt792x-usb module")
> >> > Cc: stable@vger.kernel.org
> >> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> >> > ---
> >> > drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 4 ++++
> >> > drivers/net/wireless/mediatek/mt76/mt792x_usb.c | 13 ++++++++++++-
> >> > 2 files changed, 16 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
> >> > index 7ddde9286861..d2a8b2b0df32 100644
> >> > --- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
> >> > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
> >> > @@ -392,6 +392,10 @@
> >> > #define MT_CBTOP_RGU_WF_SUBSYS_RST MT_CBTOP_RGU(0x600)
> >> > #define MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH BIT(0)
> >> >
> >> > +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST 0x70028600
> >> > +#define MT7925_WFSYS_INIT_DONE_ADDR 0x184c1604
> >> > +#define MT7925_WFSYS_INIT_DONE 0x00001d1e
> >> > +
> >> > #define MT_HW_BOUND 0x70010020
> >> > #define MT_HW_CHIPID 0x70010200
> >> > #define MT_HW_REV 0x70010204
> >> > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> >> > index a92e872226cf..47827d1c5ccb 100644
> >> > --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> >> > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> >> > @@ -224,6 +224,15 @@ static const struct mt792xu_wfsys_desc mt7921_wfsys_desc = {
> >> > .need_status_sel = true,
> >> > };
> >> >
> >> > +static const struct mt792xu_wfsys_desc mt7925_wfsys_desc = {
> >> > + .rst_reg = MT7925_CBTOP_RGU_WF_SUBSYS_RST,
> >> > + .done_reg = MT7925_WFSYS_INIT_DONE_ADDR,
> >> > + .done_mask = U32_MAX,
> >> > + .done_val = MT7925_WFSYS_INIT_DONE,
> >> > + .delay_ms = 20,
> >> > + .need_status_sel = false,
> >> > +};
> >> > +
> >> > int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
> >> > {
> >> > int err;
> >> > @@ -254,7 +263,9 @@ EXPORT_SYMBOL_GPL(mt792xu_dma_init);
> >> >
> >> > int mt792xu_wfsys_reset(struct mt792x_dev *dev)
> >> > {
> >> > - const struct mt792xu_wfsys_desc *desc = &mt7921_wfsys_desc;
> >> > + const struct mt792xu_wfsys_desc *desc = is_mt7925(&dev->mt76) ?
> >> > + &mt7925_wfsys_desc :
> >> > + &mt7921_wfsys_desc;
> >> > u32 val;
> >> > int i;
> >> >
> >> > --
> >> > 2.43.0
Sean, I have been testing this series of 2 patches for the last two days. I
am no longer seeing problems with warm boot so:
Tested-by: Nick Morrow <morrownr@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath12k: Clean up the WMI Unit Test functionality
From: Baochen Qiang @ 2026-03-16 1:55 UTC (permalink / raw)
To: Jeff Johnson, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260310-ath12k-unit-test-cleanup-v1-0-03e3df56f903@oss.qualcomm.com>
On 3/10/2026 11:16 PM, Jeff Johnson wrote:
> Patch 1 updates the core Unit Test functionality to address multiple
> existing issues, and patch 2 removes unused DFS Unit Test definitions.
>
> ---
> Jeff Johnson (2):
> wifi: ath12k: Clean up the WMI Unit Test command interface
> wifi: ath12k: Remove unused DFS Unit Test definitions
>
> drivers/net/wireless/ath/ath12k/wmi.c | 58 ++++++++++++++++-------------------
> drivers/net/wireless/ath/ath12k/wmi.h | 14 ++++++---
> 2 files changed, 36 insertions(+), 36 deletions(-)
> ---
> base-commit: 9942b3f80f4ebe6852663e0d35ecaf6b7a97c8da
> change-id: 20260305-ath12k-unit-test-cleanup-07622698c994
>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Bjorn Andersson @ 2026-03-16 2:02 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Jeff Johnson, konradybcio, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <3283cbae-4100-484c-9b00-1d7111c62456@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 01:09:08AM +0100, Daniel Lezcano wrote:
> On 3/10/26 00:50, Jeff Johnson wrote:
> > On 3/9/2026 4:03 PM, Daniel Lezcano wrote:
> > > The different subsystems implementing the QMI service protocol are
> > > using their own definition of the service id. It is not a problem but
> > > it results on having those duplicated with different names but the
> > > same value and without consistency in their name.
> > >
> > > It makes more sense to unify their names and move the definitions in
>
> [ ... ]
>
> > prefix for wireless drivers is simply wifi: <driver>:
> > so s/net: drivers: wireless:/wifi:/
>
> Noted, thanks
>
> > > remoteproc: qcom: Use the unified QMI service ID instead of defining
> > > it locally
> > > slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of
> > > defining it locally
> > > soc: qcom: pdr: Use the unified QMI service ID instead of defining it
> > > locally
> > > ALSA: usb-audio: qcom: Use the unified QMI service ID instead of
> > > defining it locally
> > > samples: qmi: Use the unified QMI service ID instead of defining it
> > > locally
> > >
> > > drivers/net/ipa/ipa_qmi.c | 6 ++----
> > > drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
> > > drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 -
> > > drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
> > > drivers/net/wireless/ath/ath11k/qmi.h | 1 -
> > > drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
> > > drivers/net/wireless/ath/ath12k/qmi.h | 1 -
> > > drivers/remoteproc/qcom_sysmon.c | 2 +-
> > > drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
> > > drivers/soc/qcom/pdr_interface.c | 4 ++--
> > > drivers/soc/qcom/pdr_internal.h | 3 ---
> > > drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
> > > include/linux/soc/qcom/qmi.h | 12 ++++++++++++
> > > samples/qmi/qmi_sample_client.c | 2 +-
> > > sound/usb/qcom/qc_audio_offload.c | 2 +-
> > > sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
> >
> > You are touching a lot of subsystems with a single series.
> > How do you plan on having these land?
> > Do you have a maintainer who will take all of these through their tree?
>
> Yes I thought Bjorn or Konrad would take them with the acked-by from the
> different subsystems
As we haven't received any such acks, I pulled patch 1 into an immutable
branch and pushed it here:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260309230346.3584252-2-daniel.lezcano@oss.qualcomm.com
Other maintainers can use this to pull respective changes, or you can
repost the individual patches with this (or follow up once it's in
-rc1).
Regards,
Bjorn
^ permalink raw reply
* Re: (subset) [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Bjorn Andersson @ 2026-03-16 2:02 UTC (permalink / raw)
To: konradybcio, Daniel Lezcano
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
On Tue, 10 Mar 2026 00:03:29 +0100, Daniel Lezcano wrote:
> The different subsystems implementing the QMI service protocol are
> using their own definition of the service id. It is not a problem but
> it results on having those duplicated with different names but the
> same value and without consistency in their name.
>
> It makes more sense to unify their names and move the definitions in
> the QMI header file providing a consistent way to represent the
> supported protocols. Consequently the different drivers will use them
> instead of their own definition of the service id.
>
> [...]
Applied, thanks!
[6/8] soc: qcom: pdr: Use the unified QMI service ID instead of defining it locally
commit: 24f80cbe0b8f4c6b27d03c7a7ad707d76c1c4885
[8/8] samples: qmi: Use the unified QMI service ID instead of defining it locally
commit: 8baf6b3b7695849581a91bdaf66af2be68ef32ed
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v1 4/8] remoteproc: qcom: Use the unified QMI service ID instead of defining it locally
From: Bjorn Andersson @ 2026-03-16 2:09 UTC (permalink / raw)
To: konradybcio, Daniel Lezcano
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-5-daniel.lezcano@oss.qualcomm.com>
On Tue, 10 Mar 2026 00:03:33 +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
>
Applied, thanks!
[4/8] remoteproc: qcom: Use the unified QMI service ID instead of defining it locally
commit: 95b6c029e56e4d75e2957ce7ac795da29415865b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
From: Baochen Qiang @ 2026-03-16 2:27 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260313113831.3053586-1-nico.escande@gmail.com>
On 3/13/2026 7:38 PM, Nicolas Escande wrote:
> On each WMI message received from the hardware, we alloc a temporary array
> of WMI_TAG_MAX entries of type void *. This array is then populated with
> pointers of parsed structs depending on the WMI type, and then freed. This
> alloc can fail when memory pressure in the system is high enough.
>
> Given the fact that it is scheduled in softirq with the system_bh_wq, we
> should not be able to parse more than one WMI message per CPU at any time.
>
> So instead lets move to a per cpu allocated array, that is reused across
> calls: ath12K_wmi_tb that is global to the ath12K module. To alloc & free
> we added two new module_init/exit functions for this module.
>
> ath12k_wmi_tlv_parse_alloc() and ath12k_wmi_tlv_parse() are merged
> together as it no longer allocs mem but returns the existing per-cpu one.
>
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
> Small note on the new ath12k_wmi_tb variable. It is located in core.c and
> I did not exported it in core.h (nor is it exported with EXPORT_SYMBOL())
> as it is only used in wmi.c and should not be used by sub modules like
> ath12k_wifi7.
agree
or alternately you can define ath12k_wmi_tb in wmi.c and add alloc/free functions in
wmi.c, then call them in core.c. this helps modularity IMO?
either way works for me!
>
> changes from v1:
> - rebased on ath-next 27401c9b1432
> - changed wording according to Jeff's comment
> - moved alloc/cleanup to new module_init/exit functions in the
> ath12k module as per Baochen's comment
>
> changes from RFC:
> - rebased on ath-next 8e0ab5b9adb7
> - converted missing call sites ath12k_wmi_obss_color_collision_event()
> & ath12k_wmi_pdev_temperature_event()
> - changed alloc order & cleanup path in ath12k_core_alloc() as it seems
> it confused people
> - used sizeof(*tb) in ath12k_wmi_tlv_parse()
> ---
> drivers/net/wireless/ath/ath12k/core.c | 22 +++
> drivers/net/wireless/ath/ath12k/core.h | 1 +
> drivers/net/wireless/ath/ath12k/wmi.c | 181 ++++++-------------------
> 3 files changed, 68 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index c31c47fb5a73..c9a5baf41845 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -34,6 +34,8 @@ module_param_named(ftm_mode, ath12k_ftm_mode, bool, 0444);
> MODULE_PARM_DESC(ftm_mode, "Boots up in factory test mode");
> EXPORT_SYMBOL(ath12k_ftm_mode);
>
> +void __percpu * ath12k_wmi_tb;
> +
> /* protected with ath12k_hw_group_mutex */
> static struct list_head ath12k_hw_group_list = LIST_HEAD_INIT(ath12k_hw_group_list);
>
> @@ -2321,5 +2323,25 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, size_t priv_size,
> return NULL;
> }
>
> +static int ath12k_init(void)
> +{
> + ath12k_wmi_tb = __alloc_percpu(WMI_TAG_MAX * sizeof(void *),
> + __alignof__(void *));
> + if (!ath12k_wmi_tb) {
> + pr_warn("Failed to alloc ath12k WMI tb\n");
generally we don't log memory allocation failure
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static void ath12k_exit(void)
> +{
> + free_percpu(ath12k_wmi_tb);
> +}
> +
> +module_init(ath12k_init);
> +module_exit(ath12k_exit);
> +
> MODULE_DESCRIPTION("Driver support for Qualcomm Technologies WLAN devices");
> MODULE_LICENSE("Dual BSD/GPL");
[...]
> @@ -9205,7 +9117,7 @@ static void ath12k_wmi_event_teardown_complete(struct ath12k_base *ab,
> const void **tb;
> int ret;
>
> - tb = ath12k_wmi_tlv_parse_alloc(ab, skb, GFP_ATOMIC);
> + tb = ath12k_wmi_tlv_parse(ab, skb);
> if (IS_ERR(tb)) {
> ret = PTR_ERR(tb);
> ath12k_warn(ab, "failed to parse teardown complete event tlv: %d\n", ret);
> @@ -9215,11 +9127,8 @@ static void ath12k_wmi_event_teardown_complete(struct ath12k_base *ab,
> ev = tb[WMI_TAG_MLO_TEARDOWN_COMPLETE];
> if (!ev) {
> ath12k_warn(ab, "failed to fetch teardown complete event\n");
> - kfree(tb);
> return;
nit: better to remove return as well
> }
> -
> - kfree(tb);
> }
>
> #ifdef CONFIG_ATH12K_DEBUGFS
^ permalink raw reply
* RE: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: Ping-Ke Shih @ 2026-03-16 2:50 UTC (permalink / raw)
To: LB F; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqSq416qqqZ7t+wG5fir9NWfi3578+brdaj05q-42Gj14w@mail.gmail.com>
LB F <goainwo@gmail.com> wrote:
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> > I'd adopt your suggestion (dynamic LPS_DEEP_MODE_NONE) if the test
> > is positive.
>
> Hi Ping-Ke,
>
> Following your suggestion, I performed an additional experiment to
> validate the dynamic LPS_DEEP_MODE_NONE idea. Please treat this
> purely as a field test report -- I am not a kernel developer, and the
> implementation below is certainly not upstream-quality. I am sharing
> it only in the hope that it helps you design a proper solution.
>
> What I did:
>
> I extended your DMI quirk in pci.c with an additional capability flag
> for LPS Deep mode. The only file touched was pci.c (your patch) --
> main.c was left completely unmodified.
>
> The changes to your patch are as follows:
>
> /* 1. Extended the capabilities enum */
> enum rtw88_quirk_dis_pci_caps {
> QUIRK_DIS_PCI_CAP_ASPM,
> QUIRK_DIS_PCI_CAP_LPS_DEEP, /* test addition */
> };
>
> /* 2. Extended disable_pci_caps() callback */
> static int disable_pci_caps(const struct dmi_system_id *dmi)
> {
> uintptr_t dis_caps = (uintptr_t)dmi->driver_data;
>
> if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_ASPM))
> rtw_pci_disable_aspm = true;
>
> if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_LPS_DEEP))
> rtw_disable_lps_deep_mode = true;
>
> return 1;
> }
>
> /* 3. Both flags set for the HP P3S95EA#ACB entry */
> .driver_data = (void *)(BIT(QUIRK_DIS_PCI_CAP_ASPM) |
> BIT(QUIRK_DIS_PCI_CAP_LPS_DEEP)),
>
> I am aware that setting rtw_disable_lps_deep_mode from pci.c is
> architecturally impure -- it is a global flag that would affect all
> rtw88 devices in a hypothetical multi-adapter system. A proper
> per-device solution (e.g. a flag inside struct rtw_dev set during
> probe) would be cleaner. I simply used the existing global as the
> most straightforward way to validate the concept.
>
> Verification:
>
> Confirmed no rtw88-related entries exist in /etc/modprobe.d/,
> /lib/modprobe.d/, or /run/modprobe.d/, ruling out any external
> parameter injection.
>
> After loading the patched modules, the following was confirmed via
> sysfs:
>
> /sys/module/rtw88_core/parameters/disable_lps_deep_mode = Y
> /sys/module/rtw88_pci/parameters/disable_aspm = Y
>
> This confirms the DMI quirk is the sole source of both values.
>
> Results (10-minute idle observation, battery power, wifi.powersave=3):
>
> With your ASPM patch alone (LPS Deep still active):
> - periodic "failed to send h2c command" bursts observed
> - occasional WiFi throughput drops and Bluetooth audio stuttering
>
> With ASPM patch + LPS Deep disabled via the quirk:
> - h2c=0, lps=0 across the entire observation window
> - WiFi throughput stable, Bluetooth audio uninterrupted
>
> The result confirms that disabling LPS Deep Mode in addition to ASPM
> completely eliminates the remaining firmware timeout loop on this
> platform.
>
> I hope this experiment is useful as a data point. Please feel free to
> discard the implementation and design a proper solution -- I am ready
> to test any updated patch you send.
Thanks for your analysis of TX/RX paths, and the changes above and
verifications. :)
I'd update the patch as your proposal and send a patch. For suggestions of
TX/RX paths, I only read them a little bit, and I will study them entirely
when I have more free time.
Ping-Ke
^ permalink raw reply
* RE: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: Ping-Ke Shih @ 2026-03-16 2:55 UTC (permalink / raw)
To: LB F; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqSf66mBiufysr3tjm74A_w98LRN50fik0U9WGVvkBJ_5g@mail.gmail.com>
LB F <goainwo@gmail.com> wrote:
>
> Oleksandr Havrylov <goainwo@gmail.com> wrote:
> > After extended testing with your DMI patch applied, the hard freeze is
> > gone. However, with ASPM disabled but LPS Deep still active, I observe
> > periodic h2c timeouts during idle which cause occasional WiFi throughput
> > drops and Bluetooth audio stuttering. When I additionally set
> > disable_lps_deep=Y, all symptoms disappear completely. This confirms
> > that combining the ASPM quirk with dynamic LPS_DEEP_MODE_NONE would be
> > the complete fix. Ready to test an updated patch if you decide to
> > include this.
>
> Hi Ping-Ke,
>
> While monitoring logs with the current patch applied, I noticed two
> things that might be useful.
>
> First, the following message appears each time the driver loads:
>
> rtw88_8821ce 0000:13:00.0: can't disable ASPM; OS doesn't have ASPM control
>
> This suggests the BIOS retains control over ASPM and prevents any
> OS-level override via pci_disable_link_state(). The system remains
> stable regardless, which confirms that the rtw_pci_disable_aspm flag
> approach in your patch is the correct and effective method here.
Not sure if this is because PCIE bridge has no ASPM capability?
>
> Second, during normal operation I observe this warning periodically:
>
> WARNING: net/mac80211/rx.c:5491 at ieee80211_rx_list+0x177/0x1020 [mac80211]
LN5491 (kernel v6.19.6) is:
case RX_ENC_VHT:
if (WARN_ONCE(status->rate_idx > 11 ||
!status->nss ||
status->nss > 8,
"Rate marked as a VHT rate but data is invalid: MCS: %d, NSS: %d\n",
status->rate_idx, status->nss))
goto drop;
break;
Looks like driver reports improper VHT nss/rate? But this warns once, and
you message isn't like this.
Could you check the source code LN5491 you are using?
Ping-Ke
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath12k: Clean up the WMI Unit Test functionality
From: Rameshkumar Sundaram @ 2026-03-16 3:48 UTC (permalink / raw)
To: Jeff Johnson, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260310-ath12k-unit-test-cleanup-v1-0-03e3df56f903@oss.qualcomm.com>
On 3/10/2026 8:46 PM, Jeff Johnson wrote:
> Patch 1 updates the core Unit Test functionality to address multiple
> existing issues, and patch 2 removes unused DFS Unit Test definitions.
>
> ---
> Jeff Johnson (2):
> wifi: ath12k: Clean up the WMI Unit Test command interface
> wifi: ath12k: Remove unused DFS Unit Test definitions
>
> drivers/net/wireless/ath/ath12k/wmi.c | 58 ++++++++++++++++-------------------
> drivers/net/wireless/ath/ath12k/wmi.h | 14 ++++++---
> 2 files changed, 36 insertions(+), 36 deletions(-)
> ---
> base-commit: 9942b3f80f4ebe6852663e0d35ecaf6b7a97c8da
> change-id: 20260305-ath12k-unit-test-cleanup-07622698c994
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
>
^ permalink raw reply
* [PATCH rtw-next] wifi: rtw88: add quirks to disable PCI ASPM and deep LPS for HP P3S95EA#ACB
From: Ping-Ke Shih @ 2026-03-16 3:56 UTC (permalink / raw)
To: linux-wireless; +Cc: goainwo
On an HP laptop (P3S95EA#ACB) equipped with a Realtek RTL8821CE 802.11ac
PCIe adapter (PCI ID: 10ec:c821), the system experiences a hard lockup
(complete freeze of the UI and kernel, sysrq doesn't work, requires
holding the power button) when the WiFi adapter enters the power
saving state. Disable PCI ASPM to avoid system freeze.
In addition, driver throws messages periodically. Though this doesn't
always cause unstable connection, missing H2C commands might cause
unpredictable results. Disable deep LPS to avoid this as well.
rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
rtw88_8821ce 0000:13:00.0: failed to send h2c command
rtw88_8821ce 0000:13:00.0: failed to send h2c command
Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/CALdGYqSQ1Ko2TTBhUizMu_FvLMUAuQfFrVwS10n_C-LSQJQQkQ@mail.gmail.com/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw88/main.h | 5 ++++
drivers/net/wireless/realtek/rtw88/pci.c | 31 +++++++++++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index 1179231a672d..9c0b746540b0 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -432,6 +432,11 @@ enum rtw_wow_flags {
RTW_WOW_FLAG_MAX,
};
+enum rtw_quirk_dis_caps {
+ QUIRK_DIS_CAP_PCI_ASPM,
+ QUIRK_DIS_CAP_LPS_DEEP,
+};
+
/* the power index is represented by differences, which cck-1s & ht40-1s are
* the base values, so for 1s's differences, there are only ht20 & ofdm
*/
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index ec0a45bfb670..bba370ad510c 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -2,6 +2,7 @@
/* Copyright(c) 2018-2019 Realtek Corporation
*/
+#include <linux/dmi.h>
#include <linux/module.h>
#include <linux/pci.h>
#include "main.h"
@@ -1744,6 +1745,34 @@ const struct pci_error_handlers rtw_pci_err_handler = {
};
EXPORT_SYMBOL(rtw_pci_err_handler);
+static int rtw_pci_disable_caps(const struct dmi_system_id *dmi)
+{
+ uintptr_t dis_caps = (uintptr_t)dmi->driver_data;
+
+ if (dis_caps & BIT(QUIRK_DIS_CAP_PCI_ASPM))
+ rtw_pci_disable_aspm = true;
+
+ if (dis_caps & BIT(QUIRK_DIS_CAP_LPS_DEEP))
+ rtw_disable_lps_deep_mode = true;
+
+ return 1;
+}
+
+static const struct dmi_system_id rtw_pci_quirks[] = {
+ {
+ .callback = rtw_pci_disable_caps,
+ .ident = "HP Notebook - P3S95EA#ACB",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Notebook"),
+ DMI_MATCH(DMI_PRODUCT_SKU, "P3S95EA#ACB"),
+ },
+ .driver_data = (void *)(BIT(QUIRK_DIS_CAP_PCI_ASPM) |
+ BIT(QUIRK_DIS_CAP_LPS_DEEP)),
+ },
+ {}
+};
+
int rtw_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -1771,6 +1800,8 @@ int rtw_pci_probe(struct pci_dev *pdev,
rtwpci = (struct rtw_pci *)rtwdev->priv;
atomic_set(&rtwpci->link_usage, 1);
+ dmi_check_system(rtw_pci_quirks);
+
ret = rtw_core_init(rtwdev);
if (ret)
goto err_release_hw;
base-commit: 039cd522dc70151da13329a5e3ae19b1736f468a
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] iw: scan: rename OWE Transition parsing function
From: Alex Gavin @ 2026-03-16 5:16 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Alex Gavin
Signed-off-by: Alex Gavin <a_gavin@icloud.com>
---
scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scan.c b/scan.c
index facb503..4d3284e 100644
--- a/scan.c
+++ b/scan.c
@@ -2311,7 +2311,7 @@ static inline void print_hs20_ind(const uint8_t type, uint8_t len,
printf("\t\tUnexpected length: %i\n", len);
}
-static void print_wifi_owe_tarns(const uint8_t type, uint8_t len,
+static void print_wifi_owe_trans(const uint8_t type, uint8_t len,
const uint8_t *data,
const struct ie_context *ctx)
{
@@ -2343,7 +2343,7 @@ static const struct ie_print wfa_printers[] = {
[9] = { "P2P", print_p2p, 2, 255, BIT(PRINT_SCAN), },
[16] = { "HotSpot 2.0 Indication", print_hs20_ind, 1, 255, BIT(PRINT_SCAN), },
[18] = { "HotSpot 2.0 OSEN", print_wifi_osen, 1, 255, BIT(PRINT_SCAN), },
- [28] = { "OWE Transition Mode", print_wifi_owe_tarns, 7, 255, BIT(PRINT_SCAN), },
+ [28] = { "OWE Transition Mode", print_wifi_owe_trans, 7, 255, BIT(PRINT_SCAN), },
};
static void print_vendor(unsigned char len, unsigned char *data,
--
2.51.2
^ permalink raw reply related
* [PATCH 2/2] iw: scan: print RSN Element Override IEs
From: Alex Gavin @ 2026-03-16 5:16 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Alex Gavin
In-Reply-To: <20260316051646.18303-1-a_gavin@icloud.com>
Parse body of RSN Element Override IEs as RSN IEs
using existing code.
RSN IEs are a minimum size of 4 octets, as detailed
in IEEE802.11-2024, 9.4.2.23.1
Example output:
RSN Element Override:
* Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: SAE
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC MFP-required MFP-capable (0x00cc)
RSN Element Override 2:
* Version: 1
* Group cipher: CCMP
* Pairwise ciphers: GCMP-256
* Authentication suites: SAE-EXT-KEY
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC MFP-required MFP-capable (0x00cc)
Signed-off-by: Alex Gavin <a_gavin@icloud.com>
---
scan.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/scan.c b/scan.c
index 4d3284e..2b6e904 100644
--- a/scan.c
+++ b/scan.c
@@ -1893,6 +1893,14 @@ static void print_wifi_osen(const uint8_t type, uint8_t len,
print_osen_ie("OSEN", "OSEN", len, data);
}
+static void print_wifi_rsn_override(const uint8_t type, uint8_t len,
+ const uint8_t *data,
+ const struct ie_context *ctx)
+{
+ printf("\n\t");
+ print_rsn_ie("CCMP", "IEEE802.1X", len, data);
+}
+
static bool print_wifi_wmm_param(const uint8_t *data, uint8_t len)
{
int i;
@@ -2344,6 +2352,8 @@ static const struct ie_print wfa_printers[] = {
[16] = { "HotSpot 2.0 Indication", print_hs20_ind, 1, 255, BIT(PRINT_SCAN), },
[18] = { "HotSpot 2.0 OSEN", print_wifi_osen, 1, 255, BIT(PRINT_SCAN), },
[28] = { "OWE Transition Mode", print_wifi_owe_trans, 7, 255, BIT(PRINT_SCAN), },
+ [41] = { "RSN Element Override", print_wifi_rsn_override, 4, 255, BIT(PRINT_SCAN), },
+ [42] = { "RSN Element Override 2", print_wifi_rsn_override, 4, 255, BIT(PRINT_SCAN), },
};
static void print_vendor(unsigned char len, unsigned char *data,
--
2.51.2
^ permalink raw reply related
* RE: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure
From: Ping-Ke Shih @ 2026-03-16 5:32 UTC (permalink / raw)
To: Christian Hewitt, Bitterblue Smith,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260301042422.195491-1-christianshewitt@gmail.com>
Christian Hewitt <christianshewitt@gmail.com> wrote:
> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
> physical map dump intermittently fails with -EBUSY during probe.
> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
> bit after 1 second.
>
> The root cause is a timing race during boot: the WiFi driver's
> chip initialization (firmware download via PCIe) overlaps with the
> Bluetooth firmware download to the same combo chip over USB. This
> can leave the efuse controller temporarily unavailable when the
> WiFi driver attempts to read the efuse map.
>
> Add a retry loop (up to 3 attempts with 500ms delays) around the
> physical efuse map dump in rtw89_parse_efuse_map_ax(). The firmware
> download path already retries up to 5 times, but the efuse read
> that follows has no retry logic, making it the weak link in the
> probe sequence.
I'd prefer adding a wrapper to retry 5 times without delay as bottom
changes for reference. If you want to limit retry only for
'dav == false' case, it is also fine to me.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
[...]
>
> drivers/net/wireless/realtek/rtw89/efuse.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/efuse.c
> b/drivers/net/wireless/realtek/rtw89/efuse.c
> index a2757a88d55d..d506f04ffd6c 100644
> --- a/drivers/net/wireless/realtek/rtw89/efuse.c
> +++ b/drivers/net/wireless/realtek/rtw89/efuse.c
> @@ -270,6 +270,7 @@ int rtw89_parse_efuse_map_ax(struct rtw89_dev *rtwdev)
> u8 *log_map = NULL;
> u8 *dav_phy_map = NULL;
> u8 *dav_log_map = NULL;
> + int retry;
> int ret;
>
> if (rtw89_read16(rtwdev, R_AX_SYS_WL_EFUSE_CTRL) & B_AX_AUTOLOAD_SUS)
> @@ -289,7 +290,17 @@ int rtw89_parse_efuse_map_ax(struct rtw89_dev *rtwdev)
> goto out_free;
> }
>
> - ret = rtw89_dump_physical_efuse_map(rtwdev, phy_map, 0, phy_size,
> false);
> + for (retry = 0; retry < 3; retry++) {
> + if (retry) {
> + rtw89_warn(rtwdev, "efuse dump failed, retrying
> (%d)\n",
> + retry);
> + fsleep(500000);
> + }
> + ret = rtw89_dump_physical_efuse_map(rtwdev, phy_map, 0,
> + phy_size, false);
> + if (!ret)
> + break;
> + }
> if (ret) {
> rtw89_warn(rtwdev, "failed to dump efuse physical map\n");
> goto out_free;
> --
> 2.43.0
How about retrying 5 times without fsleep(500000)?
diff --git a/drivers/net/wireless/realtek/rtw89/efuse.c b/drivers/net/wireless/realtek/rtw89/efuse.c
index a2757a88d55d..89d4b1b865f8 100644
--- a/drivers/net/wireless/realtek/rtw89/efuse.c
+++ b/drivers/net/wireless/realtek/rtw89/efuse.c
@@ -185,8 +185,8 @@ static int rtw89_dump_physical_efuse_map_dav(struct rtw89_dev *rtwdev, u8 *map,
return 0;
}
-static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 *map,
- u32 dump_addr, u32 dump_size, bool dav)
+static int __rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 *map,
+ u32 dump_addr, u32 dump_size, bool dav)
{
int ret;
@@ -208,6 +208,25 @@ static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 *map,
return 0;
}
+static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 *map,
+ u32 dump_addr, u32 dump_size, bool dav)
+{
+ int retry;
+ int ret;
+
+ for (retry = 0; retry < 5; retry++) {
+ ret = __rtw89_dump_physical_efuse_map(rtwdev, map, dump_addr,
+ dump_size, dav);
+ if (!ret)
+ return 0;
+
+ rtw89_warn(rtwdev, "efuse dump (dav=%d) failed, retrying (%d)\n",
+ dav, retry);
+ }
+
+ return ret;
+}
+
#define invalid_efuse_header(hdr1, hdr2) \
((hdr1) == 0xff || (hdr2) == 0xff)
#define invalid_efuse_content(word_en, i) \
^ permalink raw reply related
* Re: [PATCH] wifi: rtl8xxxu: Mark RTL8188ETV (0bda:0179) as tested
From: Ping-Ke Shih @ 2026-03-16 5:47 UTC (permalink / raw)
To: J. Neuschäfer, Jes Sorensen
Cc: linux-wireless, linux-kernel, J. Neuschäfer
In-Reply-To: <20260303-rtl8xxx-tested-v1-1-291a38a6ff2f@posteo.net>
=?utf-8?q?J=2E_Neusch=C3=A4fer?= <j.ne@posteo.net> wrote:
> From: "J. Neuschäfer" <j.ne@posteo.net>
>
> This WiFi chip appears in the "TCU Fernsehfee 3.0" set-top box.
> I have tested that it works in WPA2-PSK-CCMP client mode.
>
> Cc: Jes.Sorensen@gmail.com
> Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
2a585b2efb48 wifi: rtl8xxxu: Mark RTL8188ETV (0bda:0179) as tested
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v2] wifi: rtl8xxxu: fix potential use of uninitialized value
From: Ping-Ke Shih @ 2026-03-16 5:55 UTC (permalink / raw)
To: Yi Cong, pkshih, Jes.Sorensen; +Cc: linux-wireless, Yi Cong, stable
In-Reply-To: <20260306071627.56501-1-cong.yi@linux.dev>
Yi Cong <cong.yi@linux.dev> wrote:
> From: Yi Cong <yicong@kylinos.cn>
>
> The local variables 'mcs' and 'nss' in rtl8xxxu_update_ra_report() are
> passed to rtl8xxxu_desc_to_mcsrate() as output parameters. If the helper
> function encounters an unhandled rate index, it may return without setting
> these values, leading to the use of uninitialized stack data.
>
> Remove the helper rtl8xxxu_desc_to_mcsrate() and inline the logic into
> rtl8xxxu_update_ra_report(). This fixes the use of uninitialized 'mcs'
> and 'nss' variables for legacy rates.
>
> The new implementation explicitly handles:
> - Legacy rates: Set bitrate only.
> - HT rates (MCS0-15): Set MCS flags, index, and NSS (1 or 2) directly.
> - Invalid rates: Return early.
>
> Fixes: 7de16123d9e2 ("wifi: rtl8xxxu: Introduce rtl8xxxu_update_ra_report")
> Cc: stable@vger.kernel.org
> Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Yi Cong <yicong@kylinos.cn>
> Link: https://lore.kernel.org/all/96e31963da0c42dcb52ce44f818963d7@realtek.com/
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
f8a2fc809bfe wifi: rtl8xxxu: fix potential use of uninitialized value
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: drop redundant device reference
From: Ping-Ke Shih @ 2026-03-16 6:04 UTC (permalink / raw)
To: Johan Hovold, linux-wireless; +Cc: Ping-Ke Shih, linux-kernel, Johan Hovold
In-Reply-To: <20260306093206.21081-1-johan@kernel.org>
Johan Hovold <johan@kernel.org> wrote:
> Driver core holds a reference to the USB interface and its parent USB
> device while the interface is bound to a driver and there is no need to
> take additional references unless the structures are needed after
> disconnect.
>
> Drop the redundant device reference to reduce cargo culting, make it
> easier to spot drivers where an extra reference is needed, and reduce
> the risk of memory leaks when drivers fail to release it.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
c2a21f35cea4 wifi: rtw89: drop redundant device reference
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v2 16/18] wifi: rtl818x: drop redundant device reference
From: Ping-Ke Shih @ 2026-03-16 6:02 UTC (permalink / raw)
To: Johan Hovold, linux-wireless
Cc: Jeff Johnson, Toke Høiland-Jørgensen, Brian Norris,
Francesco Dolcini, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Jakub Kicinski, Stanislaw Gruszka,
Hin-Tak Leung, Jes Sorensen, Ping-Ke Shih, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Matthias Brugger,
AngeloGioacchino Del Regno, Greg Kroah-Hartman, libertas-dev,
linux-kernel, Johan Hovold
In-Reply-To: <20260306085144.12064-17-johan@kernel.org>
Johan Hovold <johan@kernel.org> wrote:
> Driver core holds a reference to the USB interface and its parent USB
> device while the interface is bound to a driver and there is no need to
> take additional references unless the structures are needed after
> disconnect.
>
> Drop the redundant device reference to reduce cargo culting, make it
> easier to spot drivers where an extra reference is needed, and reduce
> the risk of memory leaks when drivers fail to release it.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
3 patch(es) applied to rtw-next branch of rtw.git, thanks.
68e7d359a5ee wifi: rtl818x: drop redundant device reference
711b8add3929 wifi: rtl8xxxu: drop redundant device reference
bbb15e71156c wifi: rtw88: fix device leak on probe failure
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH RESEND] wifi: rtlwifi: usb: drop redundant device reference
From: Ping-Ke Shih @ 2026-03-16 6:07 UTC (permalink / raw)
To: Johan Hovold, linux-wireless; +Cc: Ping-Ke Shih, linux-kernel, Johan Hovold
In-Reply-To: <20260309083336.16397-1-johan@kernel.org>
Johan Hovold <johan@kernel.org> wrote:
> Driver core holds a reference to the USB interface and its parent USB
> device while the interface is bound to a driver and there is no need to
> take additional references unless the structures are needed after
> disconnect.
>
> Drop the redundant device reference to reduce cargo culting, make it
> easier to spot drivers where an extra reference is needed, and reduce
> the risk of memory leaks when drivers fail to release it.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
fc25b384fc0b wifi: rtlwifi: usb: drop redundant device reference
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH] wifi: rtlwifi: rtl8192d: fix typo in H2C wait counter names
From: Ping-Ke Shih @ 2026-03-16 6:10 UTC (permalink / raw)
To: Jaime Saguillo Revilla, pkshih
Cc: linux-wireless, linux-kernel, Jaime Saguillo Revilla
In-Reply-To: <20260308111850.20420-1-jaime.saguillo@gmail.com>
Jaime Saguillo Revilla <jaime.saguillo@gmail.com> wrote:
> Rename local variables in rtl92d_fill_h2c_cmd()
> from wait_writeh2c_limmit/wait_h2c_limmit
> to wait_writeh2c_limit/wait_h2c_limit.
>
> No functional change.
>
> Signed-off-by: Jaime Saguillo Revilla <jaime.saguillo@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
e1b6b5af5d17 wifi: rtlwifi: rtl8192d: fix typo in H2C wait counter names
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* RE: [RFC PATCH v3 1/4] wifi: rtl8xxxu: move dynamic_tx_rpt_timing_counter from ra_info to priv
From: Ping-Ke Shih @ 2026-03-16 6:17 UTC (permalink / raw)
To: Georg Müller, Jes.Sorensen@gmail.com,
rtl8821cerfe2@gmail.com
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260313135321.3196688-2-georgmueller@gmx.net>
Georg Müller <georgmueller@gmx.net> wrote:
> dynamic_tx_rpt_timing_counter is not per mac_id, but used across all
> mac_ids.
I don't know the purpose of dynamic_tx_rpt_timing_counter. Could you
share your study?
Ping-Ke
^ permalink raw reply
* RE: [RFC PATCH v3 2/4] wifi: rtl8xxxu: handle rate control for 8188e a per mac_id
From: Ping-Ke Shih @ 2026-03-16 6:35 UTC (permalink / raw)
To: Georg Müller, Jes.Sorensen@gmail.com,
rtl8821cerfe2@gmail.com
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260313135321.3196688-3-georgmueller@gmx.net>
Georg Müller <georgmueller@gmx.net> wrote:
> convert member ra_info to an array with one entry per mac id. This
> allows having different rate control settings per connected station
> in ap mode.
>
> The max_macid_num is conservative. The old driver used 32 [1], some
> other sources said 64 [2]. I have not enough adapters to test any of the
> higher values. Given the usage of this chipset in nano dongles, I think
> the 16 might be high enough.
>
> [1]
> https://github.com/lwfinger/rtl8188eu/blob/f5d1c8df2e2d8b217ea0113bf2cf3e37d
> f8cb716/include/sta_info.h#L28
> [2]
> https://lore.kernel.org/linux-wireless/27e83382-4c84-1841-c428-d1e5143ea20c@
> gmail.com/
>
> Signed-off-by: Georg Müller <georgmueller@gmx.net>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/8188e.c | 12 ++++++------
> drivers/net/wireless/realtek/rtl8xxxu/core.c | 19 ++++++++++++++-----
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 3 ++-
> 3 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
> b/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
> index de2837a91bbe..607ca62194fc 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
> @@ -1468,9 +1468,8 @@ static void rtl8188e_reset_ra_counter(struct
> rtl8xxxu_ra_info *ra)
> ra->nsc_down = (n_threshold_high[rate_id] + n_threshold_low[rate_id])
> >> 1;
> }
>
> -static void rtl8188e_rate_decision(struct rtl8xxxu_ra_info *ra)
> +static void rtl8188e_rate_decision(struct rtl8xxxu_priv *priv, struct
> rtl8xxxu_ra_info *ra)
> {
> - struct rtl8xxxu_priv *priv = container_of(ra, struct rtl8xxxu_priv,
> ra_info);
> const u8 *retry_penalty_idx_0;
> const u8 *retry_penalty_idx_1;
> const u8 *retry_penalty_up_idx;
> @@ -1669,7 +1668,7 @@ void rtl8188e_handle_ra_tx_report2(struct rtl8xxxu_priv
> *priv, struct sk_buff *s
> u32 *_rx_desc = (u32 *)(skb->data - sizeof(struct rtl8xxxu_rxdesc16));
> struct rtl8xxxu_rxdesc16 *rx_desc = (struct rtl8xxxu_rxdesc16
> *)_rx_desc;
> struct device *dev = &priv->udev->dev;
> - struct rtl8xxxu_ra_info *ra = &priv->ra_info;
> + struct rtl8xxxu_ra_info *ra;
> u32 tx_rpt_len = rx_desc->pktlen & 0x3ff;
> u32 items = tx_rpt_len / TX_RPT2_ITEM_SIZE;
The 'items' should be smaller or equal to RTL8188E_MAX_MAC_ID_NUM.
> u64 macid_valid = ((u64)_rx_desc[5] << 32) | _rx_desc[4];
> @@ -1688,6 +1687,7 @@ void rtl8188e_handle_ra_tx_report2(struct rtl8xxxu_priv
> *priv, struct sk_buff *s
>
> for (macid = 0; macid < items; macid++) {
> valid = false;
> + ra = &priv->ra_info[macid];
>
> if (macid < 64)
> valid = macid_valid & BIT(macid);
> @@ -1704,7 +1704,7 @@ void rtl8188e_handle_ra_tx_report2(struct rtl8xxxu_priv
> *priv, struct sk_buff *s
>
> if (ra->total > 0) {
> if (ra->ra_stage < 5)
> - rtl8188e_rate_decision(ra);
> + rtl8188e_rate_decision(priv, ra);
> else if (ra->ra_stage == 5)
>
> rtl8188e_power_training_try_state(ra);
> else /* ra->ra_stage == 6 */
> @@ -1781,7 +1781,7 @@ rtl8188e_update_rate_mask(struct rtl8xxxu_priv *priv,
> u32 ramask, u8 rateid, int sgi, int txbw_40mhz,
> u8 macid)
> {
> - struct rtl8xxxu_ra_info *ra = &priv->ra_info;
> + struct rtl8xxxu_ra_info *ra = &priv->ra_info[macid];
>
> ra->rate_id = rateid;
> ra->rate_mask = ramask;
> @@ -1792,7 +1792,7 @@ rtl8188e_update_rate_mask(struct rtl8xxxu_priv *priv,
>
> static void rtl8188e_ra_set_rssi(struct rtl8xxxu_priv *priv, u8 macid, u8 rssi)
> {
> - priv->ra_info.rssi_sta_ra = rssi;
> + priv->ra_info[macid].rssi_sta_ra = rssi;
> }
>
> void rtl8188e_ra_info_init_all(struct rtl8xxxu_ra_info *ra)
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> index 794187d28caa..5ad23c5c9305 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> @@ -3921,6 +3921,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> struct device *dev = &priv->udev->dev;
> struct rtl8xxxu_fileops *fops = priv->fops;
> bool macpower;
> + u16 mac_id;
> int ret;
> u8 val8;
> u16 val16;
> @@ -4393,9 +4394,16 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> priv->cfo_tracking.crystal_cap = priv->default_crystal_cap;
> }
>
> - if (priv->rtl_chip == RTL8188E)
> - rtl8188e_ra_info_init_all(&priv->ra_info);
> -
> + if (priv->rtl_chip == RTL8188E) {
> + priv->ra_info = kmalloc_array(RTL8188E_MAX_MAC_ID_NUM,
> sizeof(*priv->ra_info), GFP_KERNEL);
How about devm_ series? Then, no need to free on error path or disconnection.
> + if (!priv->ra_info) {
> + ret = -ENOMEM;
> + goto exit;
> + }
> + for (mac_id = 0; mac_id < RTL8188E_MAX_MAC_ID_NUM; mac_id++) {
> + rtl8188e_ra_info_init_all(&priv->ra_info[mac_id]);
> + }
no need brace for single line statement.
> + }
> set_bit(RTL8XXXU_BC_MC_MACID, priv->mac_id_map);
> set_bit(RTL8XXXU_BC_MC_MACID1, priv->mac_id_map);
>
> @@ -5338,7 +5346,7 @@ rtl8xxxu_fill_txdesc_v3(struct ieee80211_hw *hw, struct
> ieee80211_hdr *hdr,
> {
> struct rtl8xxxu_priv *priv = hw->priv;
> struct device *dev = &priv->udev->dev;
> - struct rtl8xxxu_ra_info *ra = &priv->ra_info;
> + struct rtl8xxxu_ra_info *ra = &priv->ra_info[macid];
> u8 *qc = ieee80211_get_qos_ctl(hdr);
> u8 tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
> u32 rate = 0;
> @@ -7895,6 +7903,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> err_set_intfdata:
> usb_set_intfdata(interface, NULL);
>
> + kfree(priv->ra_info);
> kfree(priv->fw_data);
> mutex_destroy(&priv->usb_buf_mutex);
> mutex_destroy(&priv->syson_indirect_access_mutex);
> @@ -7924,7 +7933,7 @@ static void rtl8xxxu_disconnect(struct usb_interface
> *interface)
> usb_set_intfdata(interface, NULL);
>
> dev_info(&priv->udev->dev, "disconnecting\n");
> -
> + kfree(priv->ra_info);
> kfree(priv->fw_data);
> mutex_destroy(&priv->usb_buf_mutex);
> mutex_destroy(&priv->syson_indirect_access_mutex);
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index 4a744b5c1aec..9ce820ff4793 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -76,6 +76,7 @@
> #define RTL_FW_PAGE_SIZE 4096
> #define RTL8XXXU_FIRMWARE_POLL_MAX 1000
>
> +#define RTL8188E_MAX_MAC_ID_NUM 16
> #define RTL8723A_CHANNEL_GROUPS 3
> #define RTL8723A_MAX_RF_PATHS 2
> #define RTL8723B_CHANNEL_GROUPS 6
> @@ -1915,7 +1916,7 @@ struct rtl8xxxu_priv {
> struct rtl8xxxu_btcoex bt_coex;
> struct rtl8xxxu_ra_report ra_report;
> struct rtl8xxxu_cfo_tracking cfo_tracking;
> - struct rtl8xxxu_ra_info ra_info;
> + struct rtl8xxxu_ra_info *ra_info;
It looks like this is also 8188e specific. Could you add comment by the way?
(but please /**/ style)
> u8 dynamic_tx_rpt_timing_counter; // 8188e specific
>
> bool led_registered;
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH rtw-next 02/13] wifi: rtw89: pci: update SER parameters for suspend/resume
From: Ping-Ke Shih @ 2026-03-16 6:53 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-3-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> In suspend mode, SER timer unit is different from normal mode. Set proper
> value to prevent expected SER happened during suspend.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
12 patch(es) applied to rtw-next branch of rtw.git, thanks.
177520960c01 wifi: rtw89: pci: update SER parameters for suspend/resume
9a38ef92aaa2 wifi: rtw89: mac: remove A-die off setting for RTL8852C and RTL8922A
84f5e0eaf84e wifi: rtw89: phy: limit AMPDU number for RA try rate
be28b2c4eed4 wifi: rtw89: move disabling dynamic mechanism functions to core
4516621686cb wifi: rtw89: tweak settings of TX power and channel for Wi-Fi 7
2fed8de4eb98 wifi: rtw89: chan: simplify link handling related to ROC
cf3cd3687d8a wifi: rtw89: chan: recalc MLO DBCC mode based on current entity mode
72dbc78594a1 wifi: rtw89: wow: add retry for ensuring packet are processed
829b89c2b08f wifi: rtw89: replace RF mutex with wiphy lock assertion
bda294ed0ed0 wifi: rtw89: Drop malformed AMPDU frames with abnormal PN
45ba9226b108 wifi: rtw89: Recalculate station aggregates when AMSDU length changes for MLO links
a1488456f706 wifi: rtw89: debug: simulate Wi-Fi 7 SER L0/L1 without PS mode
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* RE: [RFC PATCH v3 3/4] wifi: rtl8xxxu: update max report mac id on station add / remove for 8188e chips
From: Ping-Ke Shih @ 2026-03-16 7:07 UTC (permalink / raw)
To: Georg Müller, Jes.Sorensen@gmail.com,
rtl8821cerfe2@gmail.com
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260313135321.3196688-4-georgmueller@gmx.net>
Georg Müller <georgmueller@gmx.net> wrote:
remember to add commit messages when you send formal patch.
>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/core.c | 23 +++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> index 5ad23c5c9305..15fc4843edb2 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> @@ -3884,6 +3884,15 @@ void rtl8xxxu_init_burst(struct rtl8xxxu_priv *priv)
> rtl8xxxu_write8(priv, REG_RSV_CTRL, val8);
> }
>
> +static u8 rtl8xxxu_max_acquired_macid(struct rtl8xxxu_priv *priv)
> +{
> + u8 macid;
> +
> + macid = find_last_bit(priv->mac_id_map, RTL8XXXU_MAX_MAC_ID_NUM);
> +
> + return macid;
> +}
> +
> static u8 rtl8xxxu_acquire_macid(struct rtl8xxxu_priv *priv)
> {
> u8 macid;
> @@ -7499,6 +7508,7 @@ static int rtl8xxxu_sta_add(struct ieee80211_hw *hw,
> struct rtl8xxxu_sta_info *sta_info = (struct rtl8xxxu_sta_info
> *)sta->drv_priv;
> struct rtl8xxxu_vif *rtlvif = (struct rtl8xxxu_vif *)vif->drv_priv;
> struct rtl8xxxu_priv *priv = hw->priv;
> + u8 max_mac_id;
>
> mutex_lock(&priv->sta_mutex);
> ewma_rssi_init(&sta_info->avg_rssi);
> @@ -7510,6 +7520,11 @@ static int rtl8xxxu_sta_add(struct ieee80211_hw *hw,
> return -ENOSPC;
> }
>
> + if (priv->rtl_chip == RTL8188E) {
> + max_mac_id = rtl8xxxu_max_acquired_macid(priv);
> + rtl8xxxu_write8(priv, REG_TX_REPORT_CTRL + 1,
> max_mac_id + 1);
> + }
> +
> rtl8xxxu_refresh_rate_mask(priv, 0, sta, true);
> priv->fops->report_connect(priv, sta_info->macid,
> H2C_MACID_ROLE_STA, true);
> } else {
> @@ -7535,10 +7550,16 @@ static int rtl8xxxu_sta_remove(struct ieee80211_hw *hw,
> {
> struct rtl8xxxu_sta_info *sta_info = (struct rtl8xxxu_sta_info
> *)sta->drv_priv;
> struct rtl8xxxu_priv *priv = hw->priv;
> + u8 max_mac_id;
>
> mutex_lock(&priv->sta_mutex);
> - if (vif->type == NL80211_IFTYPE_AP)
> + if (vif->type == NL80211_IFTYPE_AP) {
> rtl8xxxu_release_macid(priv, sta_info->macid);
> + if (priv->rtl_chip == RTL8188E) {
> + max_mac_id = rtl8xxxu_max_acquired_macid(priv);
> + rtl8xxxu_write8(priv, REG_TX_REPORT_CTRL + 1,
> max_mac_id + 1);
> + }
> + }
At first glance, I'd say should we consider STA+AP concurrent case?
Because days ago, we talked about that in another thread.
It looks like MAC ID is another problem for concurrent case, because
rtl8xxxu_max_acquired_macid() returns MAC ID starting from 0.
But special MAC IDs are defined for non-AP vif:
#define RTL8XXXU_BC_MC_MACID 0
#define RTL8XXXU_BC_MC_MACID1 1
(But this is not scope of this patch.)
> mutex_unlock(&priv->sta_mutex);
>
> return 0;
> --
> 2.53.0
>
^ permalink raw reply
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