* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-05-20 9:53 UTC (permalink / raw)
To: Óscar Alfonso Díaz
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <CA+bbHrUqh+nu_eKBMVaPH6Q8YxuKS=S0kON2Zsb+gRZHU=SBPA@mail.gmail.com>
On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> Ok, let me do one final test using Johannes’ v2 patch. The expected
> behavior is as follows:
>
> 6.18 or lower: no need to test, it will not work. It’s clear now that
> this does not matter, since the goal is only to fix newer kernel
> versions.
>
> 6.19: some versions of the 6.19 will crash and others will not. The
> crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> test.
>
> 7.0, or 7.1: the expected result is that there will be no crash, and
> VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> but it will not work.
>
> So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> the results. I'll be testing this patch (v2):
> https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
>
Thanks. For testing that one you'd have to revert the other first, I
think, you could also just test this one:
https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
But I think they're basically all equivalent.
Since we eventually need a patch to apply w/o reverting, Devin's is
probably better than my old one.
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Óscar Alfonso Díaz @ 2026-05-20 9:51 UTC (permalink / raw)
To: Johannes Berg
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <739ba20fa3c88e92bf034d80383015b8bc78ebfe.camel@sipsolutions.net>
Ok, let me do one final test using Johannes’ v2 patch. The expected
behavior is as follows:
6.18 or lower: no need to test, it will not work. It’s clear now that
this does not matter, since the goal is only to fix newer kernel
versions.
6.19: some versions of the 6.19 will crash and others will not. The
crash was fixed at some point between 6.18.12 and 6.19.12. No need to
test.
7.0, or 7.1: the expected result is that there will be no crash, and
VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
(I'll test both, normal DoS and VIF+DoS). There should be no crash,
but it will not work.
So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
the results. I'll be testing this patch (v2):
https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
Give me some time to do these tests. I'll test it on both 7.0 and 7.1 kernels.
Thanks and regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mié, 20 may 2026 a las 10:58, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Wed, 2026-05-20 at 10:02 +0200, Óscar Alfonso Díaz wrote:
> > I tested it on 6.18.12
> >
> > Let me know if you need me to test it again or whatever. I remember
> > during my testing with the Brite's different patches that is not the
> > same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
> > needed to be different. I've added Brite to the thread, he can add
> > more useful data for you.
>
> I guess I don't really care about 6.18.x or 6.19.x, only about 7.1-rcX
> at this point. We'll want to explicitly _not_ backport this fix to older
> kernel versions since it caused driver crashes.
>
> > Regarding the approach of fixing the bug on the driver side... I've
> > emailed and contacted by IRC to Lorenzo explaining the problem... but
> > I got no response. So if we feel yet like this is something that needs
> > to be fixed from the "driver side"... how to say it softly... we are
> > f***ed up :) . Maybe the "hack" way dealing with the vif null var is
> > not bad idea after all as it seems the only way to move forward.
>
> I feel I've tried to say this before, but maybe it helps if I summarise:
>
> There's one feature and one (possible) bug here.
>
> The feature is:
> - monitor mode injection works for chanctx drivers.
>
> The bug is:
> - monitor mode injection with the feature patch crashes at least some
> mt76 devices, which you reported, which I consider to be a bug in the
> driver that needs to be fixed there.
>
> To me, the trade-off is crystal clear - as long as the bug exists, I'm
> not going to apply this or a similar patch to enable the feature.
>
> I'm also not going to apply a patch like proposed before that hacks it
> by redirecting the vif pointer to a (more or less random) other vif,
> that's a lazy hack that happens to fix the problem in your _specific_
> use case, but will almost certainly still expose the crash in other use
> cases.
>
> I do think there's a chance that between 6.18/6.19 and 7.1-rcX the bug
> in the driver has already been fixed, that's why I keep asking about
> versions etc. But I also think there's a chance you're just testing
> different subdrivers of mt76 with different devices, so I'm also asking
> you to compare the specific devices.
>
> I'm happy to apply this patch if the people who previously reported it
> to crash (i.e. mostly you, not sure about others) are saying that
> against a more recent kernel it no longer causes the test to crash
> (rather than just not work, which is clearly better than crashing.)
>
> You could always just claim you've tested this patch without the crash
> and I'll apply it, but then if someone still finds a crash I'm just
> going to have to revert it, and we'd be back to square one.
>
> I hope this explains what I'm thinking and going to do (and not do),
> make of it what you will.
>
> johannes
^ permalink raw reply
* RE: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Johnson Tsai @ 2026-05-20 9:41 UTC (permalink / raw)
To: Greg KH, Johannes Berg
Cc: Ping-Ke Shih, linux-wireless@vger.kernel.org,
driver-core@lists.linux.dev, sabae@valvesoftware.com,
Charles Lohr
In-Reply-To: <2026051957-refract-barge-b21e@gregkh>
On Tuesday, May 19, 2026 20:23, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, May 19, 2026 at 02:11:32PM +0200, Johannes Berg wrote:
> > Hi,
> >
> > > > Example usage from user-space:
> > > > $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> > > > SN: 36 42 00 01 23
> > > > UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
> >
> > Sysfs has a "one value per file" rule (soft rule according to the
> > docs, but harder in practice, I believe), so seems if anything that
> > should be two files. Maybe a UUID should also be formatted as such
> > with %pU or similar.
>
> That should be 2 separate sysfs files please.
>
> And yes, use %pU.
The v2 patch will use separate `sn` and `uuid` attributes, with `uuid`
formatted via `%pU`. We also removed the spaces in `sn` to provide a clean
string.
Example usage from user-space:
$ cat /sys/bus/usb/devices/2-3.1.2:1.0/sn
3642000123
$ cat /sys/bus/usb/devices/2-3.1.2:1.0/uuid
aaec2b7c-0a55-4727-8de0-b30febccbbaa
>
> And be careful about exposing serial numbers to userspace, some systems
> don't like normal users to read them so be sure to get the permissions correct.
> We had to add some USB code for ALLOW_SERIAL_NUMBER to make it so that
> systems can handle this if they want to.
>
> And shouldn't this just be the USB serial number to start with? Why is there a
> different string here? We already have a sysfs file for this value.
Regarding the serial number and permission design, these are requirements
from Valve, so we have CC'd them here to provide the background.
Hi Elliot and Charles, could you please help explain the requirements and use case here?
^ permalink raw reply
* Fwd: Unable to unsubscribe from linux-wireless@vger.kernel.org
From: Sedat Dilek @ 2026-05-20 9:31 UTC (permalink / raw)
To: postmaster; +Cc: linux-wireless
In-Reply-To: <1779269054-14963-mlmmj-1e4bac1a@vger.kernel.org>
Hi Postmaster,
can you help me with the unsubscription?
I sent an email to:
linux-wireless+unsubscribe@vger.kernel.org
And get the below answer.
Best thanks and Best regards,
-Sedat-
---------- Forwarded message ---------
From: <linux-wireless+help@vger.kernel.org>
Date: Wed, May 20, 2026 at 11:26 AM
Subject: Unable to unsubscribe from linux-wireless@vger.kernel.org
To: <sedat.dilek@gmail.com>
Greetings!
This is the mlmmj program managing the <linux-wireless@vger.kernel.org>
mailing list.
You were unable to be unsubscribed from the list because you are not
subscribed.
If you are receiving messages, perhaps a different email address is
subscribed. To find out which address you are subscribed with, refer to the
message welcoming you to the list, or look at the envelope "Return-Path"
header of a message you receive from the list.
^ permalink raw reply
* Re: pull-request: wifi: iwlwifi: fixes - 2026-05-16
From: Johannes Berg @ 2026-05-20 9:25 UTC (permalink / raw)
To: Korenblit, Miriam Rachel, linux-wireless
In-Reply-To: <DS0PR11MB788049C3A06783951B2E11DFA3022@DS0PR11MB7880.namprd11.prod.outlook.com>
Hi Miri,
I'm a bit confused because you sent two pull requests and I hadn't
pulled the previous one, but it looks like this one contains both. I
understand this can happen especially if I don't pull quickly, but
please let me know that the new one supersedes the old so I'm less
confused :)
> Contains:
> wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
> wifi: iwlwifi: mld: stop TX during firmware restart
> wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
> wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
> wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
> wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
> wifi: iwlwifi: use correct function to read STEP_URM register
That's just a slightly shorter version of the shortlog
> ----------------------------------------------------------------
> Cole Leavitt (1):
> wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
>
> Emmanuel Grumbach (1):
> wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
>
> Johannes Berg (2):
> wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
> wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
>
> Miri Korenblit (1):
> wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
>
> Moriya Itzchaki (1):
> wifi: iwlwifi: use correct function to read STEP_URM register
>
> Sheroz Juraev (1):
> wifi: iwlwifi: mld: stop TX during firmware restart
so it's not really useful for me to build a next-level overview when I
send it to net... I often don't have a really good way of summarising
the changes either, but it'd be good to try since I can't just paste the
shortlog into the next level pull request either.
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-05-20 8:58 UTC (permalink / raw)
To: Óscar Alfonso Díaz
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <CA+bbHrV3fFHWevyDGPtAS=2M2mc+LxP6=xA-5fXaiTKTD=R31g@mail.gmail.com>
On Wed, 2026-05-20 at 10:02 +0200, Óscar Alfonso Díaz wrote:
> I tested it on 6.18.12
>
> Let me know if you need me to test it again or whatever. I remember
> during my testing with the Brite's different patches that is not the
> same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
> needed to be different. I've added Brite to the thread, he can add
> more useful data for you.
I guess I don't really care about 6.18.x or 6.19.x, only about 7.1-rcX
at this point. We'll want to explicitly _not_ backport this fix to older
kernel versions since it caused driver crashes.
> Regarding the approach of fixing the bug on the driver side... I've
> emailed and contacted by IRC to Lorenzo explaining the problem... but
> I got no response. So if we feel yet like this is something that needs
> to be fixed from the "driver side"... how to say it softly... we are
> f***ed up :) . Maybe the "hack" way dealing with the vif null var is
> not bad idea after all as it seems the only way to move forward.
I feel I've tried to say this before, but maybe it helps if I summarise:
There's one feature and one (possible) bug here.
The feature is:
- monitor mode injection works for chanctx drivers.
The bug is:
- monitor mode injection with the feature patch crashes at least some
mt76 devices, which you reported, which I consider to be a bug in the
driver that needs to be fixed there.
To me, the trade-off is crystal clear - as long as the bug exists, I'm
not going to apply this or a similar patch to enable the feature.
I'm also not going to apply a patch like proposed before that hacks it
by redirecting the vif pointer to a (more or less random) other vif,
that's a lazy hack that happens to fix the problem in your _specific_
use case, but will almost certainly still expose the crash in other use
cases.
I do think there's a chance that between 6.18/6.19 and 7.1-rcX the bug
in the driver has already been fixed, that's why I keep asking about
versions etc. But I also think there's a chance you're just testing
different subdrivers of mt76 with different devices, so I'm also asking
you to compare the specific devices.
I'm happy to apply this patch if the people who previously reported it
to crash (i.e. mostly you, not sure about others) are saying that
against a more recent kernel it no longer causes the test to crash
(rather than just not work, which is clearly better than crashing.)
You could always just claim you've tested this patch without the crash
and I'll apply it, but then if someone still finds a crash I'm just
going to have to revert it, and we'd be back to square one.
I hope this explains what I'm thinking and going to do (and not do),
make of it what you will.
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Óscar Alfonso Díaz @ 2026-05-20 8:02 UTC (permalink / raw)
To: Johannes Berg
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <a36b5712dd420da4090bfa8868e78b1b2b90c916.camel@sipsolutions.net>
I tested it on 6.18.12
Let me know if you need me to test it again or whatever. I remember
during my testing with the Brite's different patches that is not the
same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
needed to be different. I've added Brite to the thread, he can add
more useful data for you.
Regarding the approach of fixing the bug on the driver side... I've
emailed and contacted by IRC to Lorenzo explaining the problem... but
I got no response. So if we feel yet like this is something that needs
to be fixed from the "driver side"... how to say it softly... we are
f***ed up :) . Maybe the "hack" way dealing with the vif null var is
not bad idea after all as it seems the only way to move forward.
Let me know if somebody needs more testing.
Thanks.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mié, 20 may 2026 a las 9:42, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Wed, 2026-05-20 at 08:49 +0200, Óscar Alfonso Díaz wrote:
> > Let me know if any testing of a concrete patch is needed when you feel
> > it is completely fixed.
>
> I guess Devin is saying it's fixed, and I'm saying it's the same as mine
> so can't be really fixed unless something else happened in the kernel.
>
> Do you recall which kernel version you tested with? (I don't.) Perhaps
> something else in the kernel changed and it's now OK to make this
> change, but we know it wasn't working when you tested before, and I'd
> rather have it not work than crash.
>
> johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-05-20 7:42 UTC (permalink / raw)
To: Óscar Alfonso Díaz, Devin Wittmayer
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, linux-kernel,
stable, fjhhz1997, Brite
In-Reply-To: <CA+bbHrUcwtNhatzV+ufa8O3Wrku2_W4-UL=3XMy4-kg9qiOdXw@mail.gmail.com>
On Wed, 2026-05-20 at 08:49 +0200, Óscar Alfonso Díaz wrote:
> Let me know if any testing of a concrete patch is needed when you feel
> it is completely fixed.
I guess Devin is saying it's fixed, and I'm saying it's the same as mine
so can't be really fixed unless something else happened in the kernel.
Do you recall which kernel version you tested with? (I don't.) Perhaps
something else in the kernel changed and it's now OK to make this
change, but we know it wasn't working when you tested before, and I'd
rather have it not work than crash.
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Óscar Alfonso Díaz @ 2026-05-20 6:49 UTC (permalink / raw)
To: Devin Wittmayer
Cc: linux-wireless, Johannes Berg, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <20260519235713.49109-2-lucid_duck@justthetip.ca>
Let me know if any testing of a concrete patch is needed when you feel
it is completely fixed.
P.S. My environment was Kali VM using Vmware.
Regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mié, 20 may 2026 a las 1:57, Devin Wittmayer
(<lucid_duck@justthetip.ca>) escribió:
>
> From: 傅继晗 <fjhhz1997@gmail.com>
>
> Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
> behaviour") restored the monitor injection fallback for drivers using
> chanctx emulation but explicitly deferred drivers that transitioned
> to real chanctx ops. mt76 falls in that category and still drops
> every injected frame when monitor coexists with another interface.
>
> When the monitor has no chanctx of its own, fall back to the only
> chanctx in flight if there is exactly one. Refuse if multiple are
> present: picking arbitrarily would inject on an unrelated channel.
> Emulated and real chanctx drivers both flow through this fallback,
> since emulation always presents zero or one chanctx in
> local->chanctx_list.
>
> Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
> VIF on the same phy + aireplay-ng deauth from the monitor) on
> mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
> Kali VM with MT7921U passthrough as the closest match to the
> original reporter's setup. None reproduced the hang seen against
> the earlier attempt at this fix
> (<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
> on lore in March.
>
> Cc: stable@vger.kernel.org # 6.9+
> Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
> Closes: https://github.com/morrownr/USB-WiFi/issues/682
> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
> Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> ---
> v4:
> - Drop the dedicated local->emulate_chanctx branch. Emulation always
> presents zero or one chanctx in local->chanctx_list, so the
> single-chanctx walk handles that path too.
> - Real-chanctx TX path is unchanged, so v3 Tested-by carries.
>
> v3:
> - Replace list_is_singular() + list_first_entry() with
> list_first_or_null_rcu() and an rcu_access_pointer() check
> that the entry is the only one in the list. The v2 pair
> re-read ->next without RCU between the singularity check
> and the entry fetch, racing list_del_rcu() of the sole entry
> (rculist.h).
>
> v2:
> - First respin under my submitter signoff; preserves fjh1997
> authorship.
> - Verification matrix; airgeddon evil-twin flow on mt7921e/
> mt7921u/Kali-VM does not reproduce the hang reported against
> the v1 attempt at this fix.
>
> net/mac80211/tx.c | 16 ++++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 933c86ca21c3..a8c5d3a2b1f0 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2407,12 +2407,18 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
> rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
> }
>
> - if (chanctx_conf)
> + if (chanctx_conf) {
> chandef = &chanctx_conf->def;
> - else if (local->emulate_chanctx)
> - chandef = &local->hw.conf.chandef;
> - else
> - goto fail_rcu;
> + } else {
> + struct ieee80211_chanctx *ctx;
> +
> + ctx = list_first_or_null_rcu(&local->chanctx_list,
> + struct ieee80211_chanctx, list);
> + if (!ctx ||
> + rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
> + goto fail_rcu;
> + chandef = &ctx->conf.def;
> + }
>
> /*
> * If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
> --
> 2.54.0
^ permalink raw reply
* Re: ath12k: QCN9274 hw2.0 single-band cards on IPQ9574 — firmware RDDM after WMI_INIT_CMD (WLAN.WBE.1.6-01243)
From: Stefano Ursino @ 2026-05-20 5:05 UTC (permalink / raw)
To: jeff.johnson; +Cc: jjohnson, quic_rajkbhag, ath12k, linux-wireless, quic_bqiang
In-Reply-To: <f2ad69a2-35da-4611-9466-eda63c264c1f@oss.qualcomm.com>
Hi Jeff,
Thanks for the pointer to Nazar's patch and for pinging the team.
Bugzilla #221550 was filed shortly after your message:
https://bugzilla.kernel.org/show_bug.cgi?id=221550
I see you have since assigned it to Rameshkumar Sundaram -- thank you.
Fix B update
------------
I read your May 11 review of Nazar's patch [1] where you pointed out the
zeroed-slot problem and suggested a compact-array approach with a separate
write index. I have implemented exactly that:
- write index j (separate from iteration index i)
- unknown module_id entries skipped with ath12k_dbg()
- ab->num_db_cap = j at loop exit (no zeroed slots, no free_dir_buff:)
The patch applies cleanly on top of current ath-next. I can post it as
[PATCH ath-next] referencing Nazar's series and your review comment if
that would help move it forward.
[1] https://lists.infradead.org/pipermail/ath12k/2026-May/009267.html
Firmware regression matrix (Fixes A + B applied, 3x QCN9274 hw2.0)
-------------------------------------------------------------------
WLAN.WBE.1.3.1-00162: stalls at 'failed to receive default regd during
init' (regulatory timeout, no RDDM)
WLAN.WBE.1.4.1-00199: no RDDM; 2.4 GHz card (board_id=0x1, OTP
programmed) reaches 'ieee80211 phy2' -- driver
initializes fully
WLAN.WBE.1.6-01243: MHI_CB_EE_RDDM ~316 ms after WMI_INIT_CMD on
all three cards simultaneously
WBE.1.4.1 is the clean reference point: the hardware and host driver
work correctly, the RDDM is a regression introduced between WBE.1.4.1
and WBE.1.6.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: fix error unwind on arch_init() failure in PCI probe
From: Rameshkumar Sundaram @ 2026-05-20 2:44 UTC (permalink / raw)
To: Ripan Deuri, ath12k; +Cc: linux-wireless
In-Reply-To: <20260519192815.3911324-1-ripan.deuri@oss.qualcomm.com>
On 5/20/2026 12:58 AM, Ripan Deuri wrote:
> From: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
>
> When arch_init() fails in ath12k_pci_probe(), the code jumps to
> err_pci_msi_free, leaking resources in teardown.
>
> Redirect the failure path to err_free_irq so teardown matches the setup order.
>
> Compile-tested only.
>
> Fixes: 614c23e24ee8 ("wifi: ath12k: Support arch-specific DP device allocation")
> Signed-off-by: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [RESEND PATCH 1/2] genirq: export irq_can_set_affinity() for module drivers
From: Hangtian Zhu @ 2026-05-20 2:42 UTC (permalink / raw)
To: Thomas Gleixner, jjohnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <875x4jxyht.ffs@tglx>
On 5/19/2026 22:30, Thomas Gleixner wrote:
> eviewed-by: Thomas Gleixner <tglx@kernel.org>
> On Tue, May 19 2026 at 09:16, Hangtian Zhu wrote:
>> Export irq_can_set_affinity() for loadable drivers that need a runtime
>> check for IRQ affinity capability.
>>
>> In hierarchical IRQ setups where the effective irqchip path lacks
>> .irq_set_affinity(), drivers may need to switch to a fallback policy.
>> Without this export, module drivers cannot use the core helper and have
>> to open-code equivalent checks.
>>
>> Signed-off-by: Hangtian Zhu <hangtian.zhu@oss.qualcomm.com>
> Assuming this goes through the wireless tree:
yes, it's wireless tree.
> Acked-by: Thomas Gleixner <tglx@kernel.org>
>
> If not, please let me know and I pick it up.
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: fix error unwind on arch_init() failure in PCI probe
From: Baochen Qiang @ 2026-05-20 2:20 UTC (permalink / raw)
To: Ripan Deuri, ath12k; +Cc: linux-wireless
In-Reply-To: <20260519192815.3911324-1-ripan.deuri@oss.qualcomm.com>
On 5/20/2026 3:28 AM, Ripan Deuri wrote:
> From: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
>
> When arch_init() fails in ath12k_pci_probe(), the code jumps to
> err_pci_msi_free, leaking resources in teardown.
>
> Redirect the failure path to err_free_irq so teardown matches the setup order.
>
> Compile-tested only.
>
> Fixes: 614c23e24ee8 ("wifi: ath12k: Support arch-specific DP device allocation")
> Signed-off-by: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw88: Add more validation for the RX descriptor
From: Ping-Ke Shih @ 2026-05-20 1:45 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
Cc: LB F, Martin Blumenstingl, Fiona Klute,
andrej.skvortzov@gmail.com, anarsoul@gmail.com, Zhen XIN
In-Reply-To: <cc24a412-40d7-4eb6-896e-0840ff0db067@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 18/05/2026 11:14, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> Some RTL8821CE cards can return frames with corrupted RX descriptor,
> >> causing warnings and crashes if they are passed to the upper layers.
> >
> > Not sure if this is the reason Larry uploaded a copy of vendor driver
> > to his repository [1].
> >
>
> He added it for someone whose wifi card sometimes wasn't powering on:
>
> https://github.com/lwfinger/rtw88/issues/98#issuecomment-1263962943
>
> > Recently, we received vulnerability report of rtw_mp_efuse_set() in
> > vendor driver. I'd like to know if people are still using the vendor
> > driver [1]. If not, is it possible to remove it? If people still need it,
> > I will share the fix made by our internal later.
> >
> > [1] https://github.com/lwfinger/rtw88/tree/master/alt_rtl8821ce
> >
>
> We haven't been updating it for the kernel API changes, so I think we
> can remove it.
Agree. As current users don't report power-on issue on rtw88.
If the problem presents again, we can spend time to dig the difference
of power-on sequence between vendor driver and rtw88.
>
> >>
> >> The PHY status size field is 4 bits wide, but in rtw88 its value should
> >> only be 0 or 4. Checking this catches most of the corrupt frames.
> >>
> >> If a PHY status is present, the PHY status size should not be 0.
> >>
> >> The frame size should not be less than or equal to 4 and should not
> >> exceed 11454.
> >>
> >> Discard the frame if any of these checks fail.
> >>
> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
> >> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> >
> > Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> >
> > [...]
> >
> >> diff --git a/drivers/net/wireless/realtek/rtw88/rx.c b/drivers/net/wireless/realtek/rtw88/rx.c
> >> index d9e11343d498..65f6db3d7fcb 100644
> >> --- a/drivers/net/wireless/realtek/rtw88/rx.c
> >> +++ b/drivers/net/wireless/realtek/rtw88/rx.c
> >> @@ -3,6 +3,7 @@
> >> */
> >>
> >> #include "main.h"
> >> +#include "mac.h"
> >> #include "rx.h"
> >> #include "ps.h"
> >> #include "debug.h"
> >> @@ -261,9 +262,9 @@ static void rtw_rx_fill_rx_status(struct rtw_dev *rtwdev,
> >> }
> >> }
> >>
> >> -void rtw_rx_query_rx_desc(struct rtw_dev *rtwdev, void *rx_desc8,
> >> - struct rtw_rx_pkt_stat *pkt_stat,
> >> - struct ieee80211_rx_status *rx_status)
> >> +int rtw_rx_query_rx_desc(struct rtw_dev *rtwdev, void *rx_desc8,
> >> + struct rtw_rx_pkt_stat *pkt_stat,
> >> + struct ieee80211_rx_status *rx_status)
> >> {
> >> u32 desc_sz = rtwdev->chip->rx_pkt_desc_sz;
> >> struct rtw_rx_desc *rx_desc = rx_desc8;
> >> @@ -303,12 +304,25 @@ void rtw_rx_query_rx_desc(struct rtw_dev *rtwdev, void *rx_desc8,
> >> pkt_stat->bw = RTW_CHANNEL_WIDTH_20;
> >
> > Do you think if we should return -EINVAL for this case too?
> >
>
> Yes. What do we do with the debug message? Should the other
> conditions also have a debug message?
Personally I'd remove the debug message. If you think they are helpful to
dig problems (for unconsidered corner cases), it is fine to me to add
a message for each condition.
I suppose you will send a new patch, and I'll wait for v2.
>
> >> }
> >>
> >> + if (unlikely(pkt_stat->drv_info_sz &&
> >> + pkt_stat->drv_info_sz != PHY_STATUS_SIZE))
> >> + return -EINVAL;
> >> +
> >> + if (unlikely(pkt_stat->phy_status && !pkt_stat->drv_info_sz))
> >> + return -EINVAL;
> >> +
> >> + if (unlikely(pkt_stat->pkt_len > IEEE80211_MAX_MPDU_LEN_VHT_11454))
> >> + return -EINVAL;
> >> +
> >> /* drv_info_sz is in unit of 8-bytes */
> >> pkt_stat->drv_info_sz *= 8;
> >>
> >> /* c2h cmd pkt's rx/phy status is not interested */
> >> if (pkt_stat->is_c2h)
> >> - return;
> >> + return 0;
> >> +
> >> + if (unlikely(pkt_stat->pkt_len <= FCS_LEN))
> >> + return -EINVAL;
> >>
> >> phy_status = rx_desc8 + desc_sz + pkt_stat->shift;
> >> hdr = phy_status + pkt_stat->drv_info_sz;
> >
> > [...]
> >
^ permalink raw reply
* Realtek RTL8852AE Firmware Crash via OTA Frame Injection
From: John Moore @ 2026-05-20 0:47 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless
[-- Attachment #1.1: Type: text/plain, Size: 6354 bytes --]
# Realtek RTL8852AE Firmware Crash via OTA Frame Injection
**Date**: May 19, 2026
**Submitted by**: J.B. Moore — Nooks Stride Project
**Contact**: jbmoore61@gmail.com
**Affected Firmware**: rtw8852a_fw.bin v0.13.36.0 (commit c33d3f88)
**Affected Hardware**: Realtek RTL8852AE 802.11ax PCIe (PCI 0000:04:00.0)
**Driver**: rtw89_8852ae / rtw89_core (Linux in-tree, mainline 7.0)
**Kernel**: Linux 7.0.0-nooks-stride #7 PREEMPT(full)
**System**: Lenovo 82JW (BIOS HHCN37WW 01/17/2024)
---
## Summary
Injecting mutated 802.11 management frames via a monitor mode interface
crashes
the RTL8852AE firmware. The driver's SER (System Error Recovery) mechanism
catches the crash (error code `0x1002`) and recovers, but each recovery
cycle
causes a ~20-second WiFi connectivity interruption.
SER `0x1002` errors are widely reported in the rtw89 community and
attributed
to ASPM/power management. We did not find a prior public report
demonstrating
OTA frame injection as a trigger.
---
## Prior Art
- **CVE-2026-43267**: rtw89 division-by-zero from zero beacon interval
(local DoS) — different root cause
- **CVE-2026-43176**: rtw89 PCI TX release report validation on RTL8922DE
(local DoS) — different chip and root cause
---
## Testing Methodology
### Tools
| Tool | Description |
|------|-------------|
| `fuzz_wifi_hostap_bridge.py` | Loads hostap oss-fuzz seed frames
(ap-mgmt, SAE, WNM, EAPOL, P2P), applies byte-level mutation, injects via
monitor mode |
| `rtw8852ae_fw_crash_poc.py` | Self-contained PoC with 16 embedded hostap
corpus seeds and mutation engine |
### Approach
Mutated hostap corpus frames were injected via a monitor mode virtual
interface
(`mon0` / `pocmon0`) on the same physical adapter. Mutation strategies: bit
flips, byte flips, boundary values, IE length corruption, random overwrites,
insertions, deletions, and multi-byte havoc. Unmutated seeds were also
injected
at a 10% rate.
### Duration
Six injection runs totaling approximately 5 minutes active. 16.3 million
mutated frames injected.
---
## Finding: Firmware Crash from Mutated 802.11 Management Frames
**Location**: RTL8852AE firmware RX path (closed-source `rtw8852a_fw.bin`)
**SER error code**: `0x1002` (firmware CPU exception)
### Description
The RTL8852AE firmware crashed when processing mutated 802.11 management
frames
derived from the hostap oss-fuzz corpus. The mutated frames included:
- Beacon frames with malformed Information Elements
- SAE commit/confirm frames with corrupted fields
- WNM BSS Transition Management requests with invalid subelements
- EAPOL-Key frames with malformed key data
- Action frames with invalid category/action codes
The crashes occurred at 37 unique firmware program counter addresses across
7
code regions.
### Kernel Log
```
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb89c0e11
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb897dbf9
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb8935670
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb897beaf
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb89c0dd9
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb89386ed
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb897dbd5
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb893957f
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb89b9205
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb89b42e9
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb893a687
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb893a619
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb897dc0f
rtw89_8852ae 0000:04:00.0: [ERR]fw PC = 0xb89c0e03
rtw89_8852ae 0000:04:00.0: SER catches error: 0x1002
```
### Firmware Crash Regions
Firmware code section loads at `0xb8970000` (357,072 bytes). The firmware
uses
a proprietary WCPU ISA (not ARM, MIPS, or x86). Function names are unknown.
| PC Range | Occurrences |
|----------|-------------|
| `0xb89336xx` | 1 |
| `0xb89386xx–0xb893a6xx` | 12 |
| `0xb89790xx–0xb897dcxx` | 8 |
| `0xb898fexx–0xb898ffxx` | 30+ |
| `0xb89b2bxx–0xb89b94xx` | 6 |
| `0xb89c0dxx–0xb89c5dxx` | 15 |
| `0xbec001xx` | 1 |
### Reproducer
A self-contained PoC is provided as `rtw8852ae_fw_crash_poc.py`:
```bash
# With SER stress (required to trigger crash reliably):
sudo python3 rtw8852ae_fw_crash_poc.py --interface wlp4s0 --duration 15
--stress
# Monitor:
dmesg -w | grep -E 'SER catches|fw PC'
```
The PoC embeds 16 hostap corpus seed frames and applies byte-level mutations
before injecting via monitor mode. The `--stress` flag concurrently triggers
SER recovery via debugfs.
### Observations
- Frame injection was performed via a monitor mode virtual interface on the
same physical adapter. No second device was used.
- The firmware crash occurred during concurrent SER recovery stress
(triggered via debugfs `fw_crash`). Frame injection alone at 125K frames/sec
for 20 seconds (2.5M frames) did not trigger a crash without concurrent
SER stress.
- With concurrent SER stress, the PoC triggered 13 crashes in 15 seconds
(1.9M frames).
- WiFi connectivity was lost for approximately 20 seconds per crash event
and restored automatically by SER recovery.
---
## Statistics
| Run | Tool | Duration | Frames Injected | Result |
|-----|------|----------|-----------------|--------|
| 1 | hostap bridge | 10s | 1.6M | SER 0x1002 (with concurrent
fuzz_wifi.py) |
| 2 | hostap bridge | 30s | 4.9M | No crash (injection only) |
| 3 | hostap bridge | 60s | 9.8M | No crash (injection only) |
| 4 | PoC | 20s | 2.5M | No crash (injection only) |
| 5 | PoC --stress | 15s | 1.9M | 13 crashes (SER 0x4000) |
| 6 | PoC --stress | 25s | 3.1M | 17 crashes (SER 0x4000) |
---
## Files Included
```
patches/
├── rtw89-wifi-fuzzing-disclosure-2026-05-19.md ← This report
└── rtw8852ae_fw_crash_poc.py ← Self-contained PoC
```
---
## Disclosure Timeline
| Date | Action |
|------|--------|
| 2026-05-19 | Finding discovered via automated fuzzing |
| 2026-05-19 | Prior-art search completed |
| 2026-05-19 | Report and PoC drafted |
| TBD | Report submitted to Realtek |
---
## Contact
**J.B. Moore**
Nooks Stride Project
Email: jbmoore61@gmail.com
"I will not be pushed, filed, stamped, indexed, briefed, debriefed, or
numbered."
~ The Prisoner
[-- Attachment #1.2: Type: text/html, Size: 12765 bytes --]
[-- Attachment #2: rtw89-disclosure-2026-05-19.zip --]
[-- Type: application/zip, Size: 26650 bytes --]
^ permalink raw reply
* RE: [PATCH rtw-next v3] wifi: rtw89: usb: Support switching to USB 3 mode
From: Ping-Ke Shih @ 2026-05-20 0:46 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <b4da28cd-17e0-46f2-a73c-e77d9c96cca1@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 18/05/2026 10:51, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> The Realtek wifi 6/7 devices which support USB 3 are weird: when first
> >> plugged in, they pretend to be USB 2. The driver needs to send some
> >> commands to the device, which make it disappear and come back as a
> >> USB 3 device.
> >>
> >> Implement the required commands in rtw89.
> >>
> >> Add a new function rtw89_usb_write32_quiet() to avoid the warnings
> >> when writing to R_{AX,BE}_PAD_CTRL2. Even though the write succeeds,
> >> usb_control_msg() returns -EPROTO, probably because the USB device
> >> disappears immediately. This results in some confusing warnings in
> >> the kernel log.
> >>
> >> When a USB 3 device is plugged into a USB 2 port, rtw89 will try to
> >> switch it to USB 3 mode only once. The device will disappear and come
> >> back still in USB 2 mode, of course.
> >
> > As we always try to switch USB 3, is it needed to add a hint to users
> > to plug USB 2 port if he has a bad performance on 2GHz band?
> >
>
> I can add a message like "2.4 GHz performance may be better in a USB 2
> port".
I suppose we should use rtw89_info().
I'll wait for v4.
^ permalink raw reply
* [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Devin Wittmayer @ 2026-05-19 23:57 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, Felix Fietkau, Lorenzo Bianconi, linux-kernel,
stable, Oscar Alfonso Diaz, fjhhz1997
In-Reply-To: <20260519235713.49109-1-lucid_duck@justthetip.ca>
From: 傅继晗 <fjhhz1997@gmail.com>
Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the monitor injection fallback for drivers using
chanctx emulation but explicitly deferred drivers that transitioned
to real chanctx ops. mt76 falls in that category and still drops
every injected frame when monitor coexists with another interface.
When the monitor has no chanctx of its own, fall back to the only
chanctx in flight if there is exactly one. Refuse if multiple are
present: picking arbitrarily would inject on an unrelated channel.
Emulated and real chanctx drivers both flow through this fallback,
since emulation always presents zero or one chanctx in
local->chanctx_list.
Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
VIF on the same phy + aireplay-ng deauth from the monitor) on
mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
Kali VM with MT7921U passthrough as the closest match to the
original reporter's setup. None reproduced the hang seen against
the earlier attempt at this fix
(<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
on lore in March.
Cc: stable@vger.kernel.org # 6.9+
Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
Closes: https://github.com/morrownr/USB-WiFi/issues/682
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
v4:
- Drop the dedicated local->emulate_chanctx branch. Emulation always
presents zero or one chanctx in local->chanctx_list, so the
single-chanctx walk handles that path too.
- Real-chanctx TX path is unchanged, so v3 Tested-by carries.
v3:
- Replace list_is_singular() + list_first_entry() with
list_first_or_null_rcu() and an rcu_access_pointer() check
that the entry is the only one in the list. The v2 pair
re-read ->next without RCU between the singularity check
and the entry fetch, racing list_del_rcu() of the sole entry
(rculist.h).
v2:
- First respin under my submitter signoff; preserves fjh1997
authorship.
- Verification matrix; airgeddon evil-twin flow on mt7921e/
mt7921u/Kali-VM does not reproduce the hang reported against
the v1 attempt at this fix.
net/mac80211/tx.c | 16 ++++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 933c86ca21c3..a8c5d3a2b1f0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2407,12 +2407,18 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
}
- if (chanctx_conf)
+ if (chanctx_conf) {
chandef = &chanctx_conf->def;
- else if (local->emulate_chanctx)
- chandef = &local->hw.conf.chandef;
- else
- goto fail_rcu;
+ } else {
+ struct ieee80211_chanctx *ctx;
+
+ ctx = list_first_or_null_rcu(&local->chanctx_list,
+ struct ieee80211_chanctx, list);
+ if (!ctx ||
+ rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
+ goto fail_rcu;
+ chandef = &ctx->conf.def;
+ }
/*
* If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Devin Wittmayer @ 2026-05-19 23:57 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, Felix Fietkau, Lorenzo Bianconi, linux-kernel,
stable, Oscar Alfonso Diaz, fjhhz1997
In-Reply-To: <20260518170147.13885-1-lucid_duck@justthetip.ca>
v3 [1] kept the existing local->emulate_chanctx branch alongside the
new single-chanctx fallback. Johannes pointed out [2] that emulation
always presents zero or one chanctxs in local->chanctx_list, so the
new fallback handles that path as well. v4 drops the branch.
The real-chanctx TX path is unchanged from v3, so my v3 Tested-by
carries: the airgeddon evil-twin flow on mt7921e PCIe + mt7921u USB
+ Kali VM with MT7921U passthrough still applies.
[1] https://lore.kernel.org/linux-wireless/20260518170147.13885-1-lucid_duck@justthetip.ca/
[2] https://lore.kernel.org/linux-wireless/58d6ee4054473af391eb5ae8b4382e6964dc3ab6.camel@sipsolutions.net/
傅继晗 (1):
wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
net/mac80211/tx.c | 16 ++++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH v3] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Devin Wittmayer @ 2026-05-19 23:56 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, linux-kernel,
stable, Oscar Alfonso Diaz, fjhhz1997
In-Reply-To: <58d6ee4054473af391eb5ae8b4382e6964dc3ab6.camel@sipsolutions.net>
Hi Johannes,
Apologies for the nesting -- I'll keep replies top-level from here.
On 19 May 2026 00:02 (CEST), Johannes Berg wrote:
> I'm sure we can basically get rid of the "emulate" check now
Agreed. v4 will drop it.
> So what changed? Could you do some investigation if mt76 got bugfixes
> in this area perhaps? Or are you just using slightly different devices
> than Oscar?
Same chip family. Oscar's MT7921U/MT7921AUN (0e8d:7961) matches my v3
rigs (mt7921e PCIe, mt7921u USB, Kali VM with MT7921U passthrough).
mt76 has had three chanctx-touching commits since 2025-12-16 (de62b24224ac
"abort ROC on chanctx changes", f0fb9afb74ec "check chanctx before
restoring channel after ROC", 381733b3a14a "nullfunc PS on offchannel
transitions"). None touches ieee80211_monitor_start_xmit or the
chanctx_list lookup v3 does.
I think it's the reproducer environment. Back in March I matched Oscar's
stack -- Kali 6.18.12, fjh1997 v2 applied, MT7921U passthrough, airgeddon
evil twin, aireplay-ng deauth into the monitor VIF. No crash. The one
variable I couldn't match was the hypervisor: I used QEMU/KVM, Oscar
hasn't said. The symptoms (instant VM freeze on deauth start) read more
like a hypervisor USB-proxy stall than a kernel hang.
I'll send v4 with the collapse.
Devin
^ permalink raw reply
* Re: [PATCH 0/6] b43: complete N-PHY rev 8 + radio 2057 rev 8 support
From: Joshua Peisach @ 2026-05-19 23:13 UTC (permalink / raw)
To: Michael Büsch, Joshua Peisach
Cc: Alessio Ferri, linux-wireless, b43-dev, kvalo, linux-kernel,
b43-dev
In-Reply-To: <20260519215244.2a0d2b29@barney>
On Tue May 19, 2026 at 3:52 PM EDT, Michael Büsch wrote:
> On Tue, 19 May 2026 15:32:44 -0400
> "Joshua Peisach" <jpeisach@ubuntu.com> wrote:
>
>> On Tue May 19, 2026 at 11:58 AM EDT, Michael Büsch wrote:
>> > On Mon, 18 May 2026 03:49:33 +0200
>> > Alessio Ferri <alessio.ferri@mythread.it> wrote:
>> >
>> > In general this looks Ok.
>> > From the style I assume that this is AI generated, right?
>> > If so, can you tell us a bit more about the inputs used for the AI?
>> > What information is this implementation based on?
>>
>> So... awkward question.
>
> Why?
>
>> Wasn't there just a conversation[1] about the
>> future development of this module, that was left off at "don't touch it
>> unless you're going to thouroughly test this",
>
> Sure. That's why I ask about the development methods used.
>
>> and now we are going to have a *LLM* work on this?
>
> I don't care whether code was generated with an LLM or not.
> What matters is the development methods used.
Fair enough. And it was tested anyway :) sorry for any perceived
arrogance.
I would tag Reviewed-by but I don't have a script to check the tables
(there probably is somewhere... it's a personal problem - a "skill
issue" as I sometimes like to call it).
-Josh
^ permalink raw reply
* Re: [PATCH 0/6] b43: complete N-PHY rev 8 + radio 2057 rev 8 support
From: Alessio Ferri @ 2026-05-19 21:02 UTC (permalink / raw)
To: Michael Büsch; +Cc: linux-wireless, b43-dev, kvalo, linux-kernel
In-Reply-To: <20260519175812.7ce97ba1@barney>
On Tue, 19 May 2026 17:58:12 +0200
Michael Büsch <m@bues.ch> wrote:
> On Mon, 18 May 2026 03:49:33 +0200
> Alessio Ferri <alessio.ferri@mythread.it> wrote:
>
> > This series completes b43 support for the Broadcom N-PHY revision 8
> > paired with radio 2057 revision 8. b43 already supports the
> > surrounding PHY family - N-PHY rev 8 with radio 2057 rev 5 and rev
> > 7 are handled, and rev 16 with radio 2057 rev 9 is handled - but
> > the rev 8 + rev 8 combination falls through four dispatcher gaps:
>
> > Alessio Ferri (6):
> > b43: add d11 core revision 0x16 to id table
> > b43: route d11 corerev 22 to 24-bit indirect radio access
> > b43: support radio 2057 rev 8
> > b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8
> > b43: add channel info table for N-PHY r8 + radio 2057 r8
> > b43: add RF power offset for N-PHY r8 + radio 2057 r8
>
>
> In general this looks Ok.
> From the style I assume that this is AI generated, right?
> If so, can you tell us a bit more about the inputs used for the AI?
> What information is this implementation based on?
>
The patchset is tested on my own DLink DSL 3580L router and generated by
claude from our shared notes, i then reviewed it for sanity and
verified it by navigating from the router with modified b43 driver with
my phone.
The shared notes were: logs and dumps taken from the proprietary binary
driver while running the stock firmware in the router, files from
brcmsmac that had some details for rev 22, GPL released broadcom code
in the GPL dump of the vendor, .rodata pieces from the binary driver and
finally logs and dumps from the live b43 running in the router flashed
with openwrt. Gathering all of this was a week long task, and writing
code was only a small part of it, like in the 5% range.
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: avoid memset overwriting tx_info->control.flags
From: Ryder Lee @ 2026-05-19 20:42 UTC (permalink / raw)
To: lorenzo.bianconi83@gmail.com, roychl666@gmail.com
Cc: linux-wireless@vger.kernel.org, nbd@nbd.name, lorenzo@kernel.org,
Shayne Chen (陳軒丞),
linux-mediatek@lists.infradead.org, Roy-CH Luo
In-Reply-To: <CAA2SeNJXv+8QO6zEOF=qB3wVCdEoSqx6fftp1i=aB-DKMFeC=A@mail.gmail.com>
On Tue, 2026-05-19 at 14:24 +0200, Lorenzo Bianconi wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> >
> > On Mon, May 18, 2026 at 5:31 AM Lorenzo Bianconi
> > <lorenzo@kernel.org> wrote:
> > >
> > > On May 15, Cheng Hao Luo wrote:
> > > > > struct ieee80211_tx_info {
> > > > > u32 flags;
> > > > > /* 0 4 */
> > > > > u32 band:3;
> > > > > /* 4: 0 4 */
> > > > > u32 status_data_idr:1;
> > > > > /* 4: 3 4 */
> > > > > u32 status_data:13;
> > > > > /* 4: 4 4 */
> > > > > u32 hw_queue:4;
> > > > > /* 4:17 4 */
> > > > > u32 tx_time_est:10;
> > > > > /* 4:21 4 */
> > > > >
> > > > > /* XXX 1 bit hole, try to pack */
> > > > >
> > > > > union {
> > > > > struct {
> > > > > union {
> > > > > struct {
> > > > > struct
> > > > > ieee80211_tx_rate rates[4]; /* 8 12 */
> > > > > s8
> > > > > rts_cts_rate_idx; /* 20 1 */
> > > > > u8 use_rts:1;
> > > > > /* 21: 0 1 */
> > > > > u8
> > > > > use_cts_prot:1; /* 21: 1 1 */
> > > > > u8
> > > > > short_preamble:1; /* 21: 2 1 */
> > > > > u8 skip_table:1;
> > > > > /* 21: 3 1 */
> > > > > u8 antennas:2;
> > > > > /* 21: 4 1 */
> > > > > };
> > > > > /* 8 14 */
> > > > > long unsigned int jiffies;
> > > > > /* 8 8 */
> > > > > };
> > > > > /* 8 16 */
> > > > > struct ieee80211_vif * vif;
> > > > > /* 24 8 */
> > > > > struct ieee80211_key_conf * hw_key;
> > > > > /* 32 8 */
> > > > > u32 flags;
> > > > > /* 40 4 */
> > > > > codel_time_t enqueue_time;
> > > > > /* 44 4 */
> > > > > } control;
> > > > > /* 8 40 */
> > > > > struct {
> > > > > u64 cookie;
> > > > > /* 8 8 */
> > > > > } ack;
> > > > > /* 8 8 */
> > > > > struct {
> > > > > struct ieee80211_tx_rate rates[4];
> > > > > /* 8 12 */
> > > > > s32 ack_signal;
> > > > > /* 20 4 */
> > > > > u8 ampdu_ack_len;
> > > > > /* 24 1 */
> > > > > u8 ampdu_len;
> > > > > /* 25 1 */
> > > > > u8 antenna;
> > > > > /* 26 1 */
> > > > > u8 pad;
> > > > > /* 27 1 */
> > > > > u16 tx_time;
> > > > > /* 28 2 */
> > > > > u8 flags;
> > > > > /* 30 1 */
> > > > > u8 pad2;
> > > > > /* 31 1 */
> > > > > void * status_driver_data[2];
> > > > > /* 32 16 */
> > > > > } status;
> > > > > /* 8 40 */
> > > > > struct {
> > > > > struct ieee80211_tx_rate
> > > > > driver_rates[4]; /* 8 12 */
> > > > > u8 pad[4];
> > > > > /* 20 4 */
> > > > > void * rate_driver_data[3];
> > > > > /* 24 24 */
> > > > > };
> > > > > /* 8 40 */
> > > > > void * driver_data[5];
> > > > > /* 8 40 */
> > > > > };
> > > > > /* 8 40 */
> > > > >
> > > > > /* size: 48, cachelines: 1, members: 7 */
> > > > > /* sum members: 44 */
> > > > > /* sum bitfield members: 31 bits, bit holes: 1, sum
> > > > > bit holes: 1 bits */
> > > > > /* last cacheline: 48 bytes */
> > > > > };
> > > > >
> > > > > According to pahole, the size of the control inner union is
> > > > > actually 16 bytes
> > > > > since the compiler adds 2 bytes of padding. Since
> > > > > mt76_tx_status_skb_add()
> > > > > meset to 0 just mt76_tx_cb size (that is 16 bytes) I can't
> > > > > see how
> > > > > control.flags is overwritten. Am I missing something?
> > > > >
> > > > > struct mt76_tx_cb {
> > > > > long unsigned int jiffies;
> > > > > /* 0 8 */
> > > > > u16 wcid;
> > > > > /* 8 2 */
> > > > > u8 pktid;
> > > > > /* 10 1 */
> > > > > u8 flags;
> > > > > /* 11 1 */
> > > > >
> > > > > /* size: 16, cachelines: 1, members: 4 */
> > > > > /* padding: 4 */
> > > > > /* last cacheline: 16 bytes */
> > > > > };
> > > >
> > > > Hi Lorenzo,
> > > >
> > > > The mt76_tx_cb is placed at status.status_driver_data (offset
> > > > 32).
> > > > It overlaps with hw_key, flags and enqueue_time in the control
> > > > union.
> > > >
> > > > static inline struct mt76_tx_cb *mt76_tx_skb_cb(struct sk_buff
> > > > *skb)
> > > > {
> > > > BUILD_BUG_ON(sizeof(struct mt76_tx_cb) >
> > > > sizeof(IEEE80211_SKB_CB(skb)->status.status_driver_data));
> > > > return ((void *)IEEE80211_SKB_CB(skb)-
> > > > >status.status_driver_data);
> > > > }
> > >
> > > Hi Roy,
> > >
> > > I still do not understand since mt76_tx_status_skb_add() sets to
> > > 0 just sizeof
> > > of mt76_tx_cb, that according to pahole is 16 bytes, so it can't
> > > overwrite
> > > hw_key pointer (whose offset respect to the beginning of the
> > > control struct is
> > > 24, 32 - 8).
> > >
> > > Regards,
> > > Lorenzo
> > >
> > > >
> > > > Regards,
> > > > Roy Luo
> >
> > Hi Lorenzo,
> >
> > The mt76_tx_status_skb_add() memset zero the 16 bytes starting from
> > status.status_driver_data (please see the above inline function
> > shared
> > in my last response) whose offset with respect to the beginning of
> > the control/status union is exactly 24 (32 - 8) instead of 0.
> >
> > Regards,
> > Roy Luo
>
> Hi Roy,
>
> I can see the issue now, I was confusing status.status_driver_data
> with
> driver_data. You are right, we have an issue here. However, copying
> all the
> ieee80211_tx_info struct seems a bit overkill, what do you think?
> Moreover, we have the same issue for various chipsets (e.g. mt7925
> and
> mt7915). I guess we should try to find a global solution for the
> problem.
>
> Regards,
> Lorenzo
What about adding an helper for cb operation?
+void
+mt76_tx_status_skb_cb_add(struct mt76_dev *dev, struct sk_buff *skb,
+ struct mt76_wcid *wcid, int pid)
+{
+ struct mt76_tx_cb *cb = mt76_tx_skb_cb(skb);
+
+ memset(cb, 0, sizeof(*cb));
+
+ spin_lock_bh(&dev->status_lock);
+ cb->wcid = wcid->idx;
+ cb->pktid = pid;
+ spin_unlock_bh(&dev->status_lock);
+}
+EXPORT_SYMBOL_GPL(mt76_tx_status_skb_cb_add);
And add this for each chipset.
index 061ab66..d0b67a2 100644
--- a/mt7996/mac.c
+++ b/mt7996/mac.c
@@ -1108,6 +1108,7 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev,
void *txwi_ptr,
if (!is_8023 || pid >= MT_PACKET_ID_FIRST)
mt7996_mac_write_txwi(dev, txwi_ptr, tx_info->skb,
wcid, key,
pid, qid, 0);
+ mt76_tx_status_skb_cb_add(dev, tx_info->skb, wcid, pid);
^ permalink raw reply related
* Re: [PATCH 0/6] b43: complete N-PHY rev 8 + radio 2057 rev 8 support
From: Michael Büsch @ 2026-05-19 19:52 UTC (permalink / raw)
To: Joshua Peisach
Cc: Alessio Ferri, linux-wireless, b43-dev, kvalo, linux-kernel,
b43-dev
In-Reply-To: <DIMWK04RLFCG.17KT0R0YCUMRW@ubuntu.com>
[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]
On Tue, 19 May 2026 15:32:44 -0400
"Joshua Peisach" <jpeisach@ubuntu.com> wrote:
> On Tue May 19, 2026 at 11:58 AM EDT, Michael Büsch wrote:
> > On Mon, 18 May 2026 03:49:33 +0200
> > Alessio Ferri <alessio.ferri@mythread.it> wrote:
> >
> > In general this looks Ok.
> > From the style I assume that this is AI generated, right?
> > If so, can you tell us a bit more about the inputs used for the AI?
> > What information is this implementation based on?
>
> So... awkward question.
Why?
> Wasn't there just a conversation[1] about the
> future development of this module, that was left off at "don't touch it
> unless you're going to thouroughly test this",
Sure. That's why I ask about the development methods used.
> and now we are going to have a *LLM* work on this?
I don't care whether code was generated with an LLM or not.
What matters is the development methods used.
Changed must be based on actual correct knowledge (e.g. reverse engineering).
Just asking an LLM to do the change without putting that knowledge in is not Ok.
Changes must be tested.
Changes must have a real benefit.
Changes should be low risk, if they can't be tested on all hardware right away.
etc. etc.
Most of this patch set looks to be low risk, because it only seems to
touch code paths for core revisions that were previously unimplemented.
But I'm unsure and I can't remember all the details.
This is why I asked about the development methods used.
What would be Ok? Using an LLM to generate a fully functional and well
tested change from reverse engineered information.
What would not be Ok? Asking an LLM to change the driver just for the
sake of changing it or "cleaning it up". Or using an LLM to make
changes from hallucinated "specifications".
Btw, this looks to be the corresponding tool PR for this change, I guess:
https://github.com/mbuesch/b43-tools/pull/10
--
Michael Büsch
https://bues.ch/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] b43: complete N-PHY rev 8 + radio 2057 rev 8 support
From: Joshua Peisach @ 2026-05-19 19:32 UTC (permalink / raw)
To: Michael Büsch, Alessio Ferri
Cc: linux-wireless, b43-dev, kvalo, linux-kernel, b43-dev
In-Reply-To: <20260519175812.7ce97ba1@barney>
On Tue May 19, 2026 at 11:58 AM EDT, Michael Büsch wrote:
> On Mon, 18 May 2026 03:49:33 +0200
> Alessio Ferri <alessio.ferri@mythread.it> wrote:
>
> In general this looks Ok.
> From the style I assume that this is AI generated, right?
> If so, can you tell us a bit more about the inputs used for the AI?
> What information is this implementation based on?
So... awkward question. Wasn't there just a conversation[1] about the
future development of this module, that was left off at "don't touch it
unless you're going to thouroughly test this", and now we are going to
have a *LLM* work on this?
That aside, I don't see any obvious issues in the patchset.
[1]: https://lore.kernel.org/b43-dev/DHTYJFGLKPQ0.RYJIDH2VLV3W@ubuntu.com/T/#t
^ permalink raw reply
* Re: [PATCH v6 00/16] firmware: qcom: Add OP-TEE PAS service support
From: Vignesh Viswanathan @ 2026-05-19 19:29 UTC (permalink / raw)
To: Sumit Garg, andersson
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260518072856.22790-1-sumit.garg@kernel.org>
On 5/18/2026 12:58 PM, 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 Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, 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.
>
> The TEE PAS service ABI is designed to be extensible with additional API
> as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
> extensions of the PAS service needed while still maintaining backwards
> compatibility.
>
> Currently OP-TEE support is being added to provide the backend PAS
> service implementation which can be found as part of this PR [1].
> This implementation has been tested on Kodiak/RB3Gen2 board with lemans
> EVK board being the next target. In addition to that WIN/IPQ targets
> planning to use OP-TEE will use this service too. Surely the backwards
> compatibility is maintained and tested for SCM backend.
>
> Note that kernel PAS service support while running in EL2 is at parity
> among OP-TEE vs QTEE. Especially the media (venus/iris) support depends
> on proper IOMMU support being worked out on the PAS client end.
>
> Patch summary:
> - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE
> only allow UEFI and Linux to boot in EL2.
> - Patch #2: adds generic PAS service.
> - Patch #3: migrates SCM backend to generic PAS service.
> - Patch #4: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #5-#14: migrates all client drivers to generic PAS service.
> - Patch #15: drops legacy PAS SCM exported APIs.
Testing this on IPQ9650, which uses OP-TEE backend for PAS service.
Feel free to carry below tag for this series.
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Thanks,
Vignesh
>
> The patch-set is based on v7.1-rc4 tag and can be found in git tree here
> [2].
>
> Merge strategy:
>
> It is expected due to APIs dependency, the entire patch-set to go via
> the Qcom tree. All other subsystem maintainers, it will be great if I
> can get acks for the corresponding subsystem patches.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged)
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v6
>
> ---
> Changes in v6:
> - Rebased to v7.1-rc4 tag.
> - Patch #14: fixed ret error print.
> - Add Kconfig descriptions for PAS symbols such that they are visible
> in menuconfig to update.
>
> Changes in v5:
> - Incorporated misc. comments from Mukesh.
> - Split up patch #11 into 2 to add an independent commit for passing
> proper PAS ID to set_remote_state API.
> - Picked up tags.
>
> Changes in v4:
> - Incorporate misc. comments on patch #4.
> - Picked up an ack for patch #10.
> - Clarify in cover letter about state of media support.
>
> Changes in v3:
> - Incorporated some style and misc. comments for patch #2, #3 and #4.
> - Add QCOM_PAS Kconfig dependency for various subsystems.
> - Switch from pseudo TA to proper TA invoke commands.
>
> Changes in v2:
> - Fixed kernel doc warnings.
> - Polish commit message and comments for patch #2.
> - Pass proper PAS ID in set_remote_state API for media firmware drivers.
> - Added Maintainer entry and dropped MODULE_AUTHOR.
>
> Mukesh Ojha (1):
> arm64: dts: qcom: kodiak: Add EL2 overlay
>
> Sumit Garg (15):
> firmware: qcom: Add a generic PAS service
> firmware: qcom_scm: Migrate to generic PAS service
> firmware: qcom: Add a PAS TEE service
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> soc: qcom: mdtloader: Switch to generic PAS TZ APIs
> remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> remoteproc: qcom: Select QCOM_PAS generic service
> drm/msm: Switch to generic PAS TZ APIs
> media: qcom: Switch to generic PAS TZ APIs
> media: qcom: Pass proper PAS ID to set_remote_state API
> net: ipa: Switch to generic PAS TZ APIs
> wifi: ath12k: Switch to generic PAS TZ APIs
> firmware: qcom_scm: Remove SCM PAS wrappers
> MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
>
> MAINTAINERS | 9 +
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++
> drivers/firmware/qcom/Kconfig | 21 +-
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 476 ++++++++++++++++++
> drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
> drivers/media/platform/qcom/iris/Kconfig | 25 +-
> .../media/platform/qcom/iris/iris_firmware.c | 9 +-
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 +-
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 +-
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/ahb.c | 10 +-
> drivers/remoteproc/Kconfig | 4 +-
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
> drivers/remoteproc/qcom_wcnss.c | 12 +-
> drivers/soc/qcom/mdt_loader.c | 12 +-
> include/linux/firmware/qcom/qcom_pas.h | 43 ++
> include/linux/firmware/qcom/qcom_scm.h | 29 --
> include/linux/soc/qcom/mdt_loader.h | 6 +-
> 28 files changed, 1119 insertions(+), 320 deletions(-)
> create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox