linux-toradex.git/drivers/net/wireless/ath/ath10k, branch master Linux kernel for Apalis and Colibri modules Merge tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux 2026-08-26T15:45:09+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-08-26T15:45:09+00:00 a5218c6474df97f2e7f3af15dcdfc674bae5c137 Pull another power sequencing update from Bartosz Golaszewski: "A single tree-wide rename of two of the public functions to better reflect their actual semantics: - rename pwrseq_power_on/off() to pwrseq_enable/disable() tree-wide" * tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable() 
Pull another power sequencing update from Bartosz Golaszewski:
 "A single tree-wide rename of two of the public functions to better
  reflect their actual semantics:

   - rename pwrseq_power_on/off() to pwrseq_enable/disable() tree-wide"

* tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()
power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable() 2026-08-26T08:05:45+00:00 Bartosz Golaszewski bartosz.golaszewski@oss.qualcomm.com 2026-07-31T13:42:18+00:00 d51fc9d4cd6eb18ac82913d83ecf7bd8c85f71ee The way power sequencing works means that a call to pwrseq_power_on() does not necessarily result in the pwrseq target being powered-on at that time: it may have already been powered on before. Similarly: a call to pwrseq_power_off() does not have to result in an actual powering off of resources: there may still be other users that requested a power-on before. We will also introduce the concept of "non-controllable" pwrseq targets soon which further increases the disconnect between the naming convention and the actual semantics. What consumers of pwrseq descriptors actually do is: they *vote* for a powering on of a given target or retract that vote. These operations could be called get/put in line with runtime PM but this could become confusing since we already provide pwrseq_get/put() for a different purpose. pwrseq_vote_on/off() also have been rejected as unusual in the tree. Change the name of the two functions to pwrseq_enable/disable() which better reflects their purpose and semantics and also mirrors other enable-counted resources like regulators and clocks. No functional change intended. If at any point users need to know *when* the exact power event happens, we can provide that information in the form of a notifier. Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Acked-by: Alessio Belle <alessio.belle@imgtec.com> # imagination Link: https://patch.msgid.link/20260731-pwrseq-vote-rename-v3-1-44e60b8be053@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> 
The way power sequencing works means that a call to pwrseq_power_on()
does not necessarily result in the pwrseq target being powered-on at
that time: it may have already been powered on before. Similarly: a call
to pwrseq_power_off() does not have to result in an actual powering off
of resources: there may still be other users that requested a power-on
before.

We will also introduce the concept of "non-controllable" pwrseq targets
soon which further increases the disconnect between the naming
convention and the actual semantics.

What consumers of pwrseq descriptors actually do is: they *vote* for a
powering on of a given target or retract that vote. These operations
could be called get/put in line with runtime PM but this could become
confusing since we already provide pwrseq_get/put() for a different
purpose. pwrseq_vote_on/off() also have been rejected as unusual in
the tree.

Change the name of the two functions to pwrseq_enable/disable() which
better reflects their purpose and semantics and also mirrors other
enable-counted resources like regulators and clocks. No functional change
intended.

If at any point users need to know *when* the exact power event happens,
we can provide that information in the form of a notifier.

Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Acked-by: Alessio Belle <alessio.belle@imgtec.com> # imagination
Link: https://patch.msgid.link/20260731-pwrseq-vote-rename-v3-1-44e60b8be053@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump 2026-08-01T15:50:27+00:00 Linghui Wu linghui.wu@oss.qualcomm.com 2026-07-27T07:26:29+00:00 4f25071afe9218aaae1c63fbf75e229aa6405319 On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1 Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Signed-off-by: Linghui Wu <linghui.wu@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260727072629.2297208-1-linghui.wu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> 
On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT).
On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to
it are not permitted. ath10k_msa_dump_memory() copies the region with a
plain memcpy(), whose optimized __pi_memcpy_generic implementation issues
wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in
ath10k_snoc_fw_crashed_dump() while collecting the devcoredump:

  Unable to handle kernel paging request ... FSC=0x21: alignment fault
  pc : __pi_memcpy_generic
  lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc]

The Oops both leaves the firmware RAM dump buffer zeroed (no dump is
captured) and crashes the kernel, which in turn breaks modem SSR
recovery.

Use memcpy_fromio(), which only performs accesses that are valid for such
a device-memory mapping. The generic memcpy_fromio() implementation aligns
the source before issuing word-sized reads and stores the destination with
put_unaligned(), so it is also safe for the coherent DMA allocation used on
the non-reserved-memory path. ath11k and ath12k use the same pattern
when copying target memory into crash dumps, so call it unconditionally
here too.
The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is
needed; use __force to keep sparse happy.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1

Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990")
Signed-off-by: Linghui Wu <linghui.wu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260727072629.2297208-1-linghui.wu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: ath10k: filter non-UTF testmode events 2026-08-01T15:50:27+00:00 Linghui Wu linghui.wu@oss.qualcomm.com 2026-07-30T02:32:26+00:00 35a3da9fe1b212a9012952a04f383b8dc3708dd7 When UTF monitor is enabled, ath10k forwards WMI events to nl80211 testmode. Non-UTF events can therefore be delivered to userspace and confuse FTM tools which expect only UTF responses. Only forward known UTF event IDs from WMI event namespaces that route events through ath10k_tm_event_wmi(), and drop other WMI events while UTF monitor is active. READY events are still handled by the normal WMI receive path. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00093.2-QCAHLSWMTPL-1 Signed-off-by: Linghui Wu <linghui.wu@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260730023226.707008-1-linghui.wu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> 
When UTF monitor is enabled, ath10k forwards WMI events to nl80211
testmode. Non-UTF events can therefore be delivered to userspace and
confuse FTM tools which expect only UTF responses.

Only forward known UTF event IDs from WMI event namespaces that route
events through ath10k_tm_event_wmi(), and drop other WMI events while UTF
monitor is active. READY events are still handled by the normal WMI
receive path.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00093.2-QCAHLSWMTPL-1

Signed-off-by: Linghui Wu <linghui.wu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730023226.707008-1-linghui.wu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Merge tag 'wireless-2026-07-26' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next 2026-07-27T23:03:40+00:00 Jakub Kicinski kuba@kernel.org 2026-07-27T23:01:11+00:00 edc84a9396acf1a0e78c46230dd0bcee1b84ac53 Johannes Berg says: ==================== wireless-next-2026-07-26 Mostly driver changes this time: - new driver mm81x for an S1G device - new driver nxpwifi for NXP devices (mostly forked off from mwifiex) - ath12k: much kernel infrastructure integration work - brcmfmac: DPP support, some Cypress part update - nl80211: per-link statistics support ==================== Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Johannes Berg says:

====================
wireless-next-2026-07-26

Mostly driver changes this time:
 - new driver mm81x for an S1G device
 - new driver nxpwifi for NXP devices
   (mostly forked off from mwifiex)
 - ath12k: much kernel infrastructure integration work
 - brcmfmac: DPP support, some Cypress part update
 - nl80211: per-link statistics support
====================

Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
wifi: ath10k: Drop redundant NULL check on devm_clk_get() 2026-07-22T16:02:18+00:00 Krzysztof Kozlowski krzysztof.kozlowski@oss.qualcomm.com 2026-07-05T17:24:06+00:00 007875346097ab22d0040bd61f7bee3e92321fff devm_clk_get() does not return NULL (only valid clock or ERR pointer), so simplify the code to drop redundant IS_ERR_OR_NULL(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260705172405.119084-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> 
devm_clk_get() does not return NULL (only valid clock or ERR pointer),
so simplify the code to drop redundant IS_ERR_OR_NULL().

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260705172405.119084-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: ath10k: trigger hardware recovery upon rx failures 2026-07-22T16:02:18+00:00 Manikanta Pubbisetty manikanta.pubbisetty@oss.qualcomm.com 2026-07-10T06:04:06+00:00 f78210dd4bea09090b828adc2733cad4b9916306 When an error occurs during RX packet processing (e.g., MSDU done failure), the driver sets rx_confused and drops all subsequent RX packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave the device in a bad state where it cannot process RX data traffic. Instead of leaving the device in such a state, trigger hardware recovery so that such an error state can be reset and the device can function again normally. Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260710060406.3323260-1-manikanta.pubbisetty@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> 
When an error occurs during RX packet processing (e.g., MSDU done
failure), the driver sets rx_confused and drops all subsequent RX
packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave
the device in a bad state where it cannot process RX data traffic.

Instead of leaving the device in such a state, trigger hardware
recovery so that such an error state can be reset and the device
can function again normally.

Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260710060406.3323260-1-manikanta.pubbisetty@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: ath10k: fix skb leak on incomplete msdu during rx pop 2026-07-09T14:44:42+00:00 Manikanta Pubbisetty manikanta.pubbisetty@oss.qualcomm.com 2026-06-23T06:43:55+00:00 7393878255e492515858f751ba4c260f248fb108 When ath10k_htt_rx_pop_paddr32_list() or ath10k_htt_rx_pop_paddr64_list() encounters an incomplete frame (RX_ATTENTION_FLAGS_MSDU_DONE not set), it returns -EIO without purging the skb list built up so far, leaking any skbs already queued in the list. Other early-exit paths within these same functions already call __skb_queue_purge() before returning an error. Add it before the -EIO return as well to be consistent and prevent the leak. Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 Fixes: c545070e404b ("ath10k: implement rx reorder support") Fixes: 3b0b55b19d1d ("ath10k: Add support for 64 bit HTT in-order indication msg") Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260623064355.1876743-1-manikanta.pubbisetty@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> 
When ath10k_htt_rx_pop_paddr32_list() or
ath10k_htt_rx_pop_paddr64_list() encounters an incomplete frame
(RX_ATTENTION_FLAGS_MSDU_DONE not set), it returns -EIO without
purging the skb list built up so far, leaking any skbs already
queued in the list.

Other early-exit paths within these same functions already call
__skb_queue_purge() before returning an error. Add it before the
-EIO return as well to be consistent and prevent the leak.

Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1

Fixes: c545070e404b ("ath10k: implement rx reorder support")
Fixes: 3b0b55b19d1d ("ath10k: Add support for 64 bit HTT in-order indication msg")
Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260623064355.1876743-1-manikanta.pubbisetty@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: ath10k: Update Qualcomm copyrights 2026-06-09T13:50:28+00:00 Jeff Johnson jeff.johnson@oss.qualcomm.com 2026-06-08T13:21:34+00:00 ae667b0f98b80146ea22830a1b53c5758ad742f1 Update Qualcomm copyrights per current legal guidance. Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/20260608-ath12k-copyright-v2-3-37504d70b03c@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> 
Update Qualcomm copyrights per current legal guidance.

Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/20260608-ath12k-copyright-v2-3-37504d70b03c@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Merge tag 'ath-next-20260526' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath 2026-05-28T08:23:15+00:00 Johannes Berg johannes.berg@intel.com 2026-05-28T08:23:12+00:00 6f5dc19f46f4bd0e104c9a4da2f0a912cdf3bd86 Jeff Johnson says: ================== ath.git patches for v7.2 (PR #2) For ath12k: - Add thermal throttling and cooling device support - Add support for handling incumbent signal interference in 6 GHz - Add support for channel 177 in the 5 GHz band In addition, a large number of cleanup and minor bug fixing across all supported drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Jeff Johnson says:
==================
ath.git patches for v7.2 (PR #2)

For ath12k:
- Add thermal throttling and cooling device support
- Add support for handling incumbent signal interference in 6 GHz
- Add support for channel 177 in the 5 GHz band

In addition, a large number of cleanup and minor bug fixing across
all supported drivers.
==================

Signed-off-by: Johannes Berg <johannes.berg@intel.com>