* [PATCH v2] wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations
From: Jose Ignacio Tornos Martinez @ 2026-07-02 10:43 UTC (permalink / raw)
To: nbd, lorenzo
Cc: ryder.lee, shayne.chen, linux-wireless,
Jose Ignacio Tornos Martinez
The driver fails to register with error -22 (EINVAL) due to a cfg80211
validation failure in wiphy_verify_iface_combinations().
Commit 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for
different chipsets") added beacon_int_min_gcd to if_comb_global and
if_comb_global_7992, but these combinations include ADHOC (IBSS)
interface type. This violates a cfg80211 rule from commit 56271da29c52
("cfg80211: disallow beacon_int_min_gcd with IBSS") that explicitly
forbids combining ADHOC with beacon_int_min_gcd.
The restriction exists because beacon_int_min_gcd requires static,
predictable beacon intervals to coordinate multiple beaconing interfaces,
but ADHOC interfaces have dynamic beacon intervals that change when
joining different networks, making the GCD constraint unenforceable.
Remove beacon_int_min_gcd from the interface combinations that include
ADHOC because they are not necessary for ADHOC operation. The if_comb
combination (AP/MESH/STA only, without ADHOC) correctly retains
beacon_int_min_gcd for multi-AP coordination.
Fixes: 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets")
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: Fix commit 56271da29c52 title reference from "cfg80211: simplify
netlink socket owner interface deletion" to "cfg80211: disallow
beacon_int_min_gcd with IBSS"
v1: https://lore.kernel.org/all/20260702071647.667539-1-jtornosm@redhat.com/
drivers/net/wireless/mediatek/mt76/mt7996/init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/init.c b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
index d6f9aa1ab52d..06f764a54405 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
@@ -34,7 +34,6 @@ static const struct ieee80211_iface_combination if_comb_global = {
BIT(NL80211_CHAN_WIDTH_40) |
BIT(NL80211_CHAN_WIDTH_80) |
BIT(NL80211_CHAN_WIDTH_160),
- .beacon_int_min_gcd = 100,
};
static const struct ieee80211_iface_combination if_comb_global_7992 = {
@@ -47,7 +46,6 @@ static const struct ieee80211_iface_combination if_comb_global_7992 = {
BIT(NL80211_CHAN_WIDTH_40) |
BIT(NL80211_CHAN_WIDTH_80) |
BIT(NL80211_CHAN_WIDTH_160),
- .beacon_int_min_gcd = 100,
};
static const struct ieee80211_iface_limit if_limits[] = {
--
2.54.0
^ permalink raw reply related
* [PATCH] wifi: p54: update stale wireless wiki URLs
From: Anas Khan @ 2026-07-02 10:23 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Kees Cook, linux-wireless, linux-kernel, Anas Khan
The p54 wireless wiki links (wireless.wiki.kernel.org) return 404; the
content moved to the Sphinx documentation site. Point them at the
current wireless.docs.kernel.org pages.
Signed-off-by: Anas Khan <anxkhn28@gmail.com>
---
drivers/net/wireless/intersil/p54/Kconfig | 6 +++---
drivers/net/wireless/intersil/p54/fwio.c | 4 +---
drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/intersil/p54/Kconfig b/drivers/net/wireless/intersil/p54/Kconfig
index 003c378ed131..44b0f1a724aa 100644
--- a/drivers/net/wireless/intersil/p54/Kconfig
+++ b/drivers/net/wireless/intersil/p54/Kconfig
@@ -10,7 +10,7 @@ config P54_COMMON
also need to be enabled in order to support any devices.
These devices require softmac firmware which can be found at
- <http://wireless.wiki.kernel.org/en/users/Drivers/p54>
+ <https://wireless.docs.kernel.org/en/latest/en/users/drivers/p54.html>
If you choose to build a module, it'll be called p54common.
@@ -22,7 +22,7 @@ config P54_USB
This driver is for USB isl38xx based wireless cards.
These devices require softmac firmware which can be found at
- <http://wireless.wiki.kernel.org/en/users/Drivers/p54>
+ <https://wireless.docs.kernel.org/en/latest/en/users/drivers/p54.html>
If you choose to build a module, it'll be called p54usb.
@@ -36,7 +36,7 @@ config P54_PCI
supported by the fullmac driver/firmware.
This driver requires softmac firmware which can be found at
- <http://wireless.wiki.kernel.org/en/users/Drivers/p54>
+ <https://wireless.docs.kernel.org/en/latest/en/users/drivers/p54.html>
If you choose to build a module, it'll be called p54pci.
diff --git a/drivers/net/wireless/intersil/p54/fwio.c b/drivers/net/wireless/intersil/p54/fwio.c
index 3baf8ab01e22..a3d9053f043c 100644
--- a/drivers/net/wireless/intersil/p54/fwio.c
+++ b/drivers/net/wireless/intersil/p54/fwio.c
@@ -131,9 +131,7 @@ int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
if (priv->fw_var < 0x500)
wiphy_info(priv->hw->wiphy,
- "you are using an obsolete firmware. "
- "visit http://wireless.wiki.kernel.org/en/users/Drivers/p54 "
- "and grab one for \"kernel >= 2.6.28\"!\n");
+ "you are using an obsolete firmware. visit https://wireless.docs.kernel.org/en/latest/en/users/drivers/p54.html and grab one for \"kernel >= 2.6.28\"!\n");
if (priv->fw_var >= 0x300) {
/* Firmware supports QoS, use it! */
diff --git a/drivers/net/wireless/intersil/p54/p54usb.c b/drivers/net/wireless/intersil/p54/p54usb.c
index c0d3b5329f4e..b88a3dadddc0 100644
--- a/drivers/net/wireless/intersil/p54/p54usb.c
+++ b/drivers/net/wireless/intersil/p54/p54usb.c
@@ -36,7 +36,7 @@ static struct usb_driver p54u_driver;
* Note:
*
* Always update our wiki's device list (located at:
- * http://wireless.wiki.kernel.org/en/users/Drivers/p54/devices ),
+ * https://wireless.docs.kernel.org/en/latest/en/users/drivers/p54/devices.html ),
* whenever you add a new device.
*/
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian
From: Baochen Qiang @ 2026-07-02 9:56 UTC (permalink / raw)
To: Alexander Wilhelm; +Cc: Jeff Johnson, linux-wireless, ath12k, linux-kernel
In-Reply-To: <akYsszdtJfrvIRSr@FUE-ALEWI-WINX>
On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
>>>
>>>
>>> On 6/29/2026 3:55 PM, Alexander Wilhelm wrote:
>>>> The ath12k_dp_get_mac_addr function performs a simple memcpy from a
>>>> CPU-native data types into an u8 array. On a big-endian architecture, this
>>>> later results in a null‑pointer dereference. Convert the data to
>>>
>>> Alex, did you find a time to investigate the root cause of the null pointer?
>
> Hi Baochen,
>
> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
> gone. I only see the following log messages:
>
> ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
is that, without this patch (if we really need it) we get a wrong mac addr, then in
ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
create a new peer and wakeup the waiting thread. But the log here clearly indicates that
the wait timeout, which does not make sense to me.
> ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
> ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
> ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
>
> Should I rebase the patch onto the latest `ath/master` branch and update the
> commit description accordingly?
>
>
> Best regards
> Alexander Wilhelm
^ permalink raw reply
* Re: [PATCH v2 1/2] wifi: ath12k: support calibration-variant from device tree
From: Baochen Qiang @ 2026-07-02 9:32 UTC (permalink / raw)
To: Andrew LaMarche, Johannes Berg, Jeff Johnson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-wireless, devicetree, ath12k, linux-kernel,
Ernest Van Hoecke
In-Reply-To: <20260630133001.1426824-1-andrewjlamarche@gmail.com>
On 6/30/2026 9:30 PM, Andrew LaMarche wrote:
> ath10k and ath11k support reading calibration variants from the device
> tree to locate the correct Board Description File (BDF). The ath12k-wsi
> binding already describes using qcom,calibration-variant but it is not
> implemented in the driver.
>
> Many ath12k designs expose all the radios under a single phy, each of
> which typically require a separate BDF. Without this, the radios may not
> come up or will not be calibrated correctly.
>
> Fix this by parsing the device tree for the generation-agnostic
> qcom,calibration-variant. This allows the driver to properly select,
> read and apply the correct BDF.
>
> Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
> ---
> Changes in v2:
> - Drop ath12k-specific binding qcom,ath12k-calibration-variant in favor
> of generation agnostic qcom,calibration-variant.
> - Link to v1: https://lore.kernel.org/all/20260131003222.2011259-1-andrewjlamarche@gmail.com
> ---
> drivers/net/wireless/ath/ath12k/core.c | 22 ++++++++++++++++++++++
> drivers/net/wireless/ath/ath12k/qmi.c | 4 ++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index 742d4fd1b598..52c28864c63c 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -812,6 +812,28 @@ int ath12k_core_check_smbios(struct ath12k_base *ab)
> return 0;
> }
>
> +int ath12k_core_check_dt(struct ath12k_base *ab)
> +{
> + size_t max_len = sizeof(ab->qmi.target.bdf_ext);
> + const char *variant = NULL;
> + struct device_node *node;
> +
> + node = ab->dev->of_node;
> + if (!node)
> + return -ENOENT;
> +
> + of_property_read_string(node, "qcom,calibration-variant",
> + &variant);
> + if (!variant)
> + return -ENODATA;
> +
> + if (strscpy(ab->qmi.target.bdf_ext, variant, max_len) < 0)
> + ath12k_dbg(ab, ATH12K_DBG_BOOT,
> + "bdf variant string is longer than the buffer can accommodate (variant: %s)\n", variant);
> +
> + return 0;
> +}
> +
> static int ath12k_core_soc_create(struct ath12k_base *ab)
> {
> int ret;
> diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
> index fd762b5d7bb5..3cf39ae06fd3 100644
> --- a/drivers/net/wireless/ath/ath12k/qmi.c
> +++ b/drivers/net/wireless/ath/ath12k/qmi.c
> @@ -2945,6 +2945,10 @@ int ath12k_qmi_request_target_cap(struct ath12k_base *ab)
> if (r)
> ath12k_dbg(ab, ATH12K_DBG_QMI, "SMBIOS bdf variant name not set.\n");
>
> + r = ath12k_core_check_dt(ab);
I understand there are already some variant exacting helper (ACPI, SMBIOS) being called
here, but they really should not. After all, how could a qmi message relates to ACPI or
SMBIOS?
I'd like firstly move the existing helpers out and then add the new DT helper.
> + if (r)> + ath12k_dbg(ab, ATH12K_DBG_QMI, "DT bdf variant name not set.\n");
> +
> r = ath12k_acpi_start(ab);
> if (r)
> /* ACPI is optional so continue in case of an error */
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian
From: Alexander Wilhelm @ 2026-07-02 9:17 UTC (permalink / raw)
To: Baochen Qiang; +Cc: Jeff Johnson, linux-wireless, ath12k, linux-kernel
In-Reply-To: <akYkNQTB5DPwzYXZ@FUE-ALEWI-WINX>
On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
> >
> >
> > On 6/29/2026 3:55 PM, Alexander Wilhelm wrote:
> > > The ath12k_dp_get_mac_addr function performs a simple memcpy from a
> > > CPU-native data types into an u8 array. On a big-endian architecture, this
> > > later results in a null‑pointer dereference. Convert the data to
> >
> > Alex, did you find a time to investigate the root cause of the null pointer?
Hi Baochen,
I am now running kernel v6.18.26, and it looks like the null-pointer issue is
gone. I only see the following log messages:
ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
Should I rebase the patch onto the latest `ath/master` branch and update the
commit description accordingly?
Best regards
Alexander Wilhelm
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()
From: Baochen Qiang @ 2026-07-02 9:07 UTC (permalink / raw)
To: Wentao Liang, jjohnson; +Cc: linux-wireless, ath11k, linux-kernel, stable
In-Reply-To: <20260609092528.220547-1-vulab@iscas.ac.cn>
On 6/9/2026 5:25 PM, Wentao Liang wrote:
> of_get_child_by_name() returns a node pointer with refcount
> incremented, but the error path when ath11k_ahb_setup_msa_resources()
> fails does not release it. Add the missing of_node_put() to avoid
> leaking the reference.
>
> Cc: stable@vger.kernel.org
> Fixes: 095cb947490c ("wifi: ath11k: allow missing memory-regions")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: wireless: ath12k: allow calibration variant for WCN7850
From: Krzysztof Kozlowski @ 2026-07-02 9:03 UTC (permalink / raw)
To: Ernest Van Hoecke
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Jeff Johnson, Andrew LaMarche, linux-wireless,
devicetree, ath12k, linux-kernel, Ernest Van Hoecke
In-Reply-To: <zglhxxu6txw2xvz4vcyu32v6722hqppcfvntan5ho32ak2y6tw@2mvfuaoxcvss>
On 02/07/2026 11:00, Ernest Van Hoecke wrote:
> On Thu, Jul 02, 2026 at 10:29:51AM +0200, Krzysztof Kozlowski wrote:
>> On 02/07/2026 10:27, Krzysztof Kozlowski wrote:
>>> On Wed, Jul 01, 2026 at 05:42:24PM +0200, Ernest Van Hoecke wrote:
>>>> From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>>>>
>>>> qcom,calibration-variant selects board-specific calibration data for
>>>> systems where the bus and device IDs are not unique.
>>>>
>>>> This is not specific to WSI-capable QCN9274 devices. The WSI binding
>>>> already allows the property, so allow it in the WCN7850 PCI binding too.
>>>
>>> Why? You need to provide reasons WHY do we want this.
>>>
>
> We (Toradex) have SoMs with the SX-PCEBE from Silex, which uses the
> WCN7850. Silex provided multiple board files for this to deal with
> separate regulatory regions. Thus, we need a mechanism to select which
> one to use even though the PCI ID and machines are the same.
>
>>>>
>>>> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>>>
>>> Where is any user of this?
>>>
>>
>> Actually I missed your link in changelog section. I still however do not
>> understand why these are separate. Separate means they are completely
>> independent and thus my question about the user stays.
>>
>> Best regards,
>> Krzysztof
>
> I agree that they could be one patchset and considered replying there,
> but felt it easier to discuss this with the relevant patch already
> attached. As the other binding already validates this property there is
> no real dependency or ordering problem, and I thought this would ease
> review.
If you do not have user in this patchset then your commit msg must
explain why you are adding this, otherwise it just looks like you are
adding unused ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: wireless: ath12k: allow calibration variant for WCN7850
From: Ernest Van Hoecke @ 2026-07-02 9:00 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Jeff Johnson, Andrew LaMarche, linux-wireless,
devicetree, ath12k, linux-kernel, Ernest Van Hoecke
In-Reply-To: <a0cb02e3-0566-4294-b41c-3b156ecda5e0@kernel.org>
On Thu, Jul 02, 2026 at 10:29:51AM +0200, Krzysztof Kozlowski wrote:
> On 02/07/2026 10:27, Krzysztof Kozlowski wrote:
> > On Wed, Jul 01, 2026 at 05:42:24PM +0200, Ernest Van Hoecke wrote:
> >> From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> >>
> >> qcom,calibration-variant selects board-specific calibration data for
> >> systems where the bus and device IDs are not unique.
> >>
> >> This is not specific to WSI-capable QCN9274 devices. The WSI binding
> >> already allows the property, so allow it in the WCN7850 PCI binding too.
> >
> > Why? You need to provide reasons WHY do we want this.
> >
We (Toradex) have SoMs with the SX-PCEBE from Silex, which uses the
WCN7850. Silex provided multiple board files for this to deal with
separate regulatory regions. Thus, we need a mechanism to select which
one to use even though the PCI ID and machines are the same.
> >>
> >> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> >
> > Where is any user of this?
> >
>
> Actually I missed your link in changelog section. I still however do not
> understand why these are separate. Separate means they are completely
> independent and thus my question about the user stays.
>
> Best regards,
> Krzysztof
I agree that they could be one patchset and considered replying there,
but felt it easier to discuss this with the relevant patch already
attached. As the other binding already validates this property there is
no real dependency or ordering problem, and I thought this would ease
review.
Kind regards,
Ernest
^ permalink raw reply
* Re: ath11k: BigEndian platform support?
From: Alexander Wilhelm @ 2026-07-02 8:56 UTC (permalink / raw)
To: Jeff Johnson; +Cc: Jeff Johnson, ath11k, ath12k, linux-wireless
In-Reply-To: <a412f206-e856-47f8-af74-8eb268ed50d0@oss.qualcomm.com>
On Wed, Jul 01, 2026 at 10:08:47AM -0700, Jeff Johnson wrote:
> On 6/29/2026 1:35 AM, Alexander Wilhelm wrote:
> > On Tue, Jul 11, 2023 at 11:49:54AM +0300, Kalle Valo wrote:
> >> Alexander Wilhelm <alexander.wilhelm@westermo.com> writes:
> >>
> >>> I am trying to get the QCN9074 module to work on a BigEndian PowerPC
> >>> platform. My question would be, has anyone done it yet? If not, what
> >>> kind of effort would you estimate for porting or are there any
> >>> firmware limitations?
> >>
> >> This is a good question. The short answer is that it _might_ work with
> >> QCN9074 but AFAIK nobody has tested it and I'm not really optimistic.
> >>
> >> The long answer is that the big endian support in ath11k is implemented
> >> in a weird way which I regret big time. The idea is that the firmware
> >> does the translation instead of ath11k driver with this flag:
> >>
> >> /* Host software's Copy Engine configuration. */
> >> #ifdef __BIG_ENDIAN
> >> #define CE_ATTR_FLAGS CE_ATTR_BYTE_SWAP_DATA
> >> #else
> >> #define CE_ATTR_FLAGS 0
> >> #endif
> >>
> >> But later I was told that not all firmware branches actually support
> >> this feature, sigh. To my knowledge QCA6390 and WCN6855 firmwares do not
> >> support this CE_ATTR_BYTE_SWAP_DATA but I'm hoping QCN9074 firmware
> >> would support it. Grep for BIG_ENDIAN to see more big endian specific
> >> changes.
> >>
> >> In ath12k the endian support was implemented in a proper way using
> >> __le32 type family and cpu_to_le32() & co macros, but it's also
> >> untested. It's on my todo list to convert ath11k to do the same but no
> >> idea when I'm able to work on it. Patches very welcome.
> >>
> >> Do let me know if you test ath11k on big endian, I'm very curious to
> >> know the results.
> >
> > Hello Jeff and the `ath` developers,
> >
> > there are still a number of pending patch requests from my side for `ath12k`
> > addressing various big endian issues. I assume there may still be gaps that I
> > did not uncover during my testing. Nevertheless, `ath12k` is now running stable
> > for me in both AP and STA modes, so I have started to look into `ath11k`.
>
> Let me start by addressing ath12k. I have been sitting on your patches because
> internally there has been a lot of discussion on this topic. Just this week I
> convinced Those That Need Convincing (tm) that your changes are consistent
> with the approach that was taken with the rest of ath12k to have the host
> driver responsible for all byte swapping. So I'll finally be taking those patches.
>
> HOWEVER, Qualcomm is trying to transition all of our products to be based upon
> the upstream driver, and the team responsible for enterprise access points
> believes that their KPIs on Big Endian platforms cannot be met with software
> byte swapping (my understanding is they currently use hardware swapping in
> their out-of-tree driver). So it is possible that ath12k will need to
> transition to hardware swapping in the future to meet that need.
That's an interesting approach. Unfortunately, the situation with the `ath11k`
driver in the past was that the upstream code never really worked on big-endian
platforms. I can understand why, since only very few people are still using such
architectures today.
However, my concern is that if `ath12k` also performs the byte swapping inside
the firmware, neither I nor the wider community will be able to fix endianness
related issues anymore. In that case, we would have to rely entirely on Qualcomm
to address such problems, which raises the question of how much interest there
still is in supporting big-endian platforms going forward. If big-endian support
is no longer a priority, wouldn't it make just as much sense to perform the
swapping in the host driver instead? For little-endian platforms, this would
effectively be a no-op anyway.
Best regards
Alexander Wilhelm
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix channel list copy on big endian
From: Alexander Wilhelm @ 2026-07-02 8:44 UTC (permalink / raw)
To: Baochen Qiang; +Cc: Jeff Johnson, linux-wireless, ath12k, linux-kernel
In-Reply-To: <8b29a6f4-0742-46f3-bc86-defa6e0faeae@oss.qualcomm.com>
On Thu, Jul 02, 2026 at 04:27:44PM +0800, Baochen Qiang wrote:
>
>
> On 6/29/2026 3:46 PM, Alexander Wilhelm wrote:
> > The ath12k_wmi_scan_req_arg structure defines the channel list in
> > CPU-native order, while wmi_start_scan_cmd expects the values in
> > little-endian format. The simple memcpy causes the hardware scan to fail on
> > big-endian architectures. Set __le32* type for the tmp_ptr and swap channel
> > values to support both architectures correctly.
> >
> > Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
> > ---
> > drivers/net/wireless/ath/ath12k/wmi.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> > index 65a05a9520ff..9e1d3c662852 100644
> > --- a/drivers/net/wireless/ath/ath12k/wmi.c
> > +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> > @@ -2571,7 +2571,8 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
> > struct wmi_tlv *tlv;
> > void *ptr;
> > int i, ret, len;
> > - u32 *tmp_ptr, extraie_len_with_pad = 0;
> > + __le32 *tmp_ptr;
> > + u32 extraie_len_with_pad = 0;
> > struct ath12k_wmi_hint_short_ssid_arg *s_ssid = NULL;
> > struct ath12k_wmi_hint_bssid_arg *hint_bssid = NULL;
> >
> > @@ -2656,9 +2657,10 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
> > tlv = ptr;
> > tlv->header = ath12k_wmi_tlv_hdr(WMI_TAG_ARRAY_UINT32, len);
> > ptr += TLV_HDR_SIZE;
> > - tmp_ptr = (u32 *)ptr;
> > + tmp_ptr = (__le32 *)ptr;
> >
> > - memcpy(tmp_ptr, arg->chan_list, arg->num_chan * 4);
> > + for (i = 0; i < arg->num_chan; i++)
> > + tmp_ptr[i] = cpu_to_le32(arg->chan_list[i]);
> >
> > ptr += len;
> >
> >
>
> seems hint_s_ssid and hint_bssid at the last also need the endian conversion?
Okay, I will investigate this further.
Best regards
Alexander Wilhelm
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian
From: Alexander Wilhelm @ 2026-07-02 8:41 UTC (permalink / raw)
To: Baochen Qiang; +Cc: Jeff Johnson, linux-wireless, ath12k, linux-kernel
In-Reply-To: <f4d0c9c0-6d21-4426-8403-209f77ab1387@oss.qualcomm.com>
On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
>
>
> On 6/29/2026 3:55 PM, Alexander Wilhelm wrote:
> > The ath12k_dp_get_mac_addr function performs a simple memcpy from a
> > CPU-native data types into an u8 array. On a big-endian architecture, this
> > later results in a null‑pointer dereference. Convert the data to
>
> Alex, did you find a time to investigate the root cause of the null pointer?
Sorry, I haven't had a chance to look into it yet. However, it's on my to-do
list. I will try to reproduce the issue again as soon as possible.
Best regards
Alexander Wilhelm
^ permalink raw reply
* Re: [PATCH] dt-bindings: wireless: ath12k: allow calibration variant for WCN7850
From: Krzysztof Kozlowski @ 2026-07-02 8:29 UTC (permalink / raw)
To: Ernest Van Hoecke
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Jeff Johnson, Andrew LaMarche, linux-wireless,
devicetree, ath12k, linux-kernel, Ernest Van Hoecke
In-Reply-To: <20260702-beneficial-hopeful-binturong-a0bee9@quoll>
On 02/07/2026 10:27, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 05:42:24PM +0200, Ernest Van Hoecke wrote:
>> From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>>
>> qcom,calibration-variant selects board-specific calibration data for
>> systems where the bus and device IDs are not unique.
>>
>> This is not specific to WSI-capable QCN9274 devices. The WSI binding
>> already allows the property, so allow it in the WCN7850 PCI binding too.
>
> Why? You need to provide reasons WHY do we want this.
>
>>
>> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>
> Where is any user of this?
>
Actually I missed your link in changelog section. I still however do not
understand why these are separate. Separate means they are completely
independent and thus my question about the user stays.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix channel list copy on big endian
From: Baochen Qiang @ 2026-07-02 8:27 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260629-fix-channel-list-copy-v1-1-5ab826c46d7c@westermo.com>
On 6/29/2026 3:46 PM, Alexander Wilhelm wrote:
> The ath12k_wmi_scan_req_arg structure defines the channel list in
> CPU-native order, while wmi_start_scan_cmd expects the values in
> little-endian format. The simple memcpy causes the hardware scan to fail on
> big-endian architectures. Set __le32* type for the tmp_ptr and swap channel
> values to support both architectures correctly.
>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
> ---
> drivers/net/wireless/ath/ath12k/wmi.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index 65a05a9520ff..9e1d3c662852 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -2571,7 +2571,8 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
> struct wmi_tlv *tlv;
> void *ptr;
> int i, ret, len;
> - u32 *tmp_ptr, extraie_len_with_pad = 0;
> + __le32 *tmp_ptr;
> + u32 extraie_len_with_pad = 0;
> struct ath12k_wmi_hint_short_ssid_arg *s_ssid = NULL;
> struct ath12k_wmi_hint_bssid_arg *hint_bssid = NULL;
>
> @@ -2656,9 +2657,10 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
> tlv = ptr;
> tlv->header = ath12k_wmi_tlv_hdr(WMI_TAG_ARRAY_UINT32, len);
> ptr += TLV_HDR_SIZE;
> - tmp_ptr = (u32 *)ptr;
> + tmp_ptr = (__le32 *)ptr;
>
> - memcpy(tmp_ptr, arg->chan_list, arg->num_chan * 4);
> + for (i = 0; i < arg->num_chan; i++)
> + tmp_ptr[i] = cpu_to_le32(arg->chan_list[i]);
>
> ptr += len;
>
>
seems hint_s_ssid and hint_bssid at the last also need the endian conversion?
> ---
> base-commit: 702847e8cfd51856836a282db2073defd7cfd80c
> change-id: 20260317-fix-channel-list-copy-cef5cad24fb6
>
> Best regards,
^ permalink raw reply
* Re: [PATCH] dt-bindings: wireless: ath12k: allow calibration variant for WCN7850
From: Krzysztof Kozlowski @ 2026-07-02 8:27 UTC (permalink / raw)
To: Ernest Van Hoecke
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Jeff Johnson, Andrew LaMarche, linux-wireless,
devicetree, ath12k, linux-kernel, Ernest Van Hoecke
In-Reply-To: <20260701-ath12k-calibration-variant-v1-1-d3eddaabf026@toradex.com>
On Wed, Jul 01, 2026 at 05:42:24PM +0200, Ernest Van Hoecke wrote:
> From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>
> qcom,calibration-variant selects board-specific calibration data for
> systems where the bus and device IDs are not unique.
>
> This is not specific to WSI-capable QCN9274 devices. The WSI binding
> already allows the property, so allow it in the WCN7850 PCI binding too.
Why? You need to provide reasons WHY do we want this.
>
> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Where is any user of this?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian
From: Baochen Qiang @ 2026-07-02 8:12 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260629-fix-mac-addr-copy-on-big-endian-v1-1-3de40f74c13e@westermo.com>
On 6/29/2026 3:55 PM, Alexander Wilhelm wrote:
> The ath12k_dp_get_mac_addr function performs a simple memcpy from a
> CPU-native data types into an u8 array. On a big-endian architecture, this
> later results in a null‑pointer dereference. Convert the data to
Alex, did you find a time to investigate the root cause of the null pointer?
> little‑endian first, then copy it into the target array.
>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
> ---
> drivers/net/wireless/ath/ath12k/dp.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/dp.h b/drivers/net/wireless/ath/ath12k/dp.h
> index f8cfc7bb29dd..50957915dbf4 100644
> --- a/drivers/net/wireless/ath/ath12k/dp.h
> +++ b/drivers/net/wireless/ath/ath12k/dp.h
> @@ -647,8 +647,11 @@ int ath12k_dp_arch_rx_tid_delete_handler(struct ath12k_dp *dp,
>
> static inline void ath12k_dp_get_mac_addr(u32 addr_l32, u16 addr_h16, u8 *addr)
> {
> - memcpy(addr, &addr_l32, 4);
> - memcpy(addr + 4, &addr_h16, ETH_ALEN - 4);
> + __le32 le_addr_l32 = cpu_to_le32(addr_l32);
> + __le16 le_addr_h16 = cpu_to_le16(addr_h16);
> +
> + memcpy(addr, &le_addr_l32, 4);
> + memcpy(addr + 4, &le_addr_h16, ETH_ALEN - 4);
> }
>
> static inline struct ath12k_dp *
>
> ---
> base-commit: 702847e8cfd51856836a282db2073defd7cfd80c
> change-id: 20260317-fix-mac-addr-copy-on-big-endian-f1a4fea40184
>
> Best regards,
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations
From: Johannes Berg @ 2026-07-02 8:06 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, nbd, lorenzo
Cc: ryder.lee, shayne.chen, linux-wireless
In-Reply-To: <20260702071647.667539-1-jtornosm@redhat.com>
On Thu, 2026-07-02 at 09:16 +0200, Jose Ignacio Tornos Martinez wrote:
> This violates a cfg80211 rule from commit 56271da29c52
> ("cfg80211: simplify netlink socket owner interface deletion") that
What?
johannes
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix SPT vaddr handling on big endian systems
From: Baochen Qiang @ 2026-07-02 7:59 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260629-fix-rx-tx-description-virtual-address-v1-1-ac1669eb43dd@westermo.com>
On 6/29/2026 3:56 PM, Alexander Wilhelm wrote:
> SPT pages store descriptor addresses in their vaddr field as little endian
> 64 bit values. Treating these entries as native pointers produces invalid
> addresses on big endian systems.
>
> Convert vaddr to __le64 and update all access paths. Write descriptor
> addresses as endian annotated 64 bit values and load them by converting
> back to native pointers. Return __le64* instead of void* from the SPT
> lookup and translate the stored value in the descriptor getters.
>
> This ensures correct and consistent handling of descriptor addresses on big
> endian systems, while little endian systems remain unaffected.
>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations
From: Jose Ignacio Tornos Martinez @ 2026-07-02 7:16 UTC (permalink / raw)
To: nbd, lorenzo
Cc: ryder.lee, shayne.chen, linux-wireless,
Jose Ignacio Tornos Martinez
The driver fails to register with error -22 (EINVAL) due to a cfg80211
validation failure in wiphy_verify_iface_combinations().
Commit 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for
different chipsets") added beacon_int_min_gcd to if_comb_global and
if_comb_global_7992, but these combinations include ADHOC (IBSS)
interface type. This violates a cfg80211 rule from commit 56271da29c52
("cfg80211: simplify netlink socket owner interface deletion") that
explicitly forbids combining ADHOC with beacon_int_min_gcd.
The restriction exists because beacon_int_min_gcd requires static,
predictable beacon intervals to coordinate multiple beaconing interfaces,
but ADHOC interfaces have dynamic beacon intervals that change when
joining different networks, making the GCD constraint unenforceable.
Remove beacon_int_min_gcd from the interface combinations that include
ADHOC because they are not necessary for ADHOC operation. The if_comb
combination (AP/MESH/STA only, without ADHOC) correctly retains
beacon_int_min_gcd for multi-AP coordination.
Fixes: 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets")
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt7996/init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/init.c b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
index d6f9aa1ab52d..06f764a54405 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
@@ -34,7 +34,6 @@ static const struct ieee80211_iface_combination if_comb_global = {
BIT(NL80211_CHAN_WIDTH_40) |
BIT(NL80211_CHAN_WIDTH_80) |
BIT(NL80211_CHAN_WIDTH_160),
- .beacon_int_min_gcd = 100,
};
static const struct ieee80211_iface_combination if_comb_global_7992 = {
@@ -47,7 +46,6 @@ static const struct ieee80211_iface_combination if_comb_global_7992 = {
BIT(NL80211_CHAN_WIDTH_40) |
BIT(NL80211_CHAN_WIDTH_80) |
BIT(NL80211_CHAN_WIDTH_160),
- .beacon_int_min_gcd = 100,
};
static const struct ieee80211_iface_limit if_limits[] = {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] ath12k: fix NULL pointer dereference in rhash table destroy
From: Jose Ignacio Tornos Martinez @ 2026-07-02 6:07 UTC (permalink / raw)
To: jtornosm; +Cc: ath12k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <20260615112103.601982-1-jtornosm@redhat.com>
Gentle ping on this patch.
This fixes a NULL pointer dereference during driver unbind that
crashes the kernel when initialization failed partially. The crash
is 100% reproducible when unbinding after an initialization failure.
This is particularly critical for VM environments with VFIO passthrough.
Regarding the concern from v1 about preferring symmetric init/deinit:
I understand the preference for unwinding init failures at each stage.
However, implementing full symmetric cleanup would require extensive
refactoring of multiple error paths across ath12k_core_start(),
ath12k_dp_alloc(), and related initialization functions.
The NULL check approach provides a safe, minimal fix that:
1. Prevents the crash without changing complex init logic
2. Follows the same pattern used elsewhere in the kernel for
conditional cleanup (e.g., other rhashtable users)
3. Has been tested and validated in the failing scenario
I've addressed the guard(mutex) feedback from v1 in this v2.
If Qualcomm engineering prefers a different approach, I'm happy to
revise, but no alternative has been suggested since the v1 discussion.
Please let me know if there are any other concerns.
Thanks
Best regards
Jose Ignacio
^ permalink raw reply
* [PATCH v2] wifi: ath: avoid repeated divisions in DFS PRI detector
From: Chun-Cheng Chang @ 2026-07-02 3:52 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, linux-kernel, Chun-Cheng Chang
In-Reply-To: <20260701170424.380202-1-frank0988855428@gmail.com>
pde_get_multiple() is called repeatedly with the same PRI (Pulse
Repetition Interval) value while validating candidate and existing PRI
sequences.
Cache the reciprocal value for each sequence structure and leverage
reciprocal_divide() in the hot path. This keeps the existing matching
logic and tolerance checks intact while replacing expensive hardware
integer divisions with low-cost multiply-and-shift operations.
Testing with a userspace model of the same detector logic demonstrated
identical detector states and outputs across 100 verification traces.
To eliminate memory allocator noise, an isolated micro-benchmark using
a static object pool showed that the reciprocal variant reduces CPU
cycles by approximately 3.4%.
Signed-off-by: Chun-Cheng Chang <frank0988855428@gmail.com>
---
Changes in v2:
- Use a known identity for the author and Signed-off-by tags.
drivers/net/wireless/ath/dfs_pri_detector.c | 14 +++++++++++---
drivers/net/wireless/ath/dfs_pri_detector.h | 3 +++
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pri_detector.c b/drivers/net/wireless/ath/dfs_pri_detector.c
index 388f9d1913bd..520fd1567a0b 100644
--- a/drivers/net/wireless/ath/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/dfs_pri_detector.c
@@ -16,6 +16,7 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/reciprocal_div.h>
#include "ath.h"
#include "dfs_pattern_detector.h"
@@ -41,7 +42,9 @@ struct pulse_elem {
* pde_get_multiple() - get number of multiples considering a given tolerance
* Return value: factor if abs(val - factor*fraction) <= tolerance, 0 otherwise
*/
-static u32 pde_get_multiple(u32 val, u32 fraction, u32 tolerance)
+static u32 pde_get_multiple(u32 val, u32 fraction,
+ struct reciprocal_value fraction_recip,
+ u32 tolerance)
{
u32 remainder;
u32 factor;
@@ -56,8 +59,8 @@ static u32 pde_get_multiple(u32 val, u32 fraction, u32 tolerance)
/* val and fraction are within tolerance */
return 1;
- factor = val / fraction;
- remainder = val % fraction;
+ factor = reciprocal_divide(val, fraction_recip);
+ remainder = val - factor * fraction;
if (remainder > tolerance) {
/* no exact match */
if ((fraction - remainder) <= tolerance)
@@ -247,6 +250,9 @@ static bool pseq_handler_create_sequences(struct pri_detector *pde,
ps.last_ts = ts;
ps.pri = GET_PRI_TO_USE(pde->rs->pri_min,
pde->rs->pri_max, ts - p->ts);
+ ps.pri_recip = (struct reciprocal_value){};
+ if (ps.pri)
+ ps.pri_recip = reciprocal_value(ps.pri);
ps.dur = ps.pri * (pde->rs->ppb - 1)
+ 2 * pde->rs->max_pri_tolerance;
@@ -261,6 +267,7 @@ static bool pseq_handler_create_sequences(struct pri_detector *pde,
break;
/* check if pulse match (multi)PRI */
factor = pde_get_multiple(ps.last_ts - p2->ts, ps.pri,
+ ps.pri_recip,
pde->rs->max_pri_tolerance);
if (factor > 0) {
ps.count++;
@@ -318,6 +325,7 @@ pseq_handler_add_to_existing_seqs(struct pri_detector *pde, u64 ts)
delta_ts = ts - ps->last_ts;
factor = pde_get_multiple(delta_ts, ps->pri,
+ ps->pri_recip,
pde->rs->max_pri_tolerance);
if (factor > 0) {
ps->last_ts = ts;
diff --git a/drivers/net/wireless/ath/dfs_pri_detector.h b/drivers/net/wireless/ath/dfs_pri_detector.h
index 86339f2b4d3a..c519466cff8b 100644
--- a/drivers/net/wireless/ath/dfs_pri_detector.h
+++ b/drivers/net/wireless/ath/dfs_pri_detector.h
@@ -18,6 +18,7 @@
#define DFS_PRI_DETECTOR_H
#include <linux/list.h>
+#include <linux/reciprocal_div.h>
extern struct ath_dfs_pool_stats global_dfs_pool_stats;
@@ -25,6 +26,7 @@ extern struct ath_dfs_pool_stats global_dfs_pool_stats;
* struct pri_sequence - sequence of pulses matching one PRI
* @head: list_head
* @pri: pulse repetition interval (PRI) in usecs
+ * @pri_recip: cached reciprocal value for PRI divisions
* @dur: duration of sequence in usecs
* @count: number of pulses in this sequence
* @count_falses: number of not matching pulses in this sequence
@@ -35,6 +37,7 @@ extern struct ath_dfs_pool_stats global_dfs_pool_stats;
struct pri_sequence {
struct list_head head;
u32 pri;
+ struct reciprocal_value pri_recip;
u32 dur;
u32 count;
u32 count_falses;
--
2.53.0
^ permalink raw reply related
* [PATCH v5] wifi: ath6kl: fix OOB access from firmware ADDBA window size
From: Tristan Madani @ 2026-07-02 0:50 UTC (permalink / raw)
To: linux-wireless, linux-kernel
Cc: vasanthakumar.thiagarajan, jeff.johnson, johannes, tristan,
Tristan Madani, stable
From: Tristan Madani <tristan@talencesecurity.com>
aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied
win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not
return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to
compute a kzalloc size and stored in rxtid->hold_q_sz, leading to
zero-size or overflowed allocations and subsequent out-of-bounds access.
Clean up any previously active aggregation session for the TID first,
then return early when win_sz is out of the valid range, instead of
proceeding with a broken allocation size.
Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
Cc: stable@vger.kernel.org
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
Changes in v5:
- Add From: tag in the patch body to fix the From/Signed-off-by
address mismatch (Jeff Johnson).
- Drop Suggested-by, add Reviewed-by (Vasanthakumar Thiagarajan).
Changes in v4:
- Move aggregation session cleanup before the window size check so
that a previously active session is always torn down, even when the
firmware sends an ADDBA event with an out-of-range window size
(Vasanthakumar Thiagarajan).
Changes in v3:
- Regenerated from wireless-next with proper git format-patch to
produce valid index hashes (v2 had post-processed index lines).
Changes in v2:
- No code changes from v1.
drivers/net/wireless/ath/ath6kl/txrx.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/txrx.c b/drivers/net/wireless/ath/ath6kl/txrx.c
index 80e66ac..a39c815 100644
--- a/drivers/net/wireless/ath/ath6kl/txrx.c
+++ b/drivers/net/wireless/ath/ath6kl/txrx.c
@@ -1722,13 +1722,15 @@ void aggr_recv_addba_req_evt(struct ath6kl_vif *vif, u8 tid_mux, u16 seq_no,
rxtid = &aggr_conn->rx_tid[tid];
- if (win_sz < AGGR_WIN_SZ_MIN || win_sz > AGGR_WIN_SZ_MAX)
- ath6kl_dbg(ATH6KL_DBG_WLAN_RX, "%s: win_sz %d, tid %d\n",
- __func__, win_sz, tid);
-
if (rxtid->aggr)
aggr_delete_tid_state(aggr_conn, tid);
+ if (win_sz < AGGR_WIN_SZ_MIN || win_sz > AGGR_WIN_SZ_MAX) {
+ ath6kl_dbg(ATH6KL_DBG_WLAN_RX, "%s: win_sz %d, tid %d\n",
+ __func__, win_sz, tid);
+ return;
+ }
+
rxtid->seq_next = seq_no;
hold_q_size = TID_WINDOW_SZ(win_sz) * sizeof(struct skb_hold_q);
rxtid->hold_q = kzalloc(hold_q_size, GFP_KERNEL);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH wireless] wifi: ath12k: avoid flushing scan work under the wiphy lock
From: Jeff Johnson @ 2026-07-01 20:47 UTC (permalink / raw)
To: Runyu Xiao, jjohnson
Cc: kvalo, quic_kangyang, linux-wireless, ath12k, linux-kernel,
jianhao.xu, stable
In-Reply-To: <20260612032701.1619188-1-runyu.xiao@seu.edu.cn>
On 6/11/2026 8:27 PM, Runyu Xiao wrote:
> ath12k_mac_op_stop() is entered with the wiphy mutex already held. It
> then takes ah->hw_mutex and ath12k_mac_stop() synchronously cancels the
> scan.timeout delayed work. The timeout worker grabs the same wiphy lock
> before it aborts the scan, so stop can deadlock against the pending
> worker.
>
> This issue was found by our static analysis tool and then manually
> reviewed against the current tree.
>
> The grounded PoC kept the ath12k_mac_op_stop() -> ath12k_mac_stop() ->
> cancel_delayed_work_sync(&ar->scan.timeout) path and the
> ath12k_scan_timeout_work() -> wiphy_lock() edge. Lockdep reported:
>
> WARNING: possible circular locking dependency detected
> ath12k_scan_timeout_work+0x25/0x42 [vuln_msv]
> __cancel_work_timer
> *** DEADLOCK ***
>
> Drain scan.timeout before re-entering the stop path under the wiphy lock
> and leave the rest of ath12k_mac_stop() unchanged.
>
> Fixes: 2830bc9e784f ("wifi: ath12k: implement remain on channel for P2P mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
This patch does not apply against the current ath.git tree, please rebase.
tag ath-current instead of wireless when you post v2
/jeff
^ permalink raw reply
* Re: [PATCH] wifi: ath: avoid repeated divisions in DFS PRI detector
From: Jeff Johnson @ 2026-07-01 19:08 UTC (permalink / raw)
To: frank0988, Jeff Johnson; +Cc: linux-wireless, linux-kernel
In-Reply-To: <20260701170424.380202-1-frank0988855428@gmail.com>
On 7/1/2026 10:04 AM, frank0988 wrote:
> pde_get_multiple() is called repeatedly with the same PRI (Pulse
> Repetition Interval) value while validating candidate and existing PRI
> sequences.
>
> Cache the reciprocal value for each sequence structure and leverage
> reciprocal_divide() in the hot path. This keeps the existing matching
> logic and tolerance checks intact while replacing expensive hardware
> integer divisions with low-cost multiply-and-shift operations.
>
> Testing with a userspace model of the same detector logic demonstrated
> identical detector states and outputs across 100 verification traces.
> To eliminate memory allocator noise, an isolated micro-benchmark using
> a static object pool showed that the reciprocal variant reduces CPU
> cycles by approximately 3.4%.
>
> Signed-off-by: frank0988 <frank0988855428@gmail.com>
You must sign off with a "known identity"
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
^ permalink raw reply
* Re: [PATCH] wifi: carl9170: fix stack-out-of-bounds in carl9170_cmd_callback
From: Jeff Johnson @ 2026-07-01 18:47 UTC (permalink / raw)
To: Christian Lamparter, Deepanshu Kartikey
Cc: linux-wireless, linux-kernel, syzbot+5c1ca6ccaa1215781cac,
tristan, TristanInSec
In-Reply-To: <26e33fea-c81e-48f4-a058-4b3bf0dc95c5@gmail.com>
On 5/1/2026 3:17 AM, Christian Lamparter wrote:
> Hi,
>
> On 4/24/26 5:17 AM, Deepanshu Kartikey wrote:
>> carl9170_cmd_callback() does not return after calling
>> carl9170_restart() when an invalid command response is detected.
>> This causes a fall-through into the memcpy block below, where
>> ar->readbuf is written with a device-controlled length (len - 4)
>> instead of the expected ar->readlen bytes.
>>
>> A malicious or fuzzing USB device can send an oversized response
>> (e.g. 60 bytes) causing a stack-out-of-bounds write into ar->readbuf,
>> as detected by KASAN.
>>
>> Fix this by adding a return after carl9170_restart() to match the
>> original intent stated in the comment ("Do not complete"). Also cap
>> the memcpy with min_t() as defense-in-depth to prevent overflow even
>> if the control flow changes in future.
>>
>> The bug has been present since the initial driver submission in 2010.
>
>
> I've seen this before in a mail from Tristan Madani (CC'd) on the 13th of April 2026.
> Unfortunately, he didn't post this to the linux-wireless mailing-list. Instead
> he went for the Security Officers <security@kernel.org> , so I can't provide any link to it.
> That said, he since changed it because of the notes I had about the driver actually want to process
> further so only the memcpy that caused the overflow was modified with the same
> "min_t(u32, len - 4, ar->readlen)" instead of "len -4" as the length:
> "[PATCH v3 1/3] wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read"
>
> https://lore.kernel.org/linux-wireless/20260421134929.325662-2-tristmd@gmail.com/
>
> So, who should get the credit? Maybe another person will post a patch soon too? Who knows.
My plan is to take Tristan's series once I get ACKs.
Any other contributions that conflict with his will be dropped.
/jeff
^ permalink raw reply
* Re: [PATCH v3 3/3] wifi: carl9170: fix buffer overflow in rx_stream failover path
From: Jeff Johnson @ 2026-07-01 18:32 UTC (permalink / raw)
To: Tristan Madani, Christian Lamparter
Cc: Johannes Berg, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421134929.325662-4-tristmd@gmail.com>
On 4/21/2026 6:49 AM, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The failover continuation in carl9170_rx_stream() copies the full tlen
> from the second USB transfer instead of capping at rx_failover_missing
> bytes. When both transfers are near maximum size, the total exceeds the
> 65535-byte failover SKB, triggering skb_over_panic.
>
> Limit the copy size to the missing byte count.
>
> Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch.
>
> Changes in v2:
> - Use min_t() instead of separate if-check, per Christian Lamparter.
>
> drivers/net/wireless/ath/carl9170/rx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
> index f6855efc05c0f..ccadc46385240 100644
> --- a/drivers/net/wireless/ath/carl9170/rx.c
> +++ b/drivers/net/wireless/ath/carl9170/rx.c
> @@ -918,7 +918,9 @@ static void carl9170_rx_stream(struct ar9170 *ar, void *buf, unsigned int len)
> }
> }
>
> - skb_put_data(ar->rx_failover, tbuf, tlen);
> + skb_put_data(ar->rx_failover, tbuf,
> + min_t(unsigned int, tlen,
checkpatch complains:
CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
no need to repost for this, I can fix when applying
> + ar->rx_failover_missing));
> ar->rx_failover_missing -= tlen;
>
> if (ar->rx_failover_missing <= 0) {
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox