* [PATCH RESEND] wifi: rtlwifi: usb: drop redundant device reference
From: Johan Hovold @ 2026-03-09 8:33 UTC (permalink / raw)
To: linux-wireless; +Cc: Ping-Ke Shih, linux-kernel, Johan Hovold
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
This one fell out when sending v2 of the series:
https://lore.kernel.org/all/20260306085144.12064-2-johan@kernel.org/
so posting again separately.
Sorry for the mess.
Johan
drivers/net/wireless/realtek/rtlwifi/usb.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index d35ed56d6db9..9a64df9eed39 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -986,7 +986,6 @@ int rtl_usb_probe(struct usb_interface *intf,
init_completion(&rtlpriv->firmware_loading_complete);
SET_IEEE80211_DEV(hw, &intf->dev);
udev = interface_to_usbdev(intf);
- usb_get_dev(udev);
usb_priv = rtl_usbpriv(hw);
memset(usb_priv, 0, sizeof(*usb_priv));
usb_priv->dev.intf = intf;
@@ -1038,7 +1037,6 @@ int rtl_usb_probe(struct usb_interface *intf,
rtl_deinit_core(hw);
error_out2:
_rtl_usb_io_handler_release(hw);
- usb_put_dev(udev);
kfree(rtlpriv->usb_data);
ieee80211_free_hw(hw);
return -ENODEV;
@@ -1050,7 +1048,6 @@ void rtl_usb_disconnect(struct usb_interface *intf)
struct ieee80211_hw *hw = usb_get_intfdata(intf);
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_mac *rtlmac = rtl_mac(rtl_priv(hw));
- struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
if (unlikely(!rtlpriv))
return;
@@ -1072,7 +1069,6 @@ void rtl_usb_disconnect(struct usb_interface *intf)
kfree(rtlpriv->usb_data);
rtlpriv->cfg->ops->deinit_sw_vars(hw);
_rtl_usb_io_handler_release(hw);
- usb_put_dev(rtlusb->udev);
usb_set_intfdata(intf, NULL);
ieee80211_free_hw(hw);
}
--
2.52.0
^ permalink raw reply related
* [PATCH wireless-next v2] wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work()
From: Lorenzo Bianconi @ 2026-03-09 8:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Lorenzo Bianconi
Delete stale station links announced in the reconfiguration IE
transmitted by the AP in the beacon frames.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v2:
- Remove unnecessary read_lock()/read_unlock()
- Link to v1: https://lore.kernel.org/r/20260307-mac80211-reconf-remove-sta-link-v1-1-efe58070cd36@kernel.org
---
net/mac80211/mlme.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 5ecd3d1b172df70c6e447351c89f956b6d873c20..71b8aeb22ea9a77b8ae34397aeb03199c152d313 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -7058,6 +7058,7 @@ static void ieee80211_ml_reconf_work(struct wiphy *wiphy,
container_of(work, struct ieee80211_sub_if_data,
u.mgd.ml_reconf_work.work);
u16 new_valid_links, new_active_links, new_dormant_links;
+ struct sta_info *sta;
int ret;
if (!sdata->u.mgd.removed_links)
@@ -7093,6 +7094,16 @@ static void ieee80211_ml_reconf_work(struct wiphy *wiphy,
}
}
+ sta = sta_info_get(sdata, sdata->vif.cfg.ap_addr);
+ if (sta) {
+ unsigned long removed_links = sdata->u.mgd.removed_links;
+ unsigned int link_id;
+
+ for_each_set_bit(link_id, &removed_links,
+ IEEE80211_MLD_MAX_NUM_LINKS)
+ ieee80211_sta_free_link(sta, link_id);
+ }
+
new_dormant_links = sdata->vif.dormant_links & ~sdata->u.mgd.removed_links;
ret = ieee80211_vif_set_links(sdata, new_valid_links,
---
base-commit: 97492c019da4b62df83255e968b23b81c0315530
change-id: 20260307-mac80211-reconf-remove-sta-link-a47fa95ea7a7
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH wireless-next] wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work()
From: Johannes Berg @ 2026-03-09 8:22 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Lachlan Hodges, linux-wireless
In-Reply-To: <aa6CuVi3BZxLBcPA@lore-desk>
On Mon, 2026-03-09 at 09:20 +0100, Lorenzo Bianconi wrote:
> > Also, I think you need ieee80211_sta_remove_link() to tell the driver?
>
> I think we already inform the driver running ieee80211_set_active_links() so
> ieee80211_sta_remove_link() seems redundant, right?
>
> ieee80211_set_active_links() -> _ieee80211_set_active_links() -> drv_change_sta_links()
Oh, hmm, yeah, good point!
> > And I realized another thing - this needs to destroy TDLS stations that
> > were on the link being removed, but maybe that's a separate commit.
>
> Do you mean ieee80211_teardown_tdls_peers()? Is it done in
> _ieee80211_set_active_links() too?
So ... it was all already consistent all along, at least towards the
driver? I totally missed that, sorry. Thanks for checking!
johannes
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work()
From: Lorenzo Bianconi @ 2026-03-09 8:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Lachlan Hodges, linux-wireless
In-Reply-To: <be1c90f6be71f6118590b0add4d657cd79d2ea2b.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]
On Mar 09, Johannes Berg wrote:
> On Sun, 2026-03-08 at 14:28 +0100, Lorenzo Bianconi wrote:
> > > > + rcu_read_lock();
> > > > + sta = sta_info_get(sdata, sdata->vif.cfg.ap_addr);
> > > > + if (sta) {
> > > > + unsigned long removed_links = sdata->u.mgd.removed_links;
> > > > + unsigned int link_id;
> > > > +
> > > > + for_each_set_bit(link_id, &removed_links,
> > > > + IEEE80211_MLD_MAX_NUM_LINKS)
> > > > + ieee80211_sta_free_link(sta, link_id);
> > > > + }
> > > > + rcu_read_unlock();
> > > > +
> > >
> > > Could use scoped_guard(rcu) instead?
> >
> > I do not have a strong opinion here.
> > @Johannes: Which one do you prefer?
> >
>
> To answer the literal question: No strong preference I guess, given that
> there's no error path here this seems fine, and the scoped version would
> just add another indentation level.
>
> But you really should just remove the rcu_read_lock/unlock anyway, it's
> not needed since this holds wiphy mutex, which is sufficient to access
> the STA table etc.
ack, I will fix it in v2.
>
> Also, I think you need ieee80211_sta_remove_link() to tell the driver?
I think we already inform the driver running ieee80211_set_active_links() so
ieee80211_sta_remove_link() seems redundant, right?
ieee80211_set_active_links() -> _ieee80211_set_active_links() -> drv_change_sta_links()
>
> And I realized another thing - this needs to destroy TDLS stations that
> were on the link being removed, but maybe that's a separate commit.
Do you mean ieee80211_teardown_tdls_peers()? Is it done in
_ieee80211_set_active_links() too?
Regards,
Lorenzo
>
> johannes
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 01/14] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Sumit Garg @ 2026-03-09 8:09 UTC (permalink / raw)
To: Mukesh Ojha
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, 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, Sumit Garg
In-Reply-To: <20260309080049.si3vzro4z6qn7ewz@hu-mojha-hyd.qualcomm.com>
On Mon, Mar 09, 2026 at 01:30:49PM +0530, Mukesh Ojha wrote:
> On Fri, Mar 06, 2026 at 04:20:14PM +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.
> >
> > [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 fixup]
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Thanks for posting, I was about to add kodiak to the already existing
> list monaco, talos here
> https://lore.kernel.org/lkml/20260127-talos-el2-overlay-v2-0-b6a2266532c4@oss.qualcomm.com/
>
> but did you really miss linux-kernel@vger.kernel.org or is it
> intentional ?
Ah I see, I missed that list. Will add in v2. BTW, this patch in the
series can be applied independently since it will work with existing
SCM interfaces provided by QTEE.
-Sumit
>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 2 ++
> > arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++++++++++++++++++++++++
> > 2 files changed, 37 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index f80b5d9cf1e8..09a7f943190e 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -139,6 +139,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-4000.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs615-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-radxa-dragon-q6a.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > +qcs6490-rb3gen2-el2-dtbs := qcs6490-rb3gen2.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-el2.dtb
> >
> > qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vision-mezzanine.dtbo
> > qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak-el2.dtso b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > new file mode 100644
> > index 000000000000..0b3a69a0d765
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > @@ -0,0 +1,35 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > + *
> > + * Kodiak specific modifications required to boot in EL2.
> > + */
> > +
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +&gpu_zap_shader {
> > + status = "disabled";
> > +};
> > +
> > +&remoteproc_adsp {
> > + iommus = <&apps_smmu 0x1800 0x0>;
> > +};
> > +
> > +&remoteproc_cdsp {
> > + iommus = <&apps_smmu 0x11a0 0x0400>;
> > +};
> > +
> > +&remoteproc_wpss {
> > + iommus = <&apps_smmu 0x1c03 0x1>,
> > + <&apps_smmu 0x1c83 0x1>;
> > +};
> > +
> > +&venus {
> > + status = "disabled";
> > +};
> > +
> > +&watchdog {
> > + status = "okay";
> > +};
> > --
> > 2.51.0
> >
>
> --
> -Mukesh Ojha
>
^ permalink raw reply
* Re: [PATCH 01/14] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Mukesh Ojha @ 2026-03-09 8:00 UTC (permalink / raw)
To: Sumit Garg
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, 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, Sumit Garg
In-Reply-To: <20260306105027.290375-2-sumit.garg@kernel.org>
On Fri, Mar 06, 2026 at 04:20:14PM +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.
>
> [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 fixup]
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Thanks for posting, I was about to add kodiak to the already existing
list monaco, talos here
https://lore.kernel.org/lkml/20260127-talos-el2-overlay-v2-0-b6a2266532c4@oss.qualcomm.com/
but did you really miss linux-kernel@vger.kernel.org or is it
intentional ?
-Mukesh
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 ++
> arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++++++++++++++++++++++++
> 2 files changed, 37 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index f80b5d9cf1e8..09a7f943190e 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -139,6 +139,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-4000.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs615-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs6490-radxa-dragon-q6a.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> +qcs6490-rb3gen2-el2-dtbs := qcs6490-rb3gen2.dtb kodiak-el2.dtbo
> +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-el2.dtb
>
> qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vision-mezzanine.dtbo
> qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
> diff --git a/arch/arm64/boot/dts/qcom/kodiak-el2.dtso b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> new file mode 100644
> index 000000000000..0b3a69a0d765
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + *
> + * Kodiak specific modifications required to boot in EL2.
> + */
> +
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&gpu_zap_shader {
> + status = "disabled";
> +};
> +
> +&remoteproc_adsp {
> + iommus = <&apps_smmu 0x1800 0x0>;
> +};
> +
> +&remoteproc_cdsp {
> + iommus = <&apps_smmu 0x11a0 0x0400>;
> +};
> +
> +&remoteproc_wpss {
> + iommus = <&apps_smmu 0x1c03 0x1>,
> + <&apps_smmu 0x1c83 0x1>;
> +};
> +
> +&venus {
> + status = "disabled";
> +};
> +
> +&watchdog {
> + status = "okay";
> +};
> --
> 2.51.0
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-03-09 7:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
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, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
Sumit Garg
In-Reply-To: <52cd78c2-95e2-4f56-9adc-242b6cf3baab@kernel.org>
On Mon, Mar 09, 2026 at 08:10:02AM +0100, Krzysztof Kozlowski wrote:
> On 09/03/2026 05:55, Sumit Garg wrote:
> > On Fri, Mar 06, 2026 at 12:15:01PM +0100, Krzysztof Kozlowski wrote:
> >> On 06/03/2026 11:50, Sumit Garg wrote:
> >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>
> >>> Qcom platforms has the legacy of using non-standard SCM calls
> >>> splintered over the various kernel drivers. These SCM calls aren't
> >>> compliant with the standard SMC calling conventions which is a
> >>> prerequisite to enable migration to the FF-A specifications from
> >>> Arm.
> >>>
> >>> OP-TEE as an alternative trusted OS to QTEE can't support these non-
> >>> standard SCM calls. And even for newer architectures QTEE won't be able
> >>> to support SCM calls either with FF-A requirements coming in. And with
> >>> both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it
> >>> makes further sense to reuse the TEE bus client drivers infrastructure.
> >>>
> >>> The added benefit of TEE bus infrastructure is that there is support
> >>> for discoverable/enumerable services. With that client drivers don't
> >>> have to manually invoke a special SCM call to know the service status.
> >>>
> >>> So enable the generic Peripheral Authentication Service (PAS) provided
> >>> by the firmware. It acts as the common layer with different TZ
> >>> backends plugged in whether it's an SCM implementation or a proper
> >>> TEE bus based PAS service implementation.
> >>>
> >>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>> ---
> >>> drivers/firmware/qcom/Kconfig | 8 +
> >>> drivers/firmware/qcom/Makefile | 1 +
> >>> drivers/firmware/qcom/qcom_pas.c | 295 +++++++++++++++++++++++++
> >>> drivers/firmware/qcom/qcom_pas.h | 53 +++++
> >>> include/linux/firmware/qcom/qcom_pas.h | 41 ++++
> >>> 5 files changed, 398 insertions(+)
> >>> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> >>> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> >>> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
> >>>
> >>> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> >>> index b477d54b495a..8653639d06db 100644
> >>> --- a/drivers/firmware/qcom/Kconfig
> >>> +++ b/drivers/firmware/qcom/Kconfig
> >>> @@ -6,6 +6,14 @@
> >>>
> >>> menu "Qualcomm firmware drivers"
> >>>
> >>> +config QCOM_PAS
> >>> + tristate
> >>> + help
> >>> + Enable the generic Peripheral Authentication Service (PAS) provided
> >>> + by the firmware. It acts as the common layer with different TZ
> >>> + backends plugged in whether it's an SCM implementation or a proper
> >>> + TEE bus based PAS service implementation.
> >>> +
> >>> config QCOM_SCM
> >>> select QCOM_TZMEM
> >>> tristate
> >>> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
> >>> index 0be40a1abc13..dc5ab45f906a 100644
> >>> --- a/drivers/firmware/qcom/Makefile
> >>> +++ b/drivers/firmware/qcom/Makefile
> >>> @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> >>> obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o
> >>> obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o
> >>> obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
> >>> +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o
> >>> diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
> >>> new file mode 100644
> >>> index 000000000000..dc04ff1b6be0
> >>> --- /dev/null
> >>> +++ b/drivers/firmware/qcom/qcom_pas.c
> >>> @@ -0,0 +1,295 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +/*
> >>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> >>> + */
> >>> +
> >>> +#include <linux/delay.h>
> >>> +#include <linux/device/devres.h>
> >>> +#include <linux/firmware/qcom/qcom_pas.h>
> >>> +#include <linux/of.h>
> >>> +#include <linux/kernel.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/slab.h>
> >>> +
> >>> +#include "qcom_pas.h"
> >>> +#include "qcom_scm.h"
> >>> +
> >>> +static struct qcom_pas_ops *ops_ptr;
> >>
> >> I really dislike this singleton design. And it is not even needed! If
> >> you were storing here some allocated instance of SCM/PAS I could
> >> understand, but singleton for only ops? Just implement one driver (so
> >> SCM + whatever you have here) which will decide which ops to use,
> >> through the probe. Really, this is neither needed nor beneficial.
> >
> > The motivation here is rather quite opposite to the single monolithic
> > SCM driver design. The TZ services like PAS, ICE and so on are going to
> > be implemented as independent discoverable devices on TEE bus which
> > rather needs independent kernel client drivers.
>
> You still have singleton here. So if you think you do opposite to
> singleton, then drop this static.
Sure.
>
> >
> > Also, the single driver probe can't work here since the SCM driver is
> > bound to the platform bus whereas the TEE PAS driver is bound to the TEE
> > bus. So there is a reason for the current design.
> >
> >>
> >> It actually leads to more problems with this barrier handling, see
> >> further comments.
> >
> > The barrier handling is something that I carried over from existing
> > implmentation but I can't see a reason why it can't be replaced with a
> > simple mutex. See diff below for mutex.
> >
> >> ...
> >>
> >>> +
> >>> +/**
> >>> + * qcom_pas_shutdown() - Shut down the remote processor
> >>> + * @pas_id: peripheral authentication service id
> >>> + *
> >>> + * Returns 0 on success.
> >>> + */
> >>> +int qcom_pas_shutdown(u32 pas_id)
> >>> +{
> >>> + if (ops_ptr)
> >>> + return ops_ptr->shutdown(ops_ptr->dev, pas_id);
> >>> +
> >>> + return -ENODEV;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(qcom_pas_shutdown);
> >>> +
> >>> +/**
> >>> + * qcom_pas_supported() - Check if the peripheral authentication service is
> >>> + * available for the given peripheral
> >>> + * @pas_id: peripheral authentication service id
> >>> + *
> >>> + * Returns true if PAS is supported for this peripheral, otherwise false.
> >>> + */
> >>> +bool qcom_pas_supported(u32 pas_id)
> >>> +{
> >>> + if (ops_ptr)
> >>
> >> Lack of barriers here is not looking right. Existing/old code is not a
> >> good example, I fixed only the obvious issue, but new code should be
> >> correct from the beginning.
> >>
> >> Barriers should normally be always paired, unless you have some clear
> >> path no concurrent execution can happen here, but such explanation is
> >> missing, look:
> >
> > Actually concurrent execution is rather required here since TZ can
> > support parallel bring-up of co-processors. The synchonization is only
> > needed when PAS client drivers are performing a deferred probe waiting
> > for the service to be available. However, you are right explanation is
> > missing here which I will add in the next version.
>
> Hm? Existing comments are completely useless. Your comment said just
> "barrier" basically... That's nothing useful.
Agree, following is something I plan for v2 (using mutex instead of a
barrier):
/*
* The ops mutex here is only intended to synchronize when client drivers
* are in parallel checking for PAS service availability. However, once the
* PAS backend becomes available, it is allowed for multiple threads to enter
* TZ for parallel bringup of co-processors during boot.
*/
static DEFINE_MUTEX(ops_mutex);
-Sumit
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work()
From: Johannes Berg @ 2026-03-09 7:14 UTC (permalink / raw)
To: Lorenzo Bianconi, Lachlan Hodges; +Cc: linux-wireless
In-Reply-To: <aa15YDx5G7WN-nsH@lore-desk>
On Sun, 2026-03-08 at 14:28 +0100, Lorenzo Bianconi wrote:
> > > + rcu_read_lock();
> > > + sta = sta_info_get(sdata, sdata->vif.cfg.ap_addr);
> > > + if (sta) {
> > > + unsigned long removed_links = sdata->u.mgd.removed_links;
> > > + unsigned int link_id;
> > > +
> > > + for_each_set_bit(link_id, &removed_links,
> > > + IEEE80211_MLD_MAX_NUM_LINKS)
> > > + ieee80211_sta_free_link(sta, link_id);
> > > + }
> > > + rcu_read_unlock();
> > > +
> >
> > Could use scoped_guard(rcu) instead?
>
> I do not have a strong opinion here.
> @Johannes: Which one do you prefer?
>
To answer the literal question: No strong preference I guess, given that
there's no error path here this seems fine, and the scoped version would
just add another indentation level.
But you really should just remove the rcu_read_lock/unlock anyway, it's
not needed since this holds wiphy mutex, which is sufficient to access
the STA table etc.
Also, I think you need ieee80211_sta_remove_link() to tell the driver?
And I realized another thing - this needs to destroy TDLS stations that
were on the link being removed, but maybe that's a separate commit.
johannes
^ permalink raw reply
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Krzysztof Kozlowski @ 2026-03-09 7:10 UTC (permalink / raw)
To: Sumit Garg
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, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
Sumit Garg
In-Reply-To: <aa5Sw1qcCnD5clth@sumit-xelite>
On 09/03/2026 05:55, Sumit Garg wrote:
> On Fri, Mar 06, 2026 at 12:15:01PM +0100, Krzysztof Kozlowski wrote:
>> On 06/03/2026 11:50, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> Qcom platforms has the legacy of using non-standard SCM calls
>>> splintered over the various kernel drivers. These SCM calls aren't
>>> compliant with the standard SMC calling conventions which is a
>>> prerequisite to enable migration to the FF-A specifications from
>>> Arm.
>>>
>>> OP-TEE as an alternative trusted OS to QTEE can't support these non-
>>> standard SCM calls. And even for newer architectures QTEE won't be able
>>> to support SCM calls either with FF-A requirements coming in. And with
>>> both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it
>>> makes further sense to reuse the TEE bus client drivers infrastructure.
>>>
>>> The added benefit of TEE bus infrastructure is that there is support
>>> for discoverable/enumerable services. With that client drivers don't
>>> have to manually invoke a special SCM call to know the service status.
>>>
>>> So enable the generic Peripheral Authentication Service (PAS) provided
>>> by the firmware. It acts as the common layer with different TZ
>>> backends plugged in whether it's an SCM implementation or a proper
>>> TEE bus based PAS service implementation.
>>>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>> drivers/firmware/qcom/Kconfig | 8 +
>>> drivers/firmware/qcom/Makefile | 1 +
>>> drivers/firmware/qcom/qcom_pas.c | 295 +++++++++++++++++++++++++
>>> drivers/firmware/qcom/qcom_pas.h | 53 +++++
>>> include/linux/firmware/qcom/qcom_pas.h | 41 ++++
>>> 5 files changed, 398 insertions(+)
>>> create mode 100644 drivers/firmware/qcom/qcom_pas.c
>>> create mode 100644 drivers/firmware/qcom/qcom_pas.h
>>> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>>>
>>> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
>>> index b477d54b495a..8653639d06db 100644
>>> --- a/drivers/firmware/qcom/Kconfig
>>> +++ b/drivers/firmware/qcom/Kconfig
>>> @@ -6,6 +6,14 @@
>>>
>>> menu "Qualcomm firmware drivers"
>>>
>>> +config QCOM_PAS
>>> + tristate
>>> + help
>>> + Enable the generic Peripheral Authentication Service (PAS) provided
>>> + by the firmware. It acts as the common layer with different TZ
>>> + backends plugged in whether it's an SCM implementation or a proper
>>> + TEE bus based PAS service implementation.
>>> +
>>> config QCOM_SCM
>>> select QCOM_TZMEM
>>> tristate
>>> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
>>> index 0be40a1abc13..dc5ab45f906a 100644
>>> --- a/drivers/firmware/qcom/Makefile
>>> +++ b/drivers/firmware/qcom/Makefile
>>> @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
>>> obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o
>>> obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o
>>> obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
>>> +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o
>>> diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
>>> new file mode 100644
>>> index 000000000000..dc04ff1b6be0
>>> --- /dev/null
>>> +++ b/drivers/firmware/qcom/qcom_pas.c
>>> @@ -0,0 +1,295 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>>> + */
>>> +
>>> +#include <linux/delay.h>
>>> +#include <linux/device/devres.h>
>>> +#include <linux/firmware/qcom/qcom_pas.h>
>>> +#include <linux/of.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include "qcom_pas.h"
>>> +#include "qcom_scm.h"
>>> +
>>> +static struct qcom_pas_ops *ops_ptr;
>>
>> I really dislike this singleton design. And it is not even needed! If
>> you were storing here some allocated instance of SCM/PAS I could
>> understand, but singleton for only ops? Just implement one driver (so
>> SCM + whatever you have here) which will decide which ops to use,
>> through the probe. Really, this is neither needed nor beneficial.
>
> The motivation here is rather quite opposite to the single monolithic
> SCM driver design. The TZ services like PAS, ICE and so on are going to
> be implemented as independent discoverable devices on TEE bus which
> rather needs independent kernel client drivers.
You still have singleton here. So if you think you do opposite to
singleton, then drop this static.
>
> Also, the single driver probe can't work here since the SCM driver is
> bound to the platform bus whereas the TEE PAS driver is bound to the TEE
> bus. So there is a reason for the current design.
>
>>
>> It actually leads to more problems with this barrier handling, see
>> further comments.
>
> The barrier handling is something that I carried over from existing
> implmentation but I can't see a reason why it can't be replaced with a
> simple mutex. See diff below for mutex.
>
>> ...
>>
>>> +
>>> +/**
>>> + * qcom_pas_shutdown() - Shut down the remote processor
>>> + * @pas_id: peripheral authentication service id
>>> + *
>>> + * Returns 0 on success.
>>> + */
>>> +int qcom_pas_shutdown(u32 pas_id)
>>> +{
>>> + if (ops_ptr)
>>> + return ops_ptr->shutdown(ops_ptr->dev, pas_id);
>>> +
>>> + return -ENODEV;
>>> +}
>>> +EXPORT_SYMBOL_GPL(qcom_pas_shutdown);
>>> +
>>> +/**
>>> + * qcom_pas_supported() - Check if the peripheral authentication service is
>>> + * available for the given peripheral
>>> + * @pas_id: peripheral authentication service id
>>> + *
>>> + * Returns true if PAS is supported for this peripheral, otherwise false.
>>> + */
>>> +bool qcom_pas_supported(u32 pas_id)
>>> +{
>>> + if (ops_ptr)
>>
>> Lack of barriers here is not looking right. Existing/old code is not a
>> good example, I fixed only the obvious issue, but new code should be
>> correct from the beginning.
>>
>> Barriers should normally be always paired, unless you have some clear
>> path no concurrent execution can happen here, but such explanation is
>> missing, look:
>
> Actually concurrent execution is rather required here since TZ can
> support parallel bring-up of co-processors. The synchonization is only
> needed when PAS client drivers are performing a deferred probe waiting
> for the service to be available. However, you are right explanation is
> missing here which I will add in the next version.
Hm? Existing comments are completely useless. Your comment said just
"barrier" basically... That's nothing useful.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH wireless-next 14/35] wifi: mm81x: add mac.c
From: Johannes Berg @ 2026-03-09 7:08 UTC (permalink / raw)
To: Lachlan Hodges
Cc: Dan Callaghan, Arien Judge, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, ayman.grais, linux-wireless,
linux-kernel
In-Reply-To: <vttdls7sm4h3br7y5kcea5i4teqnuiuzgq3miswg6r45asvng7@jto3tksuvofj>
On Mon, 2026-03-09 at 15:43 +1100, Lachlan Hodges wrote:
> > 2) Are you going to incur the wrath of mm/ folks, where instances of
> > 'struct mm_struct' are commonly called 'mm'? I can find a few
> > examples of others (struct drm_buddy *mm, struct mqd_manager *mm),
> > but you'd double the instances.
>
> This.. is definitely something I did not think of. I have no issue with
> renaming to something else.. maybe mx? I'm not sure.
Yeah I really don't know. There's no 'mm->lock' (any more? for some
reason _that_ was what caught my eye wrt. the naming) in mm/, and I
guess soon also not in your driver. I'll try to ask around, but it's
probably safer to rename, and shouldn't be _that_ hard with spatch I
guess. I guess 'mx' seems reasonable, 'mmx' is also confusing perhaps,
and 'mm81x' doesn't lend itself to obvious other abbreviations.
> > > + /*
> > > + * mm81x only support changing/setting the channel
> > > + * when we create an interface.
> > > + */
> > > + if (WARN_ON(changed & IEEE80211_CHANCTX_CHANGE_CHANNEL))
> > > + mm81x_err(mm, "Changing channel via chanctx not supported");
> >
> > Wait, what, why do you have chanctx support then? This seems highly
> > questionable, how do you not run into this all the time?
> >
> > If it just has a single, wouldn't the chanctx emulation suit the driver
> > better, and that'd make this more obvious? Hmm, but you _do_ support
> > multiple vifs? I'm confused.
>
> We originally used chanctx emulation.. but I suppose in an effort to
> be "modern" we use chanctx. It's probably best to switch back to the
> chanctx emulation anyway. As for why we don't run into this is due
> to no channel switch support yet, iirc mac80211 I think needs a minor
> tweak to work with S1G (which further reinforces the idea that we
> should just emulate chanctx)
I don't mind the emulation _that_ much to force drivers into some
unnatural scheme for them :) This seems even more confusing and
unexpected than the emulation perhaps.
But I don't want to impose here either.
> Thanks for the review. On the other thread [1] you mentioned sending a
> pull request once reviews settle down, as per the documentation in [2]
> (which I should have read earlier... :) ),
Heh, I didn't really know we had that document either, Kalle did all
that :)
> can we confirm that this means
> we are to submit subsequent patchset revisions in the same per-file
> format until everyone is happy with the driver, and then raise the PR?
I wouldn't necessarily way _everyone_, you can probably always find
someone willing to nitpick if you look hard enough ;-)
But yeah, I don't think you have a choice for how to post, the whole
driver as one patch would not really even load well in an email client I
guess, let alone make it possible to comment on easily.
As I said there, for the merge I'd prefer just a single commit as a pull
request.
Obviously I hope/expect you're going to continue to maintaining the
driver and we'll have to figure out the workflow for that - perhaps
depending on how much work you're planning to put into it.
johannes
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-03-09 6:53 UTC (permalink / raw)
To: 傅继晗
Cc: linux-wireless, linux-kernel, stable,
Óscar Alfonso Díaz
In-Reply-To: <20260308164510.5927-1-fjhhz1997@gmail.com>
On Sun, 2026-03-08 at 16:45 +0000, 傅继晗 wrote:
> Commit 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
> removed the fallback path in ieee80211_monitor_start_xmit() for when
> the monitor interface has no channel context assigned. This broke frame
> capture and injection for drivers that implement real channel context
> ops (as opposed to the ieee80211_emulate_* helpers), such as the mt76
> family, when a monitor interface runs alongside another interface
> (e.g. managed mode).
It actually broke the others too, as you note later.
> In that scenario the (virtual) monitor sdata does not get a chanctx of
> its own, even though there is an active one from the other interface.
> Before the simplification the code fell back to local->_oper_chandef;
> after it, the code goes straight to fail_rcu and silently drops every
> injected frame.
>
> Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
> behaviour") restored the fallback for drivers using emulate_chanctx,
> but explicitly left real chanctx drivers unfixed.
>
> Fix this by falling back to the first entry in local->chanctx_list
> when the monitor vif has no chanctx and the driver uses real channel
> contexts. This is analogous to how ieee80211_hw_conf_chan() already
> uses the same pattern.
I did have pretty much the same attempt at a fix:
https://lore.kernel.org/linux-wireless/20251216111909.25076-2-johannes@sipsolutions.net/
but it was reported to cause crashes on certain devices, so we didn't
think it was very safe at the time.
Is that no longer an issue?
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mt76: connac: fix txpower_cur not updated in mt76_connac_mcu_set_rate_txpower()
From: Sean Wang @ 2026-03-09 6:42 UTC (permalink / raw)
To: bryam vargas
Cc: linux-wireless, nbd, lorenzo,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <CANAPQzi3BkfnRS4CEXAA560O5cO8e6MEYxeVVx1u+xUeXS-gmA@mail.gmail.com>
Hi,
On Fri, Feb 27, 2026 at 3:53 AM bryam vargas
<bryamestebanvargas@gmail.com> wrote:
>
> From 0a29ccaeb2211451b88ad71c4c0cdbc418b7d64d Mon Sep 17 00:00:00 2001
> From: bryam <bryamestebanvargas@gmail.com>
> Date: Fri, 27 Feb 2026 04:30:01 -0500
> Subject: [PATCH 1/2] mt76: connac: fix txpower_cur not updated in
> mt76_connac_mcu_set_rate_txpower()
>
> mt76_connac_mcu_set_rate_txpower() sends the TX power SKU table to the
> firmware but never updates mphy->txpower_cur. This causes mt76_get_txpower()
> to always report 3 dBm regardless of the actual configured power level,
> since txpower_cur remains at its zero-initialized value and only the
> path delta for 2 chains (6 units of 0.5 dBm) gets applied.
>
> Fix this by calculating the effective TX power using the same approach
> as mt7915: mt76_get_power_bound() applies SAR constraints and chain
> delta, then mt76_get_rate_power_limits() applies the per-rate EEPROM
> limits, yielding the actual value the firmware will use.
I wonder if this would fit better in .get_txpower instead.
mt76_connac_mcu_set_rate_txpower() is primarily a programming path
that pushes the SKU table to firmware. Updating txpower_cur there
mixes write-side configuration with reporting logic.
It might be cleaner to handle this in .get_txpower with an
mt7921-specific callback that derives the reported TX power from the
SKU limits instead of updating the cached value in the write path.
>
> Fixes: 3b4a3bdba808 ("mt76: mt7921: add support for reporting tx power")
> Signed-off-by: Bryam Vargas <bryamestebanvargas@gmail.com>
> ---
> .../net/wireless/mediatek/mt76/mt76_connac_mcu.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> index fc3e672..4ed31ff 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> @@ -2272,6 +2272,20 @@ int mt76_connac_mcu_set_rate_txpower(struct
> mt76_phy *phy)
> return err;
> }
>
> + /* Update txpower_cur so mt76_get_txpower() reports the actual
> + * configured TX power instead of always returning 3 dBm due to
> + * txpower_cur being left at its zero-initialized value.
> + * The value is stored in 0.5 dBm units as used by the SKU table.
> + */
> + if (phy->chandef.chan) {
> + struct mt76_power_limits limits;
> + s8 tx_power;
> +
> + tx_power = mt76_get_power_bound(phy, phy->chandef.chan->max_power);
> + tx_power = mt76_get_rate_power_limits(phy, phy->chandef.chan,
> + &limits, tx_power);
> + phy->txpower_cur = tx_power;
> + }
> return 0;
> }
> EXPORT_SYMBOL_GPL(mt76_connac_mcu_set_rate_txpower);
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-03-09 6:36 UTC (permalink / raw)
To: Jeff Johnson
Cc: Trilok Soni, 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, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, mukesh.ojha, pavan.kondeti, jorge.ramirez, tonyh,
vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, Sumit Garg
In-Reply-To: <13091f47-938d-43fb-a8c0-4b081818b557@oss.qualcomm.com>
On Fri, Mar 06, 2026 at 02:00:48PM -0800, Jeff Johnson wrote:
> On 3/6/2026 11:47 AM, Trilok Soni wrote:
> > On 3/6/2026 2:50 AM, Sumit Garg wrote:
> >> +MODULE_LICENSE("GPL");
> >> +MODULE_AUTHOR("Sumit Garg <sumit.garg@oss.qualcomm.com>");
> >
> > What is the convention for Qualcomm authored drivers? In some drivers
> > I find that Qualcomm doesn't add MODULE_AUTHOR. Can Qualcomm community
> > clarify it here. I prefer consistency here for the Qualcomm submissions.
>
> WLAN team was told to not have MODULE_AUTHOR(), so ath10k was the last WLAN
> driver that had a MODULE_AUTHOR() -- ath11k and ath12k do not have one.
As I said in my other reply, it is quite subsystem specific.
>
> And in reality it is very rare for a given module, over time, to only have a
> single author. The git history contains the real authorship. So just for that
> reason I'd drop it.
Sure, but you would like the driver author to be involved in future
maintenence of the driver. In my experience that's how usually the kernel
development process works. If a separate maintainer's entry is fine then I
can switch to that instead.
-Sumit
^ permalink raw reply
* Re: [PATCH v2 00/18] wifi: drop redundant USB device references
From: Johannes Berg @ 2026-03-09 6:27 UTC (permalink / raw)
To: Jeff Johnson, Johan Hovold, linux-wireless
Cc: Jeff Johnson, Toke Høiland-Jørgensen, Brian Norris,
Francesco Dolcini, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Jakub Kicinski, Stanislaw Gruszka,
Hin-Tak Leung, Jes Sorensen, Ping-Ke Shih, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Matthias Brugger,
AngeloGioacchino Del Regno, Greg Kroah-Hartman, libertas-dev,
linux-kernel
In-Reply-To: <beaed1d8-6c51-4aef-9fd7-00d9646db948@oss.qualcomm.com>
On Fri, 2026-03-06 at 13:39 -0800, Jeff Johnson wrote:
>
> Johannes, will you be taking the entire series via wireless-next?
>
> Or should the individual wireless driver maintainers take their patches
> through their individual trees? I'm OK either way.
So far I took the ones patchwork had auto-assigned to me. I can take
others though, no particular preference, but I guess I already pulled
the series apart anyway.
Let's just say if you want me to take any, assign them to me in
patchwork.
johannes
^ permalink raw reply
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-03-09 6:25 UTC (permalink / raw)
To: Trilok Soni
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, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, mukesh.ojha, pavan.kondeti, jorge.ramirez, tonyh,
vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, Sumit Garg
In-Reply-To: <e0a86461-c136-4371-99cf-c0b0d31443a3@oss.qualcomm.com>
On Fri, Mar 06, 2026 at 11:47:55AM -0800, Trilok Soni wrote:
> On 3/6/2026 2:50 AM, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Qcom platforms has the legacy of using non-standard SCM calls
> > splintered over the various kernel drivers.
>
> You are using multiple conflicting terminologies here. In the first statement
> you have used "non-standard" and immediately you have used "aren't complaint".
Here non-standard means the SCM calls aren't compliant with SMCCC
specifications here [1].
>
> Which ARM document dictates that "standard" and "compliance" here?
It's SMCCC spec here [1].
> Are these
> SCM calls are using the vendor space per the spec, and if yes what does
> non-standard means here.
See detailed explanation of non-standard SCM calls as part of OP-TEE review
here [2].
[1] https://developer.arm.com/documentation/den0028/latest/
[2] https://github.com/OP-TEE/optee_os/pull/7311#discussion_r2106654868
>
> These SCM calls aren't
> > compliant with the standard SMC calling conventions which is a
> > prerequisite to enable migration to the FF-A specifications from
> > Arm.
> >
> > OP-TEE as an alternative trusted OS to QTEE can't support these non-
>
> What is QTEE?
Okay, I can expand that to Qualcomm TEE.
>
> > standard SCM calls. And even for newer architectures QTEE won't be able
>
> meaning of architecture please? Are you referring ARMv9.x or SOC architecture
> or software architecture? What does "newer" means? Is there
> any example available in public or are you ready to share?
Okay, I should have mentioned newer architectures with SEL2 and Hafnium
support where FF-A is only going to be the supported communication
method.
>
> > to support SCM calls either with FF-A requirements coming in. And with
> > both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it
> > makes further sense to reuse the TEE bus client drivers infrastructure.
> >
> > The added benefit of TEE bus infrastructure is that there is support
> > for discoverable/enumerable services. With that client drivers don't
> > have to manually invoke a special SCM call to know the service status.
> >
> > So enable the generic Peripheral Authentication Service (PAS) provided
> > by the firmware. It acts as the common layer with different TZ
> > backends plugged in whether it's an SCM implementation or a proper
> > TEE bus based PAS service implementation.
>
> I haven't checked cover letter in detail, but did you tested these patches
> w/ the devices which doesn't support these new facilities?
Yeah, the patch-set has been tested to be backwards compatible with SCM
APIs too.
>
> >
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> > drivers/firmware/qcom/Kconfig | 8 +
> > drivers/firmware/qcom/Makefile | 1 +
> > drivers/firmware/qcom/qcom_pas.c | 295 +++++++++++++++++++++++++
> > drivers/firmware/qcom/qcom_pas.h | 53 +++++
> > include/linux/firmware/qcom/qcom_pas.h | 41 ++++
> > 5 files changed, 398 insertions(+)
> > create mode 100644 drivers/firmware/qcom/qcom_pas.c
> > create mode 100644 drivers/firmware/qcom/qcom_pas.h
> > create mode 100644 include/linux/firmware/qcom/qcom_pas.h
> >
> > diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> > index b477d54b495a..8653639d06db 100644
> > --- a/drivers/firmware/qcom/Kconfig
> > +++ b/drivers/firmware/qcom/Kconfig
> > @@ -6,6 +6,14 @@
> >
> > menu "Qualcomm firmware drivers"
> >
> > +config QCOM_PAS
> > + tristate
> > + help
> > + Enable the generic Peripheral Authentication Service (PAS) provided
> > + by the firmware. It acts as the common layer with different TZ
> > + backends plugged in whether it's an SCM implementation or a proper
> > + TEE bus based PAS service implementation.
> > +
> > config QCOM_SCM
> > select QCOM_TZMEM
> > tristate
> > diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
> > index 0be40a1abc13..dc5ab45f906a 100644
> > --- a/drivers/firmware/qcom/Makefile
> > +++ b/drivers/firmware/qcom/Makefile
> > @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> > obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o
> > obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o
> > obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
> > +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o
> > diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
> > new file mode 100644
> > index 000000000000..dc04ff1b6be0
> > --- /dev/null
> > +++ b/drivers/firmware/qcom/qcom_pas.c
> > @@ -0,0 +1,295 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/device/devres.h>
> > +#include <linux/firmware/qcom/qcom_pas.h>
> > +#include <linux/of.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
>
> are you sure you are using functionalities from these header files?
>
> I couldn't find slab.h usage quickly and also qcom_scm.h. Can you please confirm?
You are right, I will drop the redundant header includes.
>
> > +
> > +#include "qcom_pas.h"
> > +#include "qcom_scm.h"
> > +
> > +static struct qcom_pas_ops *ops_ptr;
> > +
> > +/**
> > + * devm_qcom_pas_context_alloc() - Allocate peripheral authentication service
> > + * context for a given peripheral
> > + *
> > + * PAS context is device-resource managed, so the caller does not need
> > + * to worry about freeing the context memory.
> > + *
> > + * @dev: PAS firmware device
> > + * @pas_id: peripheral authentication service id
> > + * @mem_phys: Subsystem reserve memory start address
> > + * @mem_size: Subsystem reserve memory size
> > + *
> > + * Returns: The new PAS context, or ERR_PTR() on failure.
> > + */
> > +struct qcom_pas_context *devm_qcom_pas_context_alloc(struct device *dev,
> > + u32 pas_id,
> > + phys_addr_t mem_phys,
> > + size_t mem_size)
> > +{
> > + struct qcom_pas_context *ctx;
> > +
> > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> > + if (!ctx)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + ctx->dev = dev;
> > + ctx->pas_id = pas_id;
> > + ctx->mem_phys = mem_phys;
> > + ctx->mem_size = mem_size;
> > +
> > + return ctx;
> > +}
> > +EXPORT_SYMBOL_GPL(devm_qcom_pas_context_alloc);
> > +
> > +/**
> > + * qcom_pas_init_image() - Initialize peripheral authentication service state
> > + * machine for a given peripheral, using the metadata
> > + * @pas_id: peripheral authentication service id
> > + * @metadata: pointer to memory containing ELF header, program header table
> > + * and optional blob of data used for authenticating the metadata
> > + * and the rest of the firmware
> > + * @size: size of the metadata
> > + * @ctx: optional pas context
> > + *
> > + * Return: 0 on success.
> > + *
> > + * Upon successful return, the PAS metadata context (@ctx) will be used to
> > + * track the metadata allocation, this needs to be released by invoking
> > + * qcom_pas_metadata_release() by the caller.
> > + */
> > +int qcom_pas_init_image(u32 pas_id, const void *metadata, size_t size,
> > + struct qcom_pas_context *ctx)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->init_image(ops_ptr->dev, pas_id,
> > + metadata, size, ctx);
> > +
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_init_image);
> > +
> > +/**
> > + * qcom_pas_metadata_release() - release metadata context
> > + * @ctx: pas context
> > + */
> > +void qcom_pas_metadata_release(struct qcom_pas_context *ctx)
> > +{
> > + if (!ctx || !ctx->ptr)
> > + return;
> > +
> > + if (ops_ptr)
> > + ops_ptr->metadata_release(ops_ptr->dev, ctx);
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_metadata_release);
> > +
> > +/**
> > + * qcom_pas_mem_setup() - Prepare the memory related to a given peripheral
> > + * for firmware loading
> > + * @pas_id: peripheral authentication service id
> > + * @addr: start address of memory area to prepare
> > + * @size: size of the memory area to prepare
> > + *
> > + * Returns 0 on success.
> > + */
> > +int qcom_pas_mem_setup(u32 pas_id, phys_addr_t addr, phys_addr_t size)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->mem_setup(ops_ptr->dev, pas_id, addr, size);
> > +
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_mem_setup);
> > +
> > +/**
> > + * qcom_pas_get_rsc_table() - Retrieve the resource table in passed output buffer
> > + * for a given peripheral.
> > + *
> > + * Qualcomm remote processor may rely on both static and dynamic resources for
> > + * its functionality. Static resources typically refer to memory-mapped
> > + * addresses required by the subsystem and are often embedded within the
> > + * firmware binary and dynamic resources, such as shared memory in DDR etc.,
> > + * are determined at runtime during the boot process.
> > + *
> > + * On Qualcomm Technologies devices, it's possible that static resources are
> > + * not embedded in the firmware binary and instead are provided by TrustZone.
> > + * However, dynamic resources are always expected to come from TrustZone. This
>
> Is it confirmed that it will always come from Trustzone? Is it not possible
> that it can come from trusted controller - bypassing the trustzone? Assuming that
> such controller is never modified by anyone else including final device makers and
> blessed by the trust boundaries.
>
> Is this design going to scale if we put the MCU doing the heavy lifting instead?
I am not aware of such an MCU implementation already but surely when
such implementation comes to life, we can always revisit the APIs
needed. The comments here reflects the implementations which exists as
of now.
>
>
> > + * indicates that for Qualcomm devices, all resources (static and dynamic) will
> > + * be provided by TrustZone PAS service.
> > + *
> > + * If the remote processor firmware binary does contain static resources, they
> > + * should be passed in input_rt. These will be forwarded to TrustZone for
> > + * authentication. TrustZone will then append the dynamic resources and return
> > + * the complete resource table in output_rt_tzm.
> > + *
> > + * If the remote processor firmware binary does not include a resource table,
> > + * the caller of this function should set input_rt as NULL and input_rt_size
> > + * as zero respectively.
> > + *
> > + * More about documentation on resource table data structures can be found in
> > + * include/linux/remoteproc.h
> > + *
> > + * @ctx: PAS context
> > + * @pas_id: peripheral authentication service id
> > + * @input_rt: resource table buffer which is present in firmware binary
> > + * @input_rt_size: size of the resource table present in firmware binary
> > + * @output_rt_size: TrustZone expects caller should pass worst case size for
> > + * the output_rt_tzm.
> > + *
> > + * Return:
> > + * On success, returns a pointer to the allocated buffer containing the final
> > + * resource table and output_rt_size will have actual resource table size from
> > + * TrustZone. The caller is responsible for freeing the buffer. On failure,
> > + * returns ERR_PTR(-errno).
> > + */
> > +struct resource_table *qcom_pas_get_rsc_table(struct qcom_pas_context *ctx,
> > + void *input_rt,
> > + size_t input_rt_size,
> > + size_t *output_rt_size)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->get_rsc_table(ops_ptr->dev, ctx, input_rt,
> > + input_rt_size, output_rt_size);
> > +
> > + return ERR_PTR(-ENODEV);
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_get_rsc_table);
> > +
> > +/**
> > + * qcom_scm_pas_auth_and_reset() - Authenticate the given peripheral firmware
> > + * and reset the remote processor
> > + * @pas_id: peripheral authentication service id
> > + *
> > + * Return 0 on success.
> > + */
> > +int qcom_pas_auth_and_reset(u32 pas_id)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->auth_and_reset(ops_ptr->dev, pas_id);
> > +
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_auth_and_reset);
> > +
> > +/**
> > + * qcom_pas_prepare_and_auth_reset() - Prepare, authenticate, and reset the
> > + * remote processor
> > + *
> > + * @ctx: Context saved during call to qcom_scm_pas_context_init()
> > + *
> > + * This function performs the necessary steps to prepare a PAS subsystem,
> > + * authenticate it using the provided metadata, and initiate a reset sequence.
> > + *
> > + * It should be used when Linux is in control setting up the IOMMU hardware
> > + * for remote subsystem during secure firmware loading processes. The
> > + * preparation step sets up a shmbridge over the firmware memory before
> > + * TrustZone accesses the firmware memory region for authentication. The
> > + * authentication step verifies the integrity and authenticity of the firmware
> > + * or configuration using secure metadata. Finally, the reset step ensures the
> > + * subsystem starts in a clean and sane state.
> > + *
> > + * Return: 0 on success, negative errno on failure.
> > + */
> > +int qcom_pas_prepare_and_auth_reset(struct qcom_pas_context *ctx)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->prepare_and_auth_reset(ops_ptr->dev, ctx);
> > +
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_prepare_and_auth_reset);
> > +
> > +/**
> > + * qcom_pas_set_remote_state() - Set the remote processor state
> > + * @state: peripheral state
> > + * @pas_id: peripheral authentication service id
> > + *
> > + * Returns 0 on success.
> > + */
> > +int qcom_pas_set_remote_state(u32 state, u32 pas_id)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->set_remote_state(ops_ptr->dev, state, pas_id);
> > +
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_set_remote_state);
> > +
> > +/**
> > + * qcom_pas_shutdown() - Shut down the remote processor
> > + * @pas_id: peripheral authentication service id
> > + *
> > + * Returns 0 on success.
> > + */
> > +int qcom_pas_shutdown(u32 pas_id)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->shutdown(ops_ptr->dev, pas_id);
> > +
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_shutdown);
> > +
> > +/**
> > + * qcom_pas_supported() - Check if the peripheral authentication service is
> > + * available for the given peripheral
> > + * @pas_id: peripheral authentication service id
> > + *
> > + * Returns true if PAS is supported for this peripheral, otherwise false.
> > + */
> > +bool qcom_pas_supported(u32 pas_id)
> > +{
> > + if (ops_ptr)
> > + return ops_ptr->supported(ops_ptr->dev, pas_id);
> > +
> > + return false;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_supported);
> > +
> > +/**
> > + * qcom_pas_is_available() - Check for PAS service
> > + *
> > + * Returns true on success.
> > + */
> > +bool qcom_pas_is_available(void)
> > +{
> > + /* The barrier is needed to synchronize with client drivers. */
> > + return !!smp_load_acquire(&ops_ptr);
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_is_available);
> > +
> > +/**
> > + * qcom_pas_ops_register() - Register PAS service ops
> > + * @ops: PAS service ops pointer
> > + */
> > +void qcom_pas_ops_register(struct qcom_pas_ops *ops)
> > +{
> > + if (!qcom_pas_is_available())
> > + /* The barrier is needed to synchronize with client drivers. */
> > + smp_store_release(&ops_ptr, ops);
> > + else
> > + pr_err("qcom_pas: ops already registered\n");
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_ops_register);
> > +
> > +/**
> > + * qcom_pas_ops_unregister() - Unregister PAS service ops
> > + */
> > +void qcom_pas_ops_unregister(void)
> > +{
> > + /* The barrier is needed to synchronize with client drivers. */
> > + smp_store_release(&ops_ptr, NULL);
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_pas_ops_unregister);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Sumit Garg <sumit.garg@oss.qualcomm.com>");
>
> What is the convention for Qualcomm authored drivers? In some drivers
> I find that Qualcomm doesn't add MODULE_AUTHOR. Can Qualcomm community
> clarify it here. I prefer consistency here for the Qualcomm submissions.
Not sure if there can be a single Qualcomm policy across the upstream
kernel contributions. Generally I have seen this to vary from one
sub-system to another. In case of drivers/firmware/
$ git grep -nr MODULE_AUTHOR drivers/firmware/ | wc -l
54
whereas other subsystems prefer a maintainer's entry for new driver
code. The general idea is to keep module authors involved as part of
maintenence, reviews and bug reports. So I will leave this dicision to
Bjorn and Konrad being maintainers for drivers/firmware/qcom/.
>
> > +MODULE_DESCRIPTION("Qualcomm common TZ PAS driver");
> > diff --git a/drivers/firmware/qcom/qcom_pas.h b/drivers/firmware/qcom/qcom_pas.h
> > new file mode 100644
> > index 000000000000..4ebed22178f8
> > --- /dev/null
> > +++ b/drivers/firmware/qcom/qcom_pas.h
> > @@ -0,0 +1,53 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > + */
> > +
> > +#ifndef __QCOM_PAS_INT_H
> > +#define __QCOM_PAS_INT_H
> > +
> > +struct device;
> > +
> > +/**
> > + * struct qcom_pas_ops - Qcom Peripheral Authentication Service (PAS) ops
> > + * @drv_name: PAS driver name.
> > + * @dev: PAS device pointer.
> > + * @supported: Peripheral supported callback.
> > + * @init_image: Peripheral image initialization callback.
> > + * @mem_setup: Peripheral memory setup callback.
> > + * @get_rsc_table: Peripheral get resource table callback.
> > + * @prepare_and_auth_reset: Peripheral prepare firmware authentication and
> > + * reset callback.
> > + * @auth_and_reset: Peripheral firmware authentication and reset
> > + * callback.
> > + * @set_remote_state: Peripheral set remote state callback.
> > + * @shutdown: Peripheral shutdown callback.
> > + * @metadata_release: Image metadata release callback.
> > + */
> > +struct qcom_pas_ops {
> > + const char *drv_name;
> > + struct device *dev;
> > + bool (*supported)(struct device *dev, u32 pas_id);
> > + int (*init_image)(struct device *dev, u32 pas_id,
> > + const void *metadata, size_t size,
> > + struct qcom_pas_context *ctx);
> > + int (*mem_setup)(struct device *dev, u32 pas_id,
> > + phys_addr_t addr, phys_addr_t size);
> > + void *(*get_rsc_table)(struct device *dev,
> > + struct qcom_pas_context *ctx,
> > + void *input_rt,
> > + size_t input_rt_size,
> > + size_t *output_rt_size);
>
> void * or resource_table * as return?
The generic wrapper qcom_pas_get_rsc_table() returns that. From TZ
interface perspective it's just a data buffer.
-Sumit
^ permalink raw reply
* [PATCH mt76 11/11] wifi: mt76: add per-link beacon monitoring for MLO
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
With chanctx drivers using hardware scan or remain-on-channel,
mac80211 does not know when the radio goes off-channel, which breaks
its software beacon loss detection.
Implement per-link beacon monitoring in the driver. Track the last
beacon timestamp per link and check for beacon loss periodically from
the mac_work handler.
Beacon monitoring is initialized on association and on late link
activation, and cleared on disassociation. The beacon_mon_last
timestamp is reset when returning from offchannel and after channel
switches to prevent false beacon loss detection.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/channel.c | 2 +
drivers/net/wireless/mediatek/mt76/mac80211.c | 109 +++++++++++++++++-
drivers/net/wireless/mediatek/mt76/mt76.h | 5 +
.../net/wireless/mediatek/mt76/mt7996/mac.c | 6 +-
.../net/wireless/mediatek/mt76/mt7996/main.c | 32 +++++
drivers/net/wireless/mediatek/mt76/scan.c | 1 -
6 files changed, 150 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index 3072e11e2688..cf3fc09e5d5a 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -257,6 +257,8 @@ int mt76_switch_vif_chanctx(struct ieee80211_hw *hw,
continue;
mlink->ctx = vifs->new_ctx;
+ if (mlink->beacon_mon_interval)
+ WRITE_ONCE(mlink->beacon_mon_last, jiffies);
}
out:
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 38b2088e8c19..b4c935b8d0ec 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -2201,8 +2201,11 @@ mt76_offchannel_notify_iter(void *_data, u8 *mac, struct ieee80211_vif *vif)
mvif = mlink->mvif;
if (!ieee80211_vif_is_mld(vif)) {
- if (mt76_vif_link_phy(mlink) == data->phy)
+ if (mt76_vif_link_phy(mlink) == data->phy) {
+ if (!data->offchannel && mlink->beacon_mon_interval)
+ WRITE_ONCE(mlink->beacon_mon_last, jiffies);
mt76_offchannel_send_nullfunc(data, vif, -1);
+ }
return;
}
@@ -2216,6 +2219,9 @@ mt76_offchannel_notify_iter(void *_data, u8 *mac, struct ieee80211_vif *vif)
if (mt76_vif_link_phy(mlink) != data->phy)
continue;
+ if (!data->offchannel && mlink->beacon_mon_interval)
+ WRITE_ONCE(mlink->beacon_mon_last, jiffies);
+
mt76_offchannel_send_nullfunc(data, vif, link_id);
}
}
@@ -2237,3 +2243,104 @@ void mt76_offchannel_notify(struct mt76_phy *phy, bool offchannel)
local_bh_enable();
}
EXPORT_SYMBOL_GPL(mt76_offchannel_notify);
+
+struct mt76_rx_beacon_data {
+ struct mt76_phy *phy;
+ const u8 *bssid;
+};
+
+static void mt76_rx_beacon_iter(void *_data, u8 *mac,
+ struct ieee80211_vif *vif)
+{
+ struct mt76_rx_beacon_data *data = _data;
+ struct mt76_vif_link *mlink = (struct mt76_vif_link *)vif->drv_priv;
+ struct mt76_vif_data *mvif = mlink->mvif;
+ int link_id;
+
+ if (vif->type != NL80211_IFTYPE_STATION || !vif->cfg.assoc)
+ return;
+
+ for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS; link_id++) {
+ struct ieee80211_bss_conf *link_conf;
+
+ if (link_id == mvif->deflink_id)
+ mlink = (struct mt76_vif_link *)vif->drv_priv;
+ else
+ mlink = rcu_dereference(mvif->link[link_id]);
+ if (!mlink || !mlink->beacon_mon_interval)
+ continue;
+
+ if (mt76_vif_link_phy(mlink) != data->phy)
+ continue;
+
+ link_conf = rcu_dereference(vif->link_conf[link_id]);
+ if (!link_conf ||
+ !ether_addr_equal(link_conf->bssid, data->bssid))
+ continue;
+
+ WRITE_ONCE(mlink->beacon_mon_last, jiffies);
+ }
+}
+
+void mt76_rx_beacon(struct mt76_phy *phy, struct sk_buff *skb)
+{
+ struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
+ struct ieee80211_hdr *hdr = mt76_skb_get_hdr(skb);
+ struct mt76_rx_beacon_data data = {
+ .phy = phy,
+ .bssid = hdr->addr3,
+ };
+
+ mt76_scan_rx_beacon(phy->dev, phy->chandef.chan);
+
+ if (!phy->num_sta)
+ return;
+
+ if (status->flag & (RX_FLAG_FAILED_FCS_CRC | RX_FLAG_ONLY_MONITOR))
+ return;
+
+ ieee80211_iterate_active_interfaces_atomic(phy->hw,
+ IEEE80211_IFACE_ITER_RESUME_ALL,
+ mt76_rx_beacon_iter, &data);
+}
+EXPORT_SYMBOL_GPL(mt76_rx_beacon);
+
+static void mt76_beacon_mon_iter(void *data, u8 *mac,
+ struct ieee80211_vif *vif)
+{
+ struct mt76_phy *phy = data;
+ struct mt76_vif_link *mlink = (struct mt76_vif_link *)vif->drv_priv;
+ struct mt76_vif_data *mvif = mlink->mvif;
+ int link_id;
+
+ if (vif->type != NL80211_IFTYPE_STATION || !vif->cfg.assoc)
+ return;
+
+ for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS; link_id++) {
+ if (link_id == mvif->deflink_id)
+ mlink = (struct mt76_vif_link *)vif->drv_priv;
+ else
+ mlink = rcu_dereference(mvif->link[link_id]);
+ if (!mlink || !mlink->beacon_mon_interval)
+ continue;
+
+ if (mt76_vif_link_phy(mlink) != phy)
+ continue;
+
+ if (time_after(jiffies,
+ READ_ONCE(mlink->beacon_mon_last) +
+ MT76_BEACON_MON_MAX_MISS * mlink->beacon_mon_interval))
+ ieee80211_beacon_loss(vif);
+ }
+}
+
+void mt76_beacon_mon_check(struct mt76_phy *phy)
+{
+ if (phy->offchannel)
+ return;
+
+ ieee80211_iterate_active_interfaces_atomic(phy->hw,
+ IEEE80211_IFACE_ITER_RESUME_ALL,
+ mt76_beacon_mon_iter, phy);
+}
+EXPORT_SYMBOL_GPL(mt76_beacon_mon_check);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 0e6be1d0dffa..6dbd0bcbd1fe 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -367,6 +367,7 @@ enum mt76_wcid_flags {
};
#define MT76_N_WCIDS 1088
+#define MT76_BEACON_MON_MAX_MISS 7
/* stored in ieee80211_tx_info::hw_queue */
#define MT_TX_HW_QUEUE_PHY GENMASK(3, 2)
@@ -836,6 +837,8 @@ struct mt76_vif_link {
u8 mcast_rates_idx;
u8 beacon_rates_idx;
bool offchannel;
+ unsigned long beacon_mon_last;
+ u16 beacon_mon_interval;
struct ieee80211_chanctx_conf *ctx;
struct mt76_wcid *wcid;
struct mt76_vif_data *mvif;
@@ -1608,6 +1611,8 @@ int mt76_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_scan_request *hw_req);
void mt76_cancel_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
void mt76_scan_rx_beacon(struct mt76_dev *dev, struct ieee80211_channel *chan);
+void mt76_rx_beacon(struct mt76_phy *phy, struct sk_buff *skb);
+void mt76_beacon_mon_check(struct mt76_phy *phy);
void mt76_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
const u8 *mac);
void mt76_sw_scan_complete(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index ae7ce19a4d9b..ef31452d63ab 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -515,9 +515,6 @@ mt7996_mac_fill_rx(struct mt7996_dev *dev, enum mt76_rxq_id q,
qos_ctl = FIELD_GET(MT_RXD10_QOS_CTL, v2);
seq_ctrl = FIELD_GET(MT_RXD10_SEQ_CTRL, v2);
- if (ieee80211_is_beacon(fc))
- mt76_scan_rx_beacon(&dev->mt76, mphy->chandef.chan);
-
rxd += 4;
if ((u8 *)rxd - skb->data >= skb->len)
return -EINVAL;
@@ -664,6 +661,8 @@ mt7996_mac_fill_rx(struct mt7996_dev *dev, enum mt76_rxq_id q,
hdr = mt76_skb_get_hdr(skb);
fc = hdr->frame_control;
+ if (ieee80211_is_beacon(fc))
+ mt76_rx_beacon(mphy, skb);
if (ieee80211_is_data_qos(fc)) {
u8 *qos = ieee80211_get_qos_ctl(hdr);
@@ -2944,6 +2943,7 @@ void mt7996_mac_work(struct work_struct *work)
mutex_unlock(&mphy->dev->mutex);
+ mt76_beacon_mon_check(mphy);
mt76_tx_status_check(mphy->dev, false);
ieee80211_queue_delayed_work(mphy->hw, &mphy->mac_work,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/main.c b/drivers/net/wireless/mediatek/mt76/mt7996/main.c
index e1e51c9a0767..73ac230afde9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/main.c
@@ -376,6 +376,17 @@ int mt7996_vif_link_add(struct mt76_phy *mphy, struct ieee80211_vif *vif,
mvif->mt76.deflink_id = link_conf->link_id;
}
+ if (vif->type == NL80211_IFTYPE_STATION) {
+ vif->driver_flags |= IEEE80211_VIF_BEACON_FILTER;
+
+ if (vif->cfg.assoc && link_conf->beacon_int) {
+ mlink->beacon_mon_interval =
+ msecs_to_jiffies(ieee80211_tu_to_usec(
+ link_conf->beacon_int) / 1000);
+ WRITE_ONCE(mlink->beacon_mon_last, jiffies);
+ }
+ }
+
return 0;
}
@@ -831,6 +842,13 @@ mt7996_vif_cfg_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
if (!link)
continue;
+ if (vif->type == NL80211_IFTYPE_STATION) {
+ link->mt76.beacon_mon_interval =
+ msecs_to_jiffies(ieee80211_tu_to_usec(
+ link_conf->beacon_int) / 1000);
+ WRITE_ONCE(link->mt76.beacon_mon_last, jiffies);
+ }
+
if (!link->phy)
continue;
@@ -843,6 +861,20 @@ mt7996_vif_cfg_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
}
}
+ if ((changed & BSS_CHANGED_ASSOC) && !vif->cfg.assoc &&
+ vif->type == NL80211_IFTYPE_STATION) {
+ struct ieee80211_bss_conf *link_conf;
+ unsigned long link_id;
+
+ for_each_vif_active_link(vif, link_conf, link_id) {
+ struct mt7996_vif_link *link;
+
+ link = mt7996_vif_link(dev, vif, link_id);
+ if (link)
+ link->mt76.beacon_mon_interval = 0;
+ }
+ }
+
mutex_unlock(&dev->mt76.mutex);
}
diff --git a/drivers/net/wireless/mediatek/mt76/scan.c b/drivers/net/wireless/mediatek/mt76/scan.c
index 04cf8a01f20d..fbc10c9657cf 100644
--- a/drivers/net/wireless/mediatek/mt76/scan.c
+++ b/drivers/net/wireless/mediatek/mt76/scan.c
@@ -105,7 +105,6 @@ void mt76_scan_rx_beacon(struct mt76_dev *dev, struct ieee80211_channel *chan)
out:
spin_unlock(&dev->scan_lock);
}
-EXPORT_SYMBOL_GPL(mt76_scan_rx_beacon);
void mt76_scan_work(struct work_struct *work)
{
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 08/11] wifi: mt76: flush pending TX before channel switch
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
mt76_tx() queues frames on wcid->tx_pending for async processing by
tx_worker. In __mt76_set_channel(), the worker gets disabled before it
may have run, and the subsequent wait only checks DMA ring queues, not
the software pending list. This means frames like nullfunc PS frames
from mt76_offchannel_notify() may never be transmitted on the correct
channel.
Fix this by running mt76_txq_schedule_pending() synchronously after
disabling the tx_worker but before setting MT76_RESET, which would
otherwise cause mt76_txq_schedule_pending_wcid() to bail out.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 5 +++--
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index e6315d35c683..51fe696c9825 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -1031,9 +1031,10 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
int timeout = HZ / 5;
int ret;
- set_bit(MT76_RESET, &phy->state);
-
mt76_worker_disable(&dev->tx_worker);
+ mt76_txq_schedule_pending(phy);
+
+ set_bit(MT76_RESET, &phy->state);
wait_event_timeout(dev->tx_wait, !mt76_has_tx_pending(phy), timeout);
mt76_update_survey(phy);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index bafbc1747673..fe4f30ea71da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -1525,6 +1525,7 @@ void mt76_stop_tx_queues(struct mt76_phy *phy, struct ieee80211_sta *sta,
void mt76_tx_check_agg_ssn(struct ieee80211_sta *sta, struct sk_buff *skb);
void mt76_txq_schedule(struct mt76_phy *phy, enum mt76_txq_id qid);
void mt76_txq_schedule_all(struct mt76_phy *phy);
+void mt76_txq_schedule_pending(struct mt76_phy *phy);
void mt76_tx_worker_run(struct mt76_dev *dev);
void mt76_tx_worker(struct mt76_worker *w);
void mt76_release_buffered_frames(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 0753acf2eccb..ab62591b7a26 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -660,7 +660,7 @@ mt76_txq_schedule_pending_wcid(struct mt76_phy *phy, struct mt76_wcid *wcid,
return ret;
}
-static void mt76_txq_schedule_pending(struct mt76_phy *phy)
+void mt76_txq_schedule_pending(struct mt76_phy *phy)
{
LIST_HEAD(tx_list);
int ret = 0;
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 10/11] wifi: mt76: wait for firmware TX completion of mgmt frames before channel switch
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
After flushing software-pending frames to DMA, mt76_has_tx_pending()
only checks DMA ring q->queued. For token-based drivers, q->queued is
decremented at DMA consumption, but firmware may not have transmitted
the frame yet. Waiting for all tokens is not feasible because data
frames may be stuck in firmware powersave/aggregation queues.
Track PSD queue tokens (firmware ALTX) per phy using an atomic counter.
These frames are sent by firmware immediately without PS buffering, so
the counter reliably reaches zero after transmission.
Increment the counter in mt76_token_consume() and decrement it in
mt76_token_release(), only for PSD queue tokens. Include the counter
in mt76_has_tx_pending() so channel switch waits for firmware TX
completion of management and nullfunc frames.
mt7615 (uses mt76_token_get/put) and non-token drivers are unaffected
as they never call mt76_token_consume/release.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/dma.c | 2 ++
drivers/net/wireless/mediatek/mt76/mac80211.c | 3 +++
drivers/net/wireless/mediatek/mt76/mt76.h | 3 +++
.../net/wireless/mediatek/mt76/mt76_connac_mac.c | 6 ++++++
drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 6 ++++++
drivers/net/wireless/mediatek/mt76/tx.c | 14 +++++++++++++-
6 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index 2d133ace7c33..f8c2fe5f2f58 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -666,6 +666,8 @@ mt76_dma_tx_queue_skb(struct mt76_phy *phy, struct mt76_queue *q,
if (!t)
goto free_skb;
+ t->phy_idx = phy->band_idx;
+ t->qid = qid;
txwi = mt76_get_txwi_ptr(dev, t);
skb->prev = skb->next = NULL;
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 51fe696c9825..38b2088e8c19 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -971,6 +971,9 @@ bool mt76_has_tx_pending(struct mt76_phy *phy)
return true;
}
+ if (atomic_read(&phy->mgmt_tx_pending))
+ return true;
+
return false;
}
EXPORT_SYMBOL_GPL(mt76_has_tx_pending);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index fe4f30ea71da..0e6be1d0dffa 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -453,6 +453,7 @@ struct mt76_txwi_cache {
};
u8 qid;
+ u8 phy_idx;
};
struct mt76_rx_tid {
@@ -863,6 +864,8 @@ struct mt76_phy {
struct list_head tx_list;
struct mt76_queue *q_tx[__MT_TXQ_MAX];
+ atomic_t mgmt_tx_pending;
+
struct cfg80211_chan_def chandef;
struct cfg80211_chan_def main_chandef;
bool offchannel;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
index 15d8a6da0c92..ad539b22585e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
@@ -1209,5 +1209,11 @@ void mt76_connac2_tx_token_put(struct mt76_dev *dev)
}
spin_unlock_bh(&dev->token_lock);
idr_destroy(&dev->token);
+
+ for (id = 0; id < __MT_MAX_BAND; id++) {
+ struct mt76_phy *phy = dev->phys[id];
+ if (phy)
+ atomic_set(&phy->mgmt_tx_pending, 0);
+ }
}
EXPORT_SYMBOL_GPL(mt76_connac2_tx_token_put);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index ed9ada53f8e5..ae7ce19a4d9b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -2215,6 +2215,12 @@ void mt7996_tx_token_put(struct mt7996_dev *dev)
}
spin_unlock_bh(&dev->mt76.token_lock);
idr_destroy(&dev->mt76.token);
+
+ for (id = 0; id < __MT_MAX_BAND; id++) {
+ struct mt76_phy *phy = dev->mt76.phys[id];
+ if (phy)
+ atomic_set(&phy->mgmt_tx_pending, 0);
+ }
}
static int
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 7b0fae694f12..22f9690634c9 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -866,9 +866,15 @@ int mt76_token_consume(struct mt76_dev *dev, struct mt76_txwi_cache **ptxwi)
token = idr_alloc(&dev->token, *ptxwi, dev->token_start,
dev->token_start + dev->token_size,
GFP_ATOMIC);
- if (token >= dev->token_start)
+ if (token >= dev->token_start) {
dev->token_count++;
+ if ((*ptxwi)->qid == MT_TXQ_PSD) {
+ struct mt76_phy *mphy = mt76_dev_phy(dev, (*ptxwi)->phy_idx);
+ atomic_inc(&mphy->mgmt_tx_pending);
+ }
+ }
+
#ifdef CONFIG_NET_MEDIATEK_SOC_WED
if (mtk_wed_device_active(&dev->mmio.wed) &&
token >= dev->mmio.wed.wlan.token_start)
@@ -913,6 +919,12 @@ mt76_token_release(struct mt76_dev *dev, int token, bool *wake)
if (txwi) {
dev->token_count--;
+ if (txwi->qid == MT_TXQ_PSD) {
+ struct mt76_phy *mphy = mt76_dev_phy(dev, txwi->phy_idx);
+ if (atomic_dec_and_test(&mphy->mgmt_tx_pending))
+ wake_up(&dev->tx_wait);
+ }
+
#ifdef CONFIG_NET_MEDIATEK_SOC_WED
if (mtk_wed_device_active(&dev->mmio.wed) &&
token >= dev->mmio.wed.wlan.token_start &&
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 09/11] wifi: mt76: route nullfunc frames to PSD/ALTX queue
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
ieee80211_is_data() returns true for nullfunc/QoS-nullfunc frames, so
they bypass the PSD queue routing and go through the regular VO data
queue. This means firmware processes them through the normal TID queue
instead of the ALTX queue, which doesn't guarantee immediate
transmission.
Use ieee80211_is_data_present() instead, which returns false for both
management frames and nullfunc/QoS-nullfunc (no payload), routing them
to MT_TXQ_PSD. Firmware maps PSD to the ALTX queue, which transmits
immediately without PS buffering.
This only affects frames from the mt76_tx() pending path. Regular
mac80211 TXQ scheduling is unchanged.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index ab62591b7a26..7b0fae694f12 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -632,7 +632,7 @@ mt76_txq_schedule_pending_wcid(struct mt76_phy *phy, struct mt76_wcid *wcid,
if ((dev->drv->drv_flags & MT_DRV_HW_MGMT_TXQ) &&
!(info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) &&
- !ieee80211_is_data(hdr->frame_control) &&
+ !ieee80211_is_data_present(hdr->frame_control) &&
(!ieee80211_is_bufferable_mmpdu(skb) ||
ieee80211_is_deauth(hdr->frame_control) ||
head == &wcid->tx_offchannel))
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 07/11] wifi: mt76: send nullfunc PS frames on offchannel transitions
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
Since mt76 uses chanctx, mac80211 does not send nullfunc power save
notifications when the driver goes offchannel for scan or ROC.
Add mt76_offchannel_notify() to send nullfunc PM=1 before going
offchannel and PM=0 after returning, so that the AP can buffer
frames during the absence.
For MLO, iterate all vif links on the phy and set
IEEE80211_TX_CTRL_MLO_LINK so that the driver's tx_prepare_skb
resolves the correct per-link wcid.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/channel.c | 12 ++-
drivers/net/wireless/mediatek/mt76/mac80211.c | 101 ++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
drivers/net/wireless/mediatek/mt76/scan.c | 7 +-
4 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index f42f25101544..3072e11e2688 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -328,8 +328,10 @@ void mt76_roc_complete(struct mt76_phy *phy)
if (mlink)
mlink->mvif->roc_phy = NULL;
if (phy->chanctx && phy->main_chandef.chan && phy->offchannel &&
- !test_bit(MT76_MCU_RESET, &dev->phy.state))
+ !test_bit(MT76_MCU_RESET, &dev->phy.state)) {
__mt76_set_channel(phy, &phy->main_chandef, false);
+ mt76_offchannel_notify(phy, false);
+ }
mt76_put_vif_phy_link(phy, phy->roc_vif, phy->roc_link);
phy->roc_vif = NULL;
phy->roc_link = NULL;
@@ -367,6 +369,7 @@ int mt76_remain_on_channel(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct mt76_phy *phy = hw->priv;
struct mt76_dev *dev = phy->dev;
struct mt76_vif_link *mlink;
+ bool offchannel;
int ret = 0;
phy = dev->band_phys[chan->band];
@@ -392,8 +395,11 @@ int mt76_remain_on_channel(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
mlink->mvif->roc_phy = phy;
phy->roc_vif = vif;
phy->roc_link = mlink;
- ret = __mt76_set_channel(phy, &chandef,
- mt76_offchannel_chandef(phy, chan, &chandef));
+
+ offchannel = mt76_offchannel_chandef(phy, chan, &chandef);
+ if (offchannel)
+ mt76_offchannel_notify(phy, true);
+ ret = __mt76_set_channel(phy, &chandef, offchannel);
if (ret) {
mlink->mvif->roc_phy = NULL;
phy->roc_vif = NULL;
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 3c539c263238..e6315d35c683 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -2132,3 +2132,104 @@ u16 mt76_select_links(struct ieee80211_vif *vif, int max_active_links)
return sel_links;
}
EXPORT_SYMBOL_GPL(mt76_select_links);
+
+struct mt76_offchannel_cb_data {
+ struct mt76_phy *phy;
+ bool offchannel;
+};
+
+static void
+mt76_offchannel_send_nullfunc(struct mt76_offchannel_cb_data *data,
+ struct ieee80211_vif *vif, int link_id)
+{
+ struct mt76_phy *phy = data->phy;
+ struct ieee80211_tx_info *info;
+ struct ieee80211_sta *sta = NULL;
+ struct ieee80211_hdr *hdr;
+ struct mt76_wcid *wcid;
+ struct sk_buff *skb;
+
+ skb = ieee80211_nullfunc_get(phy->hw, vif, link_id, true);
+ if (!skb)
+ return;
+
+ hdr = (struct ieee80211_hdr *)skb->data;
+ if (data->offchannel)
+ hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_PM);
+
+ skb->priority = 7;
+ skb_set_queue_mapping(skb, IEEE80211_AC_VO);
+
+ if (!ieee80211_tx_prepare_skb(phy->hw, vif, skb,
+ phy->main_chandef.chan->band,
+ &sta)) {
+ ieee80211_free_txskb(phy->hw, skb);
+ return;
+ }
+
+ if (sta)
+ wcid = (struct mt76_wcid *)sta->drv_priv;
+ else
+ wcid = ((struct mt76_vif_link *)vif->drv_priv)->wcid;
+
+ if (link_id >= 0) {
+ info = IEEE80211_SKB_CB(skb);
+ info->control.flags &= ~IEEE80211_TX_CTRL_MLO_LINK;
+ info->control.flags |=
+ u32_encode_bits(link_id, IEEE80211_TX_CTRL_MLO_LINK);
+ }
+
+ mt76_tx(phy, sta, wcid, skb);
+}
+
+static void
+mt76_offchannel_notify_iter(void *_data, u8 *mac, struct ieee80211_vif *vif)
+{
+ struct mt76_offchannel_cb_data *data = _data;
+ struct mt76_vif_link *mlink;
+ struct mt76_vif_data *mvif;
+ int link_id;
+
+ if (vif->type != NL80211_IFTYPE_STATION || !vif->cfg.assoc)
+ return;
+
+ mlink = (struct mt76_vif_link *)vif->drv_priv;
+ mvif = mlink->mvif;
+
+ if (!ieee80211_vif_is_mld(vif)) {
+ if (mt76_vif_link_phy(mlink) == data->phy)
+ mt76_offchannel_send_nullfunc(data, vif, -1);
+ return;
+ }
+
+ for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS; link_id++) {
+ if (link_id == mvif->deflink_id)
+ mlink = (struct mt76_vif_link *)vif->drv_priv;
+ else
+ mlink = rcu_dereference(mvif->link[link_id]);
+ if (!mlink)
+ continue;
+ if (mt76_vif_link_phy(mlink) != data->phy)
+ continue;
+
+ mt76_offchannel_send_nullfunc(data, vif, link_id);
+ }
+}
+
+void mt76_offchannel_notify(struct mt76_phy *phy, bool offchannel)
+{
+ struct mt76_offchannel_cb_data data = {
+ .phy = phy,
+ .offchannel = offchannel,
+ };
+
+ if (!phy->num_sta)
+ return;
+
+ local_bh_disable();
+ ieee80211_iterate_active_interfaces_atomic(phy->hw,
+ IEEE80211_IFACE_ITER_NORMAL,
+ mt76_offchannel_notify_iter, &data);
+ local_bh_enable();
+}
+EXPORT_SYMBOL_GPL(mt76_offchannel_notify);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index fe1c50af460c..bafbc1747673 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -1816,6 +1816,7 @@ struct mt76_vif_link *mt76_get_vif_phy_link(struct mt76_phy *phy,
struct ieee80211_vif *vif);
void mt76_put_vif_phy_link(struct mt76_phy *phy, struct ieee80211_vif *vif,
struct mt76_vif_link *mlink);
+void mt76_offchannel_notify(struct mt76_phy *phy, bool offchannel);
/* usb */
static inline bool mt76u_urb_error(struct urb *urb)
diff --git a/drivers/net/wireless/mediatek/mt76/scan.c b/drivers/net/wireless/mediatek/mt76/scan.c
index 5a67e9b8183a..04cf8a01f20d 100644
--- a/drivers/net/wireless/mediatek/mt76/scan.c
+++ b/drivers/net/wireless/mediatek/mt76/scan.c
@@ -17,8 +17,10 @@ static void mt76_scan_complete(struct mt76_dev *dev, bool abort)
clear_bit(MT76_SCANNING, &phy->state);
if (dev->scan.chan && phy->main_chandef.chan && phy->offchannel &&
- !test_bit(MT76_MCU_RESET, &dev->phy.state))
+ !test_bit(MT76_MCU_RESET, &dev->phy.state)) {
mt76_set_channel(phy, &phy->main_chandef, false);
+ mt76_offchannel_notify(phy, false);
+ }
mt76_put_vif_phy_link(phy, dev->scan.vif, dev->scan.mlink);
memset(&dev->scan, 0, sizeof(dev->scan));
if (!test_bit(MT76_MCU_RESET, &dev->phy.state))
@@ -135,12 +137,15 @@ void mt76_scan_work(struct work_struct *work)
if (dev->scan.chan && phy->num_sta && phy->offchannel) {
dev->scan.chan = NULL;
mt76_set_channel(phy, &phy->main_chandef, false);
+ mt76_offchannel_notify(phy, false);
goto out;
}
dev->scan.chan = req->channels[dev->scan.chan_idx++];
offchannel = mt76_offchannel_chandef(phy, dev->scan.chan, &chandef);
+ if (offchannel)
+ mt76_offchannel_notify(phy, true);
mt76_set_channel(phy, &chandef, offchannel);
if (!req->n_ssids)
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 06/11] wifi: mt76: optimize ROC for same-channel case
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
mt76_remain_on_channel() always creates an HT20 chandef and goes
offchannel, even when the ROC channel matches the operating channel.
This unnecessarily narrows bandwidth and triggers beacon stop/restart.
When the ROC channel matches the current operating channel, preserve
the full chandef and skip the offchannel transition, matching the
optimization already present in the scan code.
Extract the shared same-channel detection into mt76_offchannel_chandef()
and use it in both ROC and scan paths.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/channel.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt76.h | 12 ++++++++++++
drivers/net/wireless/mediatek/mt76/scan.c | 6 +-----
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index 8d2e72c68c6b..f42f25101544 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -392,8 +392,8 @@ int mt76_remain_on_channel(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
mlink->mvif->roc_phy = phy;
phy->roc_vif = vif;
phy->roc_link = mlink;
- cfg80211_chandef_create(&chandef, chan, NL80211_CHAN_HT20);
- ret = __mt76_set_channel(phy, &chandef, true);
+ ret = __mt76_set_channel(phy, &chandef,
+ mt76_offchannel_chandef(phy, chan, &chandef));
if (ret) {
mlink->mvif->roc_phy = NULL;
phy->roc_vif = NULL;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index efb57a0d8965..fe1c50af460c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -1793,6 +1793,18 @@ void mt76_queue_tx_complete(struct mt76_dev *dev, struct mt76_queue *q,
struct mt76_queue_entry *e);
int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
bool offchannel);
+
+static inline bool
+mt76_offchannel_chandef(struct mt76_phy *phy, struct ieee80211_channel *chan,
+ struct cfg80211_chan_def *chandef)
+{
+ cfg80211_chandef_create(chandef, chan, NL80211_CHAN_HT20);
+ if (phy->main_chandef.chan != chan)
+ return true;
+
+ *chandef = phy->main_chandef;
+ return false;
+}
int mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
bool offchannel);
void mt76_scan_work(struct work_struct *work);
diff --git a/drivers/net/wireless/mediatek/mt76/scan.c b/drivers/net/wireless/mediatek/mt76/scan.c
index 2b5f30cef795..5a67e9b8183a 100644
--- a/drivers/net/wireless/mediatek/mt76/scan.c
+++ b/drivers/net/wireless/mediatek/mt76/scan.c
@@ -139,11 +139,7 @@ void mt76_scan_work(struct work_struct *work)
}
dev->scan.chan = req->channels[dev->scan.chan_idx++];
- cfg80211_chandef_create(&chandef, dev->scan.chan, NL80211_CHAN_HT20);
- if (phy->main_chandef.chan == dev->scan.chan) {
- chandef = phy->main_chandef;
- offchannel = false;
- }
+ offchannel = mt76_offchannel_chandef(phy, dev->scan.chan, &chandef);
mt76_set_channel(phy, &chandef, offchannel);
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 04/11] wifi: mt76: check chanctx before restoring channel after ROC
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
mt76_remove_chanctx() sets phy->chanctx to NULL but does not clear
phy->main_chandef. If ROC is later performed on that phy, completion
tries to restore the stale main_chandef channel, programming the
hardware to sit on a channel with no active context.
Add a chanctx check to avoid restoring a channel when no context is
active.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index ae7b4ed27a5c..cfff50892a6e 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -324,7 +324,7 @@ void mt76_roc_complete(struct mt76_phy *phy)
if (mlink)
mlink->mvif->roc_phy = NULL;
- if (phy->main_chandef.chan && phy->offchannel &&
+ if (phy->chanctx && phy->main_chandef.chan && phy->offchannel &&
!test_bit(MT76_MCU_RESET, &dev->phy.state))
__mt76_set_channel(phy, &phy->main_chandef, false);
mt76_put_vif_phy_link(phy, phy->roc_vif, phy->roc_link);
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 03/11] wifi: mt76: add offchannel check to mt76_roc_complete
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
mt76_roc_complete() unconditionally calls __mt76_set_channel() to
restore the operating channel. The scan equivalent mt76_scan_complete()
checks phy->offchannel first, skipping the restore if the phy is
already back on-channel.
Without this check, ROC completion performs a redundant full hardware
channel switch when something has already moved the phy back.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index d9f8529db7ed..ae7b4ed27a5c 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -324,7 +324,7 @@ void mt76_roc_complete(struct mt76_phy *phy)
if (mlink)
mlink->mvif->roc_phy = NULL;
- if (phy->main_chandef.chan &&
+ if (phy->main_chandef.chan && phy->offchannel &&
!test_bit(MT76_MCU_RESET, &dev->phy.state))
__mt76_set_channel(phy, &phy->main_chandef, false);
mt76_put_vif_phy_link(phy, phy->roc_vif, phy->roc_link);
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 02/11] wifi: mt76: support upgrading passive scans to active
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Chad Monroe, Piotr Kubik
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
From: Chad Monroe <chad@monroe.io>
On channels with NO_IR or RADAR flags, wait for beacon before sending
probe requests. Allows active scanning and WPS on restricted channels
if another AP is already present.
Fixes: c56d6edebc1f ("wifi: mt76: mt7996: use emulated hardware scan support")
Tested-by: Piotr Kubik <piotr.kubik@adtran.com>
Signed-off-by: Chad Monroe <chad@monroe.io>
Link: https://patch.msgid.link/20251118102723.47997-2-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76.h | 4 ++
.../net/wireless/mediatek/mt76/mt7996/mac.c | 3 ++
drivers/net/wireless/mediatek/mt76/scan.c | 51 +++++++++++++++++--
4 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index d0c522909e98..3c539c263238 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -726,6 +726,7 @@ mt76_alloc_device(struct device *pdev, unsigned int size,
INIT_LIST_HEAD(&dev->rxwi_cache);
dev->token_size = dev->drv->token_size;
INIT_DELAYED_WORK(&dev->scan_work, mt76_scan_work);
+ spin_lock_init(&dev->scan_lock);
for (i = 0; i < ARRAY_SIZE(dev->q_rx); i++)
skb_queue_head_init(&dev->rx_skb[i]);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 7f6f075b3088..efb57a0d8965 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -1006,6 +1006,7 @@ struct mt76_dev {
u32 rxfilter;
struct delayed_work scan_work;
+ spinlock_t scan_lock;
struct {
struct cfg80211_scan_request *req;
struct ieee80211_channel *chan;
@@ -1013,6 +1014,8 @@ struct mt76_dev {
struct mt76_vif_link *mlink;
struct mt76_phy *phy;
int chan_idx;
+ bool beacon_wait;
+ bool beacon_received;
} scan;
#ifdef CONFIG_NL80211_TESTMODE
@@ -1600,6 +1603,7 @@ int mt76_get_rate(struct mt76_dev *dev,
int mt76_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_scan_request *hw_req);
void mt76_cancel_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
+void mt76_scan_rx_beacon(struct mt76_dev *dev, struct ieee80211_channel *chan);
void mt76_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
const u8 *mac);
void mt76_sw_scan_complete(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index a415cc610eee..ed9ada53f8e5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -515,6 +515,9 @@ mt7996_mac_fill_rx(struct mt7996_dev *dev, enum mt76_rxq_id q,
qos_ctl = FIELD_GET(MT_RXD10_QOS_CTL, v2);
seq_ctrl = FIELD_GET(MT_RXD10_SEQ_CTRL, v2);
+ if (ieee80211_is_beacon(fc))
+ mt76_scan_rx_beacon(&dev->mt76, mphy->chandef.chan);
+
rxd += 4;
if ((u8 *)rxd - skb->data >= skb->len)
return -EINVAL;
diff --git a/drivers/net/wireless/mediatek/mt76/scan.c b/drivers/net/wireless/mediatek/mt76/scan.c
index 89f16c23e352..2b5f30cef795 100644
--- a/drivers/net/wireless/mediatek/mt76/scan.c
+++ b/drivers/net/wireless/mediatek/mt76/scan.c
@@ -27,6 +27,10 @@ static void mt76_scan_complete(struct mt76_dev *dev, bool abort)
void mt76_abort_scan(struct mt76_dev *dev)
{
+ spin_lock_bh(&dev->scan_lock);
+ dev->scan.beacon_wait = false;
+ spin_unlock_bh(&dev->scan_lock);
+
cancel_delayed_work_sync(&dev->scan_work);
mt76_scan_complete(dev, true);
}
@@ -79,6 +83,28 @@ mt76_scan_send_probe(struct mt76_dev *dev, struct cfg80211_ssid *ssid)
rcu_read_unlock();
}
+void mt76_scan_rx_beacon(struct mt76_dev *dev, struct ieee80211_channel *chan)
+{
+ struct mt76_phy *phy;
+
+ spin_lock(&dev->scan_lock);
+
+ if (!dev->scan.beacon_wait || dev->scan.beacon_received ||
+ dev->scan.chan != chan)
+ goto out;
+
+ phy = dev->scan.phy;
+ if (!phy)
+ goto out;
+
+ dev->scan.beacon_received = true;
+ ieee80211_queue_delayed_work(phy->hw, &dev->scan_work, 0);
+
+out:
+ spin_unlock(&dev->scan_lock);
+}
+EXPORT_SYMBOL_GPL(mt76_scan_rx_beacon);
+
void mt76_scan_work(struct work_struct *work)
{
struct mt76_dev *dev = container_of(work, struct mt76_dev,
@@ -87,9 +113,20 @@ void mt76_scan_work(struct work_struct *work)
struct cfg80211_chan_def chandef = {};
struct mt76_phy *phy = dev->scan.phy;
int duration = HZ / 9; /* ~110 ms */
- bool offchannel = true;
+ bool beacon_rx, offchannel = true;
int i;
+ if (!phy || !req)
+ return;
+
+ spin_lock_bh(&dev->scan_lock);
+ beacon_rx = dev->scan.beacon_wait && dev->scan.beacon_received;
+ dev->scan.beacon_wait = false;
+ spin_unlock_bh(&dev->scan_lock);
+
+ if (beacon_rx)
+ goto probe;
+
if (dev->scan.chan_idx >= req->n_channels) {
mt76_scan_complete(dev, false);
return;
@@ -110,10 +147,18 @@ void mt76_scan_work(struct work_struct *work)
mt76_set_channel(phy, &chandef, offchannel);
- if (!req->n_ssids ||
- chandef.chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR))
+ if (!req->n_ssids)
goto out;
+ if (chandef.chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR)) {
+ spin_lock_bh(&dev->scan_lock);
+ dev->scan.beacon_received = false;
+ dev->scan.beacon_wait = true;
+ spin_unlock_bh(&dev->scan_lock);
+ goto out;
+ }
+
+probe:
if (phy->offchannel)
duration = HZ / 16; /* ~60 ms */
local_bh_disable();
--
2.51.0
^ permalink raw reply related
* [PATCH mt76 05/11] wifi: mt76: abort ROC on chanctx changes
From: Felix Fietkau @ 2026-03-09 6:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20260309060730.87840-1-nbd@nbd.name>
mt76_change_chanctx() calls mt76_phy_update_channel() which switches
the hardware channel. If ROC is active on the same phy, this switches
away from the ROC channel and clears offchannel, but leaves ROC state
intact. Mac80211 still thinks the phy is on the ROC channel.
Abort any active ROC before proceeding, matching the pattern already
used in add, remove, assign, unassign, and switch chanctx functions.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/channel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/channel.c b/drivers/net/wireless/mediatek/mt76/channel.c
index cfff50892a6e..8d2e72c68c6b 100644
--- a/drivers/net/wireless/mediatek/mt76/channel.c
+++ b/drivers/net/wireless/mediatek/mt76/channel.c
@@ -88,6 +88,9 @@ void mt76_change_chanctx(struct ieee80211_hw *hw,
IEEE80211_CHANCTX_CHANGE_RADAR)))
return;
+ if (phy->roc_vif)
+ mt76_abort_roc(phy);
+
cancel_delayed_work_sync(&phy->mac_work);
mutex_lock(&dev->mutex);
--
2.51.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