* Re: [patch 06/24] KVM: arm64: Use ktime_get_snapshot_id() to snapshot CLOCK_REALTIME
From: Thomas Weißschuh @ 2026-05-27 7:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Marc Zyngier, Oliver Upton, kvmarm,
Rodolfo Giometti, Vincent Donnefort, Oliver Upton,
Richard Cochran, netdev, Takashi Iwai, Miri Korenblit,
Johannes Berg, Jacob Keller, Tony Nguyen, Saeed Mahameed,
Peter Hilber, Michael S. Tsirkin, virtualization, linux-wireless,
linux-sound
In-Reply-To: <20260526171223.144327185@kernel.org>
On Tue, May 26, 2026 at 07:13:58PM +0200, Thomas Gleixner wrote:
> ktime_get_snapshot() is replaced by ktime_get_snapshot_id() which allows to
> request a particular CLOCK ID to be captured along with the clocksource
> counter.
>
> Convert the usage in kvm_get_ptp_time() over and use the new
> system_time_snapshot::sys field, which holds the system timestamp selected
> by the CLOCK ID argument.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: kvmarm@lists.linux.dev
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [patch 07/24] ptp: ptp_vmclock: Convert to ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-05-27 7:10 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Richard Cochran, netdev, Rodolfo Giometti,
Vincent Donnefort, Marc Zyngier, Oliver Upton, kvmarm,
Oliver Upton, Takashi Iwai, Miri Korenblit, Johannes Berg,
Jacob Keller, Tony Nguyen, Saeed Mahameed, Peter Hilber,
Michael S. Tsirkin, virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171223.223860692@kernel.org>
On Tue, May 26, 2026 at 07:14:03PM +0200, Thomas Gleixner wrote:
> ktime_get_snapshot() is replaced by ktime_get_snapshot_id() which allows to
> request a particular CLOCK ID to be captured along with the clocksource
> counter.
>
> Convert vmclock over and use the new system_time_snapshot::sys field, which
> holds the system timestamp selected by the CLOCK ID argument.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [patch 08/24] timekeeping: Remove system_time_snapshot::real/boot
From: Thomas Weißschuh @ 2026-05-27 7:17 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171223.300914258@kernel.org>
On Tue, May 26, 2026 at 07:14:08PM +0200, Thomas Gleixner wrote:
> All users are converted over to ktime_get_snapshot_id() and
> system_time_snapshot::sys.
>
> Remove the leftovers.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> include/linux/timekeeping.h | 4 ----
> kernel/time/timekeeping.c | 8 --------
> 2 files changed, 12 deletions(-)
>
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -280,8 +280,6 @@ static inline bool ktime_get_aux_ts64(cl
> * a selected CLOCK_* and the clocksource counter value
> * @cycles: Clocksource counter value to produce the system times
> * @sys: The system time of the selected CLOCK ID
> - * @real: Realtime system time
> - * @boot: Boot time
> * @raw: Monotonic raw system time
> * @cs_id: Clocksource ID
> * @clock_was_set_seq: The sequence number of clock-was-set events
> @@ -291,8 +289,6 @@ static inline bool ktime_get_aux_ts64(cl
> struct system_time_snapshot {
> u64 cycles;
> ktime_t sys;
> - ktime_t real;
> - ktime_t boot;
> ktime_t raw;
> enum clocksource_ids cs_id;
> unsigned int clock_was_set_seq;
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1196,8 +1196,6 @@ bool ktime_get_snapshot_id(struct system
> struct timekeeper *tk;
> struct tk_data *tkd;
> unsigned int seq;
> - ktime_t base_real;
> - ktime_t base_boot;
>
> /* Invalidate the snapshot for all failure cases */
> systime_snapshot->valid = false;
> @@ -1239,18 +1237,12 @@ bool ktime_get_snapshot_id(struct system
> offs_sys = *offs;
> base_raw = tk->tkr_raw.base;
>
> - /* Kept around until the callers are fixed up */
> - base_real = ktime_add(base_sys, tk_core.timekeeper.offs_real);
> - base_boot = ktime_add(base_sys, tk_core.timekeeper.offs_boot);
> -
In patch 1 I was confused slightly why only these two lines use tk_core,
while everything else uses tk->, even base_sys.
Functionally it doesn't make a difference, but for clarity this could be more
consistent.
> nsec_sys = timekeeping_cycles_to_ns(&tk->tkr_mono, now);
> nsec_raw = timekeeping_cycles_to_ns(&tk->tkr_raw, now);
> } while (read_seqcount_retry(&tkd->seq, seq));
>
> systime_snapshot->cycles = now;
> systime_snapshot->sys = ktime_add_ns(base_sys, offs_sys + nsec_sys);
> - systime_snapshot->real = ktime_add_ns(base_real, nsec_sys);
> - systime_snapshot->boot = ktime_add_ns(base_boot, nsec_sys);
> systime_snapshot->raw = ktime_add_ns(base_raw, nsec_raw);
>
> /*
>
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-05-27 7:18 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171223.374814973@kernel.org>
On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
> Now that all users are converted it's possible to enable snapshotting of
> CLOCK_AUX time. The underlying clocksource is the same as for all other
> CLOCK variants.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [patch 17/24] timekeeping: Remove ktime_get_snapshot()
From: Thomas Weißschuh @ 2026-05-27 7:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171223.974925389@kernel.org>
On Tue, May 26, 2026 at 07:14:52PM +0200, Thomas Gleixner wrote:
> All users have been converted to ktime_get_snapshot_id().
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [patch 18/24] timekeeping: Prepare for cross timestamps on arbitrary clock IDs
From: Thomas Weißschuh @ 2026-05-27 7:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171224.050496338@kernel.org>
On Tue, May 26, 2026 at 07:14:57PM +0200, Thomas Gleixner wrote:
> PTP device system crosstime stamps support only CLOCK_REALTIME, which is
> meaningless for AUX clocks. The PTP core hands in the clock ID already, so
> prepare the core code to honor it.
>
> - Add a new sys_systime field to struct system_device_crosststamp which
> aliases the sys_realtime field. Once all users are converted
> sys_realtime can be removed.
>
> - Prepare get_device_system_crosststamp() and the related code for it by
> switching to sys_systime and providing the initial changes to utilize
> different time keepers.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [patch 22/24] timekeeping: Remove system_device_crosststamp::sys_realtime
From: Thomas Weißschuh @ 2026-05-27 7:24 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171224.347997043@kernel.org>
On Tue, May 26, 2026 at 07:15:17PM +0200, Thomas Gleixner wrote:
> All users are converted to sys_systime.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [patch 23/24] timekeeping: Add support for AUX clock cross timestamping
From: Thomas Weißschuh @ 2026-05-27 7:24 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171224.423155175@kernel.org>
On Tue, May 26, 2026 at 07:15:22PM +0200, Thomas Gleixner wrote:
> Now that all prerequisites are in place add the final support for AUX
> clocks in get_device_system_crosststamp(), which enables the PTP layer to
> support hardware cross timestamps with a new IOTCL.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [PATCH rtw-next 1/7] wifi: rtw89: fw: load TX power track element according to AID
From: Ping-Ke Shih @ 2026-05-27 8:42 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: kevin_yang
In-Reply-To: <20260520123823.1792954-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> RF parameters has different TX power track table for different AID.
> FW elements may include multiple TX power track tables for different
> AID. So, load the corresponding one.
>
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
7 patch(es) applied to rtw-next branch of rtw.git, thanks.
f50cf5f5d6a3 wifi: rtw89: fw: load TX power track element according to AID
57efc7b096a6 wifi: rtw89: 8922d: refactor digital power compensation to support new format
c77a155c96d7 wifi: rtw89: 8922d: support new digital power compensation format
89ab7535e428 wifi: rtw89: fw: load TX compensation element by RFE type
ed438b312d07 wifi: rtw89: Wi-Fi 7 configure TX power limit for large MRU
a153f9ce94e6 wifi: rtw89: debug: show large MRU in txpwr_table dbgfs
756abe2ebe3e wifi: rtw89: 8922d: configure TX shape settings
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtw88: Add more validation for the RX descriptor
From: Ping-Ke Shih @ 2026-05-27 8:46 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
Cc: Ping-Ke Shih, LB F, Martin Blumenstingl, Fiona Klute,
andrej.skvortzov, anarsoul, Zhen XIN
In-Reply-To: <5bfecba3-8a90-4e0f-9558-af5cd8a14975@gmail.com>
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.
>
> 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.
>
> The rate should not exceed 4SS MCS9.
>
> 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>
> Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
aa7d92e83811 wifi: rtw88: Add more validation for the RX descriptor
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next v4] wifi: rtw89: usb: Support switching to USB 3 mode
From: Ping-Ke Shih @ 2026-05-27 8:56 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org; +Cc: Ping-Ke Shih
In-Reply-To: <e955451c-93a1-4d04-8024-d224a04f1d4a@gmail.com>
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.
>
> Tested with RTL8832AU, RTL8832BU, RTL8832CU, and RTL8912AU.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
8368970b6240 wifi: rtw89: usb: Support switching to USB 3 mode
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [patch 05/24] KVM: arm64: Use ktime_get_snapshot_id() to retrieve CLOCK_BOOTTIME
From: Marc Zyngier @ 2026-05-27 9:02 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
thomas.weissschuh, Arthur Kiyanovski, Vincent Donnefort,
Oliver Upton, kvmarm, Rodolfo Giometti, Oliver Upton,
Richard Cochran, netdev, Takashi Iwai, Miri Korenblit,
Johannes Berg, Jacob Keller, Tony Nguyen, Saeed Mahameed,
Peter Hilber, Michael S. Tsirkin, virtualization, linux-wireless,
linux-sound
In-Reply-To: <20260526171223.070087856@kernel.org>
On Tue, 26 May 2026 18:13:53 +0100,
Thomas Gleixner <tglx@kernel.org> wrote:
>
> ktime_get_snapshot() is replaced by ktime_get_snapshot_id() which allows to
> request a particular CLOCK ID to be captured along with the clocksource
> counter.
>
> Convert the tracing mechanism over and use the new
> system_time_snapshot::sys field, which holds the system timestamp selected
> by the CLOCK ID argument.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Vincent Donnefort <vdonnefort@google.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oliver.upton@linux.dev>
> Cc: kvmarm@lists.linux.dev
> ---
> arch/arm64/kvm/hyp_trace.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [patch 06/24] KVM: arm64: Use ktime_get_snapshot_id() to snapshot CLOCK_REALTIME
From: Marc Zyngier @ 2026-05-27 9:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
thomas.weissschuh, Arthur Kiyanovski, Oliver Upton, kvmarm,
Rodolfo Giometti, Vincent Donnefort, Oliver Upton,
Richard Cochran, netdev, Takashi Iwai, Miri Korenblit,
Johannes Berg, Jacob Keller, Tony Nguyen, Saeed Mahameed,
Peter Hilber, Michael S. Tsirkin, virtualization, linux-wireless,
linux-sound
In-Reply-To: <20260526171223.144327185@kernel.org>
On Tue, 26 May 2026 18:13:58 +0100,
Thomas Gleixner <tglx@kernel.org> wrote:
>
> ktime_get_snapshot() is replaced by ktime_get_snapshot_id() which allows to
> request a particular CLOCK ID to be captured along with the clocksource
> counter.
>
> Convert the usage in kvm_get_ptp_time() over and use the new
> system_time_snapshot::sys field, which holds the system timestamp selected
> by the CLOCK ID argument.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: kvmarm@lists.linux.dev
> ---
> arch/arm64/kvm/hypercalls.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH] wifi: ipw2x00: Fix potential NULL crypt->ops dereference in libipw_xmit()
From: Nikolay Kuratov @ 2026-05-27 9:08 UTC (permalink / raw)
To: linux-kernel
Cc: linux-wireless, Stanislav Yakovlev, Hong Liu, James Ketrenos,
Nikolay Kuratov, stable
crypt and crypt->ops could be null, so we need to checking null
before dereference
Previously the commit
e8366bbabe1d ("ipw2x00: Fix potential NULL dereference in libipw_xmit()")
partially fixed that same issue in libipw_xmit().
This is similar to CVE-2022-49544.
Found by Svace static analysis tool.
Cc: stable@vger.kernel.org
Fixes: 1264fc0498e1e ("[PATCH] ieee80211: Fix TKIP, repeated fragmentation problem, and payload_size reporting")
Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
---
drivers/net/wireless/intel/ipw2x00/libipw_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/libipw_tx.c b/drivers/net/wireless/intel/ipw2x00/libipw_tx.c
index 6e16060834b8..ec455e680030 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw_tx.c
+++ b/drivers/net/wireless/intel/ipw2x00/libipw_tx.c
@@ -450,7 +450,7 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
for (; i < nr_frags; i++) {
skb_frag = txb->fragments[i];
- if (host_encrypt)
+ if (host_encrypt && crypt && crypt->ops)
skb_reserve(skb_frag,
crypt->ops->extra_mpdu_prefix_len);
--
2.34.1
^ permalink raw reply related
* Invitation to Participate in Bapco Energies Vendor EOI Program 2026/2027
From: hq.bapcoenergies.br @ 2026-05-27 9:37 UTC (permalink / raw)
To: linux-wireless
Dear Supplier,
I hope this message finds you well.
Bapco Energies is pleased to invite your esteemed organization to participate in our Vendor Expression of Interest (EOI) Program for the 2026/2027 cycle.
This program is designed to identify and qualify competent, reliable, and reputable vendors capable of supporting our forthcoming business activities and projects. Selected participants may also be considered for future opportunities involving strategic partnerships and equity participation.
Organizations interested in participating are kindly requested to respond to this email or contact our Procurement Team at tender@bhbapco-energies.com to obtain the Vendor Questionnaire and additional information regarding the program requirements and process.
We value your interest in collaborating with Bapco Energies and look forward to the opportunity of establishing a long-term and mutually beneficial business relationship.
Yours faithfully,
Mr. Firdaus Panthaki
Procurement & Supply Officer
Bapco Energies
^ permalink raw reply
* Re: [PATCH] wifi: ipw2x00: Fix potential NULL crypt->ops dereference in libipw_xmit()
From: Johannes Berg @ 2026-05-27 9:56 UTC (permalink / raw)
To: Nikolay Kuratov, linux-kernel
Cc: linux-wireless, Stanislav Yakovlev, Hong Liu, James Ketrenos,
stable
In-Reply-To: <20260527090833.521511-1-kniv@yandex-team.ru>
On Wed, 2026-05-27 at 12:08 +0300, Nikolay Kuratov wrote:
> crypt and crypt->ops could be null, so we need to checking null
> before dereference
>
> Previously the commit
> e8366bbabe1d ("ipw2x00: Fix potential NULL dereference in libipw_xmit()")
> partially fixed that same issue in libipw_xmit().
> This is similar to CVE-2022-49544.
>
> Found by Svace static analysis tool.
Might want to fix your tool to look deeper than just pattern-matching
the surrounding code :) The prior commit was also already wrong.
We already have
host_encrypt = ieee->host_encrypt && encrypt && crypt;
so "host_encrypt && crypt" is equivalent to checking just
"host_encrypt".
And the only way to set the crypt[] array where a non-NULL 'crypt' comes
from will always have ops, so "crypt && crypt->ops" is equivalent to
checking just "crypt".
johannes
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7925: add wcid publish check in mt76_sta_add
From: Jiajia Liu @ 2026-05-27 10:00 UTC (permalink / raw)
To: Sean Wang
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Michael Lo, Leon Yen, linux-wireless,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <CAGp9LzqzddmyDHMNsaqigYpVEdo_Pmzwbeh5Ri5_Gr87cVL6Dg@mail.gmail.com>
On Tue, May 26, 2026 at 04:52:32PM -0500, Sean Wang wrote:
> Hi,
>
> On Tue, May 26, 2026 at 1:09 AM Jiajia Liu <liujiajia@kylinos.cn> wrote:
> >
> > Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
> > to avoid reinitializing the wcid->poll_list for mt7925.
> >
> > Found dev->sta_poll_list corruption when using mt7925 and 7.0-rc4.
> > According to the corruption information, prev->next was changed to itself.
> >
> > wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
> > wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
> > wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
> > slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
> > list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
> >
> > mt76_wcid_add_poll+0x95/0xd0 [mt76]
> > mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
> > mt7925_rx_check+0xa7/0xc0 [mt7925_common]
> > mt76_dma_rx_poll+0x50d/0x790 [mt76]
> > mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
> >
> > Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> > ---
> >
> > Reproduced and tested using the script below over ssh. Roam between two
> > bssids with the same SSID on a router.
> >
> > #!/bin/bash
> >
> > set -ex
> >
> > while :; do
> > num=$(sudo iw wlan0 scan | grep Polaris | wc -l)
> > if [ $num -eq 2 ]; then
> > break
> > fi
> > done
> >
> > for i in $(seq 1 500); do
> >
> > echo "index $i"
> > wpa_cli -i wlan0 roam 90:fb:5d:94:8b:e3
> > sleep 5
> > wpa_cli -i wlan0 roam 90:fb:5d:94:8b:e2
> > sleep 5
> >
> > done
> >
> > ---
> > drivers/net/wireless/mediatek/mt76/mac80211.c | 11 ++++++++---
> > drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
> > drivers/net/wireless/mediatek/mt76/mt7925/main.c | 3 +++
> > 3 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
> > index 4ae5e4715a9c..83f4f941b890 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
> > @@ -1595,11 +1595,16 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> > mtxq->wcid = wcid->idx;
> > }
> >
> > - ewma_signal_init(&wcid->rssi);
> > - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> > + if (!test_bit(MT_WCID_FLAG_DRV_PUBLISH, &wcid->flags)) {
> > + ewma_signal_init(&wcid->rssi);
> > + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> > + mt76_wcid_init(wcid, phy->band_idx);
> > + } else {
> > + wcid->phy_idx = phy->band_idx;
> > + }
> > +
> > phy->num_sta++;
> >
>
> Thanks for spotting the roaming issue.
>
> I think we can avoid adding MT_WCID_FLAG_DRV_PUBLISH and instead use the
> WCID table itself for the publish check.
>
> dev->wcid[] already encodes whether a WCID has been published, so checking
> it directly avoids adding a second mirror state. MT_WCID_FLAG_* is also
> better kept for WCID features that affect WTBL setup or data-path handling,
> rather than common bookkeeping state.
>
> Something like:
>
> @@ -1620,6 +1620,7 @@ mt76_sta_add(struct mt76_phy *phy, struct
> ieee80211_vif *vif,
> {
> struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
> struct mt76_dev *dev = phy->dev;
> + struct mt76_wcid *published;
> int ret;
> int i;
>
> @@ -1639,7 +1640,10 @@ mt76_sta_add(struct mt76_phy *phy, struct
> ieee80211_vif *vif,
> mtxq->wcid = wcid->idx;
> }
>
> - if (!test_bit(MT_WCID_FLAG_DRV_PUBLISH, &wcid->flags)) {
> + published = rcu_dereference_protected(dev->wcid[wcid->idx],
> + lockdep_is_held(&dev->mutex));
> + if (published != wcid) {
> + WARN_ON_ONCE(published);
> ewma_signal_init(&wcid->rssi);
> rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> mt76_wcid_init(wcid, phy->band_idx);
>
> ....
>
Thanks for the suggestion. Will update in v2.
>
> > - mt76_wcid_init(wcid, phy->band_idx);
> > out:
> > mutex_unlock(&dev->mutex);
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
> > index 527bef97e122..8bfce686bff7 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76.h
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76.h
> > @@ -361,6 +361,7 @@ enum mt76_wcid_flags {
> > MT_WCID_FLAG_PS,
> > MT_WCID_FLAG_4ADDR,
> > MT_WCID_FLAG_HDR_TRANS,
> > + MT_WCID_FLAG_DRV_PUBLISH,
> > };
> >
> > #define MT76_N_WCIDS 1088
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> > index 73d3722739d0..35b5c718475c 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> > @@ -1102,6 +1102,9 @@ int mt7925_mac_sta_add(struct mt76_dev *mdev, struct ieee80211_vif *vif,
> > &msta->deflink);
> > }
> >
> > + if (!err)
> > + set_bit(MT_WCID_FLAG_DRV_PUBLISH, &msta->deflink.wcid.flags);
> > +
> > return err;
> > }
> > EXPORT_SYMBOL_GPL(mt7925_mac_sta_add);
> > --
> > 2.53.0
> >
> >
^ permalink raw reply
* [PATCH 1/1] wifi: nl80211: reject oversized EMA RNR element lists
From: Ren Wei @ 2026-05-27 10:01 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, quic_alokad, yuantan098, zcliangcn, bird, xuyq21, n05ec
In-Reply-To: <cover.1779632165.git.xuyq21@lenovo.com>
From: Yuqi Xu <xuyq21@lenovo.com>
nl80211_parse_rnr_elems() stores the parsed element count in a
u8-backed cfg80211_rnr_elems::cnt field and uses that count to size
the flexible array allocation.
Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches
255, before incrementing it again. This keeps the parser aligned with
the data structure it fills and matches the existing bound check used
by nl80211_parse_mbssid_elems().
Fixes: dbbb27e183b1568d5a907ace1cd144b0709ea52a ("cfg80211: support RNR for EMA AP")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Yuqi Xu <xuyq21@lenovo.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/wireless/nl80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f334cdef8958..500eb84ff55a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6354,6 +6354,9 @@ nl80211_parse_rnr_elems(struct wiphy *wiphy, struct nlattr *attrs,
if (ret)
return ERR_PTR(ret);
+ if (num_elems >= 255)
+ return ERR_PTR(-EINVAL);
+
num_elems++;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/1] wifi: nl80211: reject oversized EMA RNR element lists
From: Johannes Berg @ 2026-05-27 10:03 UTC (permalink / raw)
To: Ren Wei, linux-wireless; +Cc: quic_alokad, yuantan098, zcliangcn, bird, xuyq21
In-Reply-To: <db614d22c4d3cdae0f5fb94b9d78c8e3142c2ecd.1779632165.git.xuyq21@lenovo.com>
On Wed, 2026-05-27 at 18:01 +0800, Ren Wei wrote:
> From: Yuqi Xu <xuyq21@lenovo.com>
>
> nl80211_parse_rnr_elems() stores the parsed element count in a
> u8-backed cfg80211_rnr_elems::cnt field and uses that count to size
> the flexible array allocation.
>
> Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches
> 255, before incrementing it again. This keeps the parser aligned with
> the data structure it fills and matches the existing bound check used
> by nl80211_parse_mbssid_elems().
>
> Fixes: dbbb27e183b1568d5a907ace1cd144b0709ea52a ("cfg80211: support RNR for EMA AP")
Please fix.
johannes
^ permalink raw reply
* [PATCH net 1/1] wireless: wext: export each WEP key size only once
From: Ren Wei @ 2026-05-27 10:18 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, kilroyd, linville, yuantan098, yifanwucs, tomapufckgml,
zcliangcn, bird, xuyq21, n05ec
In-Reply-To: <cover.1779632308.git.xuyq21@lenovo.com>
From: Yuqi Xu <xuyq21@lenovo.com>
cfg80211_wext_giwrange() fills iw_range.encoding_size[] from the
cipher suites advertised by the wiphy. The WEXT range data describes
supported key sizes, but the current code appends one entry for every
WEP cipher occurrence.
A wiphy may expose repeated WEP cipher entries, which can make
cfg80211_wext_giwrange() grow num_encoding_sizes past the available
encoding_size[] slots. Track whether WEP40 and WEP104 are present
while scanning the cipher list, then emit each corresponding key size
once.
This keeps the exported WEXT data aligned with the supported key sizes
and makes duplicate cipher entries irrelevant.
Fixes: 2ab658f9ce21 ("cfg80211: set WE encoding size based on available ciphers")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Yuqi Xu <xuyq21@lenovo.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/wireless/wext-compat.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 22d9d9bae8f5..6d64facd8115 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -109,6 +109,7 @@ int cfg80211_wext_giwrange(struct net_device *dev,
struct iw_point *data = &wrqu->data;
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct iw_range *range = (struct iw_range *) extra;
+ bool have_wep40 = false, have_wep104 = false;
enum nl80211_band band;
int i, c = 0;
@@ -170,17 +171,22 @@ int cfg80211_wext_giwrange(struct net_device *dev,
break;
case WLAN_CIPHER_SUITE_WEP40:
- range->encoding_size[range->num_encoding_sizes++] =
- WLAN_KEY_LEN_WEP40;
+ have_wep40 = true;
break;
case WLAN_CIPHER_SUITE_WEP104:
- range->encoding_size[range->num_encoding_sizes++] =
- WLAN_KEY_LEN_WEP104;
+ have_wep104 = true;
break;
}
}
+ if (have_wep40)
+ range->encoding_size[range->num_encoding_sizes++] =
+ WLAN_KEY_LEN_WEP40;
+ if (have_wep104)
+ range->encoding_size[range->num_encoding_sizes++] =
+ WLAN_KEY_LEN_WEP104;
+
for (band = 0; band < NUM_NL80211_BANDS; band ++) {
struct ieee80211_supported_band *sband;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net 1/1] wireless: wext: export each WEP key size only once
From: Johannes Berg @ 2026-05-27 10:26 UTC (permalink / raw)
To: Ren Wei, linux-wireless
Cc: kilroyd, linville, yuantan098, yifanwucs, tomapufckgml, zcliangcn,
bird, xuyq21
In-Reply-To: <a039d8a18fa47ab9fce851b7f42cdadb62e54ba9.1779632308.git.xuyq21@lenovo.com>
On Wed, 2026-05-27 at 18:18 +0800, Ren Wei wrote:
> From: Yuqi Xu <xuyq21@lenovo.com>
>
> cfg80211_wext_giwrange() fills iw_range.encoding_size[] from the
> cipher suites advertised by the wiphy. The WEXT range data describes
> supported key sizes, but the current code appends one entry for every
> WEP cipher occurrence.
>
> A wiphy may expose repeated WEP cipher entries, which can make
> cfg80211_wext_giwrange() grow num_encoding_sizes past the available
> encoding_size[] slots. Track whether WEP40 and WEP104 are present
> while scanning the cipher list, then emit each corresponding key size
> once.
>
> This keeps the exported WEXT data aligned with the supported key sizes
> and makes duplicate cipher entries irrelevant.
>
> Fixes: 2ab658f9ce21 ("cfg80211: set WE encoding size based on available ciphers")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:GPT-5.4
>
Please **always** check if the issue has been fixed already...
johannes
^ permalink raw reply
* NIPA/wifibot disappeared
From: Johannes Berg @ 2026-05-27 10:52 UTC (permalink / raw)
To: linux-wireless
Hi,
Due to a mistake, the machine that was running our checks was
decommissioned and redeployed about two days ago.
I'd been planning to move the service to the servers that we have at the
netdev foundation for NIPA, but hadn't actually started doing that
because I've just been too busy with other things.
Right now there's very little point in bringing up a new machine in
Intel since that'll also take time, so for now we don't have it until I
can integrate it all with the infrastructure running on the netdev
foundation servers.
johannes
^ permalink raw reply
* Re:[PATCH] wifi: ipw2x00: Fix potential NULL crypt->ops dereference in libipw_xmit()
From: Nikolay Kuratov @ 2026-05-27 11:14 UTC (permalink / raw)
To: linux-kernel
Cc: linux-wireless, Stanislav Yakovlev, Hong Liu, James Ketrenos,
Nikolay Kuratov, Johannes Berg
In-Reply-To: <57001abe5cdd0f2a7fc533764f0d9140fe20a3ad.camel@sipsolutions.net>
> Might want to fix your tool to look deeper than just pattern-matching
> the surrounding code :) The prior commit was also already wrong.
That was me who blindly believed in existing commit correctness!
> so "host_encrypt && crypt" is equivalent to checking just
> "host_encrypt".
Thank you, missed that.
> And the only way to set the crypt[] array where a non-NULL 'crypt' comes
> from will always have ops, so "crypt && crypt->ops" is equivalent to
> checking just "crypt".
To make it more clear, this logic belongs to libipw_wx_set_encode
and libipw_wx_set_encodeext. If there is no libipw_crypt_wep module
available, then it fails with NULL crypt as you said.
Some parts of code still check for non-NULL crypt->ops separately,
but at least it should not cause problems.
Lets just drop that patch.
^ permalink raw reply
* [PATCH] mac80211: suppress false WARNING when rate_mask is empty in __rate_control_send_low
From: Jiakai Xu @ 2026-05-27 11:44 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich, Jiakai Xu
When the beacon generation path calls __rate_control_send_low() with a
zero rate_mask (rc_rateidx_mask[band] == 0), the loop skips all rates
and triggers a WARN_ONCE even though there is no actual problem: the
rate index defaults to 0, and the caller (rate_control_send_low)
subsequently corrects it via rc_send_low_basicrate() using
basic_rates. This scenario occurs when a user sets a per-band bitrate
mask via NL80211_CMD_SET_TX_BITRATE_MASK on a band different from
the one where a beacon is later sent (e.g., after CSA).
Fix by wrapping the WARN_ONCE in a check for rate_mask != 0. When
rate_mask is 0, no rates were filtered out — just the max rate index
was reached because no specific mask was applied — so the warning is
a false positive.
Fixes: 2103dec14792 ("mac80211: select and adjust bitrates according to channel mode")
Signed-off-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn>
---
net/mac80211/rate.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index ba1a3aa3f5d4..5cafc5043f19 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -396,12 +396,13 @@ static void __rate_control_send_low(struct ieee80211_hw *hw,
info->control.rates[0].idx = i;
break;
}
- WARN_ONCE(i == sband->n_bitrates,
- "no supported rates for sta %pM (0x%x, band %d) in rate_mask 0x%x with flags 0x%x\n",
- sta ? sta->addr : NULL,
- sta ? sta->deflink.supp_rates[sband->band] : -1,
- sband->band,
- rate_mask, rate_flags);
+ if (rate_mask)
+ WARN_ONCE(i == sband->n_bitrates,
+ "no supported rates for sta %pM (0x%x, band %d) in rate_mask 0x%x with flags 0x%x\n",
+ sta ? sta->addr : NULL,
+ sta ? sta->deflink.supp_rates[sband->band] : -1,
+ sband->band,
+ rate_mask, rate_flags);
info->control.rates[0].count =
(info->flags & IEEE80211_TX_CTL_NO_ACK) ?
--
2.34.1
Found by fuzzing. Here is the report:
------------[ cut here ]------------
no supported rates for sta (null) (0xffffffff, band 0) in rate_mask 0x0 with flags 0x0
WARNING: net/mac80211/rate.c:406 at __rate_control_send_low+0x20f/0x260 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/rate.c:401, CPU#0: swapper/0/0
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G L 7.0.10 #2 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:__rate_control_send_low+0x249/0x260 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/rate.c:401
Code: 10 41 8b 94 85 d4 00 00 00 eb 0e e8 e1 18 14 fc ba ff ff ff ff 48 8b 0c 24 8b 49 10 4c 89 f7 4c 89 ee 44 8b 44 24 0c 41 89 e9 <67> 48 0f b9 3a e9 40 ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00
RSP: 0018:ffa0000000003a78 EFLAGS: 00010246
RAX: ffffffff855306ef RBX: 000000000000000c RCX: 0000000000000000
RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff877d9fa0
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000002 R11: ffffffff8702d780 R12: 0000000000000800
R13: 0000000000000000 R14: ffffffff877d9fa0 R15: ff11000018fba128
FS: 0000000000000000(0000) GS:ff110000f40c5000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f23ffc CR3: 0000000023fe1000 CR4: 0000000000751ef0
PKRU: 55555554
Call Trace:
<IRQ>
rate_control_send_low+0xae/0x240 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/rate.c:429
rate_control_get_rate+0x6f/0x1c0 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/rate.c:943
ieee80211_beacon_get_finish+0x1f2/0x230 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/tx.c:5367
__ieee80211_beacon_get_ap home/zzzrrll/tmp/linux-7.0.10/net/mac80211/tx.c:5470 [inline]
ieee80211_beacon_get_ap+0xb94/0xc40 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/tx.c:5532
__ieee80211_beacon_get+0x938/0xa80 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/tx.c:5638
ieee80211_beacon_get_tim+0x60/0x150 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/tx.c:5780
ieee80211_beacon_get home/zzzrrll/tmp/linux-7.0.10/include/net/mac80211.h:5720 [inline]
mac80211_hwsim_beacon_tx+0x1bc/0x350 home/zzzrrll/tmp/linux-7.0.10/drivers/net/wireless/virtual/mac80211_hwsim.c:2361
__iterate_interfaces+0x1af/0x290 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/util.c:760
ieee80211_iterate_active_interfaces_atomic+0x32/0x40 home/zzzrrll/tmp/linux-7.0.10/net/mac80211/util.c:796
mac80211_hwsim_beacon+0x63/0xd0 home/zzzrrll/tmp/linux-7.0.10/drivers/net/wireless/virtual/mac80211_hwsim.c:2395
__run_hrtimer home/zzzrrll/tmp/linux-7.0.10/kernel/time/hrtimer.c:1790 [inline]
__hrtimer_run_queues+0x168/0x3b0 home/zzzrrll/tmp/linux-7.0.10/kernel/time/hrtimer.c:1854
hrtimer_run_softirq+0xa3/0x1f0 home/zzzrrll/tmp/linux-7.0.10/kernel/time/hrtimer.c:1871
handle_softirqs+0xdc/0x2d0 home/zzzrrll/tmp/linux-7.0.10/kernel/softirq.c:622
__do_softirq home/zzzrrll/tmp/linux-7.0.10/kernel/softirq.c:656 [inline]
invoke_softirq home/zzzrrll/tmp/linux-7.0.10/kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x44/0xd0 home/zzzrrll/tmp/linux-7.0.10/kernel/softirq.c:723
instr_sysvec_apic_timer_interrupt home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x76/0x90 home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/apic/apic.c:1056
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 home/zzzrrll/tmp/linux-7.0.10/arch/x86/include/asm/idtentry.h:697
RIP: 0010:pv_native_safe_halt+0x13/0x20 home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/paravirt.c:63
Code: ee 27 83 fb cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d a3 1c 15 00 f3 0f 1e fa fb f4 <e9> c3 27 83 fb cc cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffffff87003e88 EFLAGS: 00000212
RAX: ff110000f40c5000 RBX: 0000000000000000 RCX: 4000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000002d5c79c
RBP: 0000000000000000 R08: ffffffff81606126 R09: 0000000000000012
R10: 000001f47d45d440 R11: ffffffff813a87f0 R12: 0000000000000000
R13: ffffffff8994f020 R14: ffffffff8702d780 R15: 0000000000000000
arch_safe_halt home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/process.c:766 [inline]
default_idle+0x9/0x10 home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/process.c:767
default_idle_call+0x3c/0x60 home/zzzrrll/tmp/linux-7.0.10/kernel/sched/idle.c:122
cpuidle_idle_call home/zzzrrll/tmp/linux-7.0.10/kernel/sched/idle.c:199 [inline]
do_idle+0x18f/0x2c0 home/zzzrrll/tmp/linux-7.0.10/kernel/sched/idle.c:352
cpu_startup_entry+0x25/0x30 home/zzzrrll/tmp/linux-7.0.10/kernel/sched/idle.c:451
rest_init+0xc0/0xc0 home/zzzrrll/tmp/linux-7.0.10/init/main.c:760
start_kernel+0x34f/0x380 home/zzzrrll/tmp/linux-7.0.10/init/main.c:1209
x86_64_start_reservations+0x24/0x30 home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/head64.c:310
x86_64_start_kernel+0x109/0x110 home/zzzrrll/tmp/linux-7.0.10/arch/x86/kernel/head64.c:291
common_startup_64+0x13e/0x147
</TASK>
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess), 1 bytes skipped:
0: 41 8b 94 85 d4 00 00 mov 0xd4(%r13,%rax,4),%edx
7: 00
8: eb 0e jmp 0x18
a: e8 e1 18 14 fc call 0xfc1418f0
f: ba ff ff ff ff mov $0xffffffff,%edx
14: 48 8b 0c 24 mov (%rsp),%rcx
18: 8b 49 10 mov 0x10(%rcx),%ecx
1b: 4c 89 f7 mov %r14,%rdi
1e: 4c 89 ee mov %r13,%rsi
21: 44 8b 44 24 0c mov 0xc(%rsp),%r8d
26: 41 89 e9 mov %ebp,%r9d
* 29: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2e: e9 40 ff ff ff jmp 0xffffff73
33: 66 data16
34: 66 data16
35: 66 data16
36: 66 data16
37: 2e cs
38: 0f .byte 0xf
39: 1f (bad)
3a: 84 00 test %al,(%rax)
3c: 00 00 add %al,(%rax)
^ permalink raw reply related
* RE: [PATCH v2 rtw-next 2/2] wifi: rtw89: usb: add serial_number and uuid sysfs attributes for 0x28de:0x2432
From: Johnson Tsai @ 2026-05-27 11:46 UTC (permalink / raw)
To: Greg KH, Ping-Ke Shih
Cc: linux-wireless@vger.kernel.org, driver-core@lists.linux.dev,
johannes@sipsolutions.net, Mh_chen, charlesl@valvesoftware.com,
sabae@valvesoftware.com
In-Reply-To: <2026052524-ammonia-zeppelin-9edb@gregkh>
On : Tuesday, May 26, 2026 3:33, Greg KH wrote:
> On Mon, May 25, 2026 at 04:51:48PM +0800, Ping-Ke Shih wrote:
> > From: Johnson Tsai <wenjie.tsai@realtek.com>
> >
> > Expose the device's Serial Number (SN) and UUID from EFUSE via two
> > read-only sysfs attributes, `serial_number` and `uuid`, on the
> > ieee80211 phy device under the `rtw89_usb` attribute group.
> >
> > This hardware identification information is essential for user-space
> > applications to uniquely identify, track, and manage specific Wi-Fi
> > adapters. For example, in automated factory provisioning or device
> > management systems, user-space tools rely on the EFUSE serial number
> > and UUID to bind configurations to specific physical adapters.
> > Currently, standard wireless APIs do not expose this low-level
> > hardware information, making these sysfs nodes the only viable
> > solution for user space to extract this data.
> >
> > The attributes are gated behind a new RTW89_QUIRK_HW_INFO_SYSFS
> quirk,
> > enabled only for the VID 0x28de / PID 0x2432 device via the
> > dev_id_quirks field in rtw89_driver_info.
> >
> > Example usage from user-space:
> > $ cat /sys/class/ieee80211/phy0/rtw89_usb/serial_number
> > 3642000123
> > $ cat /sys/class/ieee80211/phy0/rtw89_usb/uuid
> > aaec2b7c-0a55-4727-8de0-b30febccbbaa
> >
> > Cc: Elliot Saba <sabae@valvesoftware.com>
> > Cc: Charles Lohr <charlesl@valvesoftware.com>
> > Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
> > Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> > ---
> > .../ABI/testing/sysfs-class-ieee80211-rtw89 | 24 ++++++++
> > drivers/net/wireless/realtek/rtw89/core.h | 6 ++
> > drivers/net/wireless/realtek/rtw89/rtw8852c.c | 10 ++++
> > drivers/net/wireless/realtek/rtw89/rtw8852c.h | 6 +-
> > .../net/wireless/realtek/rtw89/rtw8852cu.c | 12 +++-
> > drivers/net/wireless/realtek/rtw89/usb.c | 57 +++++++++++++++++++
> > 6 files changed, 113 insertions(+), 2 deletions(-) create mode
> > 100644 Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
> > b/Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
> > new file mode 100644
> > index 000000000000..7dfdce08a42f
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
> > @@ -0,0 +1,24 @@
> > +What: /sys/class/ieee80211/phyX/rtw89_usb/serial_number
> > +Date: May 2026
> > +Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-
> wireless@vger.kernel.org
> > +Description: (Read) Serial number burned into EFUSE of the RTL8852CU-
> based
> > + USB Wi-Fi adapter. Only present on devices that set the
> > + RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
> > + PID 0x2432).
> > +
> > + Format: %10phN (5 raw bytes printed as 10 lowercase hex
> > + digits, no separators).
> > +
> > + Example: 3642000123
> > +
> > +What: /sys/class/ieee80211/phyX/rtw89_usb/uuid
> > +Date: May 2026
> > +Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-
> wireless@vger.kernel.org
> > +Description: (Read) UUID burned into EFUSE of the RTL8852CU-based USB
> Wi-Fi
> > + adapter. Only present on devices that set the
> > + RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
> > + PID 0x2432).
> > +
> > + Format: %pUb (RFC 4122 UUID in lowercase with hyphens).
> > +
> > + Example: aaec2b7c-0a55-4727-8de0-b30febccbbaa
> > diff --git a/drivers/net/wireless/realtek/rtw89/core.h
> > b/drivers/net/wireless/realtek/rtw89/core.h
> > index e687216da5b6..09f17d958075 100644
> > --- a/drivers/net/wireless/realtek/rtw89/core.h
> > +++ b/drivers/net/wireless/realtek/rtw89/core.h
> > @@ -3615,6 +3615,9 @@ struct rtw89_sta_link {
> > u32 data_tx_cnt_lmt:6;
> > };
> >
> > +#define RTW89_EFUSE_SN_LEN 5
> > +#define RTW89_EFUSE_UUID_LEN 16
> > +
> > struct rtw89_efuse {
> > bool valid;
> > bool power_k_valid;
> > @@ -3625,6 +3628,8 @@ struct rtw89_efuse {
> > u8 adc_td;
> > u8 bt_setting_2;
> > u8 bt_setting_3;
> > + u8 sn[RTW89_EFUSE_SN_LEN];
> > + u8 uuid[RTW89_EFUSE_UUID_LEN];
> > };
> >
> > struct rtw89_phy_rate_pattern {
> > @@ -5373,6 +5378,7 @@ enum rtw89_quirks {
> > RTW89_QUIRK_PCI_BER,
> > RTW89_QUIRK_THERMAL_PROT_120C,
> > RTW89_QUIRK_THERMAL_PROT_110C,
> > + RTW89_QUIRK_HW_INFO_SYSFS,
> >
> > NUM_OF_RTW89_QUIRKS,
> > };
> > diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852c.c
> > b/drivers/net/wireless/realtek/rtw89/rtw8852c.c
> > index 7bb1264bcaef..3861cce42b1b 100644
> > --- a/drivers/net/wireless/realtek/rtw89/rtw8852c.c
> > +++ b/drivers/net/wireless/realtek/rtw89/rtw8852c.c
> > @@ -621,6 +621,15 @@ static void
> rtw8852c_efuse_parsing_gain_offset(struct rtw89_dev *rtwdev,
> > gain->offset_valid = valid;
> > }
> >
> > +static void rtw8852c_efuse_copy_sn_uuid_usb(struct rtw89_dev *rtwdev,
> > + const struct rtw8852c_efuse
> > +*map) {
> > + struct rtw89_efuse *efuse = &rtwdev->efuse;
> > +
> > + memcpy(efuse->sn, map->u.sn, sizeof(efuse->sn));
> > + memcpy(efuse->uuid, map->u.uuid, sizeof(efuse->uuid)); }
> > +
> > static int rtw8852c_read_efuse(struct rtw89_dev *rtwdev, u8 *log_map,
> > enum rtw89_efuse_block block) { @@
> > -640,6 +649,7 @@ static int rtw8852c_read_efuse(struct rtw89_dev
> *rtwdev, u8 *log_map,
> > break;
> > case RTW89_HCI_TYPE_USB:
> > ether_addr_copy(efuse->addr, map->u.mac_addr);
> > + rtw8852c_efuse_copy_sn_uuid_usb(rtwdev, map);
> > break;
> > default:
> > return -ENOTSUPP;
> > diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852c.h
> > b/drivers/net/wireless/realtek/rtw89/rtw8852c.h
> > index 8585921ac6c4..b1d7c354c18e 100644
> > --- a/drivers/net/wireless/realtek/rtw89/rtw8852c.h
> > +++ b/drivers/net/wireless/realtek/rtw89/rtw8852c.h
> > @@ -13,7 +13,11 @@
> > struct rtw8852c_u_efuse {
> > u8 rsvd[0x88];
> > u8 mac_addr[ETH_ALEN];
> > -};
> > + u8 rsvd1[8];
> > + u8 sn[RTW89_EFUSE_SN_LEN];
> > + u8 rsvd2[29];
> > + u8 uuid[RTW89_EFUSE_UUID_LEN];
> > +} __packed;
> >
> > struct rtw8852c_e_efuse {
> > u8 mac_addr[ETH_ALEN];
> > diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852cu.c
> > b/drivers/net/wireless/realtek/rtw89/rtw8852cu.c
> > index 8f89f9a31455..81ee96b0a048 100644
> > --- a/drivers/net/wireless/realtek/rtw89/rtw8852cu.c
> > +++ b/drivers/net/wireless/realtek/rtw89/rtw8852cu.c
> > @@ -39,6 +39,16 @@ static const struct rtw89_driver_info
> rtw89_8852cu_info = {
> > },
> > };
> >
> > +static const struct rtw89_driver_info rtw89_8852cu_valve_info = {
> > + .chip = &rtw8852c_chip_info,
> > + .variant = NULL,
> > + .quirks = NULL,
> > + .dev_id_quirks = BIT(RTW89_QUIRK_HW_INFO_SYSFS),
> > + .bus = {
> > + .usb = &rtw8852c_usb_info,
> > + },
> > +};
> > +
> > static const struct usb_device_id rtw_8852cu_id_table[] = {
> > { USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03a6, 0xff, 0xff, 0xff),
> > .driver_info = (kernel_ulong_t)&rtw89_8852cu_info }, @@ -53,7
> > +63,7 @@ static const struct usb_device_id rtw_8852cu_id_table[] = {
> > { USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0x991d, 0xff, 0xff, 0xff),
> > .driver_info = (kernel_ulong_t)&rtw89_8852cu_info },
> > { USB_DEVICE_AND_INTERFACE_INFO(0x28de, 0x2432, 0xff, 0xff, 0xff),
> > - .driver_info = (kernel_ulong_t)&rtw89_8852cu_info },
> > + .driver_info = (kernel_ulong_t)&rtw89_8852cu_valve_info },
> > { USB_DEVICE_AND_INTERFACE_INFO(0x2c7c, 0x8206, 0xff, 0xff, 0xff),
> > .driver_info = (kernel_ulong_t)&rtw89_8852cu_info },
> > { USB_DEVICE_AND_INTERFACE_INFO(0x35b2, 0x0502, 0xff, 0xff,
> > 0xff), diff --git a/drivers/net/wireless/realtek/rtw89/usb.c
> > b/drivers/net/wireless/realtek/rtw89/usb.c
> > index 88d7ec200837..7e23d0a32025 100644
> > --- a/drivers/net/wireless/realtek/rtw89/usb.c
> > +++ b/drivers/net/wireless/realtek/rtw89/usb.c
> > @@ -1059,6 +1059,61 @@ static void rtw89_usb_intf_deinit(struct
> rtw89_dev *rtwdev,
> > usb_set_intfdata(intf, NULL);
> > }
> >
> > +static ssize_t serial_number_show(struct device *dev,
> > + struct device_attribute *attr, char
> > +*buf) {
> > + struct wiphy *wiphy = container_of(dev, struct wiphy, dev);
> > + struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
> > + struct rtw89_dev *rtwdev = hw->priv;
> > + struct rtw89_efuse *efuse = &rtwdev->efuse;
> > +
> > + return sysfs_emit(buf, "%*phN\n",
> > + (int)sizeof(efuse->sn), efuse->sn); } static
> > +DEVICE_ATTR_RO(serial_number);
> > +
> > +static ssize_t uuid_show(struct device *dev,
> > + struct device_attribute *attr, char *buf) {
> > + struct wiphy *wiphy = container_of(dev, struct wiphy, dev);
> > + struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
> > + struct rtw89_dev *rtwdev = hw->priv;
> > + struct rtw89_efuse *efuse = &rtwdev->efuse;
> > +
> > + return sysfs_emit(buf, "%pUb\n", efuse->uuid); } static
> > +DEVICE_ATTR_RO(uuid);
> > +
> > +static struct attribute *rtw89_usb_attrs[] = {
> > + &dev_attr_serial_number.attr,
> > + &dev_attr_uuid.attr,
> > + NULL,
> > +};
> > +
> > +static const struct attribute_group rtw89_usb_group = {
> > + .name = "rtw89_usb",
> > + .attrs = rtw89_usb_attrs,
> > +};
> > +__ATTRIBUTE_GROUPS(rtw89_usb);
> > +
> > +static void rtw89_usb_sysfs_create(struct rtw89_dev *rtwdev) {
> > + int ret;
> > +
> > + if (!test_bit(RTW89_QUIRK_HW_INFO_SYSFS, rtwdev->quirks))
> > + return;
> > +
> > + ret = sysfs_create_groups(&rtwdev->hw->wiphy->dev.kobj,
> > + rtw89_usb_groups);
>
> You just raced with userspace and lost, please use the is_visable callback
> instead, and make this the default group attributes.
Thanks for the explanation.
I see the problem now. The user space sysfs path remains identical,
but the timing and mechanism are different. Using dev.kobj requires
manual creation/removal outside the hardware lifecycle, whereas
setting dev.groups will automatically handle creation/removal within
the same hardware lifecycle to avoid the race condition.
I will remove the manual sysfs creation and switch to default group
attributes in v3.
Specifically, the visibility of the entire group will be managed via the macro:
/* Control the visibility of the entire attribute group */
.is_visible = SYSFS_GROUP_VISIBLE(rtw89_usb),
And the group will be attached to the wiphy device default groups before registration:
/* Attach the attribute group to the wiphy device */
rtwdev->hw->wiphy->dev.groups = rtw89_usb_groups;
Thanks,
Johnson
^ 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