* RE: [PATCH rtw-next] wifi: rtw88: Enable receiving control frames in monitor mode
From: Ping-Ke Shih @ 2026-06-24 0:53 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org; +Cc: Georg Bißeling
In-Reply-To: <3445ca1b-2d5a-43ae-9df1-d3f6440fae78@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>
> >> Signed-off-by: Bitterblue Smith (S.E.A. Datentechnik GmbH) <rtl8821cerfe2@gmail.com>
> >
> > Once you migrate to your company mail, maybe you can add an entry to .mailmap,
> > which only affects the output of git-shortlog though.
> >
>
> Seeing the company name in parentheses with no explanation makes you
> think I'm part of the company, doesn't it?
I misunderstood the meaning.
> But I'm not, they just
> sponsored this patch:
>
> https://lore.kernel.org/all/20250203174626.1131225-1-kuba@kernel.org/
Thanks for the link.
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Jeff Johnson @ 2026-06-23 23:42 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260619065816.2139392-1-aaradhana.sahu@oss.qualcomm.com>
On 6/18/2026 11:58 PM, Aaradhana Sahu wrote:
> On AHB platforms, firmware operates in two modes: fixed-memory mode where
> firmware uses hardcoded addresses for memory regions such as BDF and does
> not request HOST_DDR memory from the host, and dynamic-memory mode where
> firmware expects the host to provide memory addresses including HOST_DDR
> after the Q6 read-only region and relies on host allocation for all memory
> types.
>
> Introduce QMI capability negotiation to support both modes. Add a new QMI
> PHY capability flag dynamic_ddr_support which is advertised by firmware to
> indicate it supports dynamic memory mode. When the host detects this
> capability, set the dynamic_mem_support flag in the host capability message
> to signal the host is ready to provide dynamic memory allocation. This
> triggers firmware to send the HOST_DDR memory request and use the
> host-provided address.
>
> For backward compatibility, if firmware doesn't advertise
> dynamic_ddr_support, the firmware continues to operate in fixed-memory mode
> where firmware uses predefined addresses.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
> ---
> v2:
> -Dropped QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN and QMI_WLANFW_PHY_CAP_RESP_MSG_V01_MAX_LEN changes.
I think you needed to keep the REQ_MSG MAX_LEN change.
My prior comment that the REQ_MSG MAX_LEN macros are a layering violation was
constrained with the observation "that is a preexisting issue with the QMI
interface" so we must continue to pass valid MAX_LEN values unless the QMI
interface itself is changed such QMI determines the MAX_LEN
> -Used %u instead of %d in the debug log.
> ---
> drivers/net/wireless/ath/ath12k/qmi.c | 50 +++++++++++++++++++++++++--
> drivers/net/wireless/ath/ath12k/qmi.h | 6 +++-
> 2 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
> index fd762b5d7bb5..e15a0c0120d3 100644
> --- a/drivers/net/wireless/ath/ath12k/qmi.c
> +++ b/drivers/net/wireless/ath/ath12k/qmi.c
> @@ -506,6 +506,24 @@ static const struct qmi_elem_info qmi_wlanfw_host_cap_req_msg_v01_ei[] = {
> .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
> feature_list),
> },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x33,
> + .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
> + dynamic_mem_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x33,
> + .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
> + dynamic_mem_support),
> + },
Does QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN need to be updated to account for
the new TLVs?
> {
> .data_type = QMI_EOTI,
> .array_type = NO_ARRAY,
^ permalink raw reply
* Re: [PATCHv2 ath-next] wifi: ath9k: mark static arrays as const
From: Rosen Penev @ 2026-06-23 21:31 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: linux-wireless, open list
In-Reply-To: <871pdxe7ml.fsf@toke.dk>
On Tue, Jun 23, 2026 at 5:58 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Rosen Penev <rosenp@gmail.com> writes:
>
> > On Mon, Jun 22, 2026 at 4:49 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> Rosen Penev <rosenp@gmail.com> writes:
> >>
> >> > PN9Data is a read-only lookup table and is never modified. Adding const
> >> > lets the compiler place it in .rodata and prevents accidental writes.
> >> >
> >> > Use the same treatment for bits_per_symbol. It's not modified either.
> >> >
> >> > Assisted-by: opencode:big-pickle
> >> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>
> >> Again, which actual bug are you fixing here?
> > Patches are required to be bugfixes?
>
> Well, or at least have some concrete benefit? You're changing working
> code here, we've had to revert patches of this kind before because it
> broke things.
>
> For this patch specifically, there's one of two cases:
>
> - The array is never written to, in which case the patch has no
> practical effect
>
> or
>
> - The array *is* actually written to somewhere, in which case the kernel
> will now crash as soon as someone tries to run the code.
I believe the description addresses this.
>
> Either way, I don't see how the risk/benefit tradeoff comes off positive
> for this patch?
const makes the array easier to optimize for a compiler in general.
And because it's static, it goes in rodata.
>
> -Toke
^ permalink raw reply
* Re: [PATCH v1 1/2] overflow: Allow to sum a few arguments at once
From: Andy Shevchenko @ 2026-06-23 20:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Kees Cook, linux-hardening, linux-kernel, linux-wireless,
Gustavo A. R. Silva
In-Reply-To: <ajqTpJAMFFV3H5Im@ashevche-desk.local>
On Tue, Jun 23, 2026 at 05:09:44PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 22, 2026 at 01:16:29PM +0200, Johannes Berg wrote:
> > On Sat, 2026-06-20 at 09:56 +0300, Andy Shevchenko wrote:
> > > Johannes, are you okay to take a new version (I assume the wish is to have
> > > the balanced additions)? If so, I will prepare one.
> >
> > Sure, I can take the patches, sounds good to me.
>
> Will send soon, for the record the *.i file is 61 character less with the patch.
After looking closer at the potential users, I see less benefit of this change
than before. The other case in one of wireless driver can actually benefit from
separate size_add() calls and temporary variables which will be reused later in
the code. The similar approach even can be used for nl80211.c case. So for
now I abandon this until more users come. (Of course it might be that I'm missing
something and if somebody knows what, I would like to learn.)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: only accept IBSS channel switch from our own BSSID
From: Nathan Howard @ 2026-06-23 19:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: Yingjie Cao, linux-wireless, linux-kernel, stable
In-Reply-To: <9201d828365fa2b11fb6a83d1ff66365435a9072.camel@sipsolutions.net>
On Tue, Jun 23, 2026 at 11:12:20AM +0200, Johannes Berg wrote:
> On Tue, 2026-06-23 at 11:10 +0200, Johannes Berg wrote:
> > On Tue, 2026-06-23 at 17:04 +0800, Yingjie Cao wrote:
> > > ieee80211_rx_bss_info() acts on a channel switch announcement (CSA)
> > > carried in a received beacon or probe response before it verifies that
> > > the frame's BSSID matches our own IBSS; it only checks that the SSID
> > > matches. ieee80211_rx_mgmt_spectrum_mgmt() acts on a spectrum management
> > > (channel switch) action frame without checking the BSSID at all.
> > >
> > > Because of this, any station in radio range that knows the IBSS SSID
> > > (which is broadcast in cleartext) can inject a beacon or action frame
> > > carrying a CSA element that points at an unsupported channel. The switch
> > > then fails in ieee80211_ibss_process_chanswitch(), which queues
> > > csa_connection_drop_work and tears the whole IBSS down. The members
> > > rejoin and the attacker repeats, resulting in a persistent,
> > > unauthenticated denial of service. Encrypted IBSS networks are equally
> > > affected because beacons are not protected. Since both of these CSA
> > > entry points are IBSS-specific, the impact is confined to IBSS (ad-hoc)
> > > mode; managed-mode CSA is handled separately in mlme.c and is unaffected.
> >
> > Once you rewrite this to be more honest, you'll see that the whole Cc
> > stable thing and all is fairly much pointless?
> >
> > Or have you not realised yet that stations can also trivially fake their
> > MAC address?
>
> Also, since you don't have a track record in wifi, I'll point once again
> to https://docs.kernel.org/process/coding-assistants.html
>
So, what's the litmus test? I've been watching this list for some time
now. I've seen (what appears) to be an ushering of distrust brought
on by llm's. This also seems to have come into prominence within the last 6 or
so months. I understand the cautious approach, but what if one's been
working diligently (and quietly), and has spent many hours studying and
preparing a driver series (for oneself and submission to the kernel)?
I've always done well by doing my homework the hard way. But now,
submissions are met with skepticism... that the work must have been
assisted-by if the person doesn't have a track record. How should one defend
his work (I'd rather not share credit with a machine when my work is my own)?
To be clear, my question is sourcing from what I've seen to be trending
more recently whereby several submissions have been ?softly? tagged as assisted-by.
Maybe they were, but my point still stands. Kindly provide guidance.
^ permalink raw reply
* [PATCH v10] Add device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-23 18:31 UTC (permalink / raw)
To: bhelgaas, alex, mani
Cc: jjohnson, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset.
The problem manifests in VFIO passthrough scenarios:
- WCN6855 (17cb:1103) and WCN7850 (17cb:1107) WiFi devices:
Normal VM operation works fine, including clean shutdown/reboot.
However, when the VM terminates uncleanly (crash, force-off), VFIO
attempts to reset the device before it can be assigned to another VM.
Without a working reset method, the device remains in an undefined state,
preventing reuse.
- SDX62/SDX65 (17cb:0308) 5G modems: Never successfully initialize even
on first VM assignment without proper reset capability.
Add device-specific reset methods using BAR-space hardware reset registers
that exist in these devices:
- WCN6855/WCN7850 WiFi devices use SoC global reset via BAR0 (sequence from
ath11k/ath12k driver: ath11k_pci_soc_global_reset(), ath11k_pci_sw_reset(),
ath11k_mhi_set_mhictrl_reset()):
- Write/clear reset bit at offset 0x3008
- Wait for PCIe link recovery (up to 5 seconds)
- Clear MHI controller SYSERR status at offset 0x38
- SDX62/SDX65 modem devices use MHI SoC reset via BAR0 (sequence from MHI
driver: mhi_soc_reset(), mhi_pci_reset_prepare()):
- Write reset request to offset 0xb0
- Wait 2 seconds for reset completion
These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.
Testing was performed on desktop platforms with M.2 WiFi and modem cards
using M.2-to-PCIe adapters, including extensive force-reset cycling to
verify stability.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v10:
- Complete redesign based on maintainer feedback (Manivannan Sadhasivam,
Alex Williamson): use actual hardware reset registers from
device drivers instead of D3hot power cycling
v9: https://lore.kernel.org/all/20260612142638.1243895-1-jtornosm@redhat.com/
drivers/pci/quirks.c | 118 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 431c021d7414..8ad3f214e520 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4240,6 +4240,121 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
return 0;
}
+#define QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET 0x3008
+#define QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET_V BIT(0)
+#define QUALCOMM_WIFI_MHISTATUS 0x48
+#define QUALCOMM_WIFI_MHICTRL 0x38
+#define QUALCOMM_WIFI_MHICTRL_RESET_MASK 0x2
+
+/*
+ * Qualcomm WiFi device-specific reset using SoC global reset via BAR0
+ * registers.
+ */
+static int reset_qualcomm_wifi(struct pci_dev *pdev, bool probe)
+{
+ bool link_recovered = false;
+ unsigned long timeout;
+ void __iomem *bar;
+ u32 val;
+ u16 cmd;
+
+ if (probe)
+ return 0;
+
+ if (pdev->current_state != PCI_D0)
+ return -EINVAL;
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+ bar = pci_iomap(pdev, 0, 0);
+ if (!bar) {
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+ return -ENODEV;
+ }
+
+ val = ioread32(bar + QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET);
+ val |= QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET_V;
+ iowrite32(val, bar + QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET);
+ ioread32(bar + QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET);
+
+ msleep(10);
+
+ val &= ~QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET_V;
+ iowrite32(val, bar + QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET);
+ ioread32(bar + QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET);
+
+ msleep(10);
+
+ timeout = jiffies + msecs_to_jiffies(5000);
+ while (time_before(jiffies, timeout)) {
+ val = ioread32(bar + QUALCOMM_WIFI_PCIE_SOC_GLOBAL_RESET);
+ if (val != 0xffffffff) {
+ link_recovered = true;
+ break;
+ }
+ msleep(20);
+ }
+
+ if (!link_recovered) {
+ pci_err(pdev, "PCIe link failed to recover after reset\n");
+ goto out_restore;
+ }
+
+ /* After SOC_GLOBAL_RESET, MHISTATUS may still have SYSERR bit set
+ * and thus need to set MHICTRL_RESET to clear SYSERR.
+ */
+ iowrite32(QUALCOMM_WIFI_MHICTRL_RESET_MASK, bar + QUALCOMM_WIFI_MHICTRL);
+ ioread32(bar + QUALCOMM_WIFI_MHICTRL);
+
+ msleep(10);
+
+out_restore:
+ pci_iounmap(pdev, bar);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ return link_recovered ? 0 : -ETIMEDOUT;
+}
+
+#define MHI_SOC_RESET_REQ_OFFSET 0xb0
+#define MHI_SOC_RESET_REQ BIT(0)
+
+/*
+ * Qualcomm modem device-specific reset using MHI SoC reset via BAR0
+ * register.
+ */
+static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
+{
+ void __iomem *bar;
+ u16 cmd;
+
+ if (probe)
+ return 0;
+
+ if (pdev->current_state != PCI_D0)
+ return -EINVAL;
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+ bar = pci_iomap(pdev, 0, 0);
+ if (!bar) {
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+ return -ENODEV;
+ }
+
+ iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
+ ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
+
+ /* Be sure device reset has been executed */
+ msleep(2000);
+
+ pci_iounmap(pdev, bar);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ return 0;
+}
+
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
@@ -4255,6 +4370,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
reset_chelsio_generic_dev },
{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
reset_hinic_vf_dev },
+ { PCI_VENDOR_ID_QCOM, 0x1103, reset_qualcomm_wifi }, /* WCN6855 WiFi */
+ { PCI_VENDOR_ID_QCOM, 0x1107, reset_qualcomm_wifi }, /* WCN7850 WiFi */
+ { PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */
{ 0 }
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v1 1/2] overflow: Allow to sum a few arguments at once
From: Johannes Berg @ 2026-06-23 17:50 UTC (permalink / raw)
To: David Laight, Andy Shevchenko
Cc: Kees Cook, linux-hardening, linux-kernel, linux-wireless,
Gustavo A. R. Silva
In-Reply-To: <20260623163203.195416b4@pumpkin>
On Tue, 2026-06-23 at 16:32 +0100, David Laight wrote:
>
> Both those seem to contain multiple expansions of is_constexpr().
> I'd be surprised if __builtin_constant_p() wasn't good enough.
>
> I also wonder what kind of mess the object code looks like.
You should definitely wonder less out loud and only comment when you
have actual hard facts...
> I'd also worry whether the saturating maths in any way performs the correct check.
> I suspect the (non-saturated) value gets used for a kmalloc(),
> but that has much smaller valid (and sane) limits than can come out of the above.
That's, frankly, ridiculous.
johannes
^ permalink raw reply
* Re: [PATCH v7 01/15] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Mukesh Ojha @ 2026-06-23 16:31 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, linux-arm-msm, devicetree, dri-devel, freedreno,
linux-media, netdev, linux-wireless, ath12k, linux-remoteproc,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260522115936.201208-2-sumit.garg@kernel.org>
On Fri, May 22, 2026 at 05:29:22PM +0530, Sumit Garg wrote:
> From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>
> All the existing variants Kodiak boards are using Gunyah hypervisor
> which means that, so far, Linux-based OS could only boot in EL1 on those
> devices. However, it is possible for us to boot Linux at EL2 on these
> devices [1].
>
> When running under Gunyah, the remote processor firmware IOMMU
> streams are controlled by Gunyah. However, without Gunyah, the IOMMU is
> managed by the consumer of this DeviceTree. Therefore, describe the
> firmware streams for each remote processor.
>
> Add a EL2-specific DT overlay and apply it to Kodiak IOT variant
> devices to create -el2.dtb for each of them alongside "normal" dtb.
>
> Note that modem and media subsystems haven't been supported yet due
> to missing dependencies. For GPU to work, zap shader is disabled and
> in EL2 mode the kernel owns hardware watchdog which is enabled here.
>
> [1]
> https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> [SG: watchdog and modem fixup]
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
As discussed internally, I will be taking this patch separately and you
can drop this from series.
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v1 1/2] overflow: Allow to sum a few arguments at once
From: David Laight @ 2026-06-23 15:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Johannes Berg, Kees Cook, linux-hardening, linux-kernel,
linux-wireless, Gustavo A. R. Silva
In-Reply-To: <ajqTpJAMFFV3H5Im@ashevche-desk.local>
On Tue, 23 Jun 2026 17:09:40 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Mon, Jun 22, 2026 at 01:16:29PM +0200, Johannes Berg wrote:
> > On Sat, 2026-06-20 at 09:56 +0300, Andy Shevchenko wrote:
> > > Johannes, are you okay to take a new version (I assume the wish is to have
> > > the balanced additions)? If so, I will prepare one.
> >
> > Sure, I can take the patches, sounds good to me.
>
> Will send soon, for the record the *.i file is 61 character less with the patch.
>
> Was
>
> size = __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), sizeof(*(request)) + __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})))), __size_add(sizeof(*(request)), __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");}))))));
> - size = __size_add(size, size_mul(sizeof(*request->ssids), n_ssids));
> - size = __size_add(size, size_mul(sizeof(*request->match_sets), n_match_sets));
> - size = __size_add(size, size_mul(sizeof(*request->scan_plans), n_plans));
> - size = __size_add(size, ie_len);
>
> Now
>
> size = __size_add(__size_add(__size_add(__builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), sizeof(*(request)) + __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})))), __size_add(sizeof(*(request)), __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})))))), ie_len), size_mul(sizeof(*request->ssids), n_ssids)), __size_add(size_mul(sizeof(*request->match_sets), n_match_sets), size_mul(sizeof(*request->scan_plans), n_plans)));
>
Both those seem to contain multiple expansions of is_constexpr().
I'd be surprised if __builtin_constant_p() wasn't good enough.
I also wonder what kind of mess the object code looks like.
I'd also worry whether the saturating maths in any way performs the correct check.
I suspect the (non-saturated) value gets used for a kmalloc(),
but that has much smaller valid (and sane) limits than can come out of the above.
David
^ permalink raw reply
* [PATCH ath-next v3] wifi: ath12k: avoid setting 320MHz support on non 6GHz band
From: Nicolas Escande @ 2026-06-23 15:16 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
related features on the 5GHz band while it should not:
Wiphy phy1
[...]
Band 2:
[...]
EHT Iftypes: managed
[...]
EHT PHY Capabilities: (0xe2ffdbe018778000):
320MHz in 6GHz Supported
[...]
Beamformee SS (320MHz): 7
[...]
Number Of Sounding Dimensions (320MHz): 3
[...]
EHT MCS/NSS: (0x22222222222222222200000000):
This is also reflected in the beacons sent by a mesh interface started on
that band. They erroneously advertise 320MHz support too.
This should not happen as IEEE Std 802.11-2024, subclause 9.4.2.323.3 says
we should not set the 320MHz related fields when not operating on a 6GHz
band. For example it says about Bit 0 "Support For 320 MHz In 6 GHz"
"Reserved if the EHT Capabilities element is indicating capabilities for
the 2.4 GHz or 5 GHz bands."
Fix this by clearing the related bits when converting from WMI eht phy
capabilities to mac80211 phy capabilities, for bands other than 6GHz.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
Changes from v2:
- rebased on ath-next
- fixed all typos
- changed wording in commit message & code comment
- also clear all other 6GHz related phy capabs
Changes from v1:
- rebased on ath-next
- clear all 6GHz / 320MHz related phy capabilities fields from the firmware
---
drivers/net/wireless/ath/ath12k/wmi.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 84a31b953db8..e7689ee3e701 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -5154,6 +5154,7 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
__le32 cap_info_internal)
{
struct ath12k_band_cap *cap_band = &pdev->cap.band[band];
+ u8 *phy_cap = (u8 *)&cap_band->eht_cap_phy_info[0];
u32 support_320mhz;
u8 i;
@@ -5167,8 +5168,22 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
for (i = 0; i < WMI_MAX_EHTCAP_PHY_SIZE; i++)
cap_band->eht_cap_phy_info[i] = le32_to_cpu(cap_phy_info[i]);
- if (band == NL80211_BAND_6GHZ)
+ if (band == NL80211_BAND_6GHZ) {
cap_band->eht_cap_phy_info[0] |= support_320mhz;
+ } else {
+ /*
+ * Firmware may report 6 GHz/320 MHz specific capabilities for
+ * non-6 GHz bands, so explicitly clear them.
+ */
+ phy_cap[0] &= ~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+ phy_cap[1] &= ~IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK;
+ phy_cap[2] &= ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
+ phy_cap[3] &= ~IEEE80211_EHT_PHY_CAP3_SOUNDING_DIM_320MHZ_MASK;
+ phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
+ phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_EHT_DUP_6GHZ_SUPP;
+ phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ;
+ phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ;
+ }
cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH rtw-next] wifi: rtw88: Enable receiving control frames in monitor mode
From: Bitterblue Smith @ 2026-06-23 14:18 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org; +Cc: Georg Bißeling
In-Reply-To: <7f12ff0969754a9fa4d78b0ae3d2409e@realtek.com>
On 23/06/2026 04:15, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> From: Bitterblue Smith (S.E.A. Datentechnik GmbH) <rtl8821cerfe2@gmail.com>
>>
>> By default RTL8723D, RTL8703B, RTL8812A, RTL8821A, and RTL8814A are
>> configured to filter out all control frames except PS-Poll, even in
>> monitor mode.
>>
>> Handle FIF_CONTROL in rtw_ops_configure_filter(). When it's set,
>> configure REG_RXFLTMAP1 to let all control frames through. When it's
>> unset, restore the original value. Because some drivers configure
>> REG_RXFLTMAP1 differently, keep track of its value in a new member of
>> struct rtw_hal.
>
> All behaviors are unchanged for non-monitor mode, right?
>
I think so.
>>
>> Signed-off-by: Bitterblue Smith (S.E.A. Datentechnik GmbH) <rtl8821cerfe2@gmail.com>
>
> Once you migrate to your company mail, maybe you can add an entry to .mailmap,
> which only affects the output of git-shortlog though.
>
Seeing the company name in parentheses with no explanation makes you
think I'm part of the company, doesn't it? But I'm not, they just
sponsored this patch:
https://lore.kernel.org/all/20250203174626.1131225-1-kuba@kernel.org/
It's confusing, I don't know why they didn't go with a simple
"Sponsored-by" tag.
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>
>
^ permalink raw reply
* [PATCH 2/2] wifi: ath12k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESET
From: Manivannan Sadhasivam @ 2026-06-23 14:16 UTC (permalink / raw)
To: jjohnson
Cc: linux-wireless, ath12k, ath11k, linux-kernel, mani,
Manivannan Sadhasivam, Alex Williamson
In-Reply-To: <20260623141649.41087-1-manivannan.sadhasivam@oss.qualcomm.com>
ath12k_pci_soc_global_reset() tries to reset the device by writing to the
PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure
that the write gets flushed to the device before the delay.
This may lead to the delay on the host to be insufficient, if the posted
write doesn't reach the device before the delay.
So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and
before the delay.
Compile tested only.
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Reported-by: Alex Williamson <alex@shazbot.org>
Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/pci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/pci.c b/drivers/net/wireless/ath/ath12k/pci.c
index d9a22d6afbb0..fee4129ea405 100644
--- a/drivers/net/wireless/ath/ath12k/pci.c
+++ b/drivers/net/wireless/ath/ath12k/pci.c
@@ -188,6 +188,8 @@ static void ath12k_pci_soc_global_reset(struct ath12k_base *ab)
val |= PCIE_SOC_GLOBAL_RESET_V;
ath12k_pci_write32(ab, PCIE_SOC_GLOBAL_RESET, val);
+ /* Flush the posted write to the device */
+ ath12k_pci_read32(ab, PCIE_SOC_GLOBAL_RESET);
/* TODO: exact time to sleep is uncertain */
delay = 10;
@@ -197,6 +199,8 @@ static void ath12k_pci_soc_global_reset(struct ath12k_base *ab)
val &= ~PCIE_SOC_GLOBAL_RESET_V;
ath12k_pci_write32(ab, PCIE_SOC_GLOBAL_RESET, val);
+ /* Flush the posted write to the device */
+ ath12k_pci_read32(ab, PCIE_SOC_GLOBAL_RESET);
mdelay(delay);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] wifi: ath11k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESET
From: Manivannan Sadhasivam @ 2026-06-23 14:16 UTC (permalink / raw)
To: jjohnson
Cc: linux-wireless, ath12k, ath11k, linux-kernel, mani,
Manivannan Sadhasivam, Alex Williamson
ath11k_pci_soc_global_reset() tries to reset the device by writing to the
PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure
that the write gets flushed to the device before the delay.
This may lead to the delay on the host to be insufficient, if the posted
write doesn't reach the device before the delay.
So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and
before the delay.
Compile tested only.
Fixes: f3c603d412b3 ("ath11k: reset MHI during power down and power up")
Reported-by: Alex Williamson <alex@shazbot.org>
Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath11k/pci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/pci.c b/drivers/net/wireless/ath/ath11k/pci.c
index 35bb9e7a63a2..a163168f3617 100644
--- a/drivers/net/wireless/ath/ath11k/pci.c
+++ b/drivers/net/wireless/ath/ath11k/pci.c
@@ -199,6 +199,8 @@ static void ath11k_pci_soc_global_reset(struct ath11k_base *ab)
val |= PCIE_SOC_GLOBAL_RESET_V;
ath11k_pcic_write32(ab, PCIE_SOC_GLOBAL_RESET, val);
+ /* Flush the posted write to the device */
+ ath11k_pcic_read32(ab, PCIE_SOC_GLOBAL_RESET);
/* TODO: exact time to sleep is uncertain */
delay = 10;
@@ -208,6 +210,8 @@ static void ath11k_pci_soc_global_reset(struct ath11k_base *ab)
val &= ~PCIE_SOC_GLOBAL_RESET_V;
ath11k_pcic_write32(ab, PCIE_SOC_GLOBAL_RESET, val);
+ /* Flush the posted write to the device */
+ ath11k_pcic_read32(ab, PCIE_SOC_GLOBAL_RESET);
mdelay(delay);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices
From: Alex Williamson @ 2026-06-23 14:15 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: mani, ath11k, ath12k, bhelgaas, jjohnson, linux-kernel, linux-pci,
linux-wireless, mhi, alex
In-Reply-To: <20260623125637.1188867-1-jtornosm@redhat.com>
On Tue, 23 Jun 2026 14:56:35 +0200
Jose Ignacio Tornos Martinez <jtornosm@redhat.com> wrote:
> Alex, Mani - would you prefer a dedicated VFIO PCI variant driver (similar
> to mlx5-vfio-pci) to ensure the reset logic only runs in VFIO scenarios, or
> is the quirks.c approach acceptable? I can implement either approach.
It should be a device specific reset in quirks.c. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v1 1/2] overflow: Allow to sum a few arguments at once
From: Andy Shevchenko @ 2026-06-23 14:09 UTC (permalink / raw)
To: Johannes Berg
Cc: Kees Cook, linux-hardening, linux-kernel, linux-wireless,
Gustavo A. R. Silva
In-Reply-To: <54974e4298efd26a52c9c0e9ada88d57e8695a09.camel@sipsolutions.net>
On Mon, Jun 22, 2026 at 01:16:29PM +0200, Johannes Berg wrote:
> On Sat, 2026-06-20 at 09:56 +0300, Andy Shevchenko wrote:
> > Johannes, are you okay to take a new version (I assume the wish is to have
> > the balanced additions)? If so, I will prepare one.
>
> Sure, I can take the patches, sounds good to me.
Will send soon, for the record the *.i file is 61 character less with the patch.
Was
size = __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), sizeof(*(request)) + __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})))), __size_add(sizeof(*(request)), __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");}))))));
- size = __size_add(size, size_mul(sizeof(*request->ssids), n_ssids));
- size = __size_add(size, size_mul(sizeof(*request->match_sets), n_match_sets));
- size = __size_add(size, size_mul(sizeof(*request->scan_plans), n_plans));
- size = __size_add(size, ie_len);
Now
size = __size_add(__size_add(__size_add(__builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), sizeof(*(request)) + __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})))), __size_add(sizeof(*(request)), __builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)(n_channels) * 0l)) : (int *)8))), (n_channels) * sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})), size_mul(n_channels, sizeof(*(request)->channels) + ((int)sizeof(struct {_Static_assert(!(!(!__builtin_types_compatible_p(typeof(((request)->channels)), typeof(&((request)->channels)[0])))), "must be array");})))))), ie_len), size_mul(sizeof(*request->ssids), n_ssids)), __size_add(size_mul(sizeof(*request->match_sets), n_match_sets), size_mul(sizeof(*request->scan_plans), n_plans)));
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices
From: Manivannan Sadhasivam @ 2026-06-23 13:50 UTC (permalink / raw)
To: Alex Williamson
Cc: Jose Ignacio Tornos Martinez, ath11k, ath12k, bhelgaas, jjohnson,
linux-kernel, linux-pci, linux-wireless, mhi
In-Reply-To: <20260622160822.09350246@shazbot.org>
On Mon, Jun 22, 2026 at 04:08:22PM -0600, Alex Williamson wrote:
> On Mon, 22 Jun 2026 18:22:39 +0200
> Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> > On Thu, Jun 18, 2026 at 08:33:08AM +0200, Jose Ignacio Tornos Martinez wrote:
> > > Hi Mani,
> > >
> > > Let me clarify the exact scenario and where the reset is necessary:
> > >
> > > * For the commented WiFi devices (WCN6855/WCN7850):
> > >
> > > Standard VFIO passthrough flow (this works fine):
> > > 1. Unbind native driver (ath11k/ath12k/MHI)
> > > 2. Bind vfio-pci driver
> > > 3. Assign device to VM
> > > 4. VM boots, loads its own driver → device works perfectly
> > > 5. VM shuts down cleanly → device can be reassigned → works fine
> > >
> > > The problem occurs with unclean VM termination:
> > > 1. VM crashes or is force-terminated
> > > 2. VFIO tries to reset the device before reassignment
> > > 3. Without a working PCI reset method, reset fails
> > > 4. Device stuck in undefined state → cannot be reassigned to another VM
> > >
> > > Unbinding the driver again doesn't help because the device hardware
> > > itself is in a bad state. From hypervisor:
> > > $ lspci -vvv -s 0000:03:00.0
> > > 03:00.0 Network controller: Qualcomm Technologies, Inc (rev ff) (prog-if ff)
> > > !!! Unknown header type 7f
> > > And a full host power-cycle is necessary to recover.
> > >
> >
> > Can you try the global reset available in the WLAN device BAR space?
> >
> > WCN6855: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/tree/drivers/net/wireless/ath/ath11k/pci.c#n193
> > WCN7850: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/tree/drivers/net/wireless/ath/ath12k/pci.c#n182
> >
> > > * For the commented modem devices (SDX62/SDX65):
> > >
> > > Even worse because it fails during the first VM boot without proper reset
> > > capability, standard VFIO passthrough flow:
> > > 1. Unbind native driver (MHI)
> > > 2. Bind vfio-pci driver
> > > 3. Assign device to VM
> > > 4. VM boots, loads its own driver and crashes:
> > > [ 24.024165] mhi mhi0: Device failed to enter MHI Ready
> > > [ 24.024168] mhi mhi0: MHI did not enter READY state
> > >
> > > Unbind/rebind attempts fail:
> > > [ 352.643601] mhi mhi0: Requested to power ON
> > > [ 352.643611] mhi mhi0: Power on setup success
> > > [ 373.442954] mhi mhi0: Device failed to clear MHI Reset
> > > [ 373.442970] mhi mhi0: MHI did not enter READY state
> > > And requires a full host power cycle to recover,
> > > even outside of VFIO scenarios.
> > >
> > > * MHI Host driver's remove callback may handle clean software state
> > > teardown, but it doesn't provide a PCI reset capability that VFIO can
> > > invoke. VFIO needs a reset method registered in the PCI reset hierarchy
> > > (device_specific, pm, flr, bus, etc.). VFIO invokes this reset both during
> > > initial device binding (before the VM starts) and when reassigning the
> > > device between VMs - without a working reset method, the device cannot
> > > reach a clean state for initialization.
> > >
> >
> > Likewise, there is a SoC reset available in the modem BAR space. You can try it:
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/tree/drivers/bus/mhi/host/main.c#n178
> >
> > If these works, then you can hook these in the device_specific reset callback.
>
>
> These look promising as simple flows to implement in a device specific
> reset: save command register, set memory enable, ioremap BAR space,
> match read/write/delay sequences of reset function and caller, iounmap,
> restore command.
>
> Note the delay in this latter reset is in the caller. It's also
> surprising that none of these implement a read to flush the posted
> write that initiates the reset. I wonder if that contributes to the 2s
> delay in the latter example.
>
While I agree that the absence of read-back after the posted write is a problem,
especially with a delay afterwards, the delay itself is required to let the
device reset itself and do a warm boot.
I'll submit fixes to do a read-back after triggering the reset to ensure that
the write gets flushed to the device before the delay.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices
From: Manivannan Sadhasivam @ 2026-06-23 13:40 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: alex, ath11k, ath12k, bhelgaas, jjohnson, linux-kernel, linux-pci,
linux-wireless, mhi
In-Reply-To: <20260623125637.1188867-1-jtornosm@redhat.com>
On Tue, Jun 23, 2026 at 02:56:35PM +0200, Jose Ignacio Tornos Martinez wrote:
> Hi Mani and Alex,
>
> Thank you both for the guidance.
>
>
> I think your insight about the BAR-space reset mechanisms is a much better
> approach to have a "real" reset. With that, I've implemented device-specific
> reset functions based on the driver code Mani referenced:
>
> WCN6855/WCN7850 WiFi (reset_qualcomm_wifi):
> - Uses SoC global reset via BAR0 offset 0x3008
> - Follows the sequence from ath11k_pci_soc_global_reset() /
> ath12k_pci_soc_global_reset() / ath11k_pci_sw_reset()
> - Set reset bit → 10ms delay → clear reset bit → 10ms delay → verify link
> recovery (up to 5s)
> - Includes MHI controller reset cleanup (offset 0x38) to clear SYSERR after SoC
> reset
> - Both WCN6855 and WCN7850 share identical register offsets and reset sequence
>
> SDX62/SDX65 modems (reset_qualcomm_modem):
> - Uses MHI SoC reset via BAR0 offset 0xb0
> - Follows the sequence from mhi_soc_reset() / mhi_pci_reset_prepare()
> - Write reset request → 2s delay for reset completion
>
> All implementations follow Alex's pattern: save command register ->
> enable memory decode -> ioremap BAR -> perform reset sequence ->
> iounmap -> restore command.
> Testing results: The implementation shows successful reset behavior for both
> WiFi and modem devices in VFIO passthrough scenarios.
>
Cool!
>
> Regarding the approach (quirks.c vs dedicated VFIO driver):
>
> Mani, I understand your concern about potential conflicts with the native
> drivers. I want to make sure I implement this correctly. Could you clarify
> when you envision the conflict occurring?
> From what I can see, the native drivers call their reset functions directly
> without using pci_try_reset_function(), so the device-specific reset in
> quirks.c could be enough, but I may be missing some error recovery paths or
> other scenarios.
>
MHI driver is calling pci_try_reset_function():
$ git grep -r pci_try_reset_function drivers/bus/mhi
drivers/bus/mhi/host/pci_generic.c: err = pci_try_reset_function(pdev);
So I was worried that it could create conflict. But looking more, I
understood that it won't create any conflict, but just an additional SoC reset:
pci_try_reset_function()
-> pci_dev_save_and_disable()
-> mhi_pci_reset_prepare()
-> mhi_soc_reset() <- First reset
-> __pci_reset_function_locked()
-> pci_dev_specific_reset() <- Second reset
But this additional SoC reset wouldn't cause any issue to the device due to the
2s delay, but the total recovery delay would compound to 4s now.
And that also should be fine as this path gets triggered only when the device
dies during the recovery work (very rare).
So you can implement the reset in quirks.c with device_specific reset.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCHv2 ath-next] wifi: ath9k: mark static arrays as const
From: Toke Høiland-Jørgensen @ 2026-06-23 12:58 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-wireless, open list
In-Reply-To: <CAKxU2N-bku8uZJ2nqtXb5nMhaPpxYnHqefNBj=WWe6HeKRaBXA@mail.gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> On Mon, Jun 22, 2026 at 4:49 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Rosen Penev <rosenp@gmail.com> writes:
>>
>> > PN9Data is a read-only lookup table and is never modified. Adding const
>> > lets the compiler place it in .rodata and prevents accidental writes.
>> >
>> > Use the same treatment for bits_per_symbol. It's not modified either.
>> >
>> > Assisted-by: opencode:big-pickle
>> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>
>> Again, which actual bug are you fixing here?
> Patches are required to be bugfixes?
Well, or at least have some concrete benefit? You're changing working
code here, we've had to revert patches of this kind before because it
broke things.
For this patch specifically, there's one of two cases:
- The array is never written to, in which case the patch has no
practical effect
or
- The array *is* actually written to somewhere, in which case the kernel
will now crash as soon as someone tries to run the code.
Either way, I don't see how the risk/benefit tradeoff comes off positive
for this patch?
-Toke
^ permalink raw reply
* Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-23 12:57 UTC (permalink / raw)
To: baochen.qiang
Cc: alex, ath11k, ath12k, bhelgaas, jjohnson, jtornosm, linux-kernel,
linux-pci, linux-wireless, mani, mhi
In-Reply-To: <5abb5812-cdd8-47d4-b5a0-33f7351589ea@oss.qualcomm.com>
Hello Baochen,
> what is the difference between a clean VM shutdown and an unclean termination?
> specifically, will pci driver's .shutdown callback be triggered during the clean VM
> shutdown, and not be triggered during a unclean termination?
Clean VM shutdown: The guest OS shuts down normally, so the guest kernel
calls the driver's .shutdown/.remove callbacks. The driver can properly
deinitialize the device, leaving it in a clean state.
Unclean VM termination (crash, force-off): The guest kernel never runs, so
driver callbacks are not triggered. The device remains in whatever state it
was in (DMA active, interrupts enabled, etc.). At this point, only VFIO on
the host can interact with the device to reset it before reassigning it to
the next assignment. Without a working reset method, the device stays in this
undefined state and can't be reused.
That's why VFIO calls pci_try_reset_function() - it's the only way to clean
up the device when the guest driver couldn't.
Best regards
José Ignacio
^ permalink raw reply
* Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-23 12:56 UTC (permalink / raw)
To: mani
Cc: alex, ath11k, ath12k, bhelgaas, jjohnson, jtornosm, linux-kernel,
linux-pci, linux-wireless, mhi
In-Reply-To: <r4jeqtx247iosfjdps6g4fqwtsdzine5qlgh33sdt4p6ktmaln@o725aolrpj4l>
Hi Mani and Alex,
Thank you both for the guidance.
I think your insight about the BAR-space reset mechanisms is a much better
approach to have a "real" reset. With that, I've implemented device-specific
reset functions based on the driver code Mani referenced:
WCN6855/WCN7850 WiFi (reset_qualcomm_wifi):
- Uses SoC global reset via BAR0 offset 0x3008
- Follows the sequence from ath11k_pci_soc_global_reset() /
ath12k_pci_soc_global_reset() / ath11k_pci_sw_reset()
- Set reset bit → 10ms delay → clear reset bit → 10ms delay → verify link
recovery (up to 5s)
- Includes MHI controller reset cleanup (offset 0x38) to clear SYSERR after SoC
reset
- Both WCN6855 and WCN7850 share identical register offsets and reset sequence
SDX62/SDX65 modems (reset_qualcomm_modem):
- Uses MHI SoC reset via BAR0 offset 0xb0
- Follows the sequence from mhi_soc_reset() / mhi_pci_reset_prepare()
- Write reset request → 2s delay for reset completion
All implementations follow Alex's pattern: save command register ->
enable memory decode -> ioremap BAR -> perform reset sequence ->
iounmap -> restore command.
Testing results: The implementation shows successful reset behavior for both
WiFi and modem devices in VFIO passthrough scenarios.
Regarding the approach (quirks.c vs dedicated VFIO driver):
Mani, I understand your concern about potential conflicts with the native
drivers. I want to make sure I implement this correctly. Could you clarify
when you envision the conflict occurring?
From what I can see, the native drivers call their reset functions directly
without using pci_try_reset_function(), so the device-specific reset in
quirks.c could be enough, but I may be missing some error recovery paths or
other scenarios.
Alex, Mani - would you prefer a dedicated VFIO PCI variant driver (similar
to mlx5-vfio-pci) to ensure the reset logic only runs in VFIO scenarios, or
is the quirks.c approach acceptable? I can implement either approach.
With the decision I will send v10.
Thank you again for all your help
Best regards
José Ignacio
^ permalink raw reply
* [PATCH wireless-next] wifi: cfg80211: Avoid UNPROT_BEACON on AP interfaces
From: Dhanavandhana Kannan @ 2026-06-23 10:34 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Dhanavandhana Kannan
Currently, an AP may receive unprotected beacons from neighbouring
BSSes, which cfg80211_rx_unprot_mlme_mgmt() forwards to userspace via
NL80211_CMD_UNPROT_BEACON regardless of interface type.
While the kernel rate-limits these events to once per 10 seconds per
wdev, in multi-BSS scenarios each AP interface maintains its own
rate-limit state, increasing the number of reported events.
In AP mode, hostapd has no handler for NL80211_CMD_UNPROT_BEACON and
logs an unhandled event message for each occurrence, leading to excessive
log noise and making it harder to identify real issues.
Since an AP does not need to act on unprotected beacons from neighbouring
BSSes, skip reporting this event when operating in AP mode.
Signed-off-by: Dhanavandhana Kannan <dhanavandhana.kannan@oss.qualcomm.com>
---
net/wireless/nl80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 53b4b3f76697..5d2feb5002c5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -20890,6 +20890,9 @@ void cfg80211_rx_unprot_mlme_mgmt(struct net_device *dev, const u8 *buf,
} else if (ieee80211_is_disassoc(mgmt->frame_control)) {
event.cmd = NL80211_CMD_UNPROT_DISASSOCIATE;
} else if (ieee80211_is_beacon(mgmt->frame_control)) {
+ if (wdev->iftype == NL80211_IFTYPE_AP ||
+ wdev->iftype == NL80211_IFTYPE_P2P_GO)
+ return;
if (wdev->unprot_beacon_reported &&
elapsed_jiffies_msecs(wdev->unprot_beacon_reported) < 10000)
return;
base-commit: 972c4dd19cb92e03d75b66c426cfade07582a1ba
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next] wifi: ath12k: Advertise multicast Ethernet encapsulation offload support
From: Tamizh Chelvam Raja @ 2026-06-23 10:05 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Tamizh Chelvam Raja
Advertise IEEE80211_OFFLOAD_ENCAP_MCAST to inform mac80211 that
multicast frame encapsulation is handled in hardware. This allows
mac80211 to pass Ethernet-formatted multicast frames directly to
the driver.
In ath12k_wifi7_mac_op_tx(), refine the logic that selects the MLO
multicast replication path. Add a sta pointer check so that only unicast
Hardware-encap frames use the direct transmit path, while multicast
Hardware-encap frames fall through to the MLO replication loop and are
transmitted on each active link.
In the MLO replication loop, use skb_clone() for Hardware-encap frames.
These frames are already in Ethernet format and do not require
802.11 link address rewriting by ath12k_mlo_mcast_update_tx_link_address().
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 6 ++-
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 61 +++++++++++++++++-----
2 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index af354bef5c0d..26b46a404580 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -10117,7 +10117,8 @@ static void ath12k_mac_update_vif_offload(struct ath12k_link_vif *arvif)
if (vif->type != NL80211_IFTYPE_STATION &&
vif->type != NL80211_IFTYPE_AP)
vif->offload_flags &= ~(IEEE80211_OFFLOAD_ENCAP_ENABLED |
- IEEE80211_OFFLOAD_DECAP_ENABLED);
+ IEEE80211_OFFLOAD_DECAP_ENABLED |
+ IEEE80211_OFFLOAD_ENCAP_MCAST);
if (vif->offload_flags & IEEE80211_OFFLOAD_ENCAP_ENABLED) {
ahvif->dp_vif.tx_encap_type = ATH12K_HW_TXRX_ETHERNET;
@@ -10136,6 +10137,9 @@ static void ath12k_mac_update_vif_offload(struct ath12k_link_vif *arvif)
vif->offload_flags &= ~IEEE80211_OFFLOAD_ENCAP_ENABLED;
}
+ if (vif->offload_flags & IEEE80211_OFFLOAD_ENCAP_ENABLED)
+ vif->offload_flags |= IEEE80211_OFFLOAD_ENCAP_MCAST;
+
param_id = WMI_VDEV_PARAM_RX_DECAP_TYPE;
if (vif->offload_flags & IEEE80211_OFFLOAD_DECAP_ENABLED)
param_value = ATH12K_HW_TXRX_ETHERNET;
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index 3d59fa452ec0..e5bf9d218104 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -903,6 +903,7 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
struct ethhdr *eth;
bool is_prb_rsp;
u16 mcbc_gsn;
+ u8 cb_flags;
u8 link_id;
int ret;
struct ath12k_dp *tmp_dp;
@@ -996,8 +997,13 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
ieee80211_has_protected(hdr->frame_control))
is_dvlan = true;
+ /*
+ * Add a sta pointer check to differentiate multicast encapsulation
+ * offload packets, as the ATH12K_SKB_HW_80211_ENCAP flag is also set
+ * for such packets.
+ */
if (!vif->valid_links || !is_mcast || is_dvlan ||
- (skb_cb->flags & ATH12K_SKB_HW_80211_ENCAP) ||
+ ((skb_cb->flags & ATH12K_SKB_HW_80211_ENCAP) && sta) ||
test_bit(ATH12K_FLAG_RAW_MODE, &ar->ab->dev_flags)) {
ret = ath12k_wifi7_dp_tx(dp_pdev, arvif, arsta, skb, false, 0, is_mcast);
if (unlikely(ret)) {
@@ -1009,6 +1015,7 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
mcbc_gsn = atomic_inc_return(&ahvif->dp_vif.mcbc_gsn) & 0xfff;
links_map = ahvif->links_map;
+ cb_flags = skb_cb->flags;
for_each_set_bit(link_id, &links_map,
IEEE80211_MLD_MAX_NUM_LINKS) {
tmp_arvif = rcu_dereference(ahvif->link[link_id]);
@@ -1016,21 +1023,45 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
continue;
tmp_ar = tmp_arvif->ar;
- tmp_dp_pdev = ath12k_dp_to_pdev_dp(tmp_ar->ab->dp,
+ tmp_dp = ath12k_ab_to_dp(tmp_ar->ab);
+ tmp_dp_pdev = ath12k_dp_to_pdev_dp(tmp_dp,
tmp_ar->pdev_idx);
if (!tmp_dp_pdev)
continue;
- msdu_copied = skb_copy(skb, GFP_ATOMIC);
- if (!msdu_copied) {
- ath12k_err(ar->ab,
- "skb copy failure link_id 0x%X vdevid 0x%X\n",
- link_id, tmp_arvif->vdev_id);
- continue;
- }
- ath12k_mlo_mcast_update_tx_link_address(vif, link_id,
- msdu_copied,
- info_flags);
+ if (cb_flags & ATH12K_SKB_HW_80211_ENCAP) {
+ /*
+ * skb->data may be modified for the iova_mask devices.
+ * It is better to use skb_copy() for such devices
+ * to avoid any potential skb corruption related issues.
+ */
+ if (tmp_dp->hw_params->iova_mask)
+ msdu_copied = skb_copy(skb, GFP_ATOMIC);
+ else
+ /*
+ * ath12k_wifi7_dp_tx() should treat cloned HW-encap
+ * Ethernet multicast frames as read-only.
+ */
+ msdu_copied = skb_clone(skb, GFP_ATOMIC);
+ if (!msdu_copied) {
+ ath12k_err(ar->ab,
+ "skb copy/clone failure link_id 0x%X vdevid 0x%X\n",
+ link_id, tmp_arvif->vdev_id);
+ continue;
+ }
+ } else {
+ msdu_copied = skb_copy(skb, GFP_ATOMIC);
+ if (!msdu_copied) {
+ ath12k_err(ar->ab,
+ "skb copy failure link_id 0x%X vdevid 0x%X\n",
+ link_id, tmp_arvif->vdev_id);
+ continue;
+ }
+
+ ath12k_mlo_mcast_update_tx_link_address(vif, link_id,
+ msdu_copied,
+ info_flags);
+ }
skb_cb = ATH12K_SKB_CB(msdu_copied);
skb_cb->link_id = link_id;
@@ -1046,7 +1077,6 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
if (unlikely(!ahvif->dp_vif.key_cipher))
goto skip_peer_find;
- tmp_dp = ath12k_ab_to_dp(tmp_ar->ab);
spin_lock_bh(&tmp_dp->dp_lock);
peer = ath12k_dp_link_peer_find_by_addr(tmp_dp,
tmp_arvif->bssid);
@@ -1065,11 +1095,16 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
skb_cb->cipher = key->cipher;
skb_cb->flags |= ATH12K_SKB_CIPHER_SET;
+ if (skb_cb->flags & ATH12K_SKB_HW_80211_ENCAP)
+ goto skip_fctl_protected_check;
+
hdr = (struct ieee80211_hdr *)msdu_copied->data;
if (!ieee80211_has_protected(hdr->frame_control))
hdr->frame_control |=
cpu_to_le16(IEEE80211_FCTL_PROTECTED);
}
+
+skip_fctl_protected_check:
spin_unlock_bh(&tmp_dp->dp_lock);
skip_peer_find:
base-commit: 972c4dd19cb92e03d75b66c426cfade07582a1ba
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] wifi: mac80211: only accept IBSS channel switch from our own BSSID
From: Johannes Berg @ 2026-06-23 9:12 UTC (permalink / raw)
To: Yingjie Cao; +Cc: linux-wireless, linux-kernel, stable
In-Reply-To: <c3fd8617849368e579a56c4397b7ee8624ef27ad.camel@sipsolutions.net>
On Tue, 2026-06-23 at 11:10 +0200, Johannes Berg wrote:
> On Tue, 2026-06-23 at 17:04 +0800, Yingjie Cao wrote:
> > ieee80211_rx_bss_info() acts on a channel switch announcement (CSA)
> > carried in a received beacon or probe response before it verifies that
> > the frame's BSSID matches our own IBSS; it only checks that the SSID
> > matches. ieee80211_rx_mgmt_spectrum_mgmt() acts on a spectrum management
> > (channel switch) action frame without checking the BSSID at all.
> >
> > Because of this, any station in radio range that knows the IBSS SSID
> > (which is broadcast in cleartext) can inject a beacon or action frame
> > carrying a CSA element that points at an unsupported channel. The switch
> > then fails in ieee80211_ibss_process_chanswitch(), which queues
> > csa_connection_drop_work and tears the whole IBSS down. The members
> > rejoin and the attacker repeats, resulting in a persistent,
> > unauthenticated denial of service. Encrypted IBSS networks are equally
> > affected because beacons are not protected. Since both of these CSA
> > entry points are IBSS-specific, the impact is confined to IBSS (ad-hoc)
> > mode; managed-mode CSA is handled separately in mlme.c and is unaffected.
>
> Once you rewrite this to be more honest, you'll see that the whole Cc
> stable thing and all is fairly much pointless?
>
> Or have you not realised yet that stations can also trivially fake their
> MAC address?
Also, since you don't have a track record in wifi, I'll point once again
to https://docs.kernel.org/process/coding-assistants.html
johannes
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: only accept IBSS channel switch from our own BSSID
From: Johannes Berg @ 2026-06-23 9:10 UTC (permalink / raw)
To: Yingjie Cao; +Cc: linux-wireless, linux-kernel, stable
In-Reply-To: <20260623090437.13198-1-yingjcao@sigvoid.com>
On Tue, 2026-06-23 at 17:04 +0800, Yingjie Cao wrote:
> ieee80211_rx_bss_info() acts on a channel switch announcement (CSA)
> carried in a received beacon or probe response before it verifies that
> the frame's BSSID matches our own IBSS; it only checks that the SSID
> matches. ieee80211_rx_mgmt_spectrum_mgmt() acts on a spectrum management
> (channel switch) action frame without checking the BSSID at all.
>
> Because of this, any station in radio range that knows the IBSS SSID
> (which is broadcast in cleartext) can inject a beacon or action frame
> carrying a CSA element that points at an unsupported channel. The switch
> then fails in ieee80211_ibss_process_chanswitch(), which queues
> csa_connection_drop_work and tears the whole IBSS down. The members
> rejoin and the attacker repeats, resulting in a persistent,
> unauthenticated denial of service. Encrypted IBSS networks are equally
> affected because beacons are not protected. Since both of these CSA
> entry points are IBSS-specific, the impact is confined to IBSS (ad-hoc)
> mode; managed-mode CSA is handled separately in mlme.c and is unaffected.
Once you rewrite this to be more honest, you'll see that the whole Cc
stable thing and all is fairly much pointless?
Or have you not realised yet that stations can also trivially fake their
MAC address?
johannes
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath10k: fix skb leak on incomplete msdu during rx pop
From: Baochen Qiang @ 2026-06-23 9:09 UTC (permalink / raw)
To: Manikanta Pubbisetty, ath10k; +Cc: linux-wireless
In-Reply-To: <20260623064355.1876743-1-manikanta.pubbisetty@oss.qualcomm.com>
On 6/23/2026 2:43 PM, Manikanta Pubbisetty wrote:
> 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: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ 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