* [PATCH v2] wifi: rtw89: regd: stop gating 6GHz on the ww domain
From: Matthew Leach @ 2026-06-26 11:19 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: linux-wireless, linux-kernel, kernel, Zong-Zhe Yang,
Matthew Leach
The driver maintains its own block_* bitmaps on top of cfg80211's
regulatory enforcement. These bitmaps are indexed by the position of an
entry in the active regd_map (either the built-in rtw89_regd_map or the
table loaded from a firmware element).
The ww domain is handled outside the regd_map; it lives in a standalone
rtw89_ww_regd object, and rtw89_regd_get_index() returns the
RTW89_REGD_MAX_COUNTRY_NUM sentinel for it. Every block_* lookup site
guards against that sentinel and bails out, which means none of the
block_* checks ever apply to ww. The 6GHz check therefore treats ww as
unconditionally blocked at the driver layer, independently of whatever
cfg80211/wireless-regdb permit.
Make ww a first-class entry in the regd_map instead:
- Reserve slot 0 of rtw89_regd_map for the ww entry and drop the
standalone rtw89_ww_regd object.
- In rtw89_recognize_regd_from_elm(), reserve slot 0 of the
firmware-loaded map for ww and populate it from the built-in
definition via the new rtw89_regd_static_ww_entry() helper.
- Drop the rtw89_regd_is_ww() special case in rtw89_regd_get_index()
and identify ww by alpha2 so the check works for entries in either
map.
- Have rtw89_regd_find_reg_by_name() return NULL on miss instead of
silently substituting ww. Callers that need the previous "fall back
to ww" behaviour (rtw89_regd_notifier_apply()) now do so explicitly
against the active map's slot 0, and rtw89_regd_get_index_by_name()
translates NULL into the RTW89_REGD_MAX_COUNTRY_NUM sentinel so the
existing "unknown alpha2" branches in the block_* setup paths
remain.
With ww at a real index the driver's block_* checks apply uniformly for
all bands and cfg80211 / wireless-regdb become the sole source of truth
for what is permitted on the ww domain.
Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
---
Changes in v2:
- Re-word the commit message, clarifying the motivation behind the
patch (removing the explicit 6GHz disablement).
- Re-work the patch to play nicely with firmware loaded regulatory
tables by reserving slot 0 in both static and firmware regulatory lists
for the WW domain.
- Link to v1: https://patch.msgid.link/20260617-rtw89-6ghz-regd-fixes-v1-1-33d744a07d16@collabora.com
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: linux-wireless@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/wireless/realtek/rtw89/core.h | 1 +
drivers/net/wireless/realtek/rtw89/fw.c | 6 ++++--
drivers/net/wireless/realtek/rtw89/regd.c | 32 +++++++++++++++++++++----------
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index fd29dbbb120d..dc9eae2cee69 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -7862,6 +7862,7 @@ void rtw89_chip_cfg_txpwr_ul_tb_offset(struct rtw89_dev *rtwdev,
bool rtw89_legacy_rate_to_bitrate(struct rtw89_dev *rtwdev, u8 legacy_rate, u16 *bitrate);
int rtw89_regd_setup(struct rtw89_dev *rtwdev);
int rtw89_regd_init_hint(struct rtw89_dev *rtwdev);
+const struct rtw89_regd *rtw89_regd_static_ww_entry(void);
const char *rtw89_regd_get_string(enum rtw89_regulation_type regd);
void rtw89_traffic_stats_init(struct rtw89_dev *rtwdev,
struct rtw89_traffic_stats *stats);
diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index 17704f054727..77f320cae01b 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -1347,10 +1347,11 @@ int rtw89_recognize_regd_from_elm(struct rtw89_dev *rtwdev,
{
const struct __rtw89_fw_regd_element *regd_elm = &elm->u.regd;
struct rtw89_fw_elm_info *elm_info = &rtwdev->fw.elm_info;
- u32 num_ents = le32_to_cpu(regd_elm->num_ents);
struct rtw89_regd_data *p;
struct rtw89_regd regd;
- u32 i = 0;
+ /* +1 because we reserve index 0 for WW */
+ u32 num_ents = le32_to_cpu(regd_elm->num_ents) + 1;
+ u32 i = 1;
if (num_ents > RTW89_REGD_MAX_COUNTRY_NUM) {
rtw89_warn(rtwdev,
@@ -1373,6 +1374,7 @@ int rtw89_recognize_regd_from_elm(struct rtw89_dev *rtwdev,
return -ENOMEM;
p->nr = num_ents;
+ p->map[0] = *rtw89_regd_static_ww_entry();
rtw89_for_each_in_regd_element(®d, regd_elm)
p->map[i++] = regd;
diff --git a/drivers/net/wireless/realtek/rtw89/regd.c b/drivers/net/wireless/realtek/rtw89/regd.c
index 28466cb35ea2..27ac87374e6e 100644
--- a/drivers/net/wireless/realtek/rtw89/regd.c
+++ b/drivers/net/wireless/realtek/rtw89/regd.c
@@ -21,10 +21,8 @@ void rtw89_regd_notifier(struct wiphy *wiphy, struct regulatory_request *request
static_assert(BITS_PER_TYPE(unsigned long) >= NUM_OF_RTW89_REGD_FUNC);
-static const struct rtw89_regd rtw89_ww_regd =
- COUNTRY_REGD("00", RTW89_WW, RTW89_WW, RTW89_WW, 0x0);
-
static const struct rtw89_regd rtw89_regd_map[] = {
+ COUNTRY_REGD("00", RTW89_WW, RTW89_WW, RTW89_WW, 0x0),
COUNTRY_REGD("AR", RTW89_MEXICO, RTW89_MEXICO, RTW89_FCC, 0x0),
COUNTRY_REGD("BO", RTW89_FCC, RTW89_FCC, RTW89_NA, 0x0),
COUNTRY_REGD("BR", RTW89_FCC, RTW89_FCC, RTW89_FCC, 0x0),
@@ -316,12 +314,12 @@ static const struct rtw89_regd *rtw89_regd_find_reg_by_name(struct rtw89_dev *rt
return ®d_ctrl->map[i];
}
- return &rtw89_ww_regd;
+ return NULL;
}
static bool rtw89_regd_is_ww(const struct rtw89_regd *regd)
{
- return regd == &rtw89_ww_regd;
+ return !memcmp(regd->alpha2, "00", 2);
}
static u8 rtw89_regd_get_index(struct rtw89_dev *rtwdev, const struct rtw89_regd *regd)
@@ -331,9 +329,6 @@ static u8 rtw89_regd_get_index(struct rtw89_dev *rtwdev, const struct rtw89_regd
BUILD_BUG_ON(ARRAY_SIZE(rtw89_regd_map) > RTW89_REGD_MAX_COUNTRY_NUM);
- if (rtw89_regd_is_ww(regd))
- return RTW89_REGD_MAX_COUNTRY_NUM;
-
return regd - regd_ctrl->map;
}
@@ -342,6 +337,10 @@ static u8 rtw89_regd_get_index_by_name(struct rtw89_dev *rtwdev, const char *alp
const struct rtw89_regd *regd;
regd = rtw89_regd_find_reg_by_name(rtwdev, alpha2);
+
+ if (!regd)
+ return RTW89_REGD_MAX_COUNTRY_NUM;
+
return rtw89_regd_get_index(rtwdev, regd);
}
@@ -721,7 +720,7 @@ int rtw89_regd_init_hint(struct rtw89_dev *rtwdev)
return -EINVAL;
chip_regd = rtw89_regd_find_reg_by_name(rtwdev, rtwdev->efuse.country_code);
- if (!rtw89_regd_is_ww(chip_regd)) {
+ if (chip_regd && !rtw89_regd_is_ww(chip_regd)) {
rtwdev->regulatory.regd = chip_regd;
rtwdev->regulatory.programmed = true;
@@ -743,6 +742,11 @@ int rtw89_regd_init_hint(struct rtw89_dev *rtwdev)
return 0;
}
+const struct rtw89_regd *rtw89_regd_static_ww_entry(void)
+{
+ return &rtw89_regd_map[0];
+}
+
static void rtw89_regd_apply_policy_unii4(struct rtw89_dev *rtwdev,
struct wiphy *wiphy)
{
@@ -859,7 +863,15 @@ static void rtw89_regd_notifier_apply(struct rtw89_dev *rtwdev,
struct wiphy *wiphy,
struct regulatory_request *request)
{
- rtwdev->regulatory.regd = rtw89_regd_find_reg_by_name(rtwdev, request->alpha2);
+ const struct rtw89_regd *regd = rtw89_regd_find_reg_by_name(rtwdev, request->alpha2);
+
+ if (!regd) {
+ /* Fallback to WW domain if name not found. */
+ regd = &rtwdev->regulatory.ctrl.map[0];
+ }
+
+ rtwdev->regulatory.regd = regd;
+
/* This notification might be set from the system of distros,
* and it does not expect the regulatory will be modified by
* connecting to an AP (i.e. country ie).
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260616-rtw89-6ghz-regd-fixes-d8f816880bd0
Best regards,
--
Matt
^ permalink raw reply related
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: Krzysztof Kozlowski @ 2026-06-26 11:16 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <SN7PR19MB67364ADE8CDD7C31297AE18D9DEB2@SN7PR19MB6736.namprd19.prod.outlook.com>
On 26/06/2026 12:51, George Moussalem wrote:
>>
>> No supplies? no address space? How do you actually trigger remoteproc
>> startup?
>
> No supplied and no address space. The core is booted by a
> qcom_scm_auth_and_reset call to TrustZone which authenticated the
> firmware, takes it out of reset and boots it.
Then commit msg could be improved:
"Firmware loaded is authenticated via TrustZone." ->
"Firmware is loaded and authenticated via TrustZone."
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH wireless] wifi: mac80211_hwsim: avoid division by zero in mac80211_hwsim_write_tsf()
From: Serhat Kumral @ 2026-06-25 21:56 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: Benjamin Berg, Miri Korenblit, linux-kernel,
syzbot+21629c14aa749636db9d, Serhat Kumral
mac80211_hwsim_write_tsf() adjusts the timestamp of beacon, probe
response and S1G beacon frames by dividing a constant by the legacy
bitrate of the selected tx rate, e.g.:
mgmt->u.probe_resp.timestamp =
cpu_to_le64(sim_time + data->tsf_offset +
24 * 8 * 10 / bitrate);
bitrate is taken from ieee80211_get_tx_rate(), which indexes the band's
legacy bitrates[] table by control.rates[0].idx without checking the
HT/VHT/S1G MCS flags or the table bounds. For an MCS rate the idx is not
a legacy-rate index, so the returned rate can have a bitrate of 0. The
code only guarded against a NULL rate, not a zero bitrate, so the
division can divide by zero. As the call trace shows, this is reachable
from user space by injecting a frame on a monitor interface:
divide error: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:mac80211_hwsim_write_tsf+0x3a3/0x590
Call Trace:
mac80211_hwsim_tx_frame_no_nl+0x16b/0x1760
mac80211_hwsim_tx+0x1784/0x2500
ieee80211_tx_frags+0x3df/0x890
ieee80211_monitor_start_xmit+0xb33/0x1280
__dev_queue_xmit+0x1435/0x37f0
packet_sendmsg+0x3d95/0x5040
Fixing this in ieee80211_get_tx_rate() is not viable: callers such as
ath5k and adm8211 dereference its return value without a NULL check, so
making it return NULL for MCS rates would only move the crash elsewhere.
Keep the fix local and fall back to the existing default of 100 whenever
the reported bitrate is zero, in line with the existing "/* TODO: get
MCS */" note above.
Fixes: e75129031f1c ("wifi: mac80211_hwsim: move timestamp writing later in the datapath")
Reported-by: syzbot+21629c14aa749636db9d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=21629c14aa749636db9d
Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
---
drivers/net/wireless/virtual/mac80211_hwsim_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim_main.c b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
index 0dd8a6c85953..c745395d2042 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim_main.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
@@ -1604,7 +1604,7 @@ static void mac80211_hwsim_write_tsf(struct mac80211_hwsim_data *data,
spin_lock_bh(&data->tsf_offset_lock);
txrate = ieee80211_get_tx_rate(data->hw, info);
- if (txrate)
+ if (txrate && txrate->bitrate)
bitrate = txrate->bitrate;
if (skb->len >= offsetofend(typeof(*mgmt), u.probe_resp.timestamp) &&
--
2.54.0
^ permalink raw reply related
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-06-26 11:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <87echtk24a.ffs@fw13>
On Fri, Jun 26, 2026 at 12:49:41PM +0200, Thomas Gleixner wrote:
> On Fri, Jun 26 2026 at 10:48, Thomas Weißschuh wrote:
> > On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
> > (...)
> >
> >> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
> >> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
> >> tkd = &tk_core;
> >> offs = &tk_core.timekeeper.offs_boot;
> >> break;
> >> + case CLOCK_AUX ... CLOCK_AUX_LAST:
> >> + tkd = aux_get_tk_data(clock_id);
> >> + if (!tkd)
> >> + return false;
> >> + offs = &tkd->timekeeper.offs_aux;
> >> + break;
> >
> > 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> > are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
>
> AUX clocks are independent in the first place and the MONORAW part is
> the "MONORAW" related to the AUX clock itself.
>
> > Instead 'monoraw' should be computed based on 'tk_core'.
> > Which then also requires the sequence locking of 'tk_core'.
>
> No. From a PTP and steering point of view you want the "raw" value which
> is related to the AUX clock itself and not the global one.
Ack.
However the kdocs call it 'CLOCK_MONOTONIC_RAW'. Can we clean this up?
> The global MONORAW and the AUX clock MONORAW are related obviously as
> they share the same conversion factors.
>
> MONORAW(AUX$N) = MONORAW(GLOBAL) + OFFSET(AUX$N)
>
> We don't have that information anywhere right now and we might want to
> expose it to allow user space a proper correlation, but that's an
> orthogonal problem.
>
> From a PTP/steering point of view the code is correct as is.
Thanks for the clarifications.
Thomas
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Krzysztof Kozlowski @ 2026-06-26 10:53 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-4-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
> Document the Qualcomm IPQ5018 Bluetooth controller.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/net/bluetooth/qcom,ipq5018-bt.yaml | 63 ++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> new file mode 100644
> index 000000000000..afd33f851858
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/bluetooth/qcom,ipq5018-bt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm IPQ5018 Bluetooth
> +
> +maintainers:
> + - George Moussalem <george.moussalem@outlook.com>
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-bt
> +
> + interrupts:
> + items:
> + - description:
> + Interrupt line from the M0 Bluetooth Subsystem to the host processor
What is M0?
Anyway, this part feels completely redundant. Can "interrupts" property
be anything else than an interrupt line from the device to the host
processor?
> + to notify it of events such as re
This feels useful, but cut/incomplete.
> +
> + qcom,ipc:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to a syscon node representing the APCS registers
> + - description: u32 representing offset to the register within the syscon
> + - description: u32 representing the ipc bit within the register
> + description: |
> + These entries specify the outgoing IPC bit used for signaling the remote
> + M0 BTSS core of a host event or for sending an ACK if the remote processor
> + expects it.
> +
> + qcom,rproc:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to the remote processor node representing the M0 BTSS core.
> +
> +required:
> + - compatible
> + - interrupts
> + - qcom,ipc
> + - qcom,rproc
> +
> +allOf:
> + - $ref: bluetooth-controller.yaml#
> + - $ref: qcom,bluetooth-common.yaml
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + bluetooth: bluetooth {
Drop unused label
> + compatible = "qcom,ipq5018-bt";
> +
> + qcom,ipc = <&apcs_glb 8 23>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
No firmware to load?
It feels like remoteproc node split is fake. The property qcom,rproc is
even more supporting that case. Shouldn't this be simply one device -
bluetooth? What sort of two devices do you have exactly? How can I
identify them in the hardware?
> +
> + qcom,rproc = <&m0_btss>;
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: George Moussalem @ 2026-06-26 10:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260626-tiny-warm-jerboa-3ba57a@quoll>
Hi Krzysztof,
On 6/26/26 14:47, Krzysztof Kozlowski wrote:
> On Thu, Jun 25, 2026 at 06:10:05PM +0400, George Moussalem wrote:
>> Document the M0 Bluetooth Subsystem remote processor core found in the
>> Qualcomm IPQ5018 SoC. Firmware loaded is authenticated via TrustZone.
>> The firmware running on the M0 core provides bluetooth functionality.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>> .../bindings/remoteproc/qcom,m0-btss-pil.yaml | 72 ++++++++++++++++++++++
>> 1 file changed, 72 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
>> new file mode 100644
>> index 000000000000..397bb6815d71
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
>
> Use compatible as filename.
understood, will update in v2.
>
>> @@ -0,0 +1,72 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/qcom,m0-btss-pil.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm M0 BTSS Peripheral Image Loader
>> +
>> +maintainers:
>> + - George Moussalem <george.moussalem@outlook.com>
>> +
>> +description:
>> + Qualcomm M0 BTSS Peripheral Secure Image Loader loads firmware and powers up
>> + the M0 BTSS remote processor core on the Qualcomm IPQ5018 SoC.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,ipq5018-btss-pil
>> +
>> + firmware-name:
>> + maxItems: 1
>> + description: Firmware name for the M0 Bluetooth Subsystem core
>
> You can drop description, pretty obvious.
will drop
>
>> +
>> + clocks:
>> + items:
>> + - description: M0 BTSS low power oscillator clock
>> +
>> + clock-names:
>> + items:
>> + - const: btss_lpo_clk
>
> Just "lpo"
will update
>
>> +
>> + memory-region:
>> + items:
>> + - description: M0 BTSS reserved memory carveout
>> +
>> + resets:
>> + items:
>> + - description: M0 BTSS reset
>> +
>> + reset-names:
>> + items:
>> + - const: btss_reset
>
> Drop names. Using block name as input name is not really useful.
Will drop
>
> No supplies? no address space? How do you actually trigger remoteproc
> startup?
No supplied and no address space. The core is booted by a
qcom_scm_auth_and_reset call to TrustZone which authenticated the
firmware, takes it out of reset and boots it.
>
>> +
>> +required:
>> + - compatible
>> + - firmware-name
>> + - clocks
>> + - clock-names
>> + - resets
>> + - reset-names
>> + - memory-region
>> +
>> +additionalProperties: false
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: David Woodhouse @ 2026-06-26 10:51 UTC (permalink / raw)
To: Thomas Weißschuh, Thomas Gleixner
Cc: LKML, Miroslav Lichvar, John Stultz, Stephen Boyd,
Anna-Maria Behnsen, Frederic Weisbecker, Arthur Kiyanovski,
Rodolfo Giometti, Vincent Donnefort, Marc Zyngier, Oliver Upton,
kvmarm, Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Peter Hilber, Michael S. Tsirkin, virtualization,
linux-wireless, linux-sound
In-Reply-To: <20260626103359-66ab2b54-d36f-416b-94a4-3f3708dccced@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]
On Fri, 2026-06-26 at 10:48 +0200, Thomas Weißschuh wrote:
> 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
> Instead 'monoraw' should be computed based on 'tk_core'.
> Which then also requires the sequence locking of 'tk_core'.
>
> As you know I have a series which unifies the locking between the
> different timekeepers. Maybe we revert this patch for 7.2 and I send
> a fixed variant including the prerequisites for 7.3.
>
> (The same goes for get_device_system_crosststamp())
No fundamental objection from me... but does it matter in practice?
Is it even reachable?
I think the only way these functions can end up being invoked for aux
clocks is via PTP_SYS_OFFSET_EXTENDED, which since commit a6d799608e6
("ptp: Switch to ktime_get_snapshot_id() for pre/post timestamps") and
some other driver-specific changes in this series, can now invoke them
with the user-requested clockid.
But those callers *only* care about ::systime, don't they? So the
problem never arises because there's no code path in which anything
actually cares about ::monoraw for AUX clocks.
If we back out the handling of AUX clocks in ktime_get_snapshot_id()
we'd have to roll back much of that other plumbing too. If we *just*
remove the 'case CLOCK_AUX ... CLOCK_AUX_LAST' hunk, we'd end up with
users being able to trigger the 'default: WARN_ON_ONCE(1)' which
follows.
So while you're right, I *think* it's harmless in practice and
reverting it safely is slightly more complex than it seems at first
glance?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Gleixner @ 2026-06-26 10:49 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260626103359-66ab2b54-d36f-416b-94a4-3f3708dccced@linutronix.de>
On Fri, Jun 26 2026 at 10:48, Thomas Weißschuh wrote:
> On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
> (...)
>
>> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
>> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
>> tkd = &tk_core;
>> offs = &tk_core.timekeeper.offs_boot;
>> break;
>> + case CLOCK_AUX ... CLOCK_AUX_LAST:
>> + tkd = aux_get_tk_data(clock_id);
>> + if (!tkd)
>> + return false;
>> + offs = &tkd->timekeeper.offs_aux;
>> + break;
>
> 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
AUX clocks are independent in the first place and the MONORAW part is
the "MONORAW" related to the AUX clock itself.
> Instead 'monoraw' should be computed based on 'tk_core'.
> Which then also requires the sequence locking of 'tk_core'.
No. From a PTP and steering point of view you want the "raw" value which
is related to the AUX clock itself and not the global one.
The global MONORAW and the AUX clock MONORAW are related obviously as
they share the same conversion factors.
MONORAW(AUX$N) = MONORAW(GLOBAL) + OFFSET(AUX$N)
We don't have that information anywhere right now and we might want to
expose it to allow user space a proper correlation, but that's an
orthogonal problem.
From a PTP/steering point of view the code is correct as is.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: Krzysztof Kozlowski @ 2026-06-26 10:47 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-1-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:05PM +0400, George Moussalem wrote:
> Document the M0 Bluetooth Subsystem remote processor core found in the
> Qualcomm IPQ5018 SoC. Firmware loaded is authenticated via TrustZone.
> The firmware running on the M0 core provides bluetooth functionality.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/remoteproc/qcom,m0-btss-pil.yaml | 72 ++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
> new file mode 100644
> index 000000000000..397bb6815d71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
Use compatible as filename.
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/qcom,m0-btss-pil.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm M0 BTSS Peripheral Image Loader
> +
> +maintainers:
> + - George Moussalem <george.moussalem@outlook.com>
> +
> +description:
> + Qualcomm M0 BTSS Peripheral Secure Image Loader loads firmware and powers up
> + the M0 BTSS remote processor core on the Qualcomm IPQ5018 SoC.
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-btss-pil
> +
> + firmware-name:
> + maxItems: 1
> + description: Firmware name for the M0 Bluetooth Subsystem core
You can drop description, pretty obvious.
> +
> + clocks:
> + items:
> + - description: M0 BTSS low power oscillator clock
> +
> + clock-names:
> + items:
> + - const: btss_lpo_clk
Just "lpo"
> +
> + memory-region:
> + items:
> + - description: M0 BTSS reserved memory carveout
> +
> + resets:
> + items:
> + - description: M0 BTSS reset
> +
> + reset-names:
> + items:
> + - const: btss_reset
Drop names. Using block name as input name is not really useful.
No supplies? no address space? How do you actually trigger remoteproc
startup?
> +
> +required:
> + - compatible
> + - firmware-name
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> + - memory-region
> +
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH rtw-next v3 3/3] wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
From: William Hansen-Baird @ 2026-06-26 9:56 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260626095648.1124924-1-william.hansen.baird@gmail.com>
RTL8723BE outputs a large amount of PCIe AER errors during and
after boot, even before probe and when driver is never loaded.
This causes significant system slowdown.
The errors are the same as reported by
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
Add the RTL8723BE with subsystem ID 17aa:b736 to the rtl_aspm_quirks
table to stop the AER errors. AER errors can still be present prior to
pci probe, as the device by default may have ASPM enabled.
Testing on a Razer Blade 14 2017 which shipped from the
OEM equipped with an RTL8723BE card with this subsystem ID
confirms that this patch resolves the AER flood and allows the
wireless card to function normally once the driver takes over.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 44121203671c..b5611c5a2cd5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -34,6 +34,8 @@ static const u8 ac_to_hwq[] = {
static const struct pci_device_id rtl_aspm_quirks[] = {
/* ASUSTek F441U/X555UQ */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
+ /* Razer Blade 14 2017 */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x17aa, 0xb736) },
{ }
};
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v3 2/3] wifi: rtlwifi: convert pci if-statement to ID table
From: William Hansen-Baird @ 2026-06-26 9:56 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260626095648.1124924-1-william.hansen.baird@gmail.com>
Refactor the ASUSTek quirk logic from an if-statement to a standard
rtl_aspm_quirks pci_device_id table. This allows future devices with
the same quirk to be added more easily while avoiding a large if-chain.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 38eca8d91581..44121203671c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -31,6 +31,12 @@ static const u8 ac_to_hwq[] = {
BK_QUEUE
};
+static const struct pci_device_id rtl_aspm_quirks[] = {
+ /* ASUSTek F441U/X555UQ */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
+ { }
+};
+
static u8 _rtl_mac_to_hwqueue(struct ieee80211_hw *hw, struct sk_buff *skb)
{
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
@@ -330,19 +336,15 @@ static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
{
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
- struct rtl_priv *rtlpriv = rtl_priv(hw);
_rtl_pci_update_default_setting(hw);
/*
- * RTL8723BE found on some ASUSTek laptops, such as F441U and
- * X555UQ with subsystem ID 11ad:1723 are known to output large
+ * Certain pci devices are known to output large
* amounts of PCIe AER errors during and after boot up, causing
* heavy lags, poor network throughput, and occasional lock-ups.
*/
- if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
- (rtlpci->pdev->subsystem_vendor == 0x11ad &&
- rtlpci->pdev->subsystem_device == 0x1723)) {
+ if (pci_match_id(rtl_aspm_quirks, rtlpci->pdev)) {
__rtl_pci_disable_aspm(hw);
ppsc->support_aspm = false;
}
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v3 1/3] wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
From: William Hansen-Baird @ 2026-06-26 9:56 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260626095648.1124924-1-william.hansen.baird@gmail.com>
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
adds code which sets ppsc->support_aspm to false in
_rtl_pci_update_default_setting() in order to disable ASPM.
This does not, however, disable ASPM. Rather, it disables driver
control of ASPM, and blocks calls to rtl_pci_enable_aspm()
and rtl_pci_disable_aspm().
In some cases, the pci device supplied to the probe function has
ASPM enabled. The code would therefore not disable ASPM, as it means to,
but rather just leave it enabled.
This was discovered through testing on a Razer Blade 14 2017.
Implement a new __rtl_pci_disable_aspm(hw) function which does not check
ppsc->support_aspm before disabling and call it from
rtl_pci_disable_aspm().
Then move the code added in the previous commit to rtl_pci_init_aspm() to
allow adding a call to __rtl_pci_disable_aspm(hw).
This makes sure ASPM is disabled while still disabling
driver control of ASPM to block it from being enabled later.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 39 ++++++++++++++--------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 73018a0498b4..38eca8d91581 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -156,15 +156,6 @@ static void _rtl_pci_update_default_setting(struct ieee80211_hw *hw)
PCI_EXP_LNKCTL_ASPM_L1 | PCI_EXP_LNKCTL_CCC))
ppsc->support_aspm = false;
- /* RTL8723BE found on some ASUSTek laptops, such as F441U and
- * X555UQ with subsystem ID 11ad:1723 are known to output large
- * amounts of PCIe AER errors during and after boot up, causing
- * heavy lags, poor network throughput, and occasional lock-ups.
- */
- if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
- (rtlpci->pdev->subsystem_vendor == 0x11ad &&
- rtlpci->pdev->subsystem_device == 0x1723))
- ppsc->support_aspm = false;
}
static bool _rtl_pci_platform_switch_device_pci_aspm(
@@ -203,7 +194,7 @@ static void _rtl_pci_switch_clk_req(struct ieee80211_hw *hw, u16 value)
}
/*Disable RTL8192SE ASPM & Disable Pci Bridge ASPM*/
-static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
+static void __rtl_pci_disable_aspm(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci_priv *pcipriv = rtl_pcipriv(hw);
@@ -215,9 +206,6 @@ static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
u16 aspmlevel = 0;
u16 tmp_u1b = 0;
- if (!ppsc->support_aspm)
- return;
-
if (pcibridge_vendor == PCI_BRIDGE_VENDOR_UNKNOWN) {
rtl_dbg(rtlpriv, COMP_POWER, DBG_TRACE,
"PCI(Bridge) UNKNOWN\n");
@@ -240,6 +228,16 @@ static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
_rtl_pci_platform_switch_device_pci_aspm(hw, linkctrl_reg);
}
+static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
+{
+ struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
+
+ if (!ppsc->support_aspm)
+ return;
+
+ __rtl_pci_disable_aspm(hw);
+}
+
/*Enable RTL8192SE ASPM & Enable Pci Bridge ASPM for
*power saving We should follow the sequence to enable
*RTL8192SE first then enable Pci Bridge ASPM
@@ -330,10 +328,25 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
{
+ struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
_rtl_pci_update_default_setting(hw);
+ /*
+ * RTL8723BE found on some ASUSTek laptops, such as F441U and
+ * X555UQ with subsystem ID 11ad:1723 are known to output large
+ * amounts of PCIe AER errors during and after boot up, causing
+ * heavy lags, poor network throughput, and occasional lock-ups.
+ */
+ if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
+ (rtlpci->pdev->subsystem_vendor == 0x11ad &&
+ rtlpci->pdev->subsystem_device == 0x1723)) {
+ __rtl_pci_disable_aspm(hw);
+ ppsc->support_aspm = false;
+ }
+
if (ppsc->reg_rfps_level & RT_RF_PS_LEVEL_ALWAYS_ASPM) {
/*Always enable ASPM & Clock Req. */
rtl_pci_enable_aspm(hw);
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v3 0/3] wifi: rtlwifi: fix ASPM AER flooding on RTL8723BE devices
From: William Hansen-Baird @ 2026-06-26 9:56 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
This series fixes AER error message flooding and system slowdown caused by
RTL8723BE with subsystem ID 17aa:b736. The flood is found to be caused
by ASPM, and disabling it stops the AER spam.
This flood of AER error messages for the RTL8723BE is not unique to
subsystem ID 17aa:b736.
Commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
targets the same issue for subsystem ID 11ad:1723.
The fix applied in that commit, however, does not correctly
disable ASPM. It merely disables driver control of ASPM.
Patch 1 fixes the previous commit such that it properly disables ASPM for
subsystem ID 11ad:1723.
Patch 2 converts the if-statement check of subsystem IDs to a
rtl_aspm_quirks pci_device_id table matched with pci_match_id()
such that future devices can easily be added if they have the same error.
Patch 3 adds the RTL8723BE with subsystem ID 17aa:b736 to the
rtl_aspm_quirks table to disable ASPM for it. Testing on a
Razer Blade 14 2017 showed this stops the AER error message flood and
wifi works as it should.
---
v3:
- Replace { 0 } with { } in rtl_pci_quirks table as recommended by Uwe
and requested by Ping-Ke
- Added comments to rtl_pci_quirks table describing what machine
correspond to the pci ids
- Replace net-specific comment style with wireless comment style
- Removed misleading Fixes tag from patch 1.
- Patch 3: carried forward Acked-by from v2
v2:
- Implement __rtl_pci_disable_aspm() in patch 1 which disables ASPM
without checking ppsc->support_aspm.
This is called both by rtl_pci_disable_aspm(), guarded by the original
check of ppsc->support_aspm, and the new quirk code.
- Rename rtl8723be_aspm_quirks to rtl_aspm_quirks and fill out system
vendor and device ID alongside subsystem vendor and device ID in the
rtl_aspm_quirks table such that we can use pci_match_id() alone
without the RTL8723BE check.
William Hansen-Baird (3):
wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
wifi: rtlwifi: convert pci if-statement to ID table
wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
drivers/net/wireless/realtek/rtlwifi/pci.c | 43 +++++++++++++++-------
1 file changed, 30 insertions(+), 13 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: mac80211: MLO link removal frees link RX stats percpu without RCU grace
From: Johannes Berg @ 2026-06-26 9:04 UTC (permalink / raw)
To: Maoyi Xie; +Cc: linux-wireless, linux-kernel
In-Reply-To: <20260626080158.3589711-1-maoyixie.tju@gmail.com>
Hi,
> I think there is a use after free on the MLO link removal path in
> net/mac80211/sta_info.c. The link RX stats percpu buffer is freed while a
> concurrent RX softirq can still write to it. I would appreciate it if you
> could take a look.
>
> sta_remove_link() frees the link stats and defers only the container:
>
> sta_info_free_link(&alloc->info);
> kfree_rcu(alloc, rcu_head);
>
> sta_info_free_link() does the free right away:
>
> free_percpu(link_sta->pcpu_rx_stats);
Funny, I was looking at this code just yesterday for other reasons.
> So the container waits for a grace period but the percpu stats are
> reclaimed at once. The RX fast path runs in softirq under rcu_read_lock
> only. It resolves link_sta early and writes the percpu stats later:
>
> stats = this_cpu_ptr(link_sta->pcpu_rx_stats);
> stats->last_signal = status->signal;
>
> A reader that resolved link_sta before the removal NULLed it keeps the
> pointer. The container is still alive from the kfree_rcu, so the read of
> link_sta->pcpu_rx_stats works. But the percpu block it points to is
> already freed. This needs uses_rss. That is when pcpu_rx_stats is
> allocated. The trigger is an MLO link removed over the air through a
> Multi-Link Reconfiguration element.
>
> The full STA teardown does this safely. __sta_info_destroy calls
> synchronize_net() before sta_info_free() frees the deflink stats. The MLO
> link removal path has no such barrier. That path was added in
> cb71f1d136a6 ("wifi: mac80211: add sta link addition/removal").
>
> I do not have WiFi 7 hardware. This is from reading the code. A small test
> that frees the stats buffer and writes it through the live container trips
> KASAN with a slab use after free.
>
> Does this look like a real use after free to you?
The above analysis doesn't look _incorrect_ to me, though I think
between uses_rss, sta_pre_rcu remove and how drivers tend to work
(though I can mostly speak for iwlwifi, and ath1[12]k also have RSS),
it's going to be pretty fairly difficult (if not impossible?) to hit in
practice.
The only (relevant, real RCU) reader is rx.c, which requires fast_rx too
(not all that relevant I think). During STA removal, both are removed
together and we always have to have both, so I think it's mostly OK.
When the driver passes the STA it could still be an issue though, I
think?
During link switch it could be more of an issue, but then it's MLO and
we require the driver to tell us where it's receiving, and it wouldn't
receive on a link that was just disabled, so I don't think you'll hit it
in practice here either.
> Is the right fix to
> defer the percpu free to RCU, like the container already is? I am happy to
> send a patch once you confirm.
I think it'd be better to combine them and free the link with data after
RCU, rather than bumping each to RCU separately?
johannes
^ permalink raw reply
* [PATCH ath-next v2 3/3] wifi: ath12k: Show per-radio center freq in dp stats
From: Sreeramya Soratkal @ 2026-06-26 8:52 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, sreeramya.soratkal
In-Reply-To: <20260626085253.3927269-1-sreeramya.soratkal@oss.qualcomm.com>
Currently, the frequency on which each radio is operating
is not available in device_dp_stats. This information is
helpful in debugging the channel-specific throughput and
is available with iw/nl80211 dump.
Extend the device_dp_stats dump to display the center
frequency in the existing per-radio loop.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sreeramya Soratkal <sreeramya.soratkal@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/debugfs.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/debugfs.c b/drivers/net/wireless/ath/ath12k/debugfs.c
index 57c213111259..d54995b7adb2 100644
--- a/drivers/net/wireless/ath/ath12k/debugfs.c
+++ b/drivers/net/wireless/ath/ath12k/debugfs.c
@@ -1031,6 +1031,7 @@ static ssize_t ath12k_debugfs_dump_device_dp_stats(struct file *file,
struct ath12k_device_dp_stats *device_stats = &dp->device_stats;
int len = 0, i, j, ret;
struct ath12k *ar;
+ u32 center_freq;
const int size = 4096;
static const char *rxdma_err[HAL_REO_ENTR_RING_RXDMA_ECODE_MAX] = {
[HAL_REO_ENTR_RING_RXDMA_ECODE_OVERFLOW_ERR] = "Overflow",
@@ -1164,6 +1165,12 @@ static ssize_t ath12k_debugfs_dump_device_dp_stats(struct file *file,
for (i = 0; i < ab->num_radios; i++) {
ar = ath12k_mac_get_ar_by_pdev_id(ab, DP_SW2HW_MACID(i));
if (ar) {
+ spin_lock_bh(&ar->data_lock);
+ center_freq = ar->rx_channel ? ar->rx_channel->center_freq : 0;
+ spin_unlock_bh(&ar->data_lock);
+ len += scnprintf(buf + len, size - len,
+ "\nradio%d center_freq: %u\n",
+ i, center_freq);
len += scnprintf(buf + len, size - len,
"\nradio%d tx_pending: %u\n", i,
atomic_read(&ar->dp.num_tx_pending));
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v2 2/3] wifi: ath12k: Add timestamp to dp stats display
From: Sreeramya Soratkal @ 2026-06-26 8:52 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, sreeramya.soratkal
In-Reply-To: <20260626085253.3927269-1-sreeramya.soratkal@oss.qualcomm.com>
In MLO configurations the device_dp_stats debugfs file is read
separately for each ath12k device. Without a timestamp it is impossible
to know whether two snapshots were taken at the same moment, making
counter comparisons across devices unreliable.
Prepend a ktime-based millisecond timestamp to the output header so the
reader can confirm when the snapshot was taken.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sreeramya Soratkal <sreeramya.soratkal@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/debugfs.c b/drivers/net/wireless/ath/ath12k/debugfs.c
index bab9d96d6acc..57c213111259 100644
--- a/drivers/net/wireless/ath/ath12k/debugfs.c
+++ b/drivers/net/wireless/ath/ath12k/debugfs.c
@@ -1082,6 +1082,9 @@ static ssize_t ath12k_debugfs_dump_device_dp_stats(struct file *file,
if (!buf)
return -ENOMEM;
+ len += scnprintf(buf + len, size - len,
+ "DEVICE DP STATS (timestamp: %lldms):\n\n",
+ ktime_to_ms(ktime_get()));
len += scnprintf(buf + len, size - len, "DEVICE RX STATS:\n\n");
len += scnprintf(buf + len, size - len, "err ring pkts: %u\n",
device_stats->err_ring_pkts);
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v2 1/3] wifi: ath12k: Use runtime device count in dp stats display
From: Sreeramya Soratkal @ 2026-06-26 8:52 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, sreeramya.soratkal
In-Reply-To: <20260626085253.3927269-1-sreeramya.soratkal@oss.qualcomm.com>
The REO Rx Received and Rx WBM REL SRC Errors display loops in
ath12k_debugfs_dump_device_dp_stats() iterate up to the compile-time
constant ATH12K_MAX_DEVICES. This unconditionally prints zeros
in columns with no hardware behind it, making the output misleading.
Replace the compile-time bound with the runtime ab->ag->num_devices so
only live device slots appear in the output.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sreeramya Soratkal <sreeramya.soratkal@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/debugfs.c b/drivers/net/wireless/ath/ath12k/debugfs.c
index d17d4a8f1cb7..bab9d96d6acc 100644
--- a/drivers/net/wireless/ath/ath12k/debugfs.c
+++ b/drivers/net/wireless/ath/ath12k/debugfs.c
@@ -1173,7 +1173,7 @@ static ssize_t ath12k_debugfs_dump_device_dp_stats(struct file *file,
for (i = 0; i < DP_REO_DST_RING_MAX; i++) {
len += scnprintf(buf + len, size - len, "Ring%d:", i + 1);
- for (j = 0; j < ATH12K_MAX_DEVICES; j++) {
+ for (j = 0; j < ab->ag->num_devices; j++) {
len += scnprintf(buf + len, size - len,
"\t%d:%u", j,
device_stats->reo_rx[i][j]);
@@ -1190,7 +1190,7 @@ static ssize_t ath12k_debugfs_dump_device_dp_stats(struct file *file,
for (i = 0; i < HAL_WBM_REL_SRC_MODULE_MAX; i++) {
len += scnprintf(buf + len, size - len, "%s:", wbm_rel_src[i]);
- for (j = 0; j < ATH12K_MAX_DEVICES; j++) {
+ for (j = 0; j < ab->ag->num_devices; j++) {
len += scnprintf(buf + len,
size - len,
"\t%d:%u", j,
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v2 0/3] wifi: ath12k: Improve dp stats
From: Sreeramya Soratkal @ 2026-06-26 8:52 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, sreeramya.soratkal
This short series improves the device_dp_stats debugfs interface in
ath12k to produce more useful and accurate diagnostic output in MLO
configurations.
Patch 1 fixes a latent correctness issue where the REO Rx and WBM
release error tables were unconditionally printed for
ATH12K_MAX_DEVICES columns showing zero-filled entries for device
slots that have no hardware. Replacing the compile-time constant
with the runtime device count keeps the output compact and correct.
Patch 2 prepends a ktime-based millisecond timestamp to the top of
the dump. In MLO setups the per-device file is to be read
independently for each ath12k instance, so without a common timestamp
it is difficult to verify whether two snapshots are contemporaneous,
making cross-device counter comparisons unreliable.
Patch 3 extends the existing per-radio section to report the center
frequency on which each radio is currently operating. This allows
the reader to correlate throughput and error counters with the channel
without having to cross-reference iw/nl80211 output separately.
---
Changes in v2:
- Rebased the patch series on the latest tip of ath-next
---
Sreeramya Soratkal (3):
wifi: ath12k: Use runtime device count in dp stats display
wifi: ath12k: Add timestamp to dp stats display
wifi: ath12k: Show per-radio center freq in dp stats
drivers/net/wireless/ath/ath12k/debugfs.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
base-commit: 972c4dd19cb92e03d75b66c426cfade07582a1ba
--
2.34.1
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-06-26 8:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171223.374814973@kernel.org>
On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
(...)
> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
> tkd = &tk_core;
> offs = &tk_core.timekeeper.offs_boot;
> break;
> + case CLOCK_AUX ... CLOCK_AUX_LAST:
> + tkd = aux_get_tk_data(clock_id);
> + if (!tkd)
> + return false;
> + offs = &tkd->timekeeper.offs_aux;
> + break;
'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
Instead 'monoraw' should be computed based on 'tk_core'.
Which then also requires the sequence locking of 'tk_core'.
As you know I have a series which unifies the locking between the
different timekeepers. Maybe we revert this patch for 7.2 and I send
a fixed variant including the prerequisites for 7.3.
(The same goes for get_device_system_crosststamp())
> default:
> WARN_ON_ONCE(1);
> return false;
> @@ -1228,6 +1239,10 @@ bool ktime_get_snapshot_id(struct system
> do {
> seq = read_seqcount_begin(&tkd->seq);
>
> + /* Aux clocks can be invalid */
> + if (!tk->clock_valid)
> + return false;
> +
> now = tk_clock_read(&tk->tkr_mono);
> systime_snapshot->cs_id = tk->tkr_mono.clock->id;
> systime_snapshot->cs_was_changed_seq = tk->cs_was_changed_seq;
>
^ permalink raw reply
* [PATCH ath-next v3] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Aaradhana Sahu @ 2026-06-26 8:43 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu
On AHB platforms, firmware operates in two modes: fixed-memory mode where
firmware uses hardcoded addresses for memory regions such as BDF and does
not request HOST_DDR memory from the host, and dynamic-memory mode where
firmware expects the host to provide memory addresses including HOST_DDR
after the Q6 read-only region and relies on host allocation for all memory
types.
Introduce QMI capability negotiation to support both modes. Add a new QMI
PHY capability flag dynamic_ddr_support which is advertised by firmware to
indicate it supports dynamic memory mode. When the host detects this
capability, set the dynamic_mem_support flag in the host capability message
to signal the host is ready to provide dynamic memory allocation. This
triggers firmware to send the HOST_DDR memory request and use the
host-provided address.
For backward compatibility, if firmware doesn't advertise
dynamic_ddr_support, the firmware continues to operate in fixed-memory mode
where firmware uses predefined addresses.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
v3:
-Restored QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN change.
v2:
-Dropped QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN and QMI_WLANFW_PHY_CAP_RESP_MSG_V01_MAX_LEN changes.
-Used %u instead of %d in the debug log.
---
drivers/net/wireless/ath/ath12k/qmi.c | 50 +++++++++++++++++++++++++--
drivers/net/wireless/ath/ath12k/qmi.h | 8 +++--
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
index fd762b5d7bb5..e15a0c0120d3 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.c
+++ b/drivers/net/wireless/ath/ath12k/qmi.c
@@ -506,6 +506,24 @@ static const struct qmi_elem_info qmi_wlanfw_host_cap_req_msg_v01_ei[] = {
.offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
feature_list),
},
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x33,
+ .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
+ dynamic_mem_support_valid),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x33,
+ .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
+ dynamic_mem_support),
+ },
{
.data_type = QMI_EOTI,
.array_type = NO_ARRAY,
@@ -602,6 +620,24 @@ static const struct qmi_elem_info qmi_wlanfw_phy_cap_resp_msg_v01_ei[] = {
.offset = offsetof(struct qmi_wlanfw_phy_cap_resp_msg_v01,
single_chip_mlo_support),
},
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x17,
+ .offset = offsetof(struct qmi_wlanfw_phy_cap_resp_msg_v01,
+ dynamic_ddr_support_valid),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x17,
+ .offset = offsetof(struct qmi_wlanfw_phy_cap_resp_msg_v01,
+ dynamic_ddr_support),
+ },
{
.data_type = QMI_EOTI,
.array_type = NO_ARRAY,
@@ -2248,6 +2284,11 @@ int ath12k_qmi_host_cap_send(struct ath12k_base *ab)
if (ret < 0)
goto out;
+ if (ab->qmi.dynamic_ddr_support) {
+ req.dynamic_mem_support_valid = 1;
+ req.dynamic_mem_support = 1;
+ }
+
ret = qmi_txn_init(&ab->qmi.handle, &txn,
qmi_wlanfw_host_cap_resp_msg_v01_ei, &resp);
if (ret < 0)
@@ -2319,11 +2360,14 @@ static void ath12k_qmi_phy_cap_send(struct ath12k_base *ab)
ab->qmi.num_radios = resp.num_phy;
+ if (resp.dynamic_ddr_support_valid)
+ ab->qmi.dynamic_ddr_support = resp.dynamic_ddr_support;
+
ath12k_dbg(ab, ATH12K_DBG_QMI,
- "phy capability resp valid %d single_chip_mlo_support %d valid %d num_phy %d valid %d board_id %d\n",
+ "phy capability resp valid %d single_chip_mlo_support %d valid %d num_phy %d valid %d board_id %d dynamic_ddr_valid %u dynamic_ddr_support %u\n",
resp.single_chip_mlo_support_valid, resp.single_chip_mlo_support,
- resp.num_phy_valid, resp.num_phy,
- resp.board_id_valid, resp.board_id);
+ resp.num_phy_valid, resp.num_phy, resp.board_id_valid, resp.board_id,
+ resp.dynamic_ddr_support_valid, resp.dynamic_ddr_support);
return;
diff --git a/drivers/net/wireless/ath/ath12k/qmi.h b/drivers/net/wireless/ath/ath12k/qmi.h
index 2a63e214eb42..9bdb290e2cce 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.h
+++ b/drivers/net/wireless/ath/ath12k/qmi.h
@@ -156,9 +156,10 @@ struct ath12k_qmi {
struct m3_mem_region aux_uc_mem;
unsigned int service_ins_id;
struct dev_mem_info dev_mem[ATH12K_QMI_WLFW_MAX_DEV_MEM_NUM_V01];
+ u8 dynamic_ddr_support;
};
-#define QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN 261
+#define QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN 265
#define QMI_WLANFW_HOST_CAP_REQ_V01 0x0034
#define QMI_WLANFW_HOST_CAP_RESP_MSG_V01_MAX_LEN 7
#define QMI_WLFW_HOST_CAP_RESP_V01 0x0034
@@ -258,7 +259,8 @@ struct qmi_wlanfw_host_cap_req_msg_v01 {
struct wlfw_host_mlo_chip_info_s_v01 mlo_chip_info[QMI_WLFW_MAX_NUM_MLO_CHIPS_V01];
u8 feature_list_valid;
u64 feature_list;
-
+ u8 dynamic_mem_support_valid;
+ u8 dynamic_mem_support;
};
struct qmi_wlanfw_host_cap_resp_msg_v01 {
@@ -281,6 +283,8 @@ struct qmi_wlanfw_phy_cap_resp_msg_v01 {
u32 board_id;
u8 single_chip_mlo_support_valid;
u8 single_chip_mlo_support;
+ u8 dynamic_ddr_support_valid;
+ u8 dynamic_ddr_support;
};
#define QMI_WLANFW_IND_REGISTER_REQ_MSG_V01_MAX_LEN 54
base-commit: 1547a99cd8d8c1ab3e04dbd92b72b3b5f7cb85a9
--
2.34.1
^ permalink raw reply related
* Re: [PATCH ath-next v2] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Aaradhana Sahu @ 2026-06-26 8:43 UTC (permalink / raw)
To: Jeff Johnson, ath12k; +Cc: linux-wireless
In-Reply-To: <44d9944c-3760-4ef5-8830-265eb2e9b896@oss.qualcomm.com>
On 6/24/2026 5:12 AM, Jeff Johnson wrote:
> On 6/18/2026 11:58 PM, Aaradhana Sahu wrote:
>> On AHB platforms, firmware operates in two modes: fixed-memory mode where
>> firmware uses hardcoded addresses for memory regions such as BDF and does
>> not request HOST_DDR memory from the host, and dynamic-memory mode where
>> firmware expects the host to provide memory addresses including HOST_DDR
>> after the Q6 read-only region and relies on host allocation for all memory
>> types.
>>
>> Introduce QMI capability negotiation to support both modes. Add a new QMI
>> PHY capability flag dynamic_ddr_support which is advertised by firmware to
>> indicate it supports dynamic memory mode. When the host detects this
>> capability, set the dynamic_mem_support flag in the host capability message
>> to signal the host is ready to provide dynamic memory allocation. This
>> triggers firmware to send the HOST_DDR memory request and use the
>> host-provided address.
>>
>> For backward compatibility, if firmware doesn't advertise
>> dynamic_ddr_support, the firmware continues to operate in fixed-memory mode
>> where firmware uses predefined addresses.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
>> ---
>> v2:
>> -Dropped QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN and QMI_WLANFW_PHY_CAP_RESP_MSG_V01_MAX_LEN changes.
>
> I think you needed to keep the REQ_MSG MAX_LEN change.
> My prior comment that the REQ_MSG MAX_LEN macros are a layering violation was
> constrained with the observation "that is a preexisting issue with the QMI
> interface" so we must continue to pass valid MAX_LEN values unless the QMI
> interface itself is changed such QMI determines the MAX_LEN
>
You're right. My bad, I mistakenly dropped the QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN
changes while updating the patch. I will restore in the next version.
>> -Used %u instead of %d in the debug log.
>> ---
>> drivers/net/wireless/ath/ath12k/qmi.c | 50 +++++++++++++++++++++++++--
>> drivers/net/wireless/ath/ath12k/qmi.h | 6 +++-
>> 2 files changed, 52 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
>> index fd762b5d7bb5..e15a0c0120d3 100644
>> --- a/drivers/net/wireless/ath/ath12k/qmi.c
>> +++ b/drivers/net/wireless/ath/ath12k/qmi.c
>> @@ -506,6 +506,24 @@ static const struct qmi_elem_info qmi_wlanfw_host_cap_req_msg_v01_ei[] = {
>> .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
>> feature_list),
>> },
>> + {
>> + .data_type = QMI_OPT_FLAG,
>> + .elem_len = 1,
>> + .elem_size = sizeof(u8),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x33,
>> + .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
>> + dynamic_mem_support_valid),
>> + },
>> + {
>> + .data_type = QMI_UNSIGNED_1_BYTE,
>> + .elem_len = 1,
>> + .elem_size = sizeof(u8),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x33,
>> + .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
>> + dynamic_mem_support),
>> + },
>
> Does QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN need to be updated to account for
> the new TLVs?
>
You're right. I will update QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN by 4 bytes and
send it in the next version.
>> {
>> .data_type = QMI_EOTI,
>> .array_type = NO_ARRAY,
^ permalink raw reply
* mac80211: MLO link removal frees link RX stats percpu without RCU grace
From: Maoyi Xie @ 2026-06-26 8:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: Maoyi Xie, linux-wireless, linux-kernel
Hi Johannes,
I think there is a use after free on the MLO link removal path in
net/mac80211/sta_info.c. The link RX stats percpu buffer is freed while a
concurrent RX softirq can still write to it. I would appreciate it if you
could take a look.
sta_remove_link() frees the link stats and defers only the container:
sta_info_free_link(&alloc->info);
kfree_rcu(alloc, rcu_head);
sta_info_free_link() does the free right away:
free_percpu(link_sta->pcpu_rx_stats);
So the container waits for a grace period but the percpu stats are
reclaimed at once. The RX fast path runs in softirq under rcu_read_lock
only. It resolves link_sta early and writes the percpu stats later:
stats = this_cpu_ptr(link_sta->pcpu_rx_stats);
stats->last_signal = status->signal;
A reader that resolved link_sta before the removal NULLed it keeps the
pointer. The container is still alive from the kfree_rcu, so the read of
link_sta->pcpu_rx_stats works. But the percpu block it points to is
already freed. This needs uses_rss. That is when pcpu_rx_stats is
allocated. The trigger is an MLO link removed over the air through a
Multi-Link Reconfiguration element.
The full STA teardown does this safely. __sta_info_destroy calls
synchronize_net() before sta_info_free() frees the deflink stats. The MLO
link removal path has no such barrier. That path was added in
cb71f1d136a6 ("wifi: mac80211: add sta link addition/removal").
I do not have WiFi 7 hardware. This is from reading the code. A small test
that frees the stats buffer and writes it through the live container trips
KASAN with a slab use after free.
Does this look like a real use after free to you? Is the right fix to
defer the percpu free to RCU, like the container already is? I am happy to
send a patch once you confirm.
Kaixuan Li and I found this together.
Thanks,
Maoyi
https://maoyixie.com/
^ permalink raw reply
* Re: [PATCH ath-next v3] wifi: ath12k: avoid setting 320MHz support on non 6GHz band
From: Baochen Qiang @ 2026-06-26 7:43 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260623151613.72113-1-nico.escande@gmail.com>
On 6/23/2026 11:16 PM, Nicolas Escande wrote:
> On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
> related 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 IEEE Std 802.11-2024, subclause 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>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* [PATCH wireless-next v3 33/33] wifi: mm81x: add MAINTAINERS entry
From: Lachlan Hodges @ 2026-06-26 6:29 UTC (permalink / raw)
To: johannes
Cc: arien.judge, dan.callaghan, ayman.grais, linux-wireless,
Lachlan Hodges, linux-kernel
In-Reply-To: <20260626063014.1275235-1-lachlan.hodges@morsemicro.com>
(Patches split per file for review, will be a single commit alongside
SDIO ids once review is complete. See cover letter for more
information)
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eb8cdcc76324..d5639668f3a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18012,6 +18012,14 @@ F: drivers/regulator/mpq7920.c
F: drivers/regulator/mpq7920.h
F: include/linux/mfd/mp2629.h
+MORSE MICRO MM81X WIRELESS DRIVER
+M: Lachlan Hodges <lachlan.hodges@morsemicro.com>
+M: Dan Callaghan <dan.callaghan@morsemicro.com>
+R: Arien Judge <arien.judge@morsemicro.com>
+L: linux-wireless@vger.kernel.org
+S: Supported
+F: drivers/net/wireless/morsemicro/mm81x/
+
MOST(R) TECHNOLOGY DRIVER
M: Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
M: Christian Gromm <christian.gromm@microchip.com>
--
2.43.0
^ permalink raw reply related
* [PATCH wireless-next v3 32/33] wifi: mm81x: add Kconfig and Makefile
From: Lachlan Hodges @ 2026-06-26 6:29 UTC (permalink / raw)
To: johannes, Lachlan Hodges, Dan Callaghan, Arien Judge
Cc: ayman.grais, linux-wireless, linux-kernel
In-Reply-To: <20260626063014.1275235-1-lachlan.hodges@morsemicro.com>
(Patches split per file for review, will be a single commit alongside
SDIO ids once review is complete. See cover letter for more
information)
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
---
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/Makefile | 1 +
drivers/net/wireless/morsemicro/Kconfig | 15 ++++++++++++
drivers/net/wireless/morsemicro/Makefile | 2 ++
drivers/net/wireless/morsemicro/mm81x/Kconfig | 24 +++++++++++++++++++
.../net/wireless/morsemicro/mm81x/Makefile | 21 ++++++++++++++++
6 files changed, 64 insertions(+)
create mode 100644 drivers/net/wireless/morsemicro/Kconfig
create mode 100644 drivers/net/wireless/morsemicro/Makefile
create mode 100644 drivers/net/wireless/morsemicro/mm81x/Kconfig
create mode 100644 drivers/net/wireless/morsemicro/mm81x/Makefile
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index c6599594dc99..baddadf9ec3c 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -27,6 +27,7 @@ source "drivers/net/wireless/intersil/Kconfig"
source "drivers/net/wireless/marvell/Kconfig"
source "drivers/net/wireless/mediatek/Kconfig"
source "drivers/net/wireless/microchip/Kconfig"
+source "drivers/net/wireless/morsemicro/Kconfig"
source "drivers/net/wireless/purelifi/Kconfig"
source "drivers/net/wireless/ralink/Kconfig"
source "drivers/net/wireless/realtek/Kconfig"
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index e1c4141c6004..d74f817b37de 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/
obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/
obj-$(CONFIG_WLAN_VENDOR_MEDIATEK) += mediatek/
obj-$(CONFIG_WLAN_VENDOR_MICROCHIP) += microchip/
+obj-$(CONFIG_WLAN_VENDOR_MORSEMICRO) += morsemicro/
obj-$(CONFIG_WLAN_VENDOR_PURELIFI) += purelifi/
obj-$(CONFIG_WLAN_VENDOR_QUANTENNA) += quantenna/
obj-$(CONFIG_WLAN_VENDOR_RALINK) += ralink/
diff --git a/drivers/net/wireless/morsemicro/Kconfig b/drivers/net/wireless/morsemicro/Kconfig
new file mode 100644
index 000000000000..cb0653c77d87
--- /dev/null
+++ b/drivers/net/wireless/morsemicro/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config WLAN_VENDOR_MORSEMICRO
+ bool "Morse Micro devices"
+ default y
+ help
+ If you have a wireless card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+if WLAN_VENDOR_MORSEMICRO
+source "drivers/net/wireless/morsemicro/mm81x/Kconfig"
+endif # WLAN_VENDOR_MORSEMICRO
diff --git a/drivers/net/wireless/morsemicro/Makefile b/drivers/net/wireless/morsemicro/Makefile
new file mode 100644
index 000000000000..5b2670f7d171
--- /dev/null
+++ b/drivers/net/wireless/morsemicro/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_MM81X) += mm81x/
diff --git a/drivers/net/wireless/morsemicro/mm81x/Kconfig b/drivers/net/wireless/morsemicro/mm81x/Kconfig
new file mode 100644
index 000000000000..33cdcc0df4de
--- /dev/null
+++ b/drivers/net/wireless/morsemicro/mm81x/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config MM81X
+ tristate "Morse Micro MM81x wireless devices"
+ depends on MAC80211
+ select FW_LOADER
+ select CRC7
+ help
+ This module adds support for wireless devices based
+ on Morse Micro MM81xx chipsets.
+
+config MM81X_USB
+ tristate "Morse Micro MM81x USB support"
+ depends on MM81X && USB
+ help
+ This module adds support for the USB interface of
+ devices using the Morse Micro MM81x chipset.
+
+config MM81X_SDIO
+ tristate "Morse Micro MM81x SDIO support"
+ depends on MM81X && MMC
+ help
+ This module adds support for the SDIO interface of
+ devices using the Morse Micro MM81x chipset.
diff --git a/drivers/net/wireless/morsemicro/mm81x/Makefile b/drivers/net/wireless/morsemicro/mm81x/Makefile
new file mode 100644
index 000000000000..0d494fda1412
--- /dev/null
+++ b/drivers/net/wireless/morsemicro/mm81x/Makefile
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_MM81X) += mm81x_core.o
+
+mm81x_core-y += core.o
+mm81x_core-y += mac.o
+mm81x_core-y += hw.o
+mm81x_core-y += fw.o
+mm81x_core-y += command.o
+mm81x_core-y += ps.o
+mm81x_core-y += skbq.o
+mm81x_core-y += yaps_hw.o
+mm81x_core-y += yaps.o
+mm81x_core-y += rc.o
+mm81x_core-y += mmrc.o
+
+obj-$(CONFIG_MM81X_USB) += mm81x_usb.o
+mm81x_usb-y += usb.o
+
+obj-$(CONFIG_MM81X_SDIO) += mm81x_sdio.o
+mm81x_sdio-y += sdio.o
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox