* [PATCH wireless-next v2 1/6] wifi: ipw2x00: Rename michael_mic() to libipw_michael_mic()
From: Eric Biggers @ 2026-04-08 3:06 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: linux-crypto, linux-kernel, Herbert Xu, Eric Biggers
In-Reply-To: <20260408030651.80336-1-ebiggers@kernel.org>
Rename the driver-local michael_mic() function to libipw_michael_mic()
to prevent a name conflict with the common michael_mic() function.
Note that this code will be superseded later when libipw starts using
the common michael_mic(). This commit just prevents a bisection hazard.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c b/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c
index c6b0de8d91aea..c2cd6808fd0fe 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c
+++ b/drivers/net/wireless/intel/ipw2x00/libipw_crypto_tkip.c
@@ -462,11 +462,11 @@ static int libipw_tkip_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
skb_trim(skb, skb->len - 4);
return keyidx;
}
-static int michael_mic(struct crypto_shash *tfm_michael, u8 *key, u8 *hdr,
+static int libipw_michael_mic(struct crypto_shash *tfm_michael, u8 *key, u8 *hdr,
u8 *data, size_t data_len, u8 *mic)
{
SHASH_DESC_ON_STACK(desc, tfm_michael);
int err;
@@ -544,11 +544,11 @@ static int libipw_michael_mic_add(struct sk_buff *skb, int hdr_len,
return -1;
}
michael_mic_hdr(skb, tkey->tx_hdr);
pos = skb_put(skb, 8);
- if (michael_mic(tkey->tx_tfm_michael, &tkey->key[16], tkey->tx_hdr,
+ if (libipw_michael_mic(tkey->tx_tfm_michael, &tkey->key[16], tkey->tx_hdr,
skb->data + hdr_len, skb->len - 8 - hdr_len, pos))
return -1;
return 0;
}
@@ -582,11 +582,11 @@ static int libipw_michael_mic_verify(struct sk_buff *skb, int keyidx,
if (!tkey->key_set)
return -1;
michael_mic_hdr(skb, tkey->rx_hdr);
- if (michael_mic(tkey->rx_tfm_michael, &tkey->key[24], tkey->rx_hdr,
+ if (libipw_michael_mic(tkey->rx_tfm_michael, &tkey->key[24], tkey->rx_hdr,
skb->data + hdr_len, skb->len - 8 - hdr_len, mic))
return -1;
if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) {
struct ieee80211_hdr *hdr;
hdr = (struct ieee80211_hdr *)skb->data;
--
2.53.0
^ permalink raw reply related
* [PATCH wireless-next v2 0/6] Consolidate Michael MIC code into cfg80211
From: Eric Biggers @ 2026-04-08 3:06 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: linux-crypto, linux-kernel, Herbert Xu, Eric Biggers
Michael MIC is an inherently weak algorithm that is specific to WPA
TKIP, which itself was an interim security solution to replace the
broken WEP standard.
Currently, the primary implementation of Michael MIC in the kernel is
the one in the mac80211 module. But there's also a duplicate
implementation in crypto/michael_mic.c which is exposed via the
crypto_shash API. It's used only by a few wireless drivers.
Seeing as Michael MIC is specific to WPA TKIP and should never be used
elsewhere, this series removes the crypto subsystem's implementation of
Michael MIC, leaving just the wireless subsystem's implementation. To
do that, it moves the latter implementation from mac80211 to cfg80211,
then converts the above-mentioned drivers to use it.
This consolidates duplicate code and prevents other kernel subsystems
from accidentally using this insecure algorithm.
Changed in v2:
- Added preparatory patch to fix a bisection hazard.
- Moved michael_mic() to cfg80211 so that ipw2x00 doesn't have to
start depending on mac80211.
- Adjusted the 'fips_enabled' error messages, and updated the commit
messages to clarify that ath11k and ath12k don't actually work at
all in FIPS mode but that these patches don't aim to fix that.
Eric Biggers (6):
wifi: ipw2x00: Rename michael_mic() to libipw_michael_mic()
wifi: mac80211, cfg80211: Export michael_mic() and move it to cfg80211
wifi: ath11k: Use michael_mic() from cfg80211
wifi: ath12k: Use michael_mic() from cfg80211
wifi: ipw2x00: Use michael_mic() from cfg80211
crypto: Remove michael_mic from crypto_shash API
arch/arm/configs/omap2plus_defconfig | 1 -
arch/arm/configs/spitz_defconfig | 1 -
arch/arm64/configs/defconfig | 1 -
arch/m68k/configs/amiga_defconfig | 1 -
arch/m68k/configs/apollo_defconfig | 1 -
arch/m68k/configs/atari_defconfig | 1 -
arch/m68k/configs/bvme6000_defconfig | 1 -
arch/m68k/configs/hp300_defconfig | 1 -
arch/m68k/configs/mac_defconfig | 1 -
arch/m68k/configs/multi_defconfig | 1 -
arch/m68k/configs/mvme147_defconfig | 1 -
arch/m68k/configs/mvme16x_defconfig | 1 -
arch/m68k/configs/q40_defconfig | 1 -
arch/m68k/configs/sun3_defconfig | 1 -
arch/m68k/configs/sun3x_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 1 -
arch/mips/configs/decstation_64_defconfig | 1 -
arch/mips/configs/decstation_defconfig | 1 -
arch/mips/configs/decstation_r4k_defconfig | 1 -
arch/mips/configs/gpr_defconfig | 1 -
arch/mips/configs/ip32_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
arch/mips/configs/malta_qemu_32r6_defconfig | 1 -
arch/mips/configs/maltaaprp_defconfig | 1 -
arch/mips/configs/maltasmvp_defconfig | 1 -
arch/mips/configs/maltasmvp_eva_defconfig | 1 -
arch/mips/configs/maltaup_defconfig | 1 -
arch/mips/configs/mtx1_defconfig | 1 -
arch/mips/configs/rm200_defconfig | 1 -
arch/mips/configs/sb1250_swarm_defconfig | 1 -
arch/parisc/configs/generic-32bit_defconfig | 1 -
arch/parisc/configs/generic-64bit_defconfig | 1 -
arch/powerpc/configs/g5_defconfig | 1 -
arch/powerpc/configs/linkstation_defconfig | 1 -
arch/powerpc/configs/mvme5100_defconfig | 1 -
arch/powerpc/configs/powernv_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/ppc64e_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/powerpc/configs/ps3_defconfig | 1 -
arch/s390/configs/debug_defconfig | 1 -
arch/s390/configs/defconfig | 1 -
arch/sh/configs/sh2007_defconfig | 1 -
arch/sh/configs/titan_defconfig | 1 -
arch/sh/configs/ul2_defconfig | 1 -
arch/sparc/configs/sparc32_defconfig | 1 -
arch/sparc/configs/sparc64_defconfig | 1 -
crypto/Kconfig | 12 --
crypto/Makefile | 1 -
crypto/michael_mic.c | 176 ------------------
crypto/tcrypt.c | 4 -
crypto/testmgr.c | 6 -
crypto/testmgr.h | 50 -----
drivers/net/wireless/ath/ath11k/Kconfig | 1 -
drivers/net/wireless/ath/ath11k/dp.c | 2 -
drivers/net/wireless/ath/ath11k/dp_rx.c | 60 +-----
drivers/net/wireless/ath/ath11k/peer.h | 1 -
drivers/net/wireless/ath/ath12k/Kconfig | 1 -
drivers/net/wireless/ath/ath12k/dp.c | 2 -
drivers/net/wireless/ath/ath12k/dp_peer.h | 1 -
drivers/net/wireless/ath/ath12k/dp_rx.c | 55 +-----
drivers/net/wireless/ath/ath12k/dp_rx.h | 4 -
drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c | 7 +-
drivers/net/wireless/intel/ipw2x00/Kconfig | 1 -
.../intel/ipw2x00/libipw_crypto_tkip.c | 120 +-----------
include/linux/ieee80211.h | 5 +
net/mac80211/Makefile | 1 -
net/mac80211/michael.h | 22 ---
net/mac80211/wpa.c | 1 -
net/wireless/Makefile | 2 +-
.../michael.c => wireless/michael-mic.c} | 5 +-
71 files changed, 30 insertions(+), 557 deletions(-)
delete mode 100644 crypto/michael_mic.c
delete mode 100644 net/mac80211/michael.h
rename net/{mac80211/michael.c => wireless/michael-mic.c} (96%)
base-commit: aa5e9884a2d63aa20fc3396d369382c1ecd16109
--
2.53.0
^ permalink raw reply
* RE: [PATCH v2] rtlwifi: rtl8821ae: Remove dead code in rtl8821ae_update_hal_rate_table()
From: Ping-Ke Shih @ 2026-04-08 1:47 UTC (permalink / raw)
To: Chelsy Ratnawat
Cc: colin.i.king@gmail.com, johannes.berg@intel.com,
bhelgaas@google.com, arnd@arndb.de,
linux-wireless@vger.kernel.org
In-Reply-To: <20260407123427.14612-1-chelsyratnawat2001@gmail.com>
Chelsy Ratnawat <chelsyratnawat2001@gmail.com> wrote:
> The variable 'mimo_ps' is initialized to IEEE80211_SMPS_OFF and never
> modified throughout the function. This makes the condition checking for
> IEEE80211_SMPS_STATIC always evaluate to false, rendering the entire
> if-branch unreachable dead code.
>
> The error was reported by Coverity Scan.
>
> Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* pull-request: ath-next-20260407
From: Jeff Johnson @ 2026-04-08 1:51 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
The following changes since commit aa5e9884a2d63aa20fc3396d369382c1ecd16109:
Merge tag 'rtw-next-2026-04-02' of https://github.com/pkshih/rtw into wireless-next (2026-04-07 16:20:55 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260407
for you to fetch changes up to 8fb66931fe31094aa2e1b2a5c015050b8b4cb2ec:
wifi: ath12k: Enable IPQ5424 WiFi device support (2026-04-07 17:28:22 -0700)
----------------------------------------------------------------
ath.git patches for v7.1 (PR #3)
Add ath12k support for IPQ5424.
And of course there is the usual set of cleanups and bug fixes touching
the ath10k and ath12k drivers.
----------------------------------------------------------------
Avula Sri Charan (1):
wifi: ath12k: Skip adding inactive partner vdev info
Baochen Qiang (1):
wifi: ath10k: fix station lookup failure during disconnect
Harish Rachakonda (1):
wifi: ath12k: Support channel change stats
Raj Kumar Bhagat (2):
dt-bindings: net: wireless: add ath12k wifi device IPQ5424
wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
Roopni Devanathan (2):
wifi: ath12k: Rename hw_link_id to radio_idx in ath12k_ah_to_ar()
wifi: ath12k: Create symlink for each radio in a wiphy
Saravanakumar Duraisamy (3):
wifi: ath12k: Add ath12k_hw_params for IPQ5424
wifi: ath12k: add ath12k_hw_regs for IPQ5424
wifi: ath12k: Add CE remap hardware parameters for IPQ5424
Sowmiya Sree Elavalagan (1):
wifi: ath12k: Enable IPQ5424 WiFi device support
.../bindings/net/wireless/qcom,ipq5332-wifi.yaml | 1 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 26 +++---
drivers/net/wireless/ath/ath12k/ahb.c | 36 ++++----
drivers/net/wireless/ath/ath12k/ahb.h | 1 +
drivers/net/wireless/ath/ath12k/ce.h | 13 ++-
drivers/net/wireless/ath/ath12k/core.c | 4 +-
drivers/net/wireless/ath/ath12k/core.h | 13 +--
drivers/net/wireless/ath/ath12k/debugfs.c | 29 +++++--
.../net/wireless/ath/ath12k/debugfs_htt_stats.c | 72 ++++++++++++++++
.../net/wireless/ath/ath12k/debugfs_htt_stats.h | 26 ++++++
drivers/net/wireless/ath/ath12k/mac.c | 4 +-
drivers/net/wireless/ath/ath12k/wifi7/ahb.c | 8 ++
drivers/net/wireless/ath/ath12k/wifi7/hal.c | 7 ++
drivers/net/wireless/ath/ath12k/wifi7/hal.h | 3 +
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 88 ++++++++++++++++++++
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h | 1 +
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 97 +++++++++++++++++++++-
17 files changed, 383 insertions(+), 46 deletions(-)
^ permalink raw reply
* Re: [PATCH ath-next v5 0/6] wifi: ath12k: Enable IPQ5424 AHB WiFi device
From: Jeff Johnson @ 2026-04-08 0:50 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Raj Kumar Bhagat
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang, Sowmiya Sree Elavalagan,
Krzysztof Kozlowski
In-Reply-To: <20260407-ath12k-ipq5424-v5-0-8e96aa660ec4@oss.qualcomm.com>
On Tue, 07 Apr 2026 10:56:27 +0530, Raj Kumar Bhagat wrote:
> Add support for the new ath12k AHB device IPQ5424, as currently, Ath12k
> AHB only supports IPQ5332 WiFi devices.
>
> The IPQ5424 is an IEEE 802.11be 2 GHz WiFi device, supporting 4x4
> configurations. To enable the IPQ5424 device:
> - Add the necessary hardware parameters for IPQ5424.
> - Modify the boot-up sequence for ath12k AHB to accommodate the
> requirements of the IPQ5424 device.
>
> [...]
Applied, thanks!
[1/6] dt-bindings: net: wireless: add ath12k wifi device IPQ5424
commit: 3ebaf730b5832319726e12ebe634a7679eaf2e9b
[2/6] wifi: ath12k: Add ath12k_hw_params for IPQ5424
commit: b1ad1a052beda2ac0400d6d4cc05dd2e549a6936
[3/6] wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
commit: 74f5a619b1a6a06cc5e6246d326da5b6f2b0fcbd
[4/6] wifi: ath12k: add ath12k_hw_regs for IPQ5424
commit: 7e2131ba332f5ae62b6302eb889feeeea56a1691
[5/6] wifi: ath12k: Add CE remap hardware parameters for IPQ5424
commit: 38cff745fa7c0b006f95565a2e5de9f0cac13702
[6/6] wifi: ath12k: Enable IPQ5424 WiFi device support
commit: 8fb66931fe31094aa2e1b2a5c015050b8b4cb2ec
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath10k: fix station lookup failure during disconnect
From: Jeff Johnson @ 2026-04-08 0:50 UTC (permalink / raw)
To: Jeff Johnson, Baochen Qiang; +Cc: linux-wireless, ath10k, pmenzel
In-Reply-To: <20260325-ath10k-station-lookup-failure-v1-1-2e0c970f25d5@oss.qualcomm.com>
On Wed, 25 Mar 2026 11:05:01 +0800, Baochen Qiang wrote:
> Recent commit [1] moved station statistics collection to an earlier stage
> of the disconnect flow. With this change in place, ath10k fails to resolve
> the station entry when handling a peer stats event triggered during
> disconnect, resulting in log messages such as:
>
> wlp58s0: deauthenticating from 74:1a:e0:e7:b4:c8 by local choice (Reason: 3=DEAUTH_LEAVING)
> ath10k_pci 0000:3a:00.0: not found station for peer stats
> ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22
>
> [...]
Applied, thanks!
[1/1] wifi: ath10k: fix station lookup failure during disconnect
commit: 9a34a59c6086ae731a06b3e61b0951feef758648
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Create symlink for each radio in a wiphy
From: Jeff Johnson @ 2026-04-08 0:50 UTC (permalink / raw)
To: ath12k, Roopni Devanathan; +Cc: linux-wireless, Harshitha Prem
In-Reply-To: <20260402051402.3903795-1-roopni.devanathan@oss.qualcomm.com>
On Thu, 02 Apr 2026 10:44:02 +0530, Roopni Devanathan wrote:
> In single-wiphy design, when more than one radio is registered as a
> single-wiphy in the mac80211 layer, the following warnings are seen:
>
> 1. debugfs: File 'ath12k' in directory 'phy0' already present!
> 2. debugfs: File 'simulate_fw_crash' in directory 'pci-0000:57:00.0' already present!
> debugfs: File 'device_dp_stats' in directory 'pci-01777777777777777777777:57:00.0' already present!
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Create symlink for each radio in a wiphy
commit: 0ec4b904be72f78ba6ce6bb9a8aaf2eb6b9b1004
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Skip adding inactive partner vdev info
From: Jeff Johnson @ 2026-04-08 0:50 UTC (permalink / raw)
To: ath12k, Roopni Devanathan; +Cc: linux-wireless, Avula Sri Charan
In-Reply-To: <20260330040732.1847263-1-roopni.devanathan@oss.qualcomm.com>
On Mon, 30 Mar 2026 09:37:32 +0530, Roopni Devanathan wrote:
> Currently, a vdev that is created is considered active for partner link
> population. In case of an MLD station, non-associated link vdevs can be
> created but not started. Yet, they are added as partner links. This leads
> to the creation of stale FW partner entries which accumulate and cause
> assertions.
>
> To resolve this issue, check if the vdev is started and operating on a
> chosen frequency, i.e., arvif->is_started, instead of checking if the vdev
> is created, i.e., arvif->is_created. This determines if the vdev is active
> or not and skips adding it as a partner link if it's inactive.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Skip adding inactive partner vdev info
commit: 7d7dc26f72abb7a76abb4a68ebad75d5ab7b375e
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Support channel change stats
From: Jeff Johnson @ 2026-04-08 0:50 UTC (permalink / raw)
To: ath12k, Roopni Devanathan; +Cc: linux-wireless, Harish Rachakonda
In-Reply-To: <20260326050641.3066562-1-roopni.devanathan@oss.qualcomm.com>
On Thu, 26 Mar 2026 10:36:41 +0530, Roopni Devanathan wrote:
> Add support to request channel change stats from the firmware through
> HTT stats type 76. These stats give channel switch details like the
> channel that the radio changed to, its center frequency, time taken
> for the switch, chainmask details, etc.
>
> Sample output:
> echo 76 > /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats_type
> cat /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats
> Channel Change Timings:
> |PRIMARY CHANNEL FREQ|BANDWIDTH CENTER FREQ|PHYMODE|TX_CHAINMASK|RX_CHAINMASK|SWITCH TIME(us)|INI(us)|TPC+CTL(us)|CAL(us)|MISC(us)|CTL(us)|SW PROFILE|
> | 5200| 5200| 24| 15| 15| 448850| 2410| 10546| 434593| 1071| 1100| 4|
> | 5240| 5240| 24| 15| 15| 450730| 4106| 10524| 434528| 1306| 1150| 4|
> | 5180| 5210| 26| 15| 15| 467894| 4764| 10438| 451101| 1337| 1508| 4|
> | 5200| 5200| 0| 15| 15| 13838| 2692| 1736| 8558| 686| 802| 6|
> | 5180| 5180| 0| 15| 15| 13465| 3207| 855| 8579| 578| 760| 6|
> | 5200| 5200| 24| 15| 15| 570321| 2441| 10439| 555661| 1574| 949| 4|
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Support channel change stats
commit: af5708ed67fc562bc45fafbd0f95789c464c0105
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Rename hw_link_id to radio_idx in ath12k_ah_to_ar()
From: Jeff Johnson @ 2026-04-08 0:50 UTC (permalink / raw)
To: ath12k, Roopni Devanathan; +Cc: linux-wireless
In-Reply-To: <20260331045834.1181924-1-roopni.devanathan@oss.qualcomm.com>
On Tue, 31 Mar 2026 10:28:34 +0530, Roopni Devanathan wrote:
> ath12k_ah_to_ar() is returning radio from the given hardware based on the
> radio index passed. But, the variable that radio index is received at is
> wrongly named 'hw_link_id', which points to the hardware link index that
> comes from the firmware. This affects readability.
>
> Resolve this by renaming 'hw_link_id' to 'radio_idx'.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Rename hw_link_id to radio_idx in ath12k_ah_to_ar()
commit: ba563287beaa99c18144b2e39f63b89412abfd18
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH rtw-next 00/12] wifi: rtw89: Add support for RTL8922AU
From: Ping-Ke Shih @ 2026-04-08 0:46 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <e8d10b96-f305-46f4-a473-2592f237f871@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>
> On 02/04/2026 03:48, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> On 30/03/2026 05:53, Ping-Ke Shih wrote:
> >>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>>> Often one or more of these messages appears when the chip powers on:
> >>>>
> >>>> [ +2.167037] rtw89_8922au 1-2:1.0: failed to wait RF DACK
> >>>>
> >>>> [ +2.942749] rtw89_8922au 1-2:1.0: failed to wait RF TSSI
> >>>>
> >>>> [ +0.019006] rtw89_8922au 2-4:1.0: failed to wait RF PRE_NTFY
> >>>>
> >>>> [ +5.985900] rtw89_8922au 2-4:1.0: failed to wait RF DPK
> >>>>
> >>>> It's unclear why.
> >>>
> >>> RTL8922D done RF calibrations by firmware one by one, so driver should
> >>> wait for previous one done, and trigger next one. However, it'd be
> >>> well to just do waiting at the last to wait for all calibrations.
> >>>
> >>> Try to enlarge waiting time in rtw8922a_rfk_channel().
> >>>
> >>
> >> I was convinced I tried that already, but no.
> >>
> >> After increasing all delays a bit the warnings are much more rare.
> >
> > Turn of debug mask RTW89_DBG_RFK and set a very large timeout time, and
> > do connection >20 times and then check "RF %s takes %lld ms to complete"
> > to see the maximum value in your environment.
> >
> > Please share the number for each RF calibration after your experiments.
> >
>
> I changed every delay to 500, then ran this, once with the adapter in
> USB 2, once in USB 3:
>
> for i in {01..20}; do nmcli connection up "<2.4 GHz SSID>"; sleep 10; nmcli connection up "<5 GHz SSID>";
> sleep 10; done
>
> There were no "failed to wait RF" warnings.
>
> These are the results after processing with "sort --unique":
>
> RF DACK takes 15 ms to complete
> RF DACK takes 16 ms to complete
> RF DACK takes 44 ms to complete
> RF DACK takes 72 ms to complete
>
> RF DPK takes 23 ms to complete
> RF DPK takes 24 ms to complete
> RF DPK takes 27 ms to complete
> RF DPK takes 30 ms to complete
>
> RF IQK takes 48 ms to complete
> RF IQK takes 49 ms to complete
> RF IQK takes 50 ms to complete
>
> RF PRE_NTFY takes 0 ms to complete
> RF PRE_NTFY takes 1 ms to complete
>
> RF RX_DCK takes 8 ms to complete
> RF RX_DCK takes 9 ms to complete
> RF RX_DCK takes 11 ms to complete
> RF RX_DCK takes 23 ms to complete
> RF RX_DCK takes 24 ms to complete
> RF RX_DCK takes 27 ms to complete
> RF RX_DCK takes 38 ms to complete
> RF RX_DCK takes 39 ms to complete
> RF RX_DCK takes 53 ms to complete
> RF RX_DCK takes 54 ms to complete
> RF RX_DCK takes 58 ms to complete
> RF RX_DCK takes 70 ms to complete
> RF RX_DCK takes 110 ms to complete
>
> RF TSSI takes 1 ms to complete
> RF TSSI takes 2 ms to complete
> RF TSSI takes 23 ms to complete
> RF TSSI takes 24 ms to complete
>
> RF TXGAPK takes 9 ms to complete
> RF TXGAPK takes 10 ms to complete
> RF TXGAPK takes 17 ms to complete
> RF TXGAPK takes 18 ms to complete
>
> I also left it unconnected and constantly scanning for a few minutes.
> RTW89_TSSI_SCAN always takes 1-2 ms.
>
You can make a set of number or a constant multiple for USB devices.
As we want hardware restart flow including RF calibration within a
limited time, I'd not enlarge these numbers for PCIE devices.
Ping-Ke
^ permalink raw reply
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Trilok Soni @ 2026-04-07 22:14 UTC (permalink / raw)
To: Sumit Garg, Jorge Ramirez, vikash.garodia
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, dikshita.agarwal, bod, mchehab, elder, andrew+netdev,
davem, edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
mukesh.ojha, pavan.kondeti, tonyh, vignesh.viswanathan,
srinivas.kandagatla, amirreza.zarrabi, jens.wiklander, op-tee,
apurupa, skare, harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <adOcMsk8a_Clb4WZ@sumit-xelite>
On 4/6/2026 4:42 AM, Sumit Garg wrote:
> Hi Jorge,
>
> On Fri, Apr 03, 2026 at 11:37:07AM +0200, Jorge Ramirez wrote:
>> On 27/03/26 18:40:39, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
>>> TZ service allows to support multiple TZ implementation backends like QTEE
>>> based SCM PAS service, OP-TEE based PAS service and any further future TZ
>>> backend service.
>>
>> OP-TEE based PAS service relies on the linux driver to configure the
>> iommu (just as it is done on the no_tz case). This generic patch does
>> not cover that requirement.
>
> That's exactly the reason why the kodiak EL2 dtso disables venus by
> default in patch #1 due to missing IOMMU configuration.
>
>>
>> Because of that, it is probably better if the commit message doesnt
>> mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
>> implement the same restrictions that QTEE (ie, iommu configuration).
>
> The scope for this patch is to just adopt the generic PAS layer without
> affecting the client functionality.
>
>>
>> I can send an RFC for OP-TEE support based on the integration work being
>> carried out here [1]
>
> @Vikash may know better details about support for IOMMU configuration
> for venus since it's a generic functionality missing when Linux runs in
> EL2 whether it's with QTEE or OP-TEE.
>
> However, feel free to propose your work to initiate discussions again.
Vikas and team depends on some of the IOMMU patches to get accepted
before they enable the EL2 venus support. Please reach out to him
and Prakash Gupta at Qualcomm.
>
>>
>> [1] https://github.com/OP-TEE/optee_os/pull/7721#discussion_r3016923507
>
> -Sumit
^ permalink raw reply
* Re: [PATCH rtw-next 00/12] wifi: rtw89: Add support for RTL8922AU
From: Bitterblue Smith @ 2026-04-07 20:41 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <0cbfd38ffd0b46e899885c83889d060b@realtek.com>
On 02/04/2026 03:48, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> On 30/03/2026 05:53, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>> Often one or more of these messages appears when the chip powers on:
>>>>
>>>> [ +2.167037] rtw89_8922au 1-2:1.0: failed to wait RF DACK
>>>>
>>>> [ +2.942749] rtw89_8922au 1-2:1.0: failed to wait RF TSSI
>>>>
>>>> [ +0.019006] rtw89_8922au 2-4:1.0: failed to wait RF PRE_NTFY
>>>>
>>>> [ +5.985900] rtw89_8922au 2-4:1.0: failed to wait RF DPK
>>>>
>>>> It's unclear why.
>>>
>>> RTL8922D done RF calibrations by firmware one by one, so driver should
>>> wait for previous one done, and trigger next one. However, it'd be
>>> well to just do waiting at the last to wait for all calibrations.
>>>
>>> Try to enlarge waiting time in rtw8922a_rfk_channel().
>>>
>>
>> I was convinced I tried that already, but no.
>>
>> After increasing all delays a bit the warnings are much more rare.
>
> Turn of debug mask RTW89_DBG_RFK and set a very large timeout time, and
> do connection >20 times and then check "RF %s takes %lld ms to complete"
> to see the maximum value in your environment.
>
> Please share the number for each RF calibration after your experiments.
>
I changed every delay to 500, then ran this, once with the adapter in
USB 2, once in USB 3:
for i in {01..20}; do nmcli connection up "<2.4 GHz SSID>"; sleep 10; nmcli connection up "<5 GHz SSID>"; sleep 10; done
There were no "failed to wait RF" warnings.
These are the results after processing with "sort --unique":
RF DACK takes 15 ms to complete
RF DACK takes 16 ms to complete
RF DACK takes 44 ms to complete
RF DACK takes 72 ms to complete
RF DPK takes 23 ms to complete
RF DPK takes 24 ms to complete
RF DPK takes 27 ms to complete
RF DPK takes 30 ms to complete
RF IQK takes 48 ms to complete
RF IQK takes 49 ms to complete
RF IQK takes 50 ms to complete
RF PRE_NTFY takes 0 ms to complete
RF PRE_NTFY takes 1 ms to complete
RF RX_DCK takes 8 ms to complete
RF RX_DCK takes 9 ms to complete
RF RX_DCK takes 11 ms to complete
RF RX_DCK takes 23 ms to complete
RF RX_DCK takes 24 ms to complete
RF RX_DCK takes 27 ms to complete
RF RX_DCK takes 38 ms to complete
RF RX_DCK takes 39 ms to complete
RF RX_DCK takes 53 ms to complete
RF RX_DCK takes 54 ms to complete
RF RX_DCK takes 58 ms to complete
RF RX_DCK takes 70 ms to complete
RF RX_DCK takes 110 ms to complete
RF TSSI takes 1 ms to complete
RF TSSI takes 2 ms to complete
RF TSSI takes 23 ms to complete
RF TSSI takes 24 ms to complete
RF TXGAPK takes 9 ms to complete
RF TXGAPK takes 10 ms to complete
RF TXGAPK takes 17 ms to complete
RF TXGAPK takes 18 ms to complete
I also left it unconnected and constantly scanning for a few minutes.
RTW89_TSSI_SCAN always takes 1-2 ms.
>>
>>>>
>>>> It seems to work well anyway.
>>>>
>>>
>>> If you can yield the highest rate (MCS13), I'd say it is fine.
>>>
>>> Ping-Ke
>>>
>>
>> Testing with RTL8832CU (Brostrend AX8) in AP mode, the RTL8912AU can
>> reach 1.5 Gbps (MCS10) RX, 1 Gbps TX.
>>
>> I used the RTL8832CU because my router is not working well with 160
>> MHz.
>
> Since rtw89 only support beamformee (no beamformer), beamforming can't
> work between two rtw89 devices. More, two antenna can't have good
> beamforming performance. I think this is a point that it is hard to
> yield the highest rate.
>
> Another point may be the RF performance. If the warning messages of
> RF calibration disappeared, I'd say this might not a problem.
>
> Let's mention this in commit message of 12/12.
>
> Ping-Ke
>
^ permalink raw reply
* Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction
From: Joshua Klinesmith @ 2026-04-07 17:35 UTC (permalink / raw)
To: Ben Greear
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
linux-kernel, stable
In-Reply-To: <5e197844-804e-51d7-a1de-e9e7686bad0a@candelatech.com>
On 4/7/26 Ben Greear wrote:
> If you talked some AI bot into finding non public source, or if it can
> actually generate useful c code out of vendor binaries, then I am not
> sure how legit that is to even post.
Hi Ben,
Thank you for raising this point. After considering your feedback, I
realize my workflow has involved analysis of proprietary vendor
binaries, which raises legitimate provenance and licensing concerns
for kernel submissions. I should not have submitted patches derived
from that process.
I am withdrawing my outstanding patches from this series. I will not
submit further patches based on this workflow.
Going forward, I will limit my contributions to fixes based solely on
publicly available GPL-licensed sources and will clearly document the
source and rationale in my commit messages.
Thank you again for taking the time to flag this.
On Tue, Apr 7, 2026 at 1:31 PM Ben Greear <greearb@candelatech.com> wrote:
>
> On 4/7/26 09:58, Joshua Klinesmith wrote:
> > On 4/7/26 12:31, Ben Greear wrote:
> >> I am more concerned about the trickier patches that you have been posting
> >> that is utilizing work from upstream vendor code. How much of that is pure
> >> AI driven? How much testing has been done to see if there are actual stability
> >> or performance improvements when testing actual hardware?
> >
> > Hi Ben,
> >
> > To be straightforward: my workflow involves pulling GitHub issues into
> > AI prompts along with firmware analysis tooling to identify potential
> > fixes. I have an MT6000 available, but I have not been doing thorough
> > on-hardware testing before submitting. That is a gap I need to close.
> >
> > I will hold off on submitting further patches to the mt76 driver until
> > I have a proper test workflow in place and can verify changes on real
> > hardware.
> >
> > I appreciate you raising this directly.
>
> Please be sure to add note about using AI to patch submissions,
> and link to original bug reports you are trying to fix.
>
> Possibly some of this is useful, but you need to do significant tests
> with real hardware if you are proposing non-trivial changes.
>
> If you are referencing publicly available upstream driver source, then
> be clear about that and provide links. 'Reverse Engineering' could mean a lot of things,
> some of which is grey area for patch submission. If you talked some AI bot
> into finding non public source, or if it can actually generate useful c code out of
> vendor binaries, then I am not sure how legit that is to even post.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
>
^ permalink raw reply
* Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction
From: Ben Greear @ 2026-04-07 17:31 UTC (permalink / raw)
To: Joshua Klinesmith
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
linux-kernel, stable
In-Reply-To: <CANs=ypgceH4NL5xOr2C1FPp8KvDCcUWTu10i+DiXntuOmAfJVA@mail.gmail.com>
On 4/7/26 09:58, Joshua Klinesmith wrote:
> On 4/7/26 12:31, Ben Greear wrote:
>> I am more concerned about the trickier patches that you have been posting
>> that is utilizing work from upstream vendor code. How much of that is pure
>> AI driven? How much testing has been done to see if there are actual stability
>> or performance improvements when testing actual hardware?
>
> Hi Ben,
>
> To be straightforward: my workflow involves pulling GitHub issues into
> AI prompts along with firmware analysis tooling to identify potential
> fixes. I have an MT6000 available, but I have not been doing thorough
> on-hardware testing before submitting. That is a gap I need to close.
>
> I will hold off on submitting further patches to the mt76 driver until
> I have a proper test workflow in place and can verify changes on real
> hardware.
>
> I appreciate you raising this directly.
Please be sure to add note about using AI to patch submissions,
and link to original bug reports you are trying to fix.
Possibly some of this is useful, but you need to do significant tests
with real hardware if you are proposing non-trivial changes.
If you are referencing publicly available upstream driver source, then
be clear about that and provide links. 'Reverse Engineering' could mean a lot of things,
some of which is grey area for patch submission. If you talked some AI bot
into finding non public source, or if it can actually generate useful c code out of
vendor binaries, then I am not sure how legit that is to even post.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction
From: Joshua Klinesmith @ 2026-04-07 16:58 UTC (permalink / raw)
To: Ben Greear
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
linux-kernel, stable
In-Reply-To: <ddc4ccfe-27e0-7558-9b5b-27b4c4fe54b3@candelatech.com>
On 4/7/26 12:31, Ben Greear wrote:
> I am more concerned about the trickier patches that you have been posting
> that is utilizing work from upstream vendor code. How much of that is pure
> AI driven? How much testing has been done to see if there are actual stability
> or performance improvements when testing actual hardware?
Hi Ben,
To be straightforward: my workflow involves pulling GitHub issues into
AI prompts along with firmware analysis tooling to identify potential
fixes. I have an MT6000 available, but I have not been doing thorough
on-hardware testing before submitting. That is a gap I need to close.
I will hold off on submitting further patches to the mt76 driver until
I have a proper test workflow in place and can verify changes on real
hardware.
I appreciate you raising this directly.
Joshua
On Tue, Apr 7, 2026 at 12:31 PM Ben Greear <greearb@candelatech.com> wrote:
>
> On 4/7/26 09:00, Joshua Klinesmith wrote:
> > On 4/7/26 11:25, Ben Greear wrote:
> >> How much of this is AI driven? As far as I know, mt7925 is a 2x2 chipset
> >> at max. So while the patch may be correct, it may also not matter in practice
> >> and at least may not need to be backported into stable.
> >
> > Hi Ben,
> >
> > Please accept my apologies. You are correct that the mt7925 is a 2x2
> > chipset, so this does not have a practical impact and should not have
> > been tagged for stable. I did not read the documentation in its
> > entirety before submitting, and that is on me.
> >
> > I will be much more careful and diligent with testing and review going forward.
> >
> > Thanks for the feedback.
> >
> > Joshua
>
> I am more concerned about the trickier patches that you have been posting
> that is utilizing work from upstream vendor code. How much of that is pure
> AI driven? How much testing has been done to see if there are actual stability
> or performance improvements when testing actual hardware?
>
> Thanks,
> Ben
>
> > On Tue, Apr 7, 2026 at 11:25 AM Ben Greear <greearb@candelatech.com> wrote:
> >>
> >> On 4/6/26 16:47, Joshua Klinesmith wrote:
> >>> The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
> >>> spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
> >>> for the fourth byte, consistent with the other three chains and
> >>> with the RCPI3 definitions used elsewhere in the driver
> >>> (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).
> >>
> >> Hello Joshua,
> >>
> >> How much of this is AI driven? As far as I know, mt7925 is a 2x2 chipset
> >> at max. So while the patch may be correct, it may also not matter in practice
> >> and at least may not need to be backported into stable. If it is a minor
> >> cleanup that doesn't actually matter, that should be described more clearly
> >> in the commit message?
> >>
> >> Some of your patches are touching tricky parts of the code and making
> >> subtle comparisons against how the vendor's driver is written. How well has
> >> this been tested and reviewed by a knowledgeable human in general?
> >>
> >> Thanks,
> >> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
>
^ permalink raw reply
* Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction
From: Ben Greear @ 2026-04-07 16:31 UTC (permalink / raw)
To: Joshua Klinesmith
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
linux-kernel, stable
In-Reply-To: <CANs=ypgdgB_3stm5bCvO8RTat-sxs0N6SAaeYSQ-dyq43U-ZBg@mail.gmail.com>
On 4/7/26 09:00, Joshua Klinesmith wrote:
> On 4/7/26 11:25, Ben Greear wrote:
>> How much of this is AI driven? As far as I know, mt7925 is a 2x2 chipset
>> at max. So while the patch may be correct, it may also not matter in practice
>> and at least may not need to be backported into stable.
>
> Hi Ben,
>
> Please accept my apologies. You are correct that the mt7925 is a 2x2
> chipset, so this does not have a practical impact and should not have
> been tagged for stable. I did not read the documentation in its
> entirety before submitting, and that is on me.
>
> I will be much more careful and diligent with testing and review going forward.
>
> Thanks for the feedback.
>
> Joshua
I am more concerned about the trickier patches that you have been posting
that is utilizing work from upstream vendor code. How much of that is pure
AI driven? How much testing has been done to see if there are actual stability
or performance improvements when testing actual hardware?
Thanks,
Ben
> On Tue, Apr 7, 2026 at 11:25 AM Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 4/6/26 16:47, Joshua Klinesmith wrote:
>>> The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
>>> spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
>>> for the fourth byte, consistent with the other three chains and
>>> with the RCPI3 definitions used elsewhere in the driver
>>> (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).
>>
>> Hello Joshua,
>>
>> How much of this is AI driven? As far as I know, mt7925 is a 2x2 chipset
>> at max. So while the patch may be correct, it may also not matter in practice
>> and at least may not need to be backported into stable. If it is a minor
>> cleanup that doesn't actually matter, that should be described more clearly
>> in the commit message?
>>
>> Some of your patches are touching tricky parts of the code and making
>> subtle comparisons against how the vendor's driver is written. How well has
>> this been tested and reviewed by a knowledgeable human in general?
>>
>> Thanks,
>> Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH ath-next v5 6/6] wifi: ath12k: Enable IPQ5424 WiFi device support
From: Rameshkumar Sundaram @ 2026-04-07 16:24 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Sowmiya Sree Elavalagan, Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-6-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com>
>
> Currently, ath12k AHB (in IPQ5332) uses SCM calls to authenticate the
> firmware image to bring up userpd. From IPQ5424 onwards, Q6 firmware can
> directly communicate with the Trusted Management Engine - Lite (TME-L),
> eliminating the need for SCM calls for userpd bring-up.
>
> Hence, to enable IPQ5424 device support, use qcom_mdt_load_no_init() and
> skip the SCM call as Q6 will directly authenticate the userpd firmware.
>
> 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
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com>
> Co-developed-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/ahb.c | 36 ++++++++++++++++++-----------
> drivers/net/wireless/ath/ath12k/ahb.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/ahb.c | 8 +++++++
> 3 files changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
> index 9a4d34e49104..2dcf0a52e4c1 100644
> --- a/drivers/net/wireless/ath/ath12k/ahb.c
> +++ b/drivers/net/wireless/ath/ath12k/ahb.c
> @@ -382,8 +382,12 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
> ATH12K_AHB_UPD_SWID;
>
> /* Load FW image to a reserved memory location */
> - ret = qcom_mdt_load(dev, fw, fw_name, pasid, mem_region, mem_phys, mem_size,
> - &mem_phys);
> + if (ab_ahb->scm_auth_enabled)
> + ret = qcom_mdt_load(dev, fw, fw_name, pasid, mem_region,
> + mem_phys, mem_size, &mem_phys);
> + else
> + ret = qcom_mdt_load_no_init(dev, fw, fw_name, mem_region,
> + mem_phys, mem_size, &mem_phys);
> if (ret) {
> ath12k_err(ab, "Failed to load MDT segments: %d\n", ret);
> goto err_fw;
> @@ -414,11 +418,13 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
> goto err_fw2;
> }
>
> - /* Authenticate FW image using peripheral ID */
> - ret = qcom_scm_pas_auth_and_reset(pasid);
> - if (ret) {
> - ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
> - goto err_fw2;
> + if (ab_ahb->scm_auth_enabled) {
> + /* Authenticate FW image using peripheral ID */
> + ret = qcom_scm_pas_auth_and_reset(pasid);
> + if (ret) {
> + ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
> + goto err_fw2;
> + }
> }
>
> /* Instruct Q6 to spawn userPD thread */
> @@ -475,13 +481,15 @@ static void ath12k_ahb_power_down(struct ath12k_base *ab, bool is_suspend)
>
> qcom_smem_state_update_bits(ab_ahb->stop_state, BIT(ab_ahb->stop_bit), 0);
>
> - pasid = (u32_encode_bits(ab_ahb->userpd_id, ATH12K_USERPD_ID_MASK)) |
> - ATH12K_AHB_UPD_SWID;
> - /* Release the firmware */
> - ret = qcom_scm_pas_shutdown(pasid);
> - if (ret)
> - ath12k_err(ab, "scm pas shutdown failed for userPD%d: %d\n",
> - ab_ahb->userpd_id, ret);
> + if (ab_ahb->scm_auth_enabled) {
> + pasid = (u32_encode_bits(ab_ahb->userpd_id, ATH12K_USERPD_ID_MASK)) |
> + ATH12K_AHB_UPD_SWID;
> + /* Release the firmware */
> + ret = qcom_scm_pas_shutdown(pasid);
> + if (ret)
> + ath12k_err(ab, "scm pas shutdown failed for userPD%d\n",
> + ab_ahb->userpd_id);
> + }
> }
>
> static void ath12k_ahb_init_qmi_ce_config(struct ath12k_base *ab)
> diff --git a/drivers/net/wireless/ath/ath12k/ahb.h b/drivers/net/wireless/ath/ath12k/ahb.h
> index be9e31b3682d..0fa15daaa3e6 100644
> --- a/drivers/net/wireless/ath/ath12k/ahb.h
> +++ b/drivers/net/wireless/ath/ath12k/ahb.h
> @@ -68,6 +68,7 @@ struct ath12k_ahb {
> int userpd_irq_num[ATH12K_USERPD_MAX_IRQ];
> const struct ath12k_ahb_ops *ahb_ops;
> const struct ath12k_ahb_device_family_ops *device_family_ops;
> + bool scm_auth_enabled;
> };
>
> struct ath12k_ahb_driver {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/ahb.c b/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
> index a6c5f7689edd..6a8b8b2a56f9 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
> @@ -19,6 +19,9 @@ static const struct of_device_id ath12k_wifi7_ahb_of_match[] = {
> { .compatible = "qcom,ipq5332-wifi",
> .data = (void *)ATH12K_HW_IPQ5332_HW10,
> },
> + { .compatible = "qcom,ipq5424-wifi",
> + .data = (void *)ATH12K_HW_IPQ5424_HW10,
> + },
> { }
> };
>
> @@ -38,6 +41,11 @@ static int ath12k_wifi7_ahb_probe(struct platform_device *pdev)
> switch (hw_rev) {
> case ATH12K_HW_IPQ5332_HW10:
> ab_ahb->userpd_id = ATH12K_IPQ5332_USERPD_ID;
> + ab_ahb->scm_auth_enabled = true;
> + break;
> + case ATH12K_HW_IPQ5424_HW10:
> + ab_ahb->userpd_id = ATH12K_IPQ5332_USERPD_ID;
> + ab_ahb->scm_auth_enabled = false;
> break;
> default:
> return -EOPNOTSUPP;
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 5/6] wifi: ath12k: Add CE remap hardware parameters for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:23 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-5-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add CE remap hardware parameters for Ath12k AHB device IPQ5424.
>
> 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
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/ce.h | 13 +++++++++----
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 22 +++++++++++++++++-----
> 2 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/ce.h b/drivers/net/wireless/ath/ath12k/ce.h
> index df4f2a4f8480..009cddf2d68d 100644
> --- a/drivers/net/wireless/ath/ath12k/ce.h
> +++ b/drivers/net/wireless/ath/ath12k/ce.h
> @@ -38,10 +38,15 @@
> #define PIPEDIR_INOUT 3 /* bidirectional */
> #define PIPEDIR_INOUT_H2H 4 /* bidirectional, host to host */
>
> -/* CE address/mask */
> -#define CE_HOST_IE_ADDRESS 0x75804C
> -#define CE_HOST_IE_2_ADDRESS 0x758050
> -#define CE_HOST_IE_3_ADDRESS CE_HOST_IE_ADDRESS
> +/* IPQ5332 CE address/mask */
> +#define CE_HOST_IPQ5332_IE_ADDRESS 0x75804C
> +#define CE_HOST_IPQ5332_IE_2_ADDRESS 0x758050
> +#define CE_HOST_IPQ5332_IE_3_ADDRESS CE_HOST_IPQ5332_IE_ADDRESS
> +
> +/* IPQ5424 CE address/mask */
> +#define CE_HOST_IPQ5424_IE_ADDRESS 0x21804C
> +#define CE_HOST_IPQ5424_IE_2_ADDRESS 0x218050
> +#define CE_HOST_IPQ5424_IE_3_ADDRESS CE_HOST_IPQ5424_IE_ADDRESS
>
> #define CE_HOST_IE_3_SHIFT 0xC
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> index 2b5d1f7e9e04..cb3185850439 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> @@ -329,9 +329,15 @@ static const struct ath12k_hw_ring_mask ath12k_wifi7_hw_ring_mask_wcn7850 = {
> };
>
> static const struct ce_ie_addr ath12k_wifi7_ce_ie_addr_ipq5332 = {
> - .ie1_reg_addr = CE_HOST_IE_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> - .ie2_reg_addr = CE_HOST_IE_2_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> - .ie3_reg_addr = CE_HOST_IE_3_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> + .ie1_reg_addr = CE_HOST_IPQ5332_IE_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> + .ie2_reg_addr = CE_HOST_IPQ5332_IE_2_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> + .ie3_reg_addr = CE_HOST_IPQ5332_IE_3_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> +};
> +
> +static const struct ce_ie_addr ath12k_wifi7_ce_ie_addr_ipq5424 = {
> + .ie1_reg_addr = CE_HOST_IPQ5424_IE_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .ie2_reg_addr = CE_HOST_IPQ5424_IE_2_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .ie3_reg_addr = CE_HOST_IPQ5424_IE_3_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
> };
>
> static const struct ce_remap ath12k_wifi7_ce_remap_ipq5332 = {
> @@ -340,6 +346,12 @@ static const struct ce_remap ath12k_wifi7_ce_remap_ipq5332 = {
> .cmem_offset = HAL_SEQ_WCSS_CMEM_OFFSET,
> };
>
> +static const struct ce_remap ath12k_wifi7_ce_remap_ipq5424 = {
> + .base = HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .size = HAL_IPQ5424_CE_SIZE,
> + .cmem_offset = HAL_SEQ_WCSS_CMEM_OFFSET,
> +};
> +
> static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
> {
> .name = "qcn9274 hw1.0",
> @@ -824,8 +836,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
> .iova_mask = 0,
> .supports_aspm = false,
>
> - .ce_ie_addr = NULL,
> - .ce_remap = NULL,
> + .ce_ie_addr = &ath12k_wifi7_ce_ie_addr_ipq5424,
> + .ce_remap = &ath12k_wifi7_ce_remap_ipq5424,
> .bdf_addr_offset = 0x940000,
>
> .current_cc_support = false,
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 4/6] wifi: ath12k: add ath12k_hw_regs for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:22 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-4-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add register addresses (ath12k_hw_regs) for ath12k AHB based
> WiFi 7 device IPQ5424.
>
> 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
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/wifi7/hal.c | 2 +-
> drivers/net/wireless/ath/ath12k/wifi7/hal.h | 3 +
> .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 88 ++++++++++++++++++++++
> .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h | 1 +
> 4 files changed, 93 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> index c2cc99a83f09..a0a1902fb491 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> @@ -55,7 +55,7 @@ static const struct ath12k_hw_version_map ath12k_wifi7_hw_ver_map[] = {
> .hal_desc_sz = sizeof(struct hal_rx_desc_qcn9274_compact),
> .tcl_to_wbm_rbm_map = ath12k_hal_tcl_to_wbm_rbm_map_qcn9274,
> .hal_params = &ath12k_hw_hal_params_ipq5332,
> - .hw_regs = NULL,
> + .hw_regs = &ipq5424_regs,
> },
> };
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.h b/drivers/net/wireless/ath/ath12k/wifi7/hal.h
> index 9337225a5253..3d9386198893 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal.h
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.h
> @@ -364,6 +364,9 @@
> #define HAL_IPQ5332_CE_WFSS_REG_BASE 0x740000
> #define HAL_IPQ5332_CE_SIZE 0x100000
>
> +#define HAL_IPQ5424_CE_WFSS_REG_BASE 0x200000
> +#define HAL_IPQ5424_CE_SIZE 0x100000
> +
> #define HAL_RX_MAX_BA_WINDOW 256
>
> #define HAL_DEFAULT_BE_BK_VI_REO_TIMEOUT_USEC (100 * 1000)
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
> index 41c918eb1767..ba9ce1e718e8 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
> @@ -484,6 +484,94 @@ const struct ath12k_hw_regs ipq5332_regs = {
> HAL_IPQ5332_CE_WFSS_REG_BASE,
> };
>
> +const struct ath12k_hw_regs ipq5424_regs = {
> + /* SW2TCL(x) R0 ring configuration address */
> + .tcl1_ring_id = 0x00000918,
> + .tcl1_ring_misc = 0x00000920,
> + .tcl1_ring_tp_addr_lsb = 0x0000092c,
> + .tcl1_ring_tp_addr_msb = 0x00000930,
> + .tcl1_ring_consumer_int_setup_ix0 = 0x00000940,
> + .tcl1_ring_consumer_int_setup_ix1 = 0x00000944,
> + .tcl1_ring_msi1_base_lsb = 0x00000958,
> + .tcl1_ring_msi1_base_msb = 0x0000095c,
> + .tcl1_ring_base_lsb = 0x00000910,
> + .tcl1_ring_base_msb = 0x00000914,
> + .tcl1_ring_msi1_data = 0x00000960,
> + .tcl2_ring_base_lsb = 0x00000988,
> + .tcl_ring_base_lsb = 0x00000b68,
> +
> + /* TCL STATUS ring address */
> + .tcl_status_ring_base_lsb = 0x00000d48,
> +
> + /* REO DEST ring address */
> + .reo2_ring_base = 0x00000578,
> + .reo1_misc_ctrl_addr = 0x00000b9c,
> + .reo1_sw_cookie_cfg0 = 0x0000006c,
> + .reo1_sw_cookie_cfg1 = 0x00000070,
> + .reo1_qdesc_lut_base0 = 0x00000074,
> + .reo1_qdesc_lut_base1 = 0x00000078,
> + .reo1_ring_base_lsb = 0x00000500,
> + .reo1_ring_base_msb = 0x00000504,
> + .reo1_ring_id = 0x00000508,
> + .reo1_ring_misc = 0x00000510,
> + .reo1_ring_hp_addr_lsb = 0x00000514,
> + .reo1_ring_hp_addr_msb = 0x00000518,
> + .reo1_ring_producer_int_setup = 0x00000524,
> + .reo1_ring_msi1_base_lsb = 0x00000548,
> + .reo1_ring_msi1_base_msb = 0x0000054C,
> + .reo1_ring_msi1_data = 0x00000550,
> + .reo1_aging_thres_ix0 = 0x00000B28,
> + .reo1_aging_thres_ix1 = 0x00000B2C,
> + .reo1_aging_thres_ix2 = 0x00000B30,
> + .reo1_aging_thres_ix3 = 0x00000B34,
> +
> + /* REO Exception ring address */
> + .reo2_sw0_ring_base = 0x000008c0,
> +
> + /* REO Reinject ring address */
> + .sw2reo_ring_base = 0x00000320,
> + .sw2reo1_ring_base = 0x00000398,
> +
> + /* REO cmd ring address */
> + .reo_cmd_ring_base = 0x000002A8,
> +
> + /* REO status ring address */
> + .reo_status_ring_base = 0x00000aa0,
> +
> + /* WBM idle link ring address */
> + .wbm_idle_ring_base_lsb = 0x00000d3c,
> + .wbm_idle_ring_misc_addr = 0x00000d4c,
> + .wbm_r0_idle_list_cntl_addr = 0x00000240,
> + .wbm_r0_idle_list_size_addr = 0x00000244,
> + .wbm_scattered_ring_base_lsb = 0x00000250,
> + .wbm_scattered_ring_base_msb = 0x00000254,
> + .wbm_scattered_desc_head_info_ix0 = 0x00000260,
> + .wbm_scattered_desc_head_info_ix1 = 0x00000264,
> + .wbm_scattered_desc_tail_info_ix0 = 0x00000270,
> + .wbm_scattered_desc_tail_info_ix1 = 0x00000274,
> + .wbm_scattered_desc_ptr_hp_addr = 0x0000027c,
> +
> + /* SW2WBM release ring address */
> + .wbm_sw_release_ring_base_lsb = 0x0000037c,
> +
> + /* WBM2SW release ring address */
> + .wbm0_release_ring_base_lsb = 0x00000e08,
> + .wbm1_release_ring_base_lsb = 0x00000e80,
> +
> + /* PPE release ring address */
> + .ppe_rel_ring_base = 0x0000046c,
> +
> + /* CE address */
> + .umac_ce0_src_reg_base = 0x00200000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .umac_ce0_dest_reg_base = 0x00201000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .umac_ce1_src_reg_base = 0x00202000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .umac_ce1_dest_reg_base = 0x00203000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> +};
> +
> static inline
> bool ath12k_hal_rx_desc_get_first_msdu_qcn9274(struct hal_rx_desc *desc)
> {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
> index 08c0a0469474..03cf3792d523 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
> @@ -17,6 +17,7 @@ extern const struct hal_ops hal_qcn9274_ops;
> extern const struct ath12k_hw_regs qcn9274_v1_regs;
> extern const struct ath12k_hw_regs qcn9274_v2_regs;
> extern const struct ath12k_hw_regs ipq5332_regs;
> +extern const struct ath12k_hw_regs ipq5424_regs;
> extern const struct ath12k_hal_tcl_to_wbm_rbm_map
> ath12k_hal_tcl_to_wbm_rbm_map_qcn9274[DP_TCL_NUM_RING_MAX];
> extern const struct ath12k_hw_hal_params ath12k_hw_hal_params_qcn9274;
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 3/6] wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:21 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-3-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> Add a new ath12k_hw_version_map entry for the AHB based WiFi 7 device
> IPQ5424.
>
> Reuse most of the ath12k_hw_version_map fields such as hal_ops,
> hal_desc_sz, tcl_to_wbm_rbm_map, and hal_params from IPQ5332. The
> register addresses differ on IPQ5424, hence set hw_regs temporarily
> to NULL and populated it in a subsequent patch.
>
> 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
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/wifi7/hal.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> index bd1753ca0db6..c2cc99a83f09 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> @@ -50,6 +50,13 @@ static const struct ath12k_hw_version_map ath12k_wifi7_hw_ver_map[] = {
> .hal_params = &ath12k_hw_hal_params_wcn7850,
> .hw_regs = &qcc2072_regs,
> },
> + [ATH12K_HW_IPQ5424_HW10] = {
> + .hal_ops = &hal_qcn9274_ops,
> + .hal_desc_sz = sizeof(struct hal_rx_desc_qcn9274_compact),
> + .tcl_to_wbm_rbm_map = ath12k_hal_tcl_to_wbm_rbm_map_qcn9274,
> + .hal_params = &ath12k_hw_hal_params_ipq5332,
> + .hw_regs = NULL,
> + },
> };
>
> int ath12k_wifi7_hal_init(struct ath12k_base *ab)
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 2/6] wifi: ath12k: Add ath12k_hw_params for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:20 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-2-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add ath12k_hw_params for the ath12k AHB-based WiFi 7 device IPQ5424.
> The WiFi device IPQ5424 is similar to IPQ5332. Most of the hardware
> parameters like hw_ops, wmi_init, ring_mask, etc., are the same between
> IPQ5424 and IPQ5332, hence use these same parameters for IPQ5424.
> Some parameters are specific to IPQ5424; initially set these to
> 0 or NULL, and populate them in subsequent patches.
>
> 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
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/core.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 79 ++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 59c193b24764..68453594eba8 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -157,6 +157,7 @@ enum ath12k_hw_rev {
> ATH12K_HW_WCN7850_HW20,
> ATH12K_HW_IPQ5332_HW10,
> ATH12K_HW_QCC2072_HW10,
> + ATH12K_HW_IPQ5424_HW10,
> };
>
> enum ath12k_firmware_mode {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> index ec6dba96640b..2b5d1f7e9e04 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> @@ -753,6 +753,85 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
>
> .dp_primary_link_only = false,
> },
> + {
> + .name = "ipq5424 hw1.0",
> + .hw_rev = ATH12K_HW_IPQ5424_HW10,
> + .fw = {
> + .dir = "IPQ5424/hw1.0",
> + .board_size = 256 * 1024,
> + .cal_offset = 128 * 1024,
> + .m3_loader = ath12k_m3_fw_loader_remoteproc,
> + .download_aux_ucode = false,
> + },
> + .max_radios = 1,
> + .single_pdev_only = false,
> + .qmi_service_ins_id = ATH12K_QMI_WLFW_SERVICE_INS_ID_V01_IPQ5332,
> + .internal_sleep_clock = false,
> +
> + .hw_ops = &qcn9274_ops,
> + .ring_mask = &ath12k_wifi7_hw_ring_mask_ipq5332,
> +
> + .host_ce_config = ath12k_wifi7_host_ce_config_ipq5332,
> + .ce_count = 12,
> + .target_ce_config = ath12k_wifi7_target_ce_config_wlan_ipq5332,
> + .target_ce_count = 12,
> + .svc_to_ce_map =
> + ath12k_wifi7_target_service_to_ce_map_wlan_ipq5332,
> + .svc_to_ce_map_len = 18,
> +
> + .rxdma1_enable = true,
> + .num_rxdma_per_pdev = 1,
> + .num_rxdma_dst_ring = 0,
> + .rx_mac_buf_ring = false,
> + .vdev_start_delay = false,
> +
> + .interface_modes = BIT(NL80211_IFTYPE_STATION) |
> + BIT(NL80211_IFTYPE_AP) |
> + BIT(NL80211_IFTYPE_MESH_POINT),
> + .supports_monitor = true,
> +
> + .idle_ps = false,
> + .download_calib = true,
> + .supports_suspend = false,
> + .tcl_ring_retry = true,
> + .reoq_lut_support = false,
> + .supports_shadow_regs = false,
> +
> + .num_tcl_banks = 48,
> + .max_tx_ring = 4,
> +
> + .mhi_config = NULL,
> +
> + .wmi_init = &ath12k_wifi7_wmi_init_qcn9274,
> +
> + .qmi_cnss_feature_bitmap = BIT(CNSS_QDSS_CFG_MISS_V01),
> +
> + .rfkill_pin = 0,
> + .rfkill_cfg = 0,
> + .rfkill_on_level = 0,
> +
> + .rddm_size = 0,
> +
> + .def_num_link = 0,
> + .max_mlo_peer = 256,
> +
> + .otp_board_id_register = 0,
> +
> + .supports_sta_ps = false,
> +
> + .acpi_guid = NULL,
> + .supports_dynamic_smps_6ghz = false,
> + .iova_mask = 0,
> + .supports_aspm = false,
> +
> + .ce_ie_addr = NULL,
> + .ce_remap = NULL,
> + .bdf_addr_offset = 0x940000,
> +
> + .current_cc_support = false,
> +
> + .dp_primary_link_only = true,
> + },
> };
>
> /* Note: called under rcu_read_lock() */
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction
From: Joshua Klinesmith @ 2026-04-07 16:00 UTC (permalink / raw)
To: Ben Greear
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
linux-kernel, stable
In-Reply-To: <d4622e31-4012-4c05-9288-529b0bb0aebd@candelatech.com>
On 4/7/26 11:25, Ben Greear wrote:
> How much of this is AI driven? As far as I know, mt7925 is a 2x2 chipset
> at max. So while the patch may be correct, it may also not matter in practice
> and at least may not need to be backported into stable.
Hi Ben,
Please accept my apologies. You are correct that the mt7925 is a 2x2
chipset, so this does not have a practical impact and should not have
been tagged for stable. I did not read the documentation in its
entirety before submitting, and that is on me.
I will be much more careful and diligent with testing and review going forward.
Thanks for the feedback.
Joshua
On Tue, Apr 7, 2026 at 11:25 AM Ben Greear <greearb@candelatech.com> wrote:
>
> On 4/6/26 16:47, Joshua Klinesmith wrote:
> > The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
> > spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
> > for the fourth byte, consistent with the other three chains and
> > with the RCPI3 definitions used elsewhere in the driver
> > (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).
>
> Hello Joshua,
>
> How much of this is AI driven? As far as I know, mt7925 is a 2x2 chipset
> at max. So while the patch may be correct, it may also not matter in practice
> and at least may not need to be backported into stable. If it is a minor
> cleanup that doesn't actually matter, that should be described more clearly
> in the commit message?
>
> Some of your patches are touching tricky parts of the code and making
> subtle comparisons against how the vendor's driver is written. How well has
> this been tested and reviewed by a knowledgeable human in general?
>
> Thanks,
> Ben
>
> >
> > On devices with fewer than 4 antenna chains, the corrupted value
> > is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
> > devices, this produces incorrect ACK signal strength readings.
> >
> > Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
> > ---
> > drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> > index 6334019249..85e91ca84f 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> > @@ -144,7 +144,7 @@ static void mt7925_mac_sta_poll(struct mt792x_dev *dev)
> > rssi[0] = to_rssi(GENMASK(7, 0), val);
> > rssi[1] = to_rssi(GENMASK(15, 8), val);
> > rssi[2] = to_rssi(GENMASK(23, 16), val);
> > - rssi[3] = to_rssi(GENMASK(31, 14), val);
> > + rssi[3] = to_rssi(GENMASK(31, 24), val);
> >
> > mlink->ack_signal =
> > mt76_rx_signal(msta->vif->phy->mt76->antenna_mask, rssi);
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
^ permalink raw reply
* Re: [PATCH 3/3] wifi: Transition/Padding delay subfields are for both EMLSR and EMLMR
From: Pablo MARTIN-GOMEZ @ 2026-04-07 15:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <6900294c6c10fb7336e8ca6c7217e970db2cc3a1.camel@sipsolutions.net>
On 07/04/2026 16:00, Johannes Berg wrote:
> On Fri, 2026-03-27 at 21:11 +0100, Pablo Martin-Gomez wrote:
>> -#define IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY 0x0070
>> +#define IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY 0x0070
>> #define IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_0US 0
>> #define IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_16US 1
>> #define IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_32US 2
>
> I think this is confusing. You have the "EMLSR_EMLMR_" prefix in the
> definition for the mask, but not in the values, but also the prefix
> itself gets very long, not sure what to do about that. Maybe just
> ..._EML_TRANSITION_DELAY even if it doesn't match the spec completely.
In the standard, there is two different tables to convert the field
value to a delay: 9-417j for EMLSR and 9-417l for EMLMR. E.g. if the
field has the value 1, in EMLSR mode, it's a 16 µs delay, in EMLMR mode,
it's a 32 µs delay.
As no driver implements EMLMR, I was expecting the first one to
implement it to create the defines:
```
#define IEEE80211_EML_CAP_EMLMR_TRANSITION_DELAY_0US 0
#define IEEE80211_EML_CAP_EMLMR_TRANSITION_DELAY_32US 1
[...]
```
If you prefer, I can implement it +
`ieee80211_emlmr_[trans/pad]_delay_in_us` but it will be dead code for now.
>
> And then another thing - I was going to apply the other two patches, but
> really then looked at my git log and saw that no, really, the subjects
> are stating a spec thing rather than describing a change, so please fix
> that too.
I'll fix that in a v2
>
> johannes
Pablo MG
^ permalink raw reply
* [PATCH mt76] wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S
From: Zenm Chen @ 2026-04-07 15:44 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: zenmchen, stable
Add the ID 056e:400a to the table to support an additional MT7612U
adapter: ELECOM WDC-867SU3S.
Compile tested only.
Cc: stable@vger.kernel.org # 5.10.x
Signed-off-by: Zenm Chen <zenmchen@gmail.com>
---
This ID was found from [1] and adding it to the device table should be
enough to make it work. Hardware probes at [2] can prove its existence.
[1] https://bushowhige.blogspot.com/2019/08/ubuntu-1804-mediatek-usb-wi-fi.html
[2] https://linux-hardware.org/?id=usb:056e-400a
---
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
index 01cb3b283..459c4044f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
@@ -16,6 +16,7 @@ static const struct usb_device_id mt76x2u_device_table[] = {
{ USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USBAC1200 - Alfa AWUS036ACM */
{ USB_DEVICE(0x057c, 0x8503) }, /* Avm FRITZ!WLAN AC860 */
{ USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
+ { USB_DEVICE(0x056e, 0x400a) }, /* ELECOM WDC-867SU3S */
{ USB_DEVICE(0x0e8d, 0x7632) }, /* HC-M7662BU1 */
{ USB_DEVICE(0x0471, 0x2126) }, /* LiteOn WN4516R module, nonstandard USB connector */
{ USB_DEVICE(0x0471, 0x7600) }, /* LiteOn WN4519R module, nonstandard USB connector */
--
2.53.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