* Re: [PATCH] wifi: libertas_tf: kill shared URB before resubmitting it
From: Steve deRosier @ 2026-06-11 21:28 UTC (permalink / raw)
To: Runyu Xiao
Cc: linux-wireless, libertas-dev, linville, luisca, linux-kernel,
jianhao.xu, stable
In-Reply-To: <20260611151848.2573316-1-runyu.xiao@seu.edu.cn>
On Thu, Jun 11, 2026 at 8:19 AM Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
>
> libertas_tf's usb_tx_block() reuses a shared send URB and immediately
> does usb_fill_bulk_urb() plus usb_submit_urb() on it. Depending on the
> caller, that shared carrier is either cardp->tx_urb or cardp->cmd_urb.
> There is no patch-local usb_kill_urb() before reuse, and the file-local
> completion path provides no busy flag, completion, or other ownership
> handoff that would make active reuse safe.
>
> A running system can reach this through if_usb_host_to_card() for normal
> data or command traffic, if_usb_issue_boot_command() for firmware boot
> commands, and if_usb_send_fw_pkt() for firmware download packets. Those
> paths all feed back into the same helper, so a second submission can
> refill and resubmit an URB while the previous transfer is still active.
>
> The issue was found by our static analysis tool and manually audited on
> Linux v6.18.21. It was further validated with a focused QEMU no-device KCSAN
> harness, which reproduced active reuse of both shared carriers:
> cardp->tx_urb through if_usb_host_to_card(), and cardp->cmd_urb through
> if_usb_issue_boot_command() and if_usb_send_fw_pkt().
>
> Call usb_kill_urb(urb) after selecting the shared target URB and before
> refilling it, so both tx_urb and cmd_urb are quiesced before reuse.
>
> Fixes: c305a19a0d0a ("libertas_tf: usb specific functions")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
> drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> index 5662a244f82a..7542956d3c47 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> @@ -387,6 +387,8 @@ static int usb_tx_block(struct if_usb_card *cardp, uint8_t *payload,
> else
> urb = cardp->cmd_urb;
>
> + usb_kill_urb(urb);
> +
> usb_fill_bulk_urb(urb, cardp->udev,
> usb_sndbulkpipe(cardp->udev,
> cardp->ep_out),
> --
> 2.34.1
So, If I'm reading this right, you've basically compile checked and
such on this, but you haven't actually tried this on real hardware. If
you had, you'd have noticed it splats all over the place.
`usb_kill_urb()` can not be called from within an atomic context and 3
of the 5 contexts where this is called are atomic.
You've gone and fixed a very unlikely but theoretical race condition
in a way that causes actual real damage.
This is targeting an old Marvell 8388 which is a 802.11b/g chip. With
a custom thin-firmware created by Cozybit for OLPC and AFAIK only ever
used on those units. While I appreciate the "fix it for sake of
correctness" (if indeed this would fix it, which clearly it doesn't),
I'm not sure what the value proposition is for fixing something that
basically isn't used anymore.
Anyway, this is a hard NACK.
- Steve
^ permalink raw reply
* Re: [PATCH v2 2/7] wifi: ath11k: enable support for WCN6851
From: Dmitry Baryshkov @ 2026-06-11 20:05 UTC (permalink / raw)
To: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Bartosz Golaszewski
In-Reply-To: <20260608-sm8350-wifi-v2-2-efb68f1ff04c@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 09:59:20AM +0300, Dmitry Baryshkov wrote:
> The WCN6851, found e.g. on SM8350 platforms, is an earlier version of
> WCN6855 platform. It identifies itself as hw1.1. Copy WCN6855 hw 2.0
> configuration to support hw1.1 version.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath11k/core.c | 92 ++++++++++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath11k/core.h | 1 +
> drivers/net/wireless/ath/ath11k/mhi.c | 1 +
> drivers/net/wireless/ath/ath11k/pci.c | 9 ++++
> drivers/net/wireless/ath/ath11k/pcic.c | 11 ++++
> 5 files changed, 114 insertions(+)
This crashes with the firmware that came with the board,
WLAN.HSP.1.1.c3-00200-QCAHSPSWPL_V1_V2_SILICONZ. I will revert to 3
vdevs for v3.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/7] wifi: ath11k: enable support for WCN6851
From: Dmitry Baryshkov @ 2026-06-11 20:03 UTC (permalink / raw)
To: Jeff Johnson
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pci, linux-kernel, linux-wireless, ath11k, devicetree,
Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <e5b487ea-151f-4d22-b046-b72447c023cf@oss.qualcomm.com>
On Mon, Jun 01, 2026 at 06:54:35AM -0700, Jeff Johnson wrote:
> On 6/1/2026 2:46 AM, Dmitry Baryshkov wrote:
> > The WCN6851, found e.g. on SM8350 platforms, is an earlier version of
> > WCN6855 platform. It identifies itself as hw1.1. Copy WCN6855 hw 2.0
> > configuration to support hw1.1 version.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > drivers/net/wireless/ath/ath11k/core.c | 92 ++++++++++++++++++++++++++++++++++
> > drivers/net/wireless/ath/ath11k/core.h | 1 +
> > drivers/net/wireless/ath/ath11k/mhi.c | 1 +
> > drivers/net/wireless/ath/ath11k/pci.c | 9 ++++
> > drivers/net/wireless/ath/ath11k/pcic.c | 11 ++++
> > 5 files changed, 114 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> > index 3f6f4db5b7ee..7e997016cf6e 100644
> > --- a/drivers/net/wireless/ath/ath11k/core.c
> > +++ b/drivers/net/wireless/ath/ath11k/core.c
> > @@ -393,6 +393,98 @@ static const struct ath11k_hw_params ath11k_hw_params[] = {
> > .cfr_num_stream_bufs = 0,
> > .cfr_stream_buf_size = 0,
> > },
> > + {
> > + .name = "wcn6855 hw1.1",
> > + .hw_rev = ATH11K_HW_WCN6855_HW11,
> > + .fw = {
> > + .dir = "WCN6855/hw1.1",
> > + .board_size = 256 * 1024,
> > + .cal_offset = 128 * 1024,
> > + },
> ...> + .num_vdevs = 2 + 1,
>
> this value is being modified to 4 in:
> https://msgid.link/20260525020711.2590815-1-wei.zhang@oss.qualcomm.com
>
> It is merging into ath-next today and should reach linux-next very soon.
I've upgraded it 4 for v2, but it crashes the original firmware that
came with the board. I'll revert it for 3 for the next iteration.
For the reference:
ath11k_pci 0000:01:00.0: BAR 0 [mem 0x60400000-0x605fffff 64bit]: assigned
ath11k_pci 0000:01:00.0: MSI vectors: 32
ath11k_pci 0000:01:00.0: wcn6855 hw1.1
mhi mhi0: Requested to power ON
mhi mhi0: Power on setup success
mhi mhi0: Wait for device to enter SBL or Mission mode
ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x6 soc_id 0x400c0110
ath11k_pci 0000:01:00.0: fw_version 0x110c80c8 fw_build_timestamp 2021-05-25 21:43 fw_build_id WLAN.HSP.1.1.c3-00200-QCAHSPSWPL_V1_V2_SILICONZ-1
ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM
ath11k_pci 0000:01:00.0: ignore reset dev flags 0xc800
ath11k_pci 0000:01:00.0: failed to receive wmi unified ready event: -110
ath11k_pci 0000:01:00.0: failed to start core: -110
failed to send QMI message
ath11k_pci 0000:01:00.0: failed to send wlan mode request (mode 4): -5
ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -5
>
> /jeff
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
From: Dmitry Baryshkov @ 2026-06-11 19:44 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Qiang Yu,
Jeff Johnson, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-pci,
linux-kernel, linux-wireless, ath11k, devicetree,
Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <955691e1-e40d-4584-861e-8f29db4ba8a9@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:09:27PM +0200, Konrad Dybcio wrote:
> On 6/1/26 11:46 AM, Dmitry Baryshkov wrote:
> > The SM8350 HDK has onboard WiFi/BT chip, WCN6851. It is an earlier
> > version of well-known WCN6855 WiFI/BT SoC. Describe the PMU, BT and WiFI
> > parts of the device.
>
> [...]
>
> > + wcn6855-pmu {
> > + compatible = "qcom,wcn6851-pmu", "qcom,wcn6855-pmu";
> > +
> > + pinctrl-0 = <&bt_en>, <&wlan_en>, <&swctrl>;
> > + pinctrl-names = "default";
> > +
> > + wlan-enable-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
> > + bt-enable-gpios = <&tlmm 65 GPIO_ACTIVE_HIGH>;
> > + swctrl-gpios = <&tlmm 153 GPIO_ACTIVE_HIGH>;
> > +
> > + vddio-supply = <&vreg_s10b_1p8>;
> > + vddaon-supply = <&vreg_s11b_0p95>;
> > + vddpmu-supply = <&vreg_s11b_0p95>;
> > + vddpmumx-supply = <&vreg_s2e_0p85>;
> > + vddpmucx-supply = <&vreg_s11b_0p95>;
> > + vddrfa0p95-supply = <&vreg_s11b_0p95>;
> > + vddrfa1p3-supply = <&vreg_s12b_1p25>;
> > + vddrfa1p9-supply = <&vreg_s1c_1p86>;
> > + vddpcie1p3-supply = <&vreg_s12b_1p25>;
> > + vddpcie1p9-supply = <&vreg_s1c_1p86>;
>
> [...]
>
> > @@ -373,6 +437,13 @@ vreg_l7e_2p8: ldo7 {
> > regulator-name = "vreg_l7e_2p8";
> > regulator-min-microvolt = <2800000>;
> > regulator-max-microvolt = <2800000>;
> > +
> > + /*
> > + * This is used by the RF front-end for which there is
> > + * no way to represent it in DT (yet?).
> > + */
> > + regulator-boot-on;
> > + regulator-always-on;
>
> msm-5.4 maps this to bt-vdd-asd-supply (asd being a keyboard smash,
> perhaps?) - what is its actual use?
WiFI/BT RF front-end, a separate chip containing amplifiers, couplers,
etc.
It is a separate chip (or a module), it is not powered on by the PMU,
etc.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] wifi: ieee80211: validate MLE common info length
From: Zhao Li @ 2026-06-11 17:35 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, linux-kernel, Zhao Li, stable
ieee80211_mle_common_size() uses the first common-info octet as the
common information length for all known MLE types. However,
ieee80211_mle_size_ok() only validates that octet for Basic, Probe
Request, and TDLS MLEs.
Reconfiguration MLEs also skipped the length octet when calculating the
minimum common size, and Priority Access MLEs skipped validation of the
advertised common information length.
Account for the Reconfiguration common-info length octet and validate
the advertised common information length for all known MLE types. Keep
unknown-type handling unchanged.
Fixes: 0f48b8b88aa9 ("wifi: ieee80211: add definitions for multi-link element")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
---
include/linux/ieee80211-eht.h | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/linux/ieee80211-eht.h b/include/linux/ieee80211-eht.h
index a97b1d01f3acf..a557df0088c08 100644
--- a/include/linux/ieee80211-eht.h
+++ b/include/linux/ieee80211-eht.h
@@ -844,7 +844,7 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
const struct ieee80211_multi_link_elem *mle = (const void *)data;
u8 fixed = sizeof(*mle);
u8 common = 0;
- bool check_common_len = false;
+ u8 common_len;
u16 control;
if (!data || len < fixed)
@@ -855,7 +855,6 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
switch (u16_get_bits(control, IEEE80211_ML_CONTROL_TYPE)) {
case IEEE80211_ML_CONTROL_TYPE_BASIC:
common += sizeof(struct ieee80211_mle_basic_common_info);
- check_common_len = true;
if (control & IEEE80211_MLC_BASIC_PRES_LINK_ID)
common += 1;
if (control & IEEE80211_MLC_BASIC_PRES_BSS_PARAM_CH_CNT)
@@ -875,9 +874,9 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
common += sizeof(struct ieee80211_mle_preq_common_info);
if (control & IEEE80211_MLC_PREQ_PRES_MLD_ID)
common += 1;
- check_common_len = true;
break;
case IEEE80211_ML_CONTROL_TYPE_RECONF:
+ common += 1;
if (control & IEEE80211_MLC_RECONF_PRES_MLD_MAC_ADDR)
common += ETH_ALEN;
if (control & IEEE80211_MLC_RECONF_PRES_EML_CAPA)
@@ -889,7 +888,6 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
break;
case IEEE80211_ML_CONTROL_TYPE_TDLS:
common += sizeof(struct ieee80211_mle_tdls_common_info);
- check_common_len = true;
break;
case IEEE80211_ML_CONTROL_TYPE_PRIO_ACCESS:
common = ETH_ALEN + 1;
@@ -902,11 +900,10 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
if (len < fixed + common)
return false;
- if (!check_common_len)
- return true;
-
/* if present, common length is the first octet there */
- return mle->variable[0] >= common;
+ common_len = mle->variable[0];
+
+ return common_len >= common && common_len <= len - fixed;
}
/**
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v2 2/2] wifi: cfg80211: derive S1G beacon TSF from S1G fields
From: Zhao Li @ 2026-06-11 16:19 UTC (permalink / raw)
To: Johannes Berg
Cc: Thomas Pedersen, linux-wireless, linux-kernel, Zhao Li, stable
In-Reply-To: <20260611161943.91069-4-enderaoelyther@gmail.com>
cfg80211_inform_bss_frame_data() parses S1G beacons with the extension
frame layout, but still reads the TSF from the regular probe response
layout after the S1G branch. For S1G beacons that reads bytes at the
regular management-frame timestamp offset instead of the S1G timestamp.
Use the 32-bit S1G beacon timestamp and the S1G Beacon Compatibility
element's TSF completion field when informing an S1G BSS. Keep the
regular management-frame timestamp read in the non-S1G branch.
Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
---
net/wireless/scan.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 27a56ee2e8f0b..c90619eeb03b1 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -3309,14 +3309,15 @@ cfg80211_inform_bss_frame_data(struct wiphy *wiphy,
bssid = ext->u.s1g_beacon.sa;
capability = le16_to_cpu(compat->compat_info);
beacon_interval = le16_to_cpu(compat->beacon_int);
+ tsf = le32_to_cpu(ext->u.s1g_beacon.timestamp);
+ tsf |= (u64)le32_to_cpu(compat->tsf_completion) << 32;
} else {
bssid = mgmt->bssid;
beacon_interval = le16_to_cpu(mgmt->u.probe_resp.beacon_int);
capability = le16_to_cpu(mgmt->u.probe_resp.capab_info);
+ tsf = le64_to_cpu(mgmt->u.probe_resp.timestamp);
}
- tsf = le64_to_cpu(mgmt->u.probe_resp.timestamp);
-
if (ieee80211_is_probe_resp(mgmt->frame_control))
ftype = CFG80211_BSS_FTYPE_PRESP;
else if (ext)
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v2 1/2] wifi: mac80211: validate extension-frame layout before RX
From: Zhao Li @ 2026-06-11 16:19 UTC (permalink / raw)
To: Johannes Berg
Cc: Thomas Pedersen, linux-wireless, linux-kernel, Zhao Li, stable
In-Reply-To: <20260611161943.91069-4-enderaoelyther@gmail.com>
Extension frames only have the extension header at the regular 802.11
header offset. The generic RX path can still reach helpers and interface
dispatch code that read regular header address fields before unsupported
extension subtypes are dropped.
mac80211 currently only handles S1G beacon extension frames. Drop other
extension subtypes before they can reach regular-header RX processing.
For S1G beacons, linearize the SKB with the management-frame path and
require the fixed S1G beacon header, including optional fixed fields
indicated by frame control, before generic RX dispatch.
Route S1G beacons through the station/default-link RX path without
regular-header station lookup. Avoid regular-header address reads in the
mac80211 RX paths that process S1G extension beacons, including
accept-frame, duplicate-detection, address-copy, and MLO
address-translation paths.
Also make ieee80211_get_bssid() length-safe before returning the S1G
source-address pointer.
Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
---
net/mac80211/rx.c | 34 ++++++++++++++++++++++++++++++++--
net/mac80211/util.c | 3 +++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 3fb40449c6c5c..3ddde3e808364 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1526,6 +1526,9 @@ ieee80211_rx_h_check_dup(struct ieee80211_rx_data *rx)
if (status->flag & RX_FLAG_DUP_VALIDATED)
return RX_CONTINUE;
+ if (ieee80211_is_ext(hdr->frame_control))
+ return RX_CONTINUE;
+
/*
* Drop duplicate 802.11 retransmissions
* (IEEE 802.11-2012: 9.3.2.10 "Duplicate detection and recovery")
@@ -4487,12 +4490,16 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx)
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
u8 *bssid = ieee80211_get_bssid(hdr, skb->len, sdata->vif.type);
- bool multicast = is_multicast_ether_addr(hdr->addr1) ||
- ieee80211_is_s1g_beacon(hdr->frame_control);
+ bool multicast;
static const u8 nan_network_id[ETH_ALEN] __aligned(2) = {
0x51, 0x6F, 0x9A, 0x01, 0x00, 0x00
};
+ if (ieee80211_is_s1g_beacon(hdr->frame_control))
+ return sdata->vif.type == NL80211_IFTYPE_STATION && bssid;
+
+ multicast = is_multicast_ether_addr(hdr->addr1);
+
switch (sdata->vif.type) {
case NL80211_IFTYPE_STATION:
if (!bssid && !sdata->u.mgd.use_4addr)
@@ -5174,6 +5181,11 @@ static bool ieee80211_prepare_and_rx_handle(struct ieee80211_rx_data *rx,
hdr = (struct ieee80211_hdr *)rx->skb->data;
}
+ if (ieee80211_is_s1g_beacon(hdr->frame_control)) {
+ ieee80211_invoke_rx_handlers(rx);
+ return true;
+ }
+
/* Store a copy of the pre-translated link addresses for SW crypto */
if (unlikely(is_unicast_ether_addr(hdr->addr1) &&
!ieee80211_is_data(hdr->frame_control)))
@@ -5263,6 +5275,13 @@ static bool ieee80211_rx_for_interface(struct ieee80211_rx_data *rx,
struct sta_info *sta;
int link_id = -1;
+ if (ieee80211_is_s1g_beacon(hdr->frame_control)) {
+ if (!ieee80211_rx_data_set_sta(rx, NULL, -1))
+ return false;
+
+ return ieee80211_prepare_and_rx_handle(rx, skb, consume);
+ }
+
/*
* Look up link station first, in case there's a
* chance that they might have a link address that
@@ -5338,6 +5357,17 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
err = -ENOBUFS;
else
err = skb_linearize(skb);
+ } else if (ieee80211_is_s1g_beacon(fc)) {
+ size_t s1g_hdr_len = offsetof(struct ieee80211_ext,
+ u.s1g_beacon.variable) +
+ ieee80211_s1g_optional_len(fc);
+
+ if (skb->len < s1g_hdr_len)
+ err = -ENOBUFS;
+ else
+ err = skb_linearize(skb);
+ } else if (ieee80211_is_ext(fc)) {
+ err = -EINVAL;
} else {
err = !pskb_may_pull(skb, ieee80211_hdrlen(fc));
}
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 2529b01e2cd55..5bc719222a87d 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -73,6 +73,9 @@ u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
if (ieee80211_is_s1g_beacon(fc)) {
struct ieee80211_ext *ext = (void *) hdr;
+ if (len < offsetofend(struct ieee80211_ext, u.s1g_beacon.sa))
+ return NULL;
+
return ext->u.s1g_beacon.sa;
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v2 0/2] wifi: handle S1G and extension-frame RX layout
From: Zhao Li @ 2026-06-11 16:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: Thomas Pedersen, linux-wireless, linux-kernel, Zhao Li
In-Reply-To: <20260610162700.58722-1-enderaoelyther@gmail.com>
Hi,
v2 keeps the mac80211 RX fix focused on the extension-frame layout and
adds a small cfg80211 companion fix for S1G scan-result TSF handling.
The first patch changes the RX entry path to validate and linearize S1G
beacons before generic RX dispatch, route S1G beacons without regular
addr2 station lookup, and drop unsupported extension frames before they
can reach regular-header address handling.
The second patch keeps cfg80211's regular management-frame TSF read out
of the S1G path and derives the S1G BSS TSF from the S1G beacon timestamp
and the S1G Beacon Compatibility element.
For process clarity: I used AI-assisted tooling for data-flow tracing,
state-machine analysis, code review, security checks, side-effect review,
and patch drafting. I reviewed the result and take responsibility for the
submission.
Changes since v1:
- Linearize S1G beacon SKBs together with management frames instead of
using a later pskb_may_pull() check.
- Keep the management-frame and S1G beacon minimum-length checks tied to
their respective frame layouts.
- Route S1G beacons through the station/default-link RX path without
regular addr2 station lookup.
- Avoid repeated per-sink S1G guards in the address-copy and MLO
translation paths by invoking RX handlers directly for S1G beacons.
- Drop unsupported non-S1G extension frames before generic RX dispatch.
- Add the cfg80211 S1G TSF companion fix.
Zhao Li (2):
wifi: mac80211: validate extension-frame layout before RX
wifi: cfg80211: derive S1G beacon TSF from S1G fields
net/mac80211/rx.c | 34 ++++++++++++++++++++++++++++++++--
net/mac80211/util.c | 3 +++
net/wireless/scan.c | 5 +++--
3 files changed, 38 insertions(+), 4 deletions(-)
--
2.50.1 (Apple Git-155)
^ permalink raw reply
* [PATCH] wifi: libertas_tf: kill shared URB before resubmitting it
From: Runyu Xiao @ 2026-06-11 15:18 UTC (permalink / raw)
To: linux-wireless
Cc: libertas-dev, linville, luisca, linux-kernel, jianhao.xu,
runyu.xiao, stable
libertas_tf's usb_tx_block() reuses a shared send URB and immediately
does usb_fill_bulk_urb() plus usb_submit_urb() on it. Depending on the
caller, that shared carrier is either cardp->tx_urb or cardp->cmd_urb.
There is no patch-local usb_kill_urb() before reuse, and the file-local
completion path provides no busy flag, completion, or other ownership
handoff that would make active reuse safe.
A running system can reach this through if_usb_host_to_card() for normal
data or command traffic, if_usb_issue_boot_command() for firmware boot
commands, and if_usb_send_fw_pkt() for firmware download packets. Those
paths all feed back into the same helper, so a second submission can
refill and resubmit an URB while the previous transfer is still active.
The issue was found by our static analysis tool and manually audited on
Linux v6.18.21. It was further validated with a focused QEMU no-device KCSAN
harness, which reproduced active reuse of both shared carriers:
cardp->tx_urb through if_usb_host_to_card(), and cardp->cmd_urb through
if_usb_issue_boot_command() and if_usb_send_fw_pkt().
Call usb_kill_urb(urb) after selecting the shared target URB and before
refilling it, so both tx_urb and cmd_urb are quiesced before reuse.
Fixes: c305a19a0d0a ("libertas_tf: usb specific functions")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index 5662a244f82a..7542956d3c47 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -387,6 +387,8 @@ static int usb_tx_block(struct if_usb_card *cardp, uint8_t *payload,
else
urb = cardp->cmd_urb;
+ usb_kill_urb(urb);
+
usb_fill_bulk_urb(urb, cardp->udev,
usb_sndbulkpipe(cardp->udev,
cardp->ep_out),
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request
From: Toke Høiland-Jørgensen @ 2026-06-11 14:29 UTC (permalink / raw)
To: xiaoblac
Cc: Oleksij Rempel, linux-wireless, linux-kernel, syzkaller-bugs,
Cheng Yongkang, syzbot+50122cbc2874b1eb25b0
In-Reply-To: <20260605153210.20471-1-1020691186@qq.com>
xiaoblac <teel4res@gmail.com> writes:
> From: Cheng Yongkang <teel4res@gmail.com>
>
> ath9k_hif_request_firmware() re-arms an asynchronous firmware load via
> request_firmware_nowait(), passing hif_dev as the completion context, and
> then still dereferences hif_dev:
>
> dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n",
> hif_dev->fw_name);
>
> The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events"
> workqueue and, when the firmware is missing, walks the retry chain into
> ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That
> releases the wait_for_completion(&hif_dev->fw_done) in a concurrent
> ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing
> dev_info() in the frame that re-armed the request can therefore read freed
> memory (hif_dev->udev, the first field of struct hif_device_usb):
>
> BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware
> Read of size 8 ... by task kworker/...
> ath9k_hif_request_firmware
> ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247
> request_firmware_work_func
> Allocated by ...:
> ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c
> Freed by ...:
> ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c
>
> The fw_done barrier only makes disconnect wait for the firmware chain to
> *terminate*; it does not protect the outer ath9k_hif_request_firmware()
> frame that re-armed the request and keeps touching hif_dev afterwards.
>
> Drop the post-request dev_info(): it is the only use of hif_dev after the
> async request is armed, and it is purely informational (the dev_err() on the
> failure path runs only when request_firmware_nowait() did not arm a callback,
> so hif_dev is still alive there).
>
> This was first reported by syzbot as a single, non-reproduced crash that was
> later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer,
> which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc
> device whose firmware download fails). The vulnerable code is unchanged and
> still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN
> once the (sub-microsecond) race window is widened.
>
> Fixes: e904cf6fe230 ("ath9k_htc: introduce support for different fw versions")
> Reported-by: syzbot+50122cbc2874b1eb25b0@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=50122cbc2874b1eb25b0
> Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
Thank you for the fix!
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: rtw88: WiFi card is not offloaded properly when suspending the OS
From: Giovanni Santini @ 2026-06-11 13:11 UTC (permalink / raw)
To: Ping-Ke Shih, stable@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Linux regressions mailing list
In-Reply-To: <efae0a4db2ab4b6193922b393d3dcdd6@realtek.com>
Hi Ping-Ke,
In short I should build the LTS kernel using the provided source with
all the module patches applied one by one, correct?
If so, should I also set the modprobe.d options plus disable IOMMU?
After I know this I can start testing.
Small update: the .35 LTS kernel has no issues for me, while 7.0.11 works.
I was able to get my laptop to sleep a few times, but at a certain point
the issue happened.
It is a bit hard to replicate the issue, so I will try my best.
On 2026-06-08 03:32, Ping-Ke Shih wrote:
> Giovanni Santini <giovannisantini93@yahoo.it> wrote:
>> Jun 02 17:25:33 archlinux-tug kernel: rtw88_8822ce 0000:03:00.0: failed
>> to send h2c command
>> Jun 02 17:25:33 archlinux-tug kernel: rtw88_8822ce 0000:03:00.0: failed
>> to send h2c command
>> Jun 02 17:25:33 archlinux-tug kernel: rtw88_8822ce 0000:03:00.0: failed
>> to send h2c command
>> Jun 02 17:25:33 archlinux-tug kernel: rtw88_8822ce 0000:03:00.0: failed
>> to send h2c command
>> Jun 02 17:25:36 archlinux-tug kernel: rtw88_8822ce 0000:03:00.0: failed
>> to poll offset=0x5 mask=0x2 value=0x0
>> Jun 02 17:25:36 archlinux-tug kernel: ------------[ cut here ]------------
>> Jun 02 17:25:36 archlinux-tug kernel: failed to read DBI register,
>> addr=0x0719
> Add these below to see if it can help.
>
> sudo nano /etc/modprobe.d/rtw88.conf
> options rtw88_core disable_lps_deep=y
> options rtw88_pci disable_aspm=y
>
> After cold reboot, check /sys/modules/rtw88_*/paramters/* to see if
> the modification takes effect.
>
>> I'm attaching the full boot log, if you need a fresh one I can provide it.
> Before "failed to poll ..." log, I also see
>
> Jun 02 17:25:02 archlinux-tug kernel: rtw88_8822ce 0000:03:00.0: AMD-Vi:
> Event logged [IO_PAGE_FAULT domain=0x000e address=0xae9668bc flags=0x0000]
>
> Please try to turn off IOMMU by editing /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=off iommu=off"
>
> And then update-grub
>
>> I run ArchLinux with KDE Plasma, for networking I use NetworkManager and
>> wpa_supplicant.
>>
>> If you would like me to run tests with e.g. just iwd I can do so, just
>> let me know what setup you would like me to have.
>>
>> I do not have this issue with the LTS kernel 6.18.34. This affects 7.0
>> and 7.1.
>> I believe this issue was not present in < 7 kernels, but I cannot guarantee.
>> I can however downgrade to previous kernels to understand where the
>> issue was introduced.
> The commits between 6.18.34 ~ 7.0.10 are quite few, and I can't find the
> one that can affect the behavior. Please switch your kernel back to 6.18.34,
> and apply rtw88's patches added until 7.0.10.
>
> Since the last commit of 6.18 is fce6fee0817b8899e0ee38ab6b98f0d7e939ceed
>
> Please use below commands to get the (20) patches:
> drivers/net/wireless/realtek/rtw88$ git format-patch v7.0.10...fce6fee0817b8899e0ee38ab6b98f0d7e939ceed -- ./
>
> Then you can add them one by one to see which one is the cause.
>
> The git repository you need is:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>
>
> Ping-Ke
>
>
--
Giovanni Santini
^ permalink raw reply
* [PATCH] [wireless-next] wifi: mac80211: allocate backup ieee80211_nan_sched_cfg off stack
From: Arnd Bergmann @ 2026-06-11 13:00 UTC (permalink / raw)
To: Johannes Berg, Miri Korenblit; +Cc: Arnd Bergmann, linux-wireless, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The ieee80211_nan_sched_cfg structure is too large to keep on the
per thread stack:
net/mac80211/nan.c:251:5: error: stack frame size (1560) exceeds limit (1536) in 'ieee80211_nan_set_local_sched' [-Werror,-Wframe-larger-than]
251 | int ieee80211_nan_set_local_sched(struct ieee80211_sub_if_data *sdata,
Allocate this dynamically using kmalloc_obj() to reduce the stack
usage of this function to a manageable 344 bytes for the same
configuration.
Fixes: 589c06e8fdee ("wifi: mac80211: add NAN local schedule support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/mac80211/nan.c | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/net/mac80211/nan.c b/net/mac80211/nan.c
index 1800bb96dd29..19e08661be43 100644
--- a/net/mac80211/nan.c
+++ b/net/mac80211/nan.c
@@ -253,9 +253,12 @@ int ieee80211_nan_set_local_sched(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_nan_channel *sched_idx_to_chan[IEEE80211_NAN_MAX_CHANNELS] = {};
struct ieee80211_nan_sched_cfg *sched_cfg = &sdata->vif.cfg.nan_sched;
- struct ieee80211_nan_sched_cfg backup_sched;
+ struct ieee80211_nan_sched_cfg *backup_sched __free(kfree) = kmalloc_obj(*backup_sched);
int ret;
+ if (!backup_sched)
+ return -ENOMEM;
+
if (sched->n_channels > IEEE80211_NAN_MAX_CHANNELS)
return -EOPNOTSUPP;
@@ -275,13 +278,13 @@ int ieee80211_nan_set_local_sched(struct ieee80211_sub_if_data *sdata,
bitmap_zero(sdata->u.nan.removed_channels, IEEE80211_NAN_MAX_CHANNELS);
- memcpy(backup_sched.schedule, sched_cfg->schedule,
- sizeof(backup_sched.schedule));
- memcpy(backup_sched.channels, sched_cfg->channels,
- sizeof(backup_sched.channels));
- memcpy(backup_sched.avail_blob, sched_cfg->avail_blob,
- sizeof(backup_sched.avail_blob));
- backup_sched.avail_blob_len = sched_cfg->avail_blob_len;
+ memcpy(backup_sched->schedule, sched_cfg->schedule,
+ sizeof(backup_sched->schedule));
+ memcpy(backup_sched->channels, sched_cfg->channels,
+ sizeof(backup_sched->channels));
+ memcpy(backup_sched->avail_blob, sched_cfg->avail_blob,
+ sizeof(backup_sched->avail_blob));
+ backup_sched->avail_blob_len = sched_cfg->avail_blob_len;
memcpy(sched_cfg->avail_blob, sched->nan_avail_blob,
sched->nan_avail_blob_len);
@@ -380,17 +383,17 @@ int ieee80211_nan_set_local_sched(struct ieee80211_sub_if_data *sdata,
if (!chan_def->chan)
continue;
- if (!cfg80211_chandef_identical(&backup_sched.channels[i].chanreq.oper,
+ if (!cfg80211_chandef_identical(&backup_sched->channels[i].chanreq.oper,
chan_def))
ieee80211_nan_remove_channel(sdata,
&sched_cfg->channels[i]);
}
/* Re-add all backed up channels */
- for (int i = 0; i < ARRAY_SIZE(backup_sched.channels); i++) {
+ for (int i = 0; i < ARRAY_SIZE(backup_sched->channels); i++) {
struct ieee80211_nan_channel *chan = &sched_cfg->channels[i];
- *chan = backup_sched.channels[i];
+ *chan = backup_sched->channels[i];
/*
* For deferred update, no channels were removed and the channel
@@ -421,11 +424,11 @@ int ieee80211_nan_set_local_sched(struct ieee80211_sub_if_data *sdata,
}
}
- memcpy(sched_cfg->schedule, backup_sched.schedule,
- sizeof(backup_sched.schedule));
- memcpy(sched_cfg->avail_blob, backup_sched.avail_blob,
- sizeof(backup_sched.avail_blob));
- sched_cfg->avail_blob_len = backup_sched.avail_blob_len;
+ memcpy(sched_cfg->schedule, backup_sched->schedule,
+ sizeof(backup_sched->schedule));
+ memcpy(sched_cfg->avail_blob, backup_sched->avail_blob,
+ sizeof(backup_sched->avail_blob));
+ sched_cfg->avail_blob_len = backup_sched->avail_blob_len;
sched_cfg->deferred = false;
bitmap_zero(sdata->u.nan.removed_channels, IEEE80211_NAN_MAX_CHANNELS);
--
2.39.5
^ permalink raw reply related
* [PATCH] wifi: mt76: fix airoha_npu dependency tracking
From: Arnd Bergmann @ 2026-06-11 12:58 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Arnd Bergmann, Shayne Chen, Sean Wang, Rex Lu, linux-wireless,
linux-kernel, linux-arm-kernel, linux-mediatek
From: Arnd Bergmann <arnd@arndb.de>
There is a new build failure with MT7996E=m MT76_CORE=y and NET_AIROHA_NPU=m:
ld.lld: error: undefined symbol: airoha_npu_get
ld.lld: error: undefined symbol: airoha_npu_put
>>> referenced by npu.c
>>> drivers/net/wireless/mediatek/mt76/npu.o:(mt76_npu_init) in archive vmlinux.a
Fix this by reworking the dependency for the MT7996_NPU to only
allow enabling that when mt76_core can link against the npu driver.
To make sure this gets caught more easily in the future when additional
mt76 variants need the same dependency, also turn CONFIG_MT76_NPU into
a tristate symbol that has the same dependency.
Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/mediatek/mt76/Kconfig | 4 ++--
drivers/net/wireless/mediatek/mt76/Makefile | 6 +++++-
drivers/net/wireless/mediatek/mt76/mt76.h | 2 +-
drivers/net/wireless/mediatek/mt76/mt7996/Kconfig | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/Kconfig b/drivers/net/wireless/mediatek/mt76/Kconfig
index 502303622a53..d941e67a222d 100644
--- a/drivers/net/wireless/mediatek/mt76/Kconfig
+++ b/drivers/net/wireless/mediatek/mt76/Kconfig
@@ -38,8 +38,8 @@ config MT792x_USB
select MT76_USB
config MT76_NPU
- bool
- depends on MT76_CORE
+ tristate
+ depends on NET_AIROHA_NPU=y || MT76=NET_AIROHA_NPU
source "drivers/net/wireless/mediatek/mt76/mt76x0/Kconfig"
source "drivers/net/wireless/mediatek/mt76/mt76x2/Kconfig"
diff --git a/drivers/net/wireless/mediatek/mt76/Makefile b/drivers/net/wireless/mediatek/mt76/Makefile
index 1d42adfe8030..cacdd2b13d05 100644
--- a/drivers/net/wireless/mediatek/mt76/Makefile
+++ b/drivers/net/wireless/mediatek/mt76/Makefile
@@ -12,7 +12,11 @@ mt76-y := \
mmio.o util.o trace.o dma.o mac80211.o debugfs.o eeprom.o \
tx.o agg-rx.o mcu.o wed.o scan.o channel.o
-mt76-$(CONFIG_MT76_NPU) += npu.o
+ifdef CONFIG_MT76_NPU
+# CONFIG_MT76_NPU is tristate to simplify dependency tracking,
+# but it behaves as a bool symbol here.
+mt76-y += npu.o
+endif
mt76-$(CONFIG_PCI) += pci.o
mt76-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 07955555f84d..60bd155cc7d5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -1647,7 +1647,7 @@ int mt76_testmode_dump(struct ieee80211_hw *hw, struct sk_buff *skb,
int mt76_testmode_set_state(struct mt76_phy *phy, enum mt76_testmode_state state);
int mt76_testmode_alloc_skb(struct mt76_phy *phy, u32 len);
-#ifdef CONFIG_MT76_NPU
+#if IS_ENABLED(CONFIG_MT76_NPU)
void mt76_npu_check_ppe(struct mt76_dev *dev, struct sk_buff *skb,
u32 info);
int mt76_npu_dma_add_buf(struct mt76_phy *phy, struct mt76_queue *q,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/Kconfig b/drivers/net/wireless/mediatek/mt76/mt7996/Kconfig
index 5503d03bf62c..5742bce12fbb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/Kconfig
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/Kconfig
@@ -16,6 +16,6 @@ config MT7996E
config MT7996_NPU
bool "MT7996 (PCIe) NPU support"
depends on MT7996E
- depends on NET_AIROHA_NPU=y || MT7996E=NET_AIROHA_NPU
+ depends on NET_AIROHA_NPU=y || MT76_CORE=NET_AIROHA_NPU
select MT76_NPU
default n
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] wifi: ieee80211: validate MLE common info length
From: Johannes Berg @ 2026-06-11 12:14 UTC (permalink / raw)
To: Zhao Li; +Cc: linux-wireless, linux-kernel, stable
In-Reply-To: <20260610154303.37079-1-enderaoelyther@gmail.com>
On Wed, 2026-06-10 at 23:43 +0800, Zhao Li wrote:
> ieee80211_mle_size_ok() verifies that the advertised common information
> length is large enough for the fixed fields that are present, but it does
> not verify that the length also fits in the containing element.
>
> Reconfiguration and Priority Access MLEs also carry a common information
> length octet, but currently skip the common-length check. Reconfiguration
> additionally fails to include the length octet in the minimum common size.
>
> Validate the common information length for Reconfiguration and Priority
> Access MLEs, account for the Reconfiguration length octet, and reject
> common lengths that exceed the element body.
>
> Fixes: 0f48b8b88aa9 ("wifi: ieee80211: add definitions for multi-link element")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
> ---
> include/linux/ieee80211-eht.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/ieee80211-eht.h b/include/linux/ieee80211-eht.h
> index a97b1d01f3acf..d875045abf6cc 100644
> --- a/include/linux/ieee80211-eht.h
> +++ b/include/linux/ieee80211-eht.h
> @@ -878,6 +878,8 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
> check_common_len = true;
> break;
> case IEEE80211_ML_CONTROL_TYPE_RECONF:
> + common += 1;
> + check_common_len = true;
> if (control & IEEE80211_MLC_RECONF_PRES_MLD_MAC_ADDR)
> common += ETH_ALEN;
> if (control & IEEE80211_MLC_RECONF_PRES_EML_CAPA)
> @@ -893,6 +895,7 @@ static inline bool ieee80211_mle_size_ok(const u8 *data, size_t len)
> break;
> case IEEE80211_ML_CONTROL_TYPE_PRIO_ACCESS:
> common = ETH_ALEN + 1;
> + check_common_len = true;
> break;
You just made check_common_len redundant, it's now always true.
I originally introduced it because variable[0] wasn't always common_len,
but that actually got fixed in later drafts, and we should've adjusted
that when we added +1 to all of these, e.g. commit 19aa842dcbb58.
We should probably more comprehensively change the whole thing so that
common_info_len is a separate u8 rather than variable[0], but that's
going to be much harder to do.
A smaller but probably better change would be to use the sub-structs
here that are defined, e.g. struct ieee80211_mle_preq_common_info,
struct ieee80211_mle_tdls_common_info and struct
ieee80211_mle_basic_common_info. But the layout is a bit stupid even
that way, dunno.
johannes
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
From: Konrad Dybcio @ 2026-06-11 12:09 UTC (permalink / raw)
To: Dmitry Baryshkov, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Qiang Yu,
Jeff Johnson, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-7-242917d88031@oss.qualcomm.com>
On 6/1/26 11:46 AM, Dmitry Baryshkov wrote:
> The SM8350 HDK has onboard WiFi/BT chip, WCN6851. It is an earlier
> version of well-known WCN6855 WiFI/BT SoC. Describe the PMU, BT and WiFI
> parts of the device.
[...]
> + wcn6855-pmu {
> + compatible = "qcom,wcn6851-pmu", "qcom,wcn6855-pmu";
> +
> + pinctrl-0 = <&bt_en>, <&wlan_en>, <&swctrl>;
> + pinctrl-names = "default";
> +
> + wlan-enable-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
> + bt-enable-gpios = <&tlmm 65 GPIO_ACTIVE_HIGH>;
> + swctrl-gpios = <&tlmm 153 GPIO_ACTIVE_HIGH>;
> +
> + vddio-supply = <&vreg_s10b_1p8>;
> + vddaon-supply = <&vreg_s11b_0p95>;
> + vddpmu-supply = <&vreg_s11b_0p95>;
> + vddpmumx-supply = <&vreg_s2e_0p85>;
> + vddpmucx-supply = <&vreg_s11b_0p95>;
> + vddrfa0p95-supply = <&vreg_s11b_0p95>;
> + vddrfa1p3-supply = <&vreg_s12b_1p25>;
> + vddrfa1p9-supply = <&vreg_s1c_1p86>;
> + vddpcie1p3-supply = <&vreg_s12b_1p25>;
> + vddpcie1p9-supply = <&vreg_s1c_1p86>;
[...]
> @@ -373,6 +437,13 @@ vreg_l7e_2p8: ldo7 {
> regulator-name = "vreg_l7e_2p8";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <2800000>;
> +
> + /*
> + * This is used by the RF front-end for which there is
> + * no way to represent it in DT (yet?).
> + */
> + regulator-boot-on;
> + regulator-always-on;
msm-5.4 maps this to bt-vdd-asd-supply (asd being a keyboard smash,
perhaps?) - what is its actual use?
Konrad
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: qcom: sm8350: expand UART18 to 4 pins config
From: Konrad Dybcio @ 2026-06-11 12:04 UTC (permalink / raw)
To: Dmitry Baryshkov, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Qiang Yu,
Jeff Johnson, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-5-242917d88031@oss.qualcomm.com>
On 6/1/26 11:46 AM, Dmitry Baryshkov wrote:
> On SM8350 platforms the primary use of UART18 is a 4-pin UART (targeting
> Bluetooth or other similar applications). Add all 4 pins to the default
> pinctrl entry for the UART.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: validate S1G beacon length before RX
From: Johannes Berg @ 2026-06-11 12:03 UTC (permalink / raw)
To: Zhao Li; +Cc: Thomas Pedersen, linux-wireless, linux-kernel, stable
In-Reply-To: <20260610162700.58722-1-enderaoelyther@gmail.com>
On Thu, 2026-06-11 at 00:27 +0800, Zhao Li wrote:
> S1G beacons are extension frames, so ieee80211_hdrlen() only guarantees
> the extension header before the generic RX path starts dispatching the
> frame.
>
> The RX path can then reach helpers and interface handling code that read
> regular 802.11 header address fields, which are not present at those
> offsets in an S1G beacon.
>
> Pull the complete S1G beacon fixed header, including optional fixed
> fields indicated by frame control, before generic RX dispatch.
>
> Also make ieee80211_get_bssid() length-safe for S1G beacons and avoid
> regular-header address reads for S1G frames in accept/interface/MLO
> address handling. Skip extension frames in duplicate detection for the
> same reason, since that path consumes the regular sequence-control field.
This is all true, but all of the below seems far too complicated a fix?
Also seems like you should probably disclose some LLM usage, unless
you're going to tell me you wrote all this code yourself?
> @@ -4487,12 +4490,17 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx)
> struct ieee80211_hdr *hdr = (void *)skb->data;
> struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
> u8 *bssid = ieee80211_get_bssid(hdr, skb->len, sdata->vif.type);
> - bool multicast = is_multicast_ether_addr(hdr->addr1) ||
> - ieee80211_is_s1g_beacon(hdr->frame_control);
> + bool s1g = ieee80211_is_s1g_beacon(hdr->frame_control);
> + bool multicast;
> static const u8 nan_network_id[ETH_ALEN] __aligned(2) = {
> 0x51, 0x6F, 0x9A, 0x01, 0x00, 0x00
> };
>
> + if (s1g)
no need to introduce the 's1g' variable, and it sounds weird anyway
because s1g uses other frames too, not just beacons
> @@ -5175,11 +5183,13 @@ static bool ieee80211_prepare_and_rx_handle(struct ieee80211_rx_data *rx,
> }
>
> /* Store a copy of the pre-translated link addresses for SW crypto */
> - if (unlikely(is_unicast_ether_addr(hdr->addr1) &&
> + if (unlikely(!ieee80211_is_s1g_beacon(hdr->frame_control) &&
> + is_unicast_ether_addr(hdr->addr1) &&
> !ieee80211_is_data(hdr->frame_control)))
> memcpy(rx->link_addrs, &hdr->addrs, 3 * ETH_ALEN);
>
> if (unlikely(rx->sta && rx->sta->sta.mlo) &&
> + !ieee80211_is_s1g_beacon(hdr->frame_control) &&
> is_unicast_ether_addr(hdr->addr1) &&
> !ieee80211_is_probe_resp(hdr->frame_control) &&
> !ieee80211_is_beacon(hdr->frame_control)) {
This seems very ... specific, and doing the same thing twice also seems
odd. While not great, I'd probably advocate for a goto or just doing the
invoke() separately for s1g beacons.
> @@ -5260,23 +5270,30 @@ static bool ieee80211_rx_for_interface(struct ieee80211_rx_data *rx,
> {
> struct link_sta_info *link_sta;
> struct ieee80211_hdr *hdr = (void *)skb->data;
> + u8 *sta_addr = hdr->addr2;
> struct sta_info *sta;
> int link_id = -1;
>
> + if (ieee80211_is_s1g_beacon(hdr->frame_control)) {
> + sta_addr = ieee80211_get_bssid(hdr, skb->len, rx->sdata->vif.type);
> + if (!sta_addr)
> + return false;
> + }
That one seems even weirder - especially in the face of your *other*
changes that attempt to never access hdr-> without making sure it's
actually the right format ... you still create a pointer to addr2 here.
It's valid since you never use it, but it's also weird because it pretty
much looks like hdr->addr2 _is_ OK at the whole function level.
> +
> /*
> * Look up link station first, in case there's a
> * chance that they might have a link address that
> * is identical to the MLD address, that way we'll
> * have the link information if needed.
> */
> - link_sta = link_sta_info_get_bss(rx->sdata, hdr->addr2);
> + link_sta = link_sta_info_get_bss(rx->sdata, sta_addr);
Obviously, if things work today, we didn't really need the link_sta for
these frames, and that makes some sense since there's no MLO and it's
just ieee80211_rx_mgmt_beacon() basically. Probably better to just skip
this entirely and handle s1g beacons separately.
> if (link_sta) {
> sta = link_sta->sta;
> link_id = link_sta->link_id;
> } else {
> struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
>
> - sta = sta_info_get_bss(rx->sdata, hdr->addr2);
> + sta = sta_info_get_bss(rx->sdata, sta_addr);
> if (status->link_valid) {
> link_id = status->link_id;
> } else if (ieee80211_vif_is_mld(&rx->sdata->vif) &&
> @@ -5347,6 +5364,12 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
> return;
> }
>
> + if (ieee80211_is_s1g_beacon(fc) &&
> + !pskb_may_pull(skb, ieee80211_s1g_beacon_min_len(fc))) {
> + dev_kfree_skb(skb);
> + return;
> + }
I'm fairly certain this still leaves things (e.g.
ieee80211_rx_mgmt_beacon()) wrong if the driver ever reports an s1g
beacon as a frag skb.
I think much better to just treat this frame like mgmt frames and
linearize it earlier in the function along with mgmt frames etc. Still
need to check the length, but we could even do that there as well,
rather than this late.
johannes
^ permalink raw reply
* Re: [stable request] mt7921e: backport two mt76 fixes to 6.12.y
From: Ajrat Makhmutov @ 2026-06-11 10:38 UTC (permalink / raw)
To: Sasha Levin, stable
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, linux-wireless
In-Reply-To: <20260610-stable-reply-0014@kernel.org>
Hi Sasha,
> I'm going to hold off on this one. The second commit, 5ed54896b6bd,
> introduces a reachable dev->mutex self-deadlock on STA-remove-while-ROC;
> the follow-up that cures it (d5059e52) isn't in any stable tree and was
> never marked for stable (it's only in linux-next so far).
Thanks, and good catch.
I'll resend the request for all three together as soon as it lands in
Linus' tree.
Note for whenever it does: when applied to 6.12.y, d5059e52 needs one
trivial
change - keep del_timer_sync() instead of timer_delete_sync(), as the timer
API rename is not present in 6.12.y.
Thanks,
Ajrat
^ permalink raw reply
* Re: [PATCH v12 10/22] wifi: nxpwifi: implement cfg80211 ops for STA and AP modes
From: Jeff Chen @ 2026-06-11 9:43 UTC (permalink / raw)
To: Rafael Beims
Cc: linux-wireless, linux-kernel, briannorris, johannes, francesco,
wyatt.hsu, s.hauer, ulf.hansson
In-Reply-To: <aimMeKc7yODvwNOT@burns.beims.me>
On Wed, Jun 10, 2026 at 01:10:32 PM -0300, Rafael Beims wrote:
> After a quick check, it seems that this patch contains the same
> problem being fixed here:
> https://lore.kernel.org/all/20260610150021.1018611-1-rafael@beims.me/
>
> Maybe it would be worth it to confirm and fix it before sending the pull request.
>
> Rafael
>
Hi Rafael,
Thanks for the analysis. I’ll incorporate this into nxpwifi as well.
Thanks,
Jeff
^ permalink raw reply
* Re:RE: [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
From: Wentao Guan @ 2026-06-11 9:11 UTC (permalink / raw)
To: Ping-Ke Shih (pkshih@realtek.com
Cc: linux-wireless@vger.kernel.org, linux-kernel,
dian_syuan0116 (dian_syuan0116@r, 占俊,
聂诚
In-Reply-To: <1017648a65ec4b139b76e2eb7583da26@realtek.com>
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> > Sent: Thursday, June 11, 2026 5:06 PM
> > To: Wentao Guan <guanwentao@uniontech.com>
> > Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; David Yang(楊典軒)
> > <dian_syuan0116@realtek.com>; zhanjun@uniontech.com; niecheng1@uniontech.com
> > Subject: RE: [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
> >
> > Wentao Guan <guanwentao@uniontech.com> wrote:
> > > BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1.
> > > These will cause h2c->w1 wrong overlap by w2 and w2 not initialized.
> >
> > Thanks for the catch.
> >
> > >
> > > Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D")
> > > Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
> >
> > Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> >
>
> To let subject clear, I'll change it to
> " wifi: rtw89: fw: correct preload field of w2 in rtw89_fw_h2c_default_cmac_tbl_be() "
OK, thanks for you review.
BRs
Wentao Guan
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
From: Ping-Ke Shih @ 2026-06-11 9:08 UTC (permalink / raw)
To: Ping-Ke Shih, Wentao Guan
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
David Yang(楊典軒), zhanjun@uniontech.com,
niecheng1@uniontech.com
In-Reply-To: <60dbac65771f46ae85efb922dd9f319e@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> Sent: Thursday, June 11, 2026 5:06 PM
> To: Wentao Guan <guanwentao@uniontech.com>
> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; David Yang(楊典軒)
> <dian_syuan0116@realtek.com>; zhanjun@uniontech.com; niecheng1@uniontech.com
> Subject: RE: [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
>
> Wentao Guan <guanwentao@uniontech.com> wrote:
> > BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1.
> > These will cause h2c->w1 wrong overlap by w2 and w2 not initialized.
>
> Thanks for the catch.
>
> >
> > Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D")
> > Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>
To let subject clear, I'll change it to
" wifi: rtw89: fw: correct preload field of w2 in rtw89_fw_h2c_default_cmac_tbl_be() "
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
From: Ping-Ke Shih @ 2026-06-11 9:05 UTC (permalink / raw)
To: Wentao Guan
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
David Yang(楊典軒), zhanjun@uniontech.com,
niecheng1@uniontech.com
In-Reply-To: <20260611082021.46650-1-guanwentao@uniontech.com>
Wentao Guan <guanwentao@uniontech.com> wrote:
> BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1.
> These will cause h2c->w1 wrong overlap by w2 and w2 not initialized.
Thanks for the catch.
>
> Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D")
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* Re: [PATCH] wifi: mwifiex: fix roaming to different channel in host_mlme mode
From: Francesco Dolcini @ 2026-06-11 8:53 UTC (permalink / raw)
To: Rafael Beims
Cc: Brian Norris, Francesco Dolcini, Rafael Beims, linux-wireless,
linux-kernel, Jeff Chen, stable
In-Reply-To: <20260610150021.1018611-1-rafael@beims.me>
On Wed, Jun 10, 2026 at 12:00:18PM -0300, Rafael Beims wrote:
> From: Rafael Beims <rafael.beims@toradex.com>
>
> When host MLME is enabled, mwifiex_cfg80211_authenticate() transmits the
> authentication frame on a remain-on-channel (ROC) reservation so that the
> frame is sent on the target BSS's channel. The ROC is only configured
> when priv->auth_flag is zero.
...
>
> Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Rafael Beims <rafael.beims@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
^ permalink raw reply
* [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
From: Nicolas Escande @ 2026-06-11 8:44 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
realated features on the 5GHz band while it should not:
Wiphy phy1
[...]
Band 2:
[...]
EHT Iftypes: managed
[...]
EHT PHY Capabilities: (0xe2ffdbe018778000):
320MHz in 6GHz Supported
[...]
Beamformee SS (320MHz): 7
[...]
Number Of Sounding Dimensions (320MHz): 3
[...]
EHT MCS/NSS: (0x22222222222222222200000000):
This is also reflected in the beacons sent by a mesh interface started on
that band. They erroneously advertise 320MHZ support too.
This should not happen as the spec at section 9.4.2.323.3 says we should
not set the 320MHz related fields when not operating on a 6GHz band.
For example it says about Bit 0 "Support For 320 MHz In 6 GHz"
"Reserved if the EHT Capabilities element is indicating capabilities for
the 2.4 GHz or 5 GHz bands."
Fix this by clearing the related bits when converting from WMI eht phy
capabilities to mac80211 phy capabilities, for bands other than 6GHz.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
Changes from v1:
- rebased on ath-next
- clear all 6GHz / 320MHz related phy capabilities fields from the firmware
---
drivers/net/wireless/ath/ath12k/wmi.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 84a31b953db8..a8a4654c4f34 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -5154,6 +5154,7 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
__le32 cap_info_internal)
{
struct ath12k_band_cap *cap_band = &pdev->cap.band[band];
+ u8 *phy_cap = (u8 *)&cap_band->eht_cap_phy_info[0];
u32 support_320mhz;
u8 i;
@@ -5167,8 +5168,22 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
for (i = 0; i < WMI_MAX_EHTCAP_PHY_SIZE; i++)
cap_band->eht_cap_phy_info[i] = le32_to_cpu(cap_phy_info[i]);
- if (band == NL80211_BAND_6GHZ)
+ if (band == NL80211_BAND_6GHZ) {
cap_band->eht_cap_phy_info[0] |= support_320mhz;
+ } else {
+ /*
+ * It seems the firmware can report capabilities specific to
+ * 6GHz also for 5GHz, so lets explicitely clear them out.
+ */
+ phy_cap[0] &= ~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+ phy_cap[1] &= ~IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK;
+ phy_cap[2] &= ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
+ phy_cap[3] &= ~IEEE80211_EHT_PHY_CAP3_SOUNDING_DIM_320MHZ_MASK;
+ phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
+ phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_EHT_DUP_6GHZ_SUPP;
+ phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ;
+ phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ; ;
+ }
cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);
--
2.54.0
^ permalink raw reply related
* [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
From: Wentao Guan @ 2026-06-11 8:20 UTC (permalink / raw)
To: pkshih
Cc: linux-wireless, linux-kernel, dian_syuan0116, zhanjun, niecheng1,
Wentao Guan
BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1.
These will cause h2c->w1 wrong overlap by w2 and w2 not initialized.
Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D")
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
drivers/net/wireless/realtek/rtw89/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index 17704f054727a..af9bcdcef8fbb 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -3711,7 +3711,7 @@ int rtw89_fw_h2c_default_cmac_tbl_be(struct rtw89_dev *rtwdev,
le32_encode_bits(4, BE_CCTL_INFO_W1_RTS_RTY_LOWEST_RATE);
h2c->m1 = cpu_to_le32(BE_CCTL_INFO_W1_ALL);
- h2c->w1 = le32_encode_bits(preld, BE_CCTL_INFO_W2_PRELOAD_ENABLE);
+ h2c->w2 = le32_encode_bits(preld, BE_CCTL_INFO_W2_PRELOAD_ENABLE);
h2c->m2 = cpu_to_le32(BE_CCTL_INFO_W2_ALL);
h2c->m3 = cpu_to_le32(BE_CCTL_INFO_W3_ALL);
--
2.30.2
^ 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