* [GIT PULL] wireless-2026-05-21
From: Johannes Berg @ 2026-05-21 15:28 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
Sorry for the last minute thing ... if it makes it at all.
I forgot during the day, and it's already more because we
had a holiday last week.
Please pull and let us know if there's any problem.
Thanks,
johannes
The following changes since commit fcee7d82f27d6a8b1ddc5bbefda59b4e441e9bc0:
Merge tag 'net-7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-05-07 10:32:03 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git tags/wireless-2026-05-21
for you to fetch changes up to dc14686f27df6454b13b16ad1c9203ab3e9b0375:
wifi: cfg80211: wext: validate chandef in monitor mode (2026-05-20 11:44:19 +0200)
----------------------------------------------------------------
Quite a few more updates:
- cfg80211/mac80211:
- various security(-ish) fixes
- fix A-MSDU subframe handling
- fix multi-link element parsing
- ath10: avoid sending commands to dead device
- ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
- ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
- iwlwifi:
- fix TSO segmentation explosion
- don't TX to dead device
- fix warning in WoWLAN
- fix TX rates on old devices
- disconnect on beacon loss only if also no other traffic
- fill NULL-ptr deref
- fix STEP_URM hardware access
----------------------------------------------------------------
Alexandru Hossu (1):
wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs
Baochen Qiang (1):
wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing
Cole Leavitt (1):
wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
Emmanuel Grumbach (2):
wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
wifi: mac80211: don't override max_amsdu_subframes
Johannes Berg (6):
wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
wifi: mac80211: fix MLE defragmentation
wifi: mac80211: fix multi-link element inheritance
Merge tag 'iwlwifi-fixes-2026-05-16' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Merge tag 'ath-current-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
John Walker (1):
wifi: cfg80211: advance loop vars in cfg80211_merge_profile()
Kang Yang (1):
wifi: ath10k: skip WMI and beacon transmission when device is wedged
Kartik Nair (1):
wifi: cfg80211: wext: validate chandef in monitor mode
Kyle Farnung (1):
wifi: ath11k: clear shared SRNG pointer state on restart
Matthew Leach (1):
wifi: ath11k: fix peer resolution on rx path when peer_id=0
Michael Bommarito (1):
wifi: mac80211: consume only present negotiated TTLM maps
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
Nicolas Escande (3):
wifi: ath11k: fix error path leaks in some WMI WOW calls
wifi: ath11k: fix error path leaks in some WMI calls
wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()
Sheroz Juraev (1):
wifi: iwlwifi: mld: stop TX during firmware restart
Shitalkumar Gandhi (1):
wifi: wilc1000: fix dma_buffer leak on bus acquire failure
Willmar Knikker (1):
wifi: ath11k: fix use after free in ath11k_dp_rx_msdu_coalesce()
Zhao Li (1):
wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb
drivers/net/wireless/ath/ath10k/wmi.c | 17 ++-
drivers/net/wireless/ath/ath11k/dp_rx.c | 9 +-
drivers/net/wireless/ath/ath11k/hal.c | 14 ++-
drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +-
drivers/net/wireless/ath/ath11k/testmode.c | 1 +
drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++---
drivers/net/wireless/ath/ath12k/mac.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mld/constants.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mld/d3.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mld/link.c | 13 +-
drivers/net/wireless/intel/iwlwifi/mld/tx.c | 15 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 27 +++--
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 14 +--
.../intel/iwlwifi/pcie/gen1_2/trans-gen2.c | 6 +-
drivers/net/wireless/microchip/wilc1000/wlan.c | 2 +-
net/mac80211/cfg.c | 5 +-
net/mac80211/mlme.c | 5 +-
net/mac80211/parse.c | 107 ++++++++++-------
net/mac80211/rx.c | 6 +-
net/wireless/scan.c | 3 +
net/wireless/wext-compat.c | 2 +
21 files changed, 276 insertions(+), 124 deletions(-)
^ permalink raw reply
* [syzbot] [wireless?] WARNING in drv_get_tsf (3)
From: syzbot @ 2026-05-21 15:27 UTC (permalink / raw)
To: johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 6916d5703ddf Merge tag 'drm-fixes-2026-05-16' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14dd2536580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d0f0911eedbc130a
dashboard link: https://syzkaller.appspot.com/bug?extid=1c8c45017f784e646b47
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/1efefe7c73e1/disk-6916d570.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1dcf16f12a0f/vmlinux-6916d570.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7bc2e1f3e5cd/bzImage-6916d570.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1c8c45017f784e646b47@syzkaller.appspotmail.com
------------[ cut here ]------------
wlan0: Failed check-sdata-in-driver check, flags: 0x0
WARNING: net/mac80211/driver-ops.c:255 at drv_get_tsf+0x33f/0x770 net/mac80211/driver-ops.c:255, CPU#0: kworker/u8:17/7122
Modules linked in:
CPU: 0 UID: 0 PID: 7122 Comm: kworker/u8:17 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Workqueue: events_unbound cfg80211_wiphy_work
RIP: 0010:drv_get_tsf+0x345/0x770 net/mac80211/driver-ops.c:255
Code: 0a 00 00 4d 85 ed 0f 84 45 03 00 00 e8 34 92 11 f7 49 81 c5 20 01 00 00 e8 28 92 11 f7 48 8d 3d c1 57 f2 05 44 89 f2 4c 89 ee <67> 48 0f b9 3a e9 a6 fd ff ff e8 0c 92 11 f7 65 44 8b 25 78 47 14
RSP: 0018:ffffc90003797b70 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88805c850e40 RCX: ffffffff8af67847
RDX: 0000000000000000 RSI: ffff88805c850120 RDI: ffffffff90e8d060
RBP: ffff88805c830f20 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88805c851878
R13: ffff88805c850120 R14: 0000000000000000 R15: ffff88805c8306c0
FS: 0000000000000000(0000) GS:ffff888124374000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f619fa17e9c CR3: 000000005f5f6000 CR4: 00000000003526f0
Call Trace:
<TASK>
ieee80211_if_fmt_tsf+0x42/0x70 net/mac80211/debugfs_netdev.c:660
wiphy_locked_debugfs_read_work+0xe6/0x1c0 net/wireless/debugfs.c:168
cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 0a 00 or (%rax),%al
2: 00 4d 85 add %cl,-0x7b(%rbp)
5: ed in (%dx),%eax
6: 0f 84 45 03 00 00 je 0x351
c: e8 34 92 11 f7 call 0xf7119245
11: 49 81 c5 20 01 00 00 add $0x120,%r13
18: e8 28 92 11 f7 call 0xf7119245
1d: 48 8d 3d c1 57 f2 05 lea 0x5f257c1(%rip),%rdi # 0x5f257e5
24: 44 89 f2 mov %r14d,%edx
27: 4c 89 ee mov %r13,%rsi
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: e9 a6 fd ff ff jmp 0xfffffdda
34: e8 0c 92 11 f7 call 0xf7119245
39: 65 gs
3a: 44 rex.R
3b: 8b .byte 0x8b
3c: 25 .byte 0x25
3d: 78 47 js 0x86
3f: 14 .byte 0x14
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Greg KH @ 2026-05-21 13:11 UTC (permalink / raw)
To: Johnson Tsai
Cc: Elliot Saba, Johannes Berg, Ping-Ke Shih,
linux-wireless@vger.kernel.org, driver-core@lists.linux.dev,
Charles Lohr
In-Reply-To: <fe2a612385f8439a820272f442314d37@realtek.com>
On Thu, May 21, 2026 at 01:06:09PM +0000, Johnson Tsai wrote:
>
> On Thursday, May 21, 2026 18:58, Greg KH wrote:
> > On Wed, May 20, 2026 at 07:32:13PM +0000, Elliot Saba wrote:
> > > Hello Greg, Johannes, thank you for your time and feedback on this
> > patchset.
> > >
> > > The purpose of this information is to provide access to two pieces of
> > information, a serial number (also printed on the outside of the device, used
> > for product tracking, RMAs, etc...) and a GUID (random entropy that is
> > intentionally difficult to guess).
> > > We use the GUID to establish a direct connection between the USB network
> > adapter and another device.
> > >
> > > To directly answer your USB questions, unfortunately the ASIC used in this
> > product does not support customization of the USB serial number; all devices
> > have the same USB serial number. Indeed, I believe there is no mutable state
> > on the device at all except for the e-fuses that are written at the factory to
> > write these two values. Given those constraints, we're trying to find the best
> > way to raise this up to userspace, and we're grateful for your feedback.
> >
> > Then where exactly does that "serial number" come from in the device so that
> > it can be read by the kernel, if not in the USB device itself?
>
> The "serial number" we're talking about right now is not exposed through the standard
> USB descriptors. It is obtained via a vendor-specific H2C (Host-to-Chip)
> command, which reads EFUSE data into the rtw89 driver.
> Both SN and UUID are stored as specific fields within that data block.
Ick, ok, gotta love custom USB commands :(
> > > This USB device is expected to operate on both Windows and Linux hosts,
> > on the Windows side we have a custom driver that allows our host application
> > (Steam) to directly query these fuses and setup the network connection
> > appropriately. We're attempting to upstream this capability as much as
> > possible so that users running a vanilla kernel can take advantage of these
> > features as much as possible.
> >
> > Great, why can't this driver also query the fuses?
>
> Yes, the driver can query the fuses directly, similar to the Windows driver
> implementation.
> In this RFC v1, the H2C implementation is intentionally omitted to keep the discussion
> focused on the sysfs interface design and gather early feedback from the
> community.
Great, put these on the network device that you create as they are not a
generic USB attribute, and properly document them in Documentation/ABI/
>
> >
> > > With regards to permissions, we'd really like to make this serial number
> > readable by non-root users so that the pairing functionality can work out-of-
> > the-box without needing special udev/tmpfiles.d rules to adjust permissions
> > to allow Steam to read this information, but we are simultaneously
> > sympathetic to the desire to limit trackable/identifying information by default.
> > Of course we can adjust permissions however needed for our own Linux
> > distribution, but in our effort to support the rest of the Linux ecosystem as
> > best we can, we'd like to do our best to find a solution that would work
> > everywhere. We're open to comparing against any existing precedent for
> > devices that necessarily require identifying information to perform their basic
> > function, if you know of any.
> >
> > My objection is the placement of random sysfs files in the USB device
> > directory, for something that is not a USB device-specific thing, but rather a
> > driver-specific thing. If this is a driver/device bound specific thing, then put it
> > in the device that the driver creates and owns. NOT in the device that the USB
> > core creates and owns.
> >
>
> We completely agree with your concern. Since accessing these values requires
> driver-specific commands rather than standard USB requests, they should not live
> under the USB device directory.
Great
> In the upcoming v2 patchset, we will move these attributes under the wiphy device
> managed by the rtw89 driver. The paths will be something like:
>
> $ cat /sys/class/ieee80211/phy0/sn
> 3642000123
Spell it out, you have almost unlimited number of characters for a file name :)
> $ cat /sys/class/ieee80211/phy0/uuid
> aaec2b7c-0a55-4727-8de0-b30febccbbaa
>
> Additionally, these sysfs attributes will be strictly limited to Valve's specific VID/PID
> pair and will not be exposed on generic RTL8852CU devices.
Great, please document it as such.
thanks,
greg k-h
^ permalink raw reply
* RE: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Johnson Tsai @ 2026-05-21 13:06 UTC (permalink / raw)
To: Greg KH, Elliot Saba
Cc: Johannes Berg, Ping-Ke Shih, linux-wireless@vger.kernel.org,
driver-core@lists.linux.dev, Charles Lohr
In-Reply-To: <2026052152-pureness-blinker-9e5c@gregkh>
On Thursday, May 21, 2026 18:58, Greg KH wrote:
> On Wed, May 20, 2026 at 07:32:13PM +0000, Elliot Saba wrote:
> > Hello Greg, Johannes, thank you for your time and feedback on this
> patchset.
> >
> > The purpose of this information is to provide access to two pieces of
> information, a serial number (also printed on the outside of the device, used
> for product tracking, RMAs, etc...) and a GUID (random entropy that is
> intentionally difficult to guess).
> > We use the GUID to establish a direct connection between the USB network
> adapter and another device.
> >
> > To directly answer your USB questions, unfortunately the ASIC used in this
> product does not support customization of the USB serial number; all devices
> have the same USB serial number. Indeed, I believe there is no mutable state
> on the device at all except for the e-fuses that are written at the factory to
> write these two values. Given those constraints, we're trying to find the best
> way to raise this up to userspace, and we're grateful for your feedback.
>
> Then where exactly does that "serial number" come from in the device so that
> it can be read by the kernel, if not in the USB device itself?
The "serial number" we're talking about right now is not exposed through the standard
USB descriptors. It is obtained via a vendor-specific H2C (Host-to-Chip)
command, which reads EFUSE data into the rtw89 driver.
Both SN and UUID are stored as specific fields within that data block.
>
> > This USB device is expected to operate on both Windows and Linux hosts,
> on the Windows side we have a custom driver that allows our host application
> (Steam) to directly query these fuses and setup the network connection
> appropriately. We're attempting to upstream this capability as much as
> possible so that users running a vanilla kernel can take advantage of these
> features as much as possible.
>
> Great, why can't this driver also query the fuses?
Yes, the driver can query the fuses directly, similar to the Windows driver
implementation.
In this RFC v1, the H2C implementation is intentionally omitted to keep the discussion
focused on the sysfs interface design and gather early feedback from the
community.
>
> > With regards to permissions, we'd really like to make this serial number
> readable by non-root users so that the pairing functionality can work out-of-
> the-box without needing special udev/tmpfiles.d rules to adjust permissions
> to allow Steam to read this information, but we are simultaneously
> sympathetic to the desire to limit trackable/identifying information by default.
> Of course we can adjust permissions however needed for our own Linux
> distribution, but in our effort to support the rest of the Linux ecosystem as
> best we can, we'd like to do our best to find a solution that would work
> everywhere. We're open to comparing against any existing precedent for
> devices that necessarily require identifying information to perform their basic
> function, if you know of any.
>
> My objection is the placement of random sysfs files in the USB device
> directory, for something that is not a USB device-specific thing, but rather a
> driver-specific thing. If this is a driver/device bound specific thing, then put it
> in the device that the driver creates and owns. NOT in the device that the USB
> core creates and owns.
>
We completely agree with your concern. Since accessing these values requires
driver-specific commands rather than standard USB requests, they should not live
under the USB device directory.
In the upcoming v2 patchset, we will move these attributes under the wiphy device
managed by the rtw89 driver. The paths will be something like:
$ cat /sys/class/ieee80211/phy0/sn
3642000123
$ cat /sys/class/ieee80211/phy0/uuid
aaec2b7c-0a55-4727-8de0-b30febccbbaa
Additionally, these sysfs attributes will be strictly limited to Valve's specific VID/PID
pair and will not be exposed on generic RTL8852CU devices.
Thanks,
Johnson
^ permalink raw reply
* [PATCH v2] wireless-regdb: add regulatory rules for Iraq (IQ)
From: Mohammed Abdullah Ali Al-Obaidi @ 2026-05-21 10:15 UTC (permalink / raw)
To: wireless-regdb; +Cc: linux-wireless, Mohammed Abdullah Ali Al-Obaidi
In-Reply-To: <20260521101501.1841-1-mnew_iraq.ref@yahoo.com>
Add a regulatory entry for Iraq (ISO 3166-1 alpha-2: IQ).
Iraq is currently absent from the regulatory database. Devices set
to country=IQ fall back to the world domain (00), which leaves most
of the 5 GHz spectrum marked "no IR" and severely restricts even
2.4 GHz operation. The Iraqi Communications and Media Commission
(CMC) has now published an explicit, numerical national regulation
that fills this gap.
Source document
---------------
Title : Regulation on short-range radio communication devices
(SRD) and devices using ultra-broadband (UWB) technology
Issuer: Republic of Iraq, Communications and Media Commission
(CMC), Telecommunications Regulatory Department,
International Relations Section
Decree: Council of Commissioners decision No. 122/q-2025
In force from: 2025-09-22
Edition: First edition, 2025; 26 pages
URL : https://cmc.iq/wp-content/uploads/2025/09/Regulation-on-short-range-radio-communication-devices-SRD-and-devices-using-ultra-broadband-UWB-technology.pdf
The values below are taken directly from Article 4-1-13 ("Wireless
Access Systems / WAS") of that regulation, which is the table
governing Wi-Fi (Annex A of the regulation defines Wi-Fi as
"802.11 Local Area Networking in 2.4 and 5 GHz ISM bands").
Bands and limits, as stated in Article 4-1-13:
2400-2483.5 MHz : 100 mW EIRP, indoor and outdoor, LBT/DAA
(EN 300 328, ERC/REC 70-03)
5150-5250 MHz : 200 mW EIRP, indoor
(EN 301 893, ITU-R Res. 229 Rev. WRC-19)
5250-5350 MHz : 200 mW EIRP, indoor
(EN 301 893)
5470-5725 MHz : 1000 mW EIRP, indoor, DFS + TPC
(EN 301 893)
5725-5875 MHz : 2000 mW EIRP (10 MHz ch) / 4000 mW (20 MHz ch),
indoor and outdoor
(EN 302 502)
5945-6425 MHz : 200 mW EIRP, indoor
(EN 303 687, ECC Report 75)
57-66 GHz : 10 W EIRP, indoor, LBT/DAA
(EN 302 567)
Notes on the encoding chosen below
----------------------------------
* TPC handling for 5470-5725 MHz: The regulation explicitly requires
both DFS and TPC. Because Linux/wireless-regdb does not natively
enforce TPC limits, the rule is encoded with the standard DFS flag
to remain as compliant as possible within the framework's capabilities.
* Indoor/Outdoor for 5725-5875 MHz: The regulation explicitly permits
both indoor and outdoor operation for this band, so no NO-OUTDOOR flag
is applied.
* EIRP limit for 5725-5875 MHz: The regulation provides two figures
(2000 mW for 10 MHz channels, 4000 mW for 20 MHz channels). Because
wireless-regdb expresses a strict per-band ceiling to ensure compliance
across all configurations, the limit is conservatively set to 2000 mW
to prevent narrower channel widths from exceeding their legal limit.
* 6 GHz channel width: Encoded at 80 MHz (the widest standard-power
option) pending further clarification from the CMC regarding AFC
requirements.
Background on the unique 5.8 GHz figure
---------------------------------------
The 2000 mW EIRP ceiling for 5725-5875 MHz reflects an explicit Iraqi
national choice that follows EN 302 502 (BFWA). This choice puts Iraq
at the high end of the regional spectrum policy for the 5.8 GHz band
and is included verbatim from the regulation.
Signed-off-by: Mohammed Abdullah Ali Al-Obaidi <mnew_iraq@yahoo.com>
---
v2:
- Changed 5725-5875 MHz EIRP ceiling from 4000 mW to 2000 mW to
ensure absolute compliance at narrower channel widths (10 MHz).
- Trimmed redundant encoding notes regarding standard NO-OUTDOOR,
DFS, and AUTO-BW conventions.
- Clarified TPC handling limitations and indoor/outdoor encoding
choices.
db.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/db.txt b/db.txt
--- a/db.txt
+++ b/db.txt
@@ -insert-after-IN-block@@
+# Iraq
+# Source: Regulation on short-range radio communication devices (SRD)
+# and devices using ultra-broadband (UWB) technology, First Edition
+# 2025, issued by the Iraqi Communications and Media Commission (CMC)
+# under Council of Commissioners decision No. 122/q-2025, in force
+# from 2025-09-22. Limits below are taken from Article 4-1-13
+# (Wireless Access Systems) of that regulation.
+# https://cmc.iq/wp-content/uploads/2025/09/Regulation-on-short-range-radio-communication-devices-SRD-and-devices-using-ultra-broadband-UWB-technology.pdf
+country IQ: DFS-ETSI
+ (2400 - 2483.5 @ 40), (100 mW), wmmrule=ETSI
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5470 - 5725 @ 160), (1000 mW), NO-OUTDOOR, DFS, wmmrule=ETSI
+ (5725 - 5875 @ 80), (2000 mW)
+ (5945 - 6425 @ 80), (200 mW), NO-OUTDOOR, wmmrule=ETSI
+ (57000 - 66000 @ 2160), (40)
--
2.43.0
^ permalink raw reply
* Re: [External Mail] Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Greg KH @ 2026-05-21 10:57 UTC (permalink / raw)
To: Elliot Saba
Cc: Johnson Tsai, Johannes Berg, Ping-Ke Shih,
linux-wireless@vger.kernel.org, driver-core@lists.linux.dev,
Charles Lohr
In-Reply-To: <9ce7404ea7bc480786b5ed0bb2182157@valvesoftware.com>
On Wed, May 20, 2026 at 07:32:13PM +0000, Elliot Saba wrote:
> Hello Greg, Johannes, thank you for your time and feedback on this patchset.
>
> The purpose of this information is to provide access to two pieces of information, a serial number (also printed on the outside of the device, used for product tracking, RMAs, etc...) and a GUID (random entropy that is intentionally difficult to guess).
> We use the GUID to establish a direct connection between the USB network adapter and another device.
>
> To directly answer your USB questions, unfortunately the ASIC used in this product does not support customization of the USB serial number; all devices have the same USB serial number. Indeed, I believe there is no mutable state on the device at all except for the e-fuses that are written at the factory to write these two values. Given those constraints, we're trying to find the best way to raise this up to userspace, and we're grateful for your feedback.
Then where exactly does that "serial number" come from in the device so
that it can be read by the kernel, if not in the USB device itself?
> This USB device is expected to operate on both Windows and Linux hosts, on the Windows side we have a custom driver that allows our host application (Steam) to directly query these fuses and setup the network connection appropriately. We're attempting to upstream this capability as much as possible so that users running a vanilla kernel can take advantage of these features as much as possible.
Great, why can't this driver also query the fuses?
> With regards to permissions, we'd really like to make this serial number readable by non-root users so that the pairing functionality can work out-of-the-box without needing special udev/tmpfiles.d rules to adjust permissions to allow Steam to read this information, but we are simultaneously sympathetic to the desire to limit trackable/identifying information by default. Of course we can adjust permissions however needed for our own Linux distribution, but in our effort to support the rest of the Linux ecosystem as best we can, we'd like to do our best to find a solution that would work everywhere. We're open to comparing against any existing precedent for devices that necessarily require identifying information to perform their basic function, if you know of any.
My objection is the placement of random sysfs files in the USB device
directory, for something that is not a USB device-specific thing, but
rather a driver-specific thing. If this is a driver/device bound
specific thing, then put it in the device that the driver creates and
owns. NOT in the device that the USB core creates and owns.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 07/10] [v6 net-next] dt-bindings: net: add st,stlc4560/p54spi binding
From: Bartosz Golaszewski @ 2026-05-21 9:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Bogendoerfer, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, Matti Vaittinen,
Florian Fainelli, Jonas Gorski, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wireless, linux-omap, linux-arm-kernel, linux-mips,
linux-sh, linux-input, linux-leds, netdev, Christian Lamparter,
Conor Dooley, linux-gpio
In-Reply-To: <20260520183815.2510387-8-arnd@kernel.org>
On Wed, 20 May 2026 20:38:12 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The SPI version of Prism54 was sold under a couple of different
> names and supported by the Linux p54spi driver, but there was
> never a DT binding for it.
>
> Document the four known names of this device and the properties
> that are sufficient for its use on the Nokia N8x0 tablet.
>
> As I don't have this hardware or documentation for it, this is
> purely based on existing usage in the driver.
>
> Link: https://lore.kernel.org/all/e8dc9acb-6f85-e0a9-a145-d101ca6da201@gmail.com/
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 02/10] [v3] input: gpio-keys: make legacy gpiolib optional
From: Bartosz Golaszewski @ 2026-05-21 9:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Bogendoerfer, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, Matti Vaittinen,
Florian Fainelli, Jonas Gorski, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wireless, linux-omap, linux-arm-kernel, linux-mips,
linux-sh, linux-input, linux-leds, netdev, linux-gpio
In-Reply-To: <20260520183815.2510387-3-arnd@kernel.org>
On Wed, 20 May 2026 20:38:07 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Most users of gpio-keys and gpio-keys-polled use modern gpiolib
> interfaces, but there are still number of ancient sh, arm32 and x86
> machines that have never been converted.
>
> Add an #ifdef block for the parts of the driver that are only used on
> those legacy machines.
>
> The two Rohm PMIC drivers use a gpio-keys device without an actual GPIO,
> passing an IRQ number instead. In order to keep this working both with
> and with CONFIG_GPIOLIB_LEGACY, change the gpio-keys driver to ignore
> the gpio number if an IRQ is passed.
>
> Link: https://lore.kernel.org/all/b3c94552-c104-42e3-be15-7e8362e8039e@gmail.com/
> Link: https://lore.kernel.org/all/afJXG4_rtaj3l2Dk@google.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v7 6/6] wifi: mac80211: Fix PERR frame processing
From: Masashi Honma @ 2026-05-21 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Masashi Honma
In-Reply-To: <20260521085647.394151-1-masashi.honma@gmail.com>
There are no issues with the PERR processing itself; however, to maintain
consistency with the previous PREQ/PREP code modifications, I will create a new
mesh_path_parse_error_frame() function to separately implement the frame format
validation and the "not supported" check.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
include/linux/ieee80211-mesh.h | 41 ++++++++++++++++++++++++++++++++++
net/mac80211/mesh_hwmp.c | 14 ++++++++++--
net/mac80211/parse.c | 9 ++++++--
3 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/include/linux/ieee80211-mesh.h b/include/linux/ieee80211-mesh.h
index b4fca2937de0..bd83c647a578 100644
--- a/include/linux/ieee80211-mesh.h
+++ b/include/linux/ieee80211-mesh.h
@@ -365,4 +365,45 @@ static inline bool ieee80211_mesh_prep_size_ok(const u8 *pos, u8 elen)
return elen == needed;
}
+/* IEEE Std 802.11-2016 9.4.2.115 PERR element */
+static inline bool ieee80211_mesh_perr_size_ok(const u8 *pos, u8 elen)
+{
+ struct ieee80211_mesh_hwmp_perr *perr_elem = (void *)pos;
+ u8 number_of_dst;
+ u8 needed;
+ const u8 *start;
+ int i;
+
+ start = pos;
+ needed = sizeof(struct ieee80211_mesh_hwmp_perr);
+ pos += sizeof(struct ieee80211_mesh_hwmp_perr);
+
+ /* Check if the element contains number of dst */
+ if (elen < needed)
+ return false;
+
+ number_of_dst = perr_elem->number_of_dst;
+ if (number_of_dst < 1 || number_of_dst > 19)
+ return false;
+
+ for (i = 0; i < number_of_dst; i++) {
+ struct ieee80211_mesh_hwmp_perr_dst *perr_dst =
+ &perr_elem->dsts[i];
+ u8 dst_len;
+
+ /* Check if the element contains flags */
+ if (elen < pos - start + 1)
+ return false;
+
+ dst_len = sizeof(struct ieee80211_mesh_hwmp_perr_dst) +
+ ((perr_dst->flags & AE_F) ? ETH_ALEN : 0)
+ /* Destination External Address */ +
+ 2 /* Reason Code */;
+ needed += dst_len;
+ pos += dst_len;
+ }
+
+ return elen == needed;
+}
+
#endif /* LINUX_IEEE80211_MESH_H */
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 391d37721b23..a74d7b28a35d 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -957,9 +957,19 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data *sdata,
path_metric);
}
if (elems->perr) {
- if (elems->perr_len != 15)
- /* Right now we support only one destination per PERR */
+ struct ieee80211_mesh_hwmp_perr *perr_elem =
+ (struct ieee80211_mesh_hwmp_perr *)elems->perr;
+ int i;
+
+ /* Right now we support only one destination per PERR */
+ if (perr_elem->number_of_dst != 1)
goto free;
+
+ /* Right now we do not support AE (Address Extension) */
+ for (i = 0; i < perr_elem->number_of_dst; i++)
+ if (perr_elem->dsts[i].flags & AE_F)
+ goto free;
+
hwmp_perr_frame_process(sdata, mgmt, elems->perr);
}
if (elems->rann)
diff --git a/net/mac80211/parse.c b/net/mac80211/parse.c
index bbd1e1bc77b4..d84e5e12ad24 100644
--- a/net/mac80211/parse.c
+++ b/net/mac80211/parse.c
@@ -565,8 +565,13 @@ _ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params,
}
break;
case WLAN_EID_PERR:
- elems->perr = pos;
- elems->perr_len = elen;
+ if (ieee80211_mesh_perr_size_ok(pos, elen)) {
+ elems->perr = pos;
+ elems->perr_len = elen;
+ } else {
+ elem_parse_failed =
+ IEEE80211_PARSE_ERR_BAD_ELEM_SIZE;
+ }
break;
case WLAN_EID_RANN:
if (elen >= sizeof(struct ieee80211_rann_ie))
--
2.43.0
^ permalink raw reply related
* [PATCH v7 5/6] wifi: mac80211: Fix overread in PREP frame processing
From: Masashi Honma @ 2026-05-21 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Masashi Honma
In-Reply-To: <20260521085647.394151-1-masashi.honma@gmail.com>
When the AF flag is enabled, hwmp_prep_frame_process() overreads orig_addr
by 2 bytes. Since this occurs within the socket buffer, it does not read across
memory boundaries and therefore poses no security risk; however, we will fix it
as a precaution.
In this fix, a new function mesh_path_parse_reply_frame() is established to
separate the implementation of frame format validation and the check for
unsupported features. This is intended to facilitate future work when
implementing the currently unsupported parts.
Assisted-by: Claude:Sonnet 4.6
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
include/linux/ieee80211-mesh.h | 16 ++++++++++++++++
net/mac80211/mesh_hwmp.c | 4 ++--
net/mac80211/parse.c | 9 +++++++--
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/linux/ieee80211-mesh.h b/include/linux/ieee80211-mesh.h
index 42a5bd73838c..b4fca2937de0 100644
--- a/include/linux/ieee80211-mesh.h
+++ b/include/linux/ieee80211-mesh.h
@@ -349,4 +349,20 @@ static inline bool ieee80211_mesh_preq_size_ok(const u8 *pos, u8 elen)
return elen == needed;
}
+/* IEEE Std 802.11-2016 9.4.2.114 PREP element */
+static inline bool ieee80211_mesh_prep_size_ok(const u8 *pos, u8 elen)
+{
+ u8 needed;
+
+ /* Check if the element contains flags */
+ if (elen < 1)
+ return false;
+
+ needed = sizeof(struct ieee80211_mesh_hwmp_prep_top) +
+ (ieee80211_mesh_preq_prep_ae_enabled(pos) ? ETH_ALEN : 0)
+ /* Target External Address */ +
+ sizeof(struct ieee80211_mesh_hwmp_prep_bottom);
+ return elen == needed;
+}
+
#endif /* LINUX_IEEE80211_MESH_H */
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index ad3e575a0a94..391d37721b23 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -947,8 +947,8 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data *sdata,
path_metric);
}
if (elems->prep) {
- if (elems->prep_len != 31)
- /* Right now we support no AE */
+ /* Right now we do not support AE (Address Extension) */
+ if (ieee80211_mesh_preq_prep_ae_enabled(elems->prep))
goto free;
path_metric = hwmp_route_info_get(sdata, mgmt, elems->prep,
MPATH_PREP);
diff --git a/net/mac80211/parse.c b/net/mac80211/parse.c
index 9e52cc48fc18..bbd1e1bc77b4 100644
--- a/net/mac80211/parse.c
+++ b/net/mac80211/parse.c
@@ -556,8 +556,13 @@ _ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params,
}
break;
case WLAN_EID_PREP:
- elems->prep = pos;
- elems->prep_len = elen;
+ if (ieee80211_mesh_prep_size_ok(pos, elen)) {
+ elems->prep = pos;
+ elems->prep_len = elen;
+ } else {
+ elem_parse_failed =
+ IEEE80211_PARSE_ERR_BAD_ELEM_SIZE;
+ }
break;
case WLAN_EID_PERR:
elems->perr = pos;
--
2.43.0
^ permalink raw reply related
* [PATCH v7 4/6] wifi: mac80211: Fix overread in PREQ frame processing
From: Masashi Honma @ 2026-05-21 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Masashi Honma
In-Reply-To: <20260521085647.394151-1-masashi.honma@gmail.com>
When the AF flag is enabled, hwmp_preq_frame_process() overreads target_addr
by 2 bytes. Since this occurs within the socket buffer, it does not read across
memory boundaries and therefore poses no security risk; however, we will fix it
as a precaution.
In this fix, a new function mesh_path_parse_request_frame() is established to
separate the implementation of frame format validation and the check for
unsupported features. This is intended to facilitate future work when
implementing the currently unsupported parts.
Assisted-by: Claude:Sonnet 4.6
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
include/linux/ieee80211-mesh.h | 28 ++++++++++++++++++++++++++++
net/mac80211/mesh_hwmp.c | 12 ++++++++++--
net/mac80211/parse.c | 9 +++++++--
3 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/include/linux/ieee80211-mesh.h b/include/linux/ieee80211-mesh.h
index 0e9bd56b54f2..42a5bd73838c 100644
--- a/include/linux/ieee80211-mesh.h
+++ b/include/linux/ieee80211-mesh.h
@@ -321,4 +321,32 @@ ieee80211_mesh_hwmp_perr_get_rcode(const u8 *ie, u8 dst_idx)
(dst->flags & AE_F) ? ETH_ALEN : 0]);
}
+/* IEEE Std 802.11-2016 9.4.2.113 PREQ element */
+static inline bool ieee80211_mesh_preq_size_ok(const u8 *pos, u8 elen)
+{
+ struct ieee80211_mesh_hwmp_preq_bottom *preq_elem_bottom =
+ ieee80211_mesh_hwmp_preq_get_bottom(pos);
+ u8 target_count;
+ u8 needed;
+
+ /* Check if the element contains flags */
+ if (elen < 1)
+ return false;
+
+ /* Check if the element contains target_count */
+ needed = sizeof(struct ieee80211_mesh_hwmp_preq_top) +
+ (ieee80211_mesh_preq_prep_ae_enabled(pos) ? ETH_ALEN : 0)
+ /* Originator External Address */ +
+ sizeof(struct ieee80211_mesh_hwmp_preq_bottom);
+ if (elen < needed)
+ return false;
+
+ target_count = preq_elem_bottom->target_count;
+ if (target_count < 1 || target_count > 20)
+ return false;
+
+ needed += target_count * sizeof(struct ieee80211_mesh_hwmp_preq_target);
+ return elen == needed;
+}
+
#endif /* LINUX_IEEE80211_MESH_H */
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index fa144a187fe2..ad3e575a0a94 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -929,9 +929,17 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data *sdata,
return;
if (elems->preq) {
- if (elems->preq_len != 37)
- /* Right now we support just 1 destination and no AE */
+ struct ieee80211_mesh_hwmp_preq_bottom *preq_elem_bottom =
+ ieee80211_mesh_hwmp_preq_get_bottom(elems->preq);
+
+ /* Right now we do not support AE (Address Extension) */
+ if (ieee80211_mesh_preq_prep_ae_enabled(elems->preq))
goto free;
+
+ /* Right now we only support 1 target */
+ if (preq_elem_bottom->target_count != 1)
+ goto free;
+
path_metric = hwmp_route_info_get(sdata, mgmt, elems->preq,
MPATH_PREQ);
if (path_metric)
diff --git a/net/mac80211/parse.c b/net/mac80211/parse.c
index 5e61457be0f3..9e52cc48fc18 100644
--- a/net/mac80211/parse.c
+++ b/net/mac80211/parse.c
@@ -547,8 +547,13 @@ _ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params,
elems->awake_window = (void *)pos;
break;
case WLAN_EID_PREQ:
- elems->preq = pos;
- elems->preq_len = elen;
+ if (ieee80211_mesh_preq_size_ok(pos, elen)) {
+ elems->preq = pos;
+ elems->preq_len = elen;
+ } else {
+ elem_parse_failed =
+ IEEE80211_PARSE_ERR_BAD_ELEM_SIZE;
+ }
break;
case WLAN_EID_PREP:
elems->prep = pos;
--
2.43.0
^ permalink raw reply related
* [PATCH v7 3/6] wifi: mac80211: Use struct instead of macro for PERR frame
From: Masashi Honma @ 2026-05-21 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Masashi Honma
In-Reply-To: <20260521085647.394151-1-masashi.honma@gmail.com>
In preparation for subsequent patches.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
include/linux/ieee80211-mesh.h | 25 +++++++++++++++++++++++++
net/mac80211/mesh_hwmp.c | 31 +++++--------------------------
2 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/include/linux/ieee80211-mesh.h b/include/linux/ieee80211-mesh.h
index 4ce4e47d6d01..0e9bd56b54f2 100644
--- a/include/linux/ieee80211-mesh.h
+++ b/include/linux/ieee80211-mesh.h
@@ -71,6 +71,20 @@ struct ieee80211_mesh_hwmp_prep_bottom {
__le32 orig_sn;
} __packed;
+struct ieee80211_mesh_hwmp_perr_dst {
+ u8 flags;
+ u8 addr[ETH_ALEN];
+ __le32 sn;
+ /* optional Destination External Address */
+ u8 variable[];
+} __packed;
+
+struct ieee80211_mesh_hwmp_perr {
+ u8 ttl;
+ u8 number_of_dst;
+ struct ieee80211_mesh_hwmp_perr_dst dsts[];
+} __packed;
+
/* Mesh flags */
#define MESH_FLAGS_AE_A4 0x1
#define MESH_FLAGS_AE_A5_A6 0x2
@@ -296,4 +310,15 @@ ieee80211_mesh_hwmp_prep_get_bottom(const u8 *ie)
ieee80211_mesh_preq_prep_ae_enabled(ie) ? ETH_ALEN : 0];
}
+static inline u16
+ieee80211_mesh_hwmp_perr_get_rcode(const u8 *ie, u8 dst_idx)
+{
+ struct ieee80211_mesh_hwmp_perr *perr_ie = (void *)ie;
+ struct ieee80211_mesh_hwmp_perr_dst *dst =
+ &perr_ie->dsts[dst_idx];
+
+ return get_unaligned_le16(&dst->variable[
+ (dst->flags & AE_F) ? ETH_ALEN : 0]);
+}
+
#endif /* LINUX_IEEE80211_MESH_H */
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 39b782370df0..fa144a187fe2 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -20,29 +20,7 @@
static void mesh_queue_preq(struct mesh_path *, u8);
-static inline u32 u32_field_get(const u8 *preq_elem, int offset, bool ae)
-{
- if (ae)
- offset += 6;
- return get_unaligned_le32(preq_elem + offset);
-}
-
-static inline u16 u16_field_get(const u8 *preq_elem, int offset, bool ae)
-{
- if (ae)
- offset += 6;
- return get_unaligned_le16(preq_elem + offset);
-}
-
/* HWMP IE processing macros */
-#define AE_F_SET(x) (*x & AE_F)
-
-#define PERR_IE_TTL(x) (*(x))
-#define PERR_IE_TARGET_FLAGS(x) (*(x + 2))
-#define PERR_IE_TARGET_ADDR(x) (x + 3)
-#define PERR_IE_TARGET_SN(x) u32_field_get(x, 9, 0)
-#define PERR_IE_TARGET_RCODE(x) u16_field_get(x, 13, 0)
-
#define MSEC_TO_TU(x) (x*1000/1024)
#define SN_GT(x, y) ((s32)(y - x) < 0)
#define SN_LT(x, y) ((s32)(x - y) < 0)
@@ -774,6 +752,7 @@ static void hwmp_perr_frame_process(struct ieee80211_sub_if_data *sdata,
const u8 *perr_elem)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_mesh_hwmp_perr *perr_elem_s = (void *)perr_elem;
struct mesh_path *mpath;
u8 ttl;
const u8 *ta, *target_addr;
@@ -781,15 +760,15 @@ static void hwmp_perr_frame_process(struct ieee80211_sub_if_data *sdata,
u16 target_rcode;
ta = mgmt->sa;
- ttl = PERR_IE_TTL(perr_elem);
+ ttl = perr_elem_s->ttl;
if (ttl <= 1) {
ifmsh->mshstats.dropped_frames_ttl++;
return;
}
ttl--;
- target_addr = PERR_IE_TARGET_ADDR(perr_elem);
- target_sn = PERR_IE_TARGET_SN(perr_elem);
- target_rcode = PERR_IE_TARGET_RCODE(perr_elem);
+ target_addr = perr_elem_s->dsts[0].addr;
+ target_sn = le32_to_cpu(perr_elem_s->dsts[0].sn);
+ target_rcode = ieee80211_mesh_hwmp_perr_get_rcode(perr_elem, 0);
rcu_read_lock();
mpath = mesh_path_lookup(sdata, target_addr);
--
2.43.0
^ permalink raw reply related
* [PATCH v7 2/6] wifi: mac80211: Use struct instead of macro for PREP frame
From: Masashi Honma @ 2026-05-21 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Masashi Honma
In-Reply-To: <20260521085647.394151-1-masashi.honma@gmail.com>
In preparation for subsequent patches.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
include/linux/ieee80211-mesh.h | 27 ++++++++++++++++++++
net/mac80211/mesh_hwmp.c | 46 ++++++++++++++++------------------
2 files changed, 49 insertions(+), 24 deletions(-)
diff --git a/include/linux/ieee80211-mesh.h b/include/linux/ieee80211-mesh.h
index bf4a544aed00..4ce4e47d6d01 100644
--- a/include/linux/ieee80211-mesh.h
+++ b/include/linux/ieee80211-mesh.h
@@ -53,6 +53,24 @@ struct ieee80211_mesh_hwmp_preq_bottom {
struct ieee80211_mesh_hwmp_preq_target targets[];
} __packed;
+struct ieee80211_mesh_hwmp_prep_top {
+ u8 flags;
+ u8 hopcount;
+ u8 ttl;
+ u8 target_addr[ETH_ALEN];
+ __le32 target_sn;
+
+ /* optional Target External Address */
+ u8 variable[];
+} __packed;
+
+struct ieee80211_mesh_hwmp_prep_bottom {
+ __le32 lifetime;
+ __le32 metric;
+ u8 orig_addr[ETH_ALEN];
+ __le32 orig_sn;
+} __packed;
+
/* Mesh flags */
#define MESH_FLAGS_AE_A4 0x1
#define MESH_FLAGS_AE_A5_A6 0x2
@@ -269,4 +287,13 @@ ieee80211_mesh_hwmp_preq_get_bottom(const u8 *ie)
ieee80211_mesh_preq_prep_ae_enabled(ie) ? ETH_ALEN : 0];
}
+static inline struct ieee80211_mesh_hwmp_prep_bottom *
+ieee80211_mesh_hwmp_prep_get_bottom(const u8 *ie)
+{
+ struct ieee80211_mesh_hwmp_prep_top *top = (void *)ie;
+
+ return (void *)&top->variable[
+ ieee80211_mesh_preq_prep_ae_enabled(ie) ? ETH_ALEN : 0];
+}
+
#endif /* LINUX_IEEE80211_MESH_H */
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 1a6a22b185d9..39b782370df0 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -37,16 +37,6 @@ static inline u16 u16_field_get(const u8 *preq_elem, int offset, bool ae)
/* HWMP IE processing macros */
#define AE_F_SET(x) (*x & AE_F)
-#define PREP_IE_FLAGS(x) (*(x))
-#define PREP_IE_HOPCOUNT(x) (*(x + 1))
-#define PREP_IE_TTL(x) (*(x + 2))
-#define PREP_IE_ORIG_ADDR(x) (AE_F_SET(x) ? x + 27 : x + 21)
-#define PREP_IE_ORIG_SN(x) u32_field_get(x, 27, AE_F_SET(x))
-#define PREP_IE_LIFETIME(x) u32_field_get(x, 13, AE_F_SET(x))
-#define PREP_IE_METRIC(x) u32_field_get(x, 17, AE_F_SET(x))
-#define PREP_IE_TARGET_ADDR(x) (x + 3)
-#define PREP_IE_TARGET_SN(x) u32_field_get(x, 9, 0)
-
#define PERR_IE_TTL(x) (*(x))
#define PERR_IE_TARGET_FLAGS(x) (*(x + 2))
#define PERR_IE_TARGET_ADDR(x) (x + 3)
@@ -419,11 +409,16 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
* so that we can easily use a single function to gather path
* information from both PREQ and PREP frames.
*/
- orig_addr = PREP_IE_TARGET_ADDR(hwmp_ie);
- orig_sn = PREP_IE_TARGET_SN(hwmp_ie);
- orig_lifetime = PREP_IE_LIFETIME(hwmp_ie);
- orig_metric = PREP_IE_METRIC(hwmp_ie);
- hopcount = PREP_IE_HOPCOUNT(hwmp_ie) + 1;
+ struct ieee80211_mesh_hwmp_prep_top *prep_elem_top =
+ (void *)hwmp_ie;
+ struct ieee80211_mesh_hwmp_prep_bottom *prep_elem_bottom =
+ ieee80211_mesh_hwmp_prep_get_bottom(hwmp_ie);
+
+ orig_addr = prep_elem_top->target_addr;
+ orig_sn = le32_to_cpu(prep_elem_top->target_sn);
+ orig_lifetime = le32_to_cpu(prep_elem_bottom->lifetime);
+ orig_metric = le32_to_cpu(prep_elem_bottom->metric);
+ hopcount = prep_elem_top->hopcount + 1;
break;
default:
rcu_read_unlock();
@@ -714,6 +709,9 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
const u8 *prep_elem, u32 metric)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_mesh_hwmp_prep_top *prep_elem_top = (void *)prep_elem;
+ struct ieee80211_mesh_hwmp_prep_bottom *prep_elem_bottom =
+ ieee80211_mesh_hwmp_prep_get_bottom(prep_elem);
struct mesh_path *mpath;
const u8 *target_addr, *orig_addr;
u8 ttl, hopcount, flags;
@@ -721,9 +719,9 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
u32 target_sn, orig_sn, lifetime;
mhwmp_dbg(sdata, "received PREP from %pM\n",
- PREP_IE_TARGET_ADDR(prep_elem));
+ prep_elem_top->target_addr);
- orig_addr = PREP_IE_ORIG_ADDR(prep_elem);
+ orig_addr = prep_elem_bottom->orig_addr;
if (ether_addr_equal(orig_addr, sdata->vif.addr))
/* destination, no forwarding required */
return;
@@ -731,7 +729,7 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
if (!ifmsh->mshcfg.dot11MeshForwarding)
return;
- ttl = PREP_IE_TTL(prep_elem);
+ ttl = prep_elem_top->ttl;
if (ttl <= 1) {
sdata->u.mesh.mshstats.dropped_frames_ttl++;
return;
@@ -750,12 +748,12 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
memcpy(next_hop, next_hop_deref_protected(mpath)->sta.addr, ETH_ALEN);
spin_unlock_bh(&mpath->state_lock);
--ttl;
- flags = PREP_IE_FLAGS(prep_elem);
- lifetime = PREP_IE_LIFETIME(prep_elem);
- hopcount = PREP_IE_HOPCOUNT(prep_elem) + 1;
- target_addr = PREP_IE_TARGET_ADDR(prep_elem);
- target_sn = PREP_IE_TARGET_SN(prep_elem);
- orig_sn = PREP_IE_ORIG_SN(prep_elem);
+ flags = prep_elem_top->flags;
+ lifetime = le32_to_cpu(prep_elem_bottom->lifetime);
+ hopcount = prep_elem_top->hopcount + 1;
+ target_addr = prep_elem_top->target_addr;
+ target_sn = le32_to_cpu(prep_elem_top->target_sn);
+ orig_sn = le32_to_cpu(prep_elem_bottom->orig_sn);
mesh_path_sel_frame_tx(MPATH_PREP, flags, orig_addr, orig_sn, 0,
target_addr, target_sn, next_hop, hopcount,
--
2.43.0
^ permalink raw reply related
* [PATCH v7 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
From: Masashi Honma @ 2026-05-21 8:56 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Masashi Honma
In preparation for subsequent patches.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
include/linux/ieee80211-mesh.h | 42 +++++++++++++++++++++
net/mac80211/mesh_hwmp.c | 67 ++++++++++++++++------------------
2 files changed, 74 insertions(+), 35 deletions(-)
diff --git a/include/linux/ieee80211-mesh.h b/include/linux/ieee80211-mesh.h
index 4b829bcb38b6..bf4a544aed00 100644
--- a/include/linux/ieee80211-mesh.h
+++ b/include/linux/ieee80211-mesh.h
@@ -28,12 +28,40 @@ struct ieee80211s_hdr {
u8 eaddr2[ETH_ALEN];
} __packed __aligned(2);
+struct ieee80211_mesh_hwmp_preq_target {
+ u8 flags;
+ u8 addr[ETH_ALEN];
+ __le32 sn;
+} __packed;
+
+struct ieee80211_mesh_hwmp_preq_top {
+ u8 flags;
+ u8 hopcount;
+ u8 ttl;
+ __le32 preq_id;
+ u8 orig_addr[ETH_ALEN];
+ __le32 orig_sn;
+
+ /* optional AE, lifetime, metric, target */
+ u8 variable[];
+} __packed;
+
+struct ieee80211_mesh_hwmp_preq_bottom {
+ __le32 lifetime;
+ __le32 metric;
+ u8 target_count;
+ struct ieee80211_mesh_hwmp_preq_target targets[];
+} __packed;
+
/* Mesh flags */
#define MESH_FLAGS_AE_A4 0x1
#define MESH_FLAGS_AE_A5_A6 0x2
#define MESH_FLAGS_AE 0x3
#define MESH_FLAGS_PS_DEEP 0x4
+/* HWMP IE processing macros */
+#define AE_F (1<<6)
+
/**
* enum ieee80211_preq_flags - mesh PREQ element flags
*
@@ -227,4 +255,18 @@ enum ieee80211_root_mode_identifier {
IEEE80211_PROACTIVE_RANN = 4,
};
+static inline bool ieee80211_mesh_preq_prep_ae_enabled(const u8 *ie)
+{
+ return ie[0] & AE_F;
+}
+
+static inline struct ieee80211_mesh_hwmp_preq_bottom *
+ieee80211_mesh_hwmp_preq_get_bottom(const u8 *ie)
+{
+ struct ieee80211_mesh_hwmp_preq_top *top = (void *)ie;
+
+ return (void *)&top->variable[
+ ieee80211_mesh_preq_prep_ae_enabled(ie) ? ETH_ALEN : 0];
+}
+
#endif /* LINUX_IEEE80211_MESH_H */
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 9d89ebcce1c1..1a6a22b185d9 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -35,24 +35,11 @@ static inline u16 u16_field_get(const u8 *preq_elem, int offset, bool ae)
}
/* HWMP IE processing macros */
-#define AE_F (1<<6)
#define AE_F_SET(x) (*x & AE_F)
-#define PREQ_IE_FLAGS(x) (*(x))
-#define PREQ_IE_HOPCOUNT(x) (*(x + 1))
-#define PREQ_IE_TTL(x) (*(x + 2))
-#define PREQ_IE_PREQ_ID(x) u32_field_get(x, 3, 0)
-#define PREQ_IE_ORIG_ADDR(x) (x + 7)
-#define PREQ_IE_ORIG_SN(x) u32_field_get(x, 13, 0)
-#define PREQ_IE_LIFETIME(x) u32_field_get(x, 17, AE_F_SET(x))
-#define PREQ_IE_METRIC(x) u32_field_get(x, 21, AE_F_SET(x))
-#define PREQ_IE_TARGET_F(x) (*(AE_F_SET(x) ? x + 32 : x + 26))
-#define PREQ_IE_TARGET_ADDR(x) (AE_F_SET(x) ? x + 33 : x + 27)
-#define PREQ_IE_TARGET_SN(x) u32_field_get(x, 33, AE_F_SET(x))
-
-
-#define PREP_IE_FLAGS(x) PREQ_IE_FLAGS(x)
-#define PREP_IE_HOPCOUNT(x) PREQ_IE_HOPCOUNT(x)
-#define PREP_IE_TTL(x) PREQ_IE_TTL(x)
+
+#define PREP_IE_FLAGS(x) (*(x))
+#define PREP_IE_HOPCOUNT(x) (*(x + 1))
+#define PREP_IE_TTL(x) (*(x + 2))
#define PREP_IE_ORIG_ADDR(x) (AE_F_SET(x) ? x + 27 : x + 21)
#define PREP_IE_ORIG_SN(x) u32_field_get(x, 27, AE_F_SET(x))
#define PREP_IE_LIFETIME(x) u32_field_get(x, 13, AE_F_SET(x))
@@ -415,11 +402,16 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
switch (action) {
case MPATH_PREQ:
- orig_addr = PREQ_IE_ORIG_ADDR(hwmp_ie);
- orig_sn = PREQ_IE_ORIG_SN(hwmp_ie);
- orig_lifetime = PREQ_IE_LIFETIME(hwmp_ie);
- orig_metric = PREQ_IE_METRIC(hwmp_ie);
- hopcount = PREQ_IE_HOPCOUNT(hwmp_ie) + 1;
+ struct ieee80211_mesh_hwmp_preq_top *preq_elem_top =
+ (void *)hwmp_ie;
+ struct ieee80211_mesh_hwmp_preq_bottom *preq_elem_bottom =
+ ieee80211_mesh_hwmp_preq_get_bottom(hwmp_ie);
+
+ orig_addr = preq_elem_top->orig_addr;
+ orig_sn = le32_to_cpu(preq_elem_top->orig_sn);
+ orig_lifetime = le32_to_cpu(preq_elem_bottom->lifetime);
+ orig_metric = le32_to_cpu(preq_elem_bottom->metric);
+ hopcount = preq_elem_top->hopcount + 1;
break;
case MPATH_PREP:
/* Originator here refers to the MP that was the target in the
@@ -579,6 +571,11 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
const u8 *preq_elem, u32 orig_metric)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_mesh_hwmp_preq_top *preq_elem_top = (void *)preq_elem;
+ struct ieee80211_mesh_hwmp_preq_bottom *preq_elem_bottom =
+ ieee80211_mesh_hwmp_preq_get_bottom(preq_elem);
+ struct ieee80211_mesh_hwmp_preq_target *target =
+ preq_elem_bottom->targets;
struct mesh_path *mpath = NULL;
const u8 *target_addr, *orig_addr;
const u8 *da;
@@ -589,13 +586,13 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
bool root_is_gate;
/* Update target SN, if present */
- target_addr = PREQ_IE_TARGET_ADDR(preq_elem);
- orig_addr = PREQ_IE_ORIG_ADDR(preq_elem);
- target_sn = PREQ_IE_TARGET_SN(preq_elem);
- orig_sn = PREQ_IE_ORIG_SN(preq_elem);
- target_flags = PREQ_IE_TARGET_F(preq_elem);
+ target_addr = target[0].addr;
+ orig_addr = preq_elem_top->orig_addr;
+ target_sn = le32_to_cpu(target[0].sn);
+ orig_sn = le32_to_cpu(preq_elem_top->orig_sn);
+ target_flags = target[0].flags;
/* Proactive PREQ gate announcements */
- flags = PREQ_IE_FLAGS(preq_elem);
+ flags = preq_elem_top->flags;
root_is_gate = !!(flags & RANN_FLAG_IS_GATE);
mhwmp_dbg(sdata, "received PREQ from %pM\n", orig_addr);
@@ -655,7 +652,7 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
}
if (reply) {
- lifetime = PREQ_IE_LIFETIME(preq_elem);
+ lifetime = le32_to_cpu(preq_elem_bottom->lifetime);
ttl = ifmsh->mshcfg.element_ttl;
if (ttl != 0) {
mhwmp_dbg(sdata, "replying to the PREQ\n");
@@ -673,22 +670,22 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
u32 preq_id;
u8 hopcount;
- ttl = PREQ_IE_TTL(preq_elem);
- lifetime = PREQ_IE_LIFETIME(preq_elem);
+ ttl = preq_elem_top->ttl;
+ lifetime = le32_to_cpu(preq_elem_bottom->lifetime);
if (ttl <= 1) {
ifmsh->mshstats.dropped_frames_ttl++;
return;
}
mhwmp_dbg(sdata, "forwarding the PREQ from %pM\n", orig_addr);
--ttl;
- preq_id = PREQ_IE_PREQ_ID(preq_elem);
- hopcount = PREQ_IE_HOPCOUNT(preq_elem) + 1;
+ preq_id = le32_to_cpu(preq_elem_top->preq_id);
+ hopcount = preq_elem_top->hopcount + 1;
da = (mpath && mpath->is_root) ?
mpath->rann_snd_addr : broadcast_addr;
if (flags & IEEE80211_PREQ_PROACTIVE_PREP_FLAG) {
- target_addr = PREQ_IE_TARGET_ADDR(preq_elem);
- target_sn = PREQ_IE_TARGET_SN(preq_elem);
+ target_addr = target[0].addr;
+ target_sn = le32_to_cpu(target[0].sn);
}
mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 5/6] wifi: mac80211: Fix overread in PREP frame processing
From: Masashi Honma @ 2026-05-21 8:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <46554aec366d99839894bbcca066daa3450df9d2.camel@sipsolutions.net>
Thank you, fixed other _size_of functions as well.
2026年5月20日(水) 20:16 Johannes Berg <johannes@sipsolutions.net>:
>
> On Sat, 2026-05-16 at 08:38 +0900, Masashi Honma wrote:
> >
> > +/* IEEE Std 802.11-2016 9.4.2.114 PREP element */
> > +static inline bool ieee80211_mesh_prep_size_ok(const u8 *pos, u8 elen)
> > +{
> ...
>
> > + if (elen != needed)
> > + return false;
> > +
> > + return true;
>
> nit: maybe just "return elen == needed;"
>
> johannes
^ permalink raw reply
* Re: [PATCH v6 4/6] wifi: mac80211: Fix overread in PREQ frame processing
From: Masashi Honma @ 2026-05-21 8:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <530aec47e907fce393bcb789516becf3a2102a97.camel@sipsolutions.net>
Thank you, I really need to use LLM to write comment :)
2026年5月20日(水) 20:15 Johannes Berg <johannes@sipsolutions.net>:
>
> On Sat, 2026-05-16 at 08:38 +0900, Masashi Honma wrote:
> >
> > + /* Right now we only supports 1 target */
>
> nit: "support"
>
> johannes
^ permalink raw reply
* Re: [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
From: Masashi Honma @ 2026-05-21 8:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Ping-Ke Shih
In-Reply-To: <9996dcdc12774caf835205040e18eaeb@realtek.com>
Thank you so much. I fixed those.
2026年5月21日(木) 16:53 Ping-Ke Shih <pkshih@realtek.com>:
>
> Johannes Berg <johannes@sipsolutions.net> wrote:
> > > In my tests with arm-gcc compiler, I did a special case:
> > >
> > > struct foo {
> > > int a;
> > > char b;
> > > } __packed;
> > >
> > > int bar(struct foo *foo)
> > > {
> > > return foo->a;
> > > }
> > >
> > > It is obviously aligned (offset = 0), so I guessed arm-gcc can generate
> > > a single load instruction, but actually it doesn't (even with -O3).
> >
> > No, it cannot, because in addition it has to assume the pointer 'foo'
> > itself has no alignment. We use this a lot too, since a struct like your
> > 'struct foo' could be in a frame element where we don't know what came
> > before it while parsing the elements, so we don't know that 'foo' has
> > any alignment.
> >
> > The reasons are related to what happens when you have a
> >
> > struct foo array[N];
> >
> > I think, because then __packed means there's no padding at the end of
> > 'struct foo' either, and array[1] is a completely unaligned pointer.
> >
> > So no, the compiler couldn't assume alignment even for fields that look
> > aligned within 'struct foo'.
>
> I learned more. Super thank you. :)
>
> Ping-Ke
>
^ permalink raw reply
* RE: [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
From: Ping-Ke Shih @ 2026-05-21 7:53 UTC (permalink / raw)
To: Johannes Berg, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <bf2081a986eccd28378b4019b2968c15e6659b7f.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> > In my tests with arm-gcc compiler, I did a special case:
> >
> > struct foo {
> > int a;
> > char b;
> > } __packed;
> >
> > int bar(struct foo *foo)
> > {
> > return foo->a;
> > }
> >
> > It is obviously aligned (offset = 0), so I guessed arm-gcc can generate
> > a single load instruction, but actually it doesn't (even with -O3).
>
> No, it cannot, because in addition it has to assume the pointer 'foo'
> itself has no alignment. We use this a lot too, since a struct like your
> 'struct foo' could be in a frame element where we don't know what came
> before it while parsing the elements, so we don't know that 'foo' has
> any alignment.
>
> The reasons are related to what happens when you have a
>
> struct foo array[N];
>
> I think, because then __packed means there's no padding at the end of
> 'struct foo' either, and array[1] is a completely unaligned pointer.
>
> So no, the compiler couldn't assume alignment even for fields that look
> aligned within 'struct foo'.
I learned more. Super thank you. :)
Ping-Ke
^ permalink raw reply
* Re: [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
From: Johannes Berg @ 2026-05-21 7:42 UTC (permalink / raw)
To: Ping-Ke Shih, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <7e1aac3afd714d448e5bfba4a9a113b0@realtek.com>
On Thu, 2026-05-21 at 07:38 +0000, Ping-Ke Shih wrote:
> Johannes Berg <johannes@sipsolutions.net> wrote:
> > The point is that __packed forces the compiler to emit code that doesn't
> > rely on alignment.
>
> I was not aware that __packed is a hint of unalignment to compiler.
> I learned. :)
Yes. Note it goes further:
> In my tests with arm-gcc compiler, I did a special case:
>
> struct foo {
> int a;
> char b;
> } __packed;
>
> int bar(struct foo *foo)
> {
> return foo->a;
> }
>
> It is obviously aligned (offset = 0), so I guessed arm-gcc can generate
> a single load instruction, but actually it doesn't (even with -O3).
No, it cannot, because in addition it has to assume the pointer 'foo'
itself has no alignment. We use this a lot too, since a struct like your
'struct foo' could be in a frame element where we don't know what came
before it while parsing the elements, so we don't know that 'foo' has
any alignment.
The reasons are related to what happens when you have a
struct foo array[N];
I think, because then __packed means there's no padding at the end of
'struct foo' either, and array[1] is a completely unaligned pointer.
So no, the compiler couldn't assume alignment even for fields that look
aligned within 'struct foo'.
johannes
^ permalink raw reply
* RE: [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
From: Ping-Ke Shih @ 2026-05-21 7:38 UTC (permalink / raw)
To: Johannes Berg, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <93ab81b4fb7130a4d4e1048581d886568086fe24.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> The point is that __packed forces the compiler to emit code that doesn't
> rely on alignment.
I was not aware that __packed is a hint of unalignment to compiler.
I learned. :)
>
> So say e.g. you have
>
> __le32 *ptr = ...;
>
> u32 val = cpu_to_le32(*ptr);
>
> In this case, the compiler can emit a load instruction that assumes
> alignment, so if 'ptr' can be unaligned, we need to use
>
> u32 val = get_unaligned_le32(ptr);
Got it.
With the assignment to pointer, the hint disappeared.
>
> instead.
>
> However, if we have
>
> struct ieee80211_mesh_hwmp_preq_top *ptr = ...;
>
> u32 val = cpu_to_le32(ptr->preq_id);
>
> then the compiler _cannot_ emit a load instruction that assumes
> alignment because of the __packed, and so the compiler has to emit a
> (perhaps sequence of) instruction(s) that load the 32-bit value without
> relying on alignment. As a consequence, we don't have to explicitly
> write it the more complicated way and can just write it the more natural
> way.
I'll remember this is better style in practice. Compiler can help.
In my tests with arm-gcc compiler, I did a special case:
struct foo {
int a;
char b;
} __packed;
int bar(struct foo *foo)
{
return foo->a;
}
It is obviously aligned (offset = 0), so I guessed arm-gcc can generate
a single load instruction, but actually it doesn't (even with -O3).
But this is not the course of this thread. :)
Thank you
Ping-Ke
^ permalink raw reply
* Re: [PATCH 04/10] [v2] sh: select legacy gpiolib interface
From: John Paul Adrian Glaubitz @ 2026-05-21 6:49 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Bogendoerfer, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Linus Walleij,
Bartosz Golaszewski, Dmitry Torokhov, Lee Jones, Pavel Machek,
Matti Vaittinen, Florian Fainelli, Jonas Gorski, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-wireless, linux-omap, linux-arm-kernel,
linux-mips, linux-sh, linux-input, linux-leds, netdev
In-Reply-To: <20260520183815.2510387-5-arnd@kernel.org>
Hi Arnd,
On Wed, 2026-05-20 at 20:38 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Many board files on sh reference the legacy gpiolib interfaces that
> are becoming optional. To ensure the boards can keep building, select
> CONFIG_GPIOLIB_LEGACY on each of the boards that have one of the
> hardcoded calls.
>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: no changes. Adrian said he'll pick it up for 7.2, but so
> far the patch is not in linux-next yet, so I'm including it
> for completeness here.
Sorry, I hadn't gotten around to pick the changes for v7.2 yet. I can
pick it up this weekend as I was planning to review and merge some
patches this weekend.
I have received quite a lot of patches for SH recently, so it will take
some time to dig myself through the queue.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v6 11/16] media: qcom: Switch to generic PAS TZ APIs
From: Vikash Garodia @ 2026-05-21 6:40 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,
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, linux-kernel, Sumit Garg,
pgujjula
In-Reply-To: <20260518072856.22790-12-sumit.garg@kernel.org>
On 5/18/2026 12:58 PM, Sumit Garg wrote:
> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> index 5f408024e967..b3c5281aea91 100644
> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> @@ -4,6 +4,7 @@
> */
>
> #include <linux/firmware.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/firmware/qcom/qcom_scm.h>
> #include <linux/of_address.h>
> #include <linux/of_reserved_mem.h>
> @@ -79,7 +80,7 @@ int iris_fw_load(struct iris_core *core)
> return -ENOMEM;
> }
>
> - ret = qcom_scm_pas_auth_and_reset(core->iris_platform_data->pas_id);
> + ret = qcom_pas_auth_and_reset(core->iris_platform_data->pas_id);
> if (ret) {
> dev_err(core->dev, "auth and reset failed: %d\n", ret);
> return ret;
> @@ -93,7 +94,7 @@ int iris_fw_load(struct iris_core *core)
> cp_config->cp_nonpixel_size);
> if (ret) {
> dev_err(core->dev, "qcom_scm_mem_protect_video_var failed: %d\n", ret);
> - qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> + qcom_pas_shutdown(core->iris_platform_data->pas_id);
> return ret;
> }
> }
> @@ -103,10 +104,10 @@ int iris_fw_load(struct iris_core *core)
>
> int iris_fw_unload(struct iris_core *core)
> {
> - return qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> + return qcom_pas_shutdown(core->iris_platform_data->pas_id);
> }
>
> int iris_set_hw_state(struct iris_core *core, bool resume)
> {
> - return qcom_scm_set_remote_state(resume, 0);
> + return qcom_pas_set_remote_state(resume, 0);
> }
> diff --git a/drivers/media/platform/qcom/venus/Kconfig b/drivers/media/platform/qcom/venus/Kconfig
> index 63ee8c78dc6d..7997b8aa427a 100644
> --- a/drivers/media/platform/qcom/venus/Kconfig
> +++ b/drivers/media/platform/qcom/venus/Kconfig
> @@ -6,6 +6,7 @@ config VIDEO_QCOM_VENUS
> select OF_DYNAMIC if ARCH_QCOM
> select QCOM_MDT_LOADER
> select QCOM_SCM
> + select QCOM_PAS
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
> help
> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> index 1de7436713ed..3a38ff985822 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -12,6 +12,7 @@
> #include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/of_device.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/firmware/qcom/qcom_scm.h>
> #include <linux/sizes.h>
> #include <linux/soc/qcom/mdt_loader.h>
> @@ -58,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
> int ret;
>
> if (core->use_tz) {
> - ret = qcom_scm_set_remote_state(resume, 0);
> + ret = qcom_pas_set_remote_state(resume, 0);
> if (resume && ret == -EINVAL)
> ret = 0;
> return ret;
> @@ -218,7 +219,7 @@ int venus_boot(struct venus_core *core)
> int ret;
>
> if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) ||
> - (core->use_tz && !qcom_scm_is_available()))
> + (core->use_tz && !qcom_pas_is_available()))
> return -EPROBE_DEFER;
>
> ret = of_property_read_string_index(dev->of_node, "firmware-name", 0,
> @@ -236,7 +237,7 @@ int venus_boot(struct venus_core *core)
> core->fw.mem_phys = mem_phys;
>
> if (core->use_tz)
> - ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
> + ret = qcom_pas_auth_and_reset(VENUS_PAS_ID);
> else
> ret = venus_boot_no_tz(core, mem_phys, mem_size);
>
> @@ -259,7 +260,7 @@ int venus_boot(struct venus_core *core)
> res->cp_nonpixel_start,
> res->cp_nonpixel_size);
> if (ret) {
> - qcom_scm_pas_shutdown(VENUS_PAS_ID);
> + qcom_pas_shutdown(VENUS_PAS_ID);
> dev_err(dev, "set virtual address ranges fail (%d)\n",
> ret);
> return ret;
API "qcom_scm_mem_protect_video_var() would also need this migration,
any reason not to consider that ?
Could you please check, if any such usage of legacy *scm* APIs, like the
one i pointed above, can be enforced to err out at compile time ?
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH v6 12/16] media: qcom: Pass proper PAS ID to set_remote_state API
From: Vikash Garodia @ 2026-05-21 6:30 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,
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, linux-kernel, Sumit Garg
In-Reply-To: <20260518072856.22790-13-sumit.garg@kernel.org>
On 5/18/2026 12:58 PM, Sumit Garg wrote:
> From: Sumit Garg<sumit.garg@oss.qualcomm.com>
>
> As per testing the SCM backend just ignores it while OP-TEE makes
> use of it to for proper book keeping purpose.
>
> Reviewed-by: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
> Tested-by: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com> # Lemans
> Signed-off-by: Sumit Garg<sumit.garg@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_firmware.c | 2 +-
> drivers/media/platform/qcom/venus/firmware.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
From: Johannes Berg @ 2026-05-21 6:24 UTC (permalink / raw)
To: Ping-Ke Shih, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <d2c051127e384a918ff014da02e37e1e@realtek.com>
On Thu, 2026-05-21 at 00:42 +0000, Ping-Ke Shih wrote:
> > > + orig_addr = preq_elem_top->orig_addr;
> > > + orig_sn = get_unaligned_le32(&preq_elem_top->orig_sn);
> > > + orig_lifetime = get_unaligned_le32(&preq_elem_bottom->lifetime);
> > > + orig_metric = get_unaligned_le32(&preq_elem_bottom->metric);
> >
> > Ok, oops, I just realized my other thought on this was wrong - the
> > previous PREQ_IE_LIFETIME() was u32_field_get() which loaded an entirely
> > u32 from there using get_unaligned_le32().
> >
> > However, another comment: You don't need get_unaligned_le32() here since
> > the struct is __packed, so you can simplify all of these to just
> >
> > orig_sn = le32_to_cpu(preq_elem_top->orig_sn);
> >
>
> I think the __packed can cause unaligned.
Of course.
> Not sure if the pointer preq_elem_top can adjust offset back to be aligned?
> (But I think we don't make this assumption.)
No, that's not going to happen.
The point is that __packed forces the compiler to emit code that doesn't
rely on alignment.
So say e.g. you have
__le32 *ptr = ...;
u32 val = cpu_to_le32(*ptr);
In this case, the compiler can emit a load instruction that assumes
alignment, so if 'ptr' can be unaligned, we need to use
u32 val = get_unaligned_le32(ptr);
instead.
However, if we have
struct ieee80211_mesh_hwmp_preq_top *ptr = ...;
u32 val = cpu_to_le32(ptr->preq_id);
then the compiler _cannot_ emit a load instruction that assumes
alignment because of the __packed, and so the compiler has to emit a
(perhaps sequence of) instruction(s) that load the 32-bit value without
relying on alignment. As a consequence, we don't have to explicitly
write it the more complicated way and can just write it the more natural
way.
johannes
^ permalink raw reply
* [PATCH v3] PCI: Disable broken FLR on MediaTek MT7925
From: Jose Ignacio Tornos Martinez @ 2026-05-21 6:12 UTC (permalink / raw)
To: bhelgaas, alex
Cc: nbd, lorenzo, shayne.chen, sean.wang, linux-pci, linux-wireless,
linux-kernel, Jose Ignacio Tornos Martinez
The MediaTek MT7925 WiFi device (14c3:7925) advertises FLR capability
but the implementation is broken - reset always fails, leaving the device
in an undefined state.
This manifests in VFIO passthrough scenarios: Normal VM operation works
fine, including clean shutdown/reboot. However, when the VM terminates
uncleanly (crash, force-off), VFIO attempts to reset the device before
it can be assigned to another VM. Because FLR is broken, the reset fails
and the device remains in an undefined state, preventing reuse.
Disable FLR for this device so the PCI core falls back to working reset
methods (PM reset or bus reset).
This follows the existing pattern used for the MediaTek MT7922 WiFi
(14c3:0616), which is the predecessor device and already uses this quirk.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v3: Resend with MediaTek wireless maintainers CC'd
v2: https://lore.kernel.org/all/20260508145153.717641-1-jtornosm@redhat.com/
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 000000000000..111111111111 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5607,6 +5607,7 @@
* Intel 82579LM Gigabit Ethernet Controller 0x1502
* Intel 82579V Gigabit Ethernet Controller 0x1503
* Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
+ * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
*/
static void quirk_no_flr(struct pci_dev *dev)
{
@@ -5617,6 +5618,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
/* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
static void quirk_no_flr_snet(struct pci_dev *dev)
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox