]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
3 weeks agoMerge tag 'rtw-next-2025-11-21-v2' of https://github.com/pkshih/rtw
Johannes Berg [Mon, 24 Nov 2025 12:01:02 +0000 (13:01 +0100)] 
Merge tag 'rtw-next-2025-11-21-v2' of https://github.com/pkshih/rtw

Ping-Ke Shih says:
==================
rtw-next patches for v6.19

Main changes are about rtw89 USB support, which two USB devices are added
with proper TX status, and other notable items are listed below.

rtl8xxxu:

 - fix 40MHz bandwidth connection

rtw89:

 - support USB devices RTL8852AU and RTL8852CU

 - report TX status from air for USB devices

 - resolve racing between processes of TX and TX report

 - resolve racing of skb queue of C2H events

 - support injected packets with bandwidth and data rate

 - more materials for coming RTL8922DE
==================

Link: https://patch.msgid.link/45eed1763a354460acba15a8e69f9e3e@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: rtl8xxxu: Enable 40 MHz width by default
Bitterblue Smith [Thu, 20 Nov 2025 14:13:49 +0000 (16:13 +0200)] 
wifi: rtl8xxxu: Enable 40 MHz width by default

40 MHz support is hidden behind the ht40_2g module parameter with
this comment:

/*
 * Some APs will negotiate HT20_40 in a noisy environment leading
 * to miserable performance. Rather than defaulting to this, only
 * enable it if explicitly requested at module load time.
 */

This parameter was added in commit 26f1fad29ad9 ("New driver:
rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU
and the RTL8192CU family. It's entirely possible the miserable
performance was due to mistakes in the channel switching function,
which were fixed in a previous patch.

Delete the ht40_2g module parameter. If someone still needs to
disable 40 MHz support, cfg80211 has the module parameter
cfg80211_disable_40mhz_24ghz. That works too.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/4f053103-adfd-4ead-acb3-ef69127a4bab@gmail.com
4 weeks agowifi: rtl8xxxu: Fix RX channel width reported by RTL8192FU
Bitterblue Smith [Thu, 20 Nov 2025 14:13:17 +0000 (16:13 +0200)] 
wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FU

The other chips report the RX channel width in the RX descriptor,
but this one doesn't.

Get the RX channel width from the PHY status.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1c6c1fd4-92f6-4327-a24e-f0747ab21819@gmail.com
4 weeks agowifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BU
Bitterblue Smith [Thu, 20 Nov 2025 14:12:35 +0000 (16:12 +0200)] 
wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BU

rtl8xxxu_gen2_config_channel() was missing the subchannel setting.
This function is used by RTL8192EU and RTL8723BU.

This change seems to make no difference in my testing on channel 13
with either chip.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/a5de8d39-45c1-4667-ab4c-7109de6eb13d@gmail.com
4 weeks agowifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz width
Bitterblue Smith [Thu, 20 Nov 2025 14:11:58 +0000 (16:11 +0200)] 
wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz width

Set the required fields in the TX descriptor to allow these chips to
transmit with 40 MHz channel width when the access point supports it.

Tested only with RTL8192CU, but these settings are identical for
RTL8723AU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/30d95228-69b2-48f9-8854-c98d2408c4d3@gmail.com
4 weeks agowifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU
Bitterblue Smith [Thu, 20 Nov 2025 14:10:01 +0000 (16:10 +0200)] 
wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU

Flip the response rate subchannel. It was backwards, causing low
speeds when using 40 MHz channel width. "iw dev ... station dump"
showed a low RX rate, 11M or less.

Also fix the channel width field of RF6052_REG_MODE_AG.

Tested only with RTL8192CU, but these settings are identical for
RTL8723AU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1f46571d-855b-43e1-8bfc-abacceb96043@gmail.com
4 weeks agowifi: rtw89: 8852a: correct field mask of reset DAC/ADC FIFO
Ping-Ke Shih [Thu, 20 Nov 2025 03:10:43 +0000 (11:10 +0800)] 
wifi: rtw89: 8852a: correct field mask of reset DAC/ADC FIFO

The field mask should be bits 16-31, but suddenly use wrong bits 24-31,
rarely causing a little performance degraded if DAC/DAC FIFO stays on
an unexpected state.

Found this by Geert who works on bit field functions.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Closes: https://lore.kernel.org/linux-wireless/CAMuHMdVt+5yOA6tuasX4KQgZud5wtRwu0A15UkEfQJbcd_xvVw@mail.gmail.com/
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251120031044.12493-2-pkshih@realtek.com
4 weeks agowifi: rtw88: add WQ_UNBOUND to alloc_workqueue users
Marco Crivellari [Tue, 18 Nov 2025 10:20:32 +0000 (11:20 +0100)] 
wifi: rtw88: add WQ_UNBOUND to alloc_workqueue users

Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

This change adds the WQ_UNBOUND flag to explicitly request
alloc_workqueue() to be unbound, because this specific workload has no
benefit being per-cpu.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251118102032.54375-3-marco.crivellari@suse.com
4 weeks agowifi: rtlwifi: add WQ_UNBOUND to alloc_workqueue users
Marco Crivellari [Tue, 18 Nov 2025 10:20:31 +0000 (11:20 +0100)] 
wifi: rtlwifi: add WQ_UNBOUND to alloc_workqueue users

Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

This change adds the WQ_UNBOUND flag to explicitly request
alloc_workqueue() to be unbound, because this specific workload has no
benefit being per-cpu.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251118102032.54375-2-marco.crivellari@suse.com
4 weeks agowifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()
Seungjin Bae [Tue, 18 Nov 2025 01:32:59 +0000 (20:32 -0500)] 
wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()

The rtl8187_rx_cb() calculates the rx descriptor header address
by subtracting its size from the skb tail pointer.
However, it does not validate if the received packet
(skb->len from urb->actual_length) is large enough to contain this
header.

If a truncated packet is received, this will lead to a buffer
underflow, reading memory before the start of the skb data area,
and causing a kernel panic.

Add length checks for both rtl8187 and rtl8187b descriptor headers
before attempting to access them, dropping the packet cleanly if the
check fails.

Fixes: 6f7853f3cbe4 ("rtl8187: change rtl8187_dev.c to support RTL8187B (part 2)")
Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251118013258.1789949-2-eeodqql09@gmail.com
4 weeks agowifi: mac80211: refactor CMAC packet handlers
Chien Wong [Thu, 13 Nov 2025 14:05:11 +0000 (22:05 +0800)] 
wifi: mac80211: refactor CMAC packet handlers

Merge CMAC-128 and CMAC-256 handlers since they are almost the same.
This removes duplication.

The comment 'MIC = AES-128-CMAC(IGTK, AAD ...' is out-dated since CMAC
is also used with BIGTK, as is the comment for CMAC-256. Simply remove
the comments.

Tested-on: mac80211_hwsim

Signed-off-by: Chien Wong <m@xv97.com>
Link: https://patch.msgid.link/20251113140511.48658-6-m@xv97.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: mac80211: refactor CMAC crypt functions
Chien Wong [Thu, 13 Nov 2025 14:05:10 +0000 (22:05 +0800)] 
wifi: mac80211: refactor CMAC crypt functions

ieee80211_aes_cmac() and ieee80211_aes_cmac_256() are almost the same.
Merge them. This removes duplication.

Signed-off-by: Chien Wong <m@xv97.com>
Link: https://patch.msgid.link/20251113140511.48658-5-m@xv97.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: mac80211: utilize the newly defined CMAC constants
Chien Wong [Thu, 13 Nov 2025 14:05:09 +0000 (22:05 +0800)] 
wifi: mac80211: utilize the newly defined CMAC constants

Make use of the added constants to reduce duplication.

Signed-off-by: Chien Wong <m@xv97.com>
Link: https://patch.msgid.link/20251113140511.48658-4-m@xv97.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: mac80211: add generic MMIE struct defines
Chien Wong [Thu, 13 Nov 2025 14:05:08 +0000 (22:05 +0800)] 
wifi: mac80211: add generic MMIE struct defines

The added struct is needed when writing generic handler for both CMAC-128
and CMAC-256.

Signed-off-by: Chien Wong <m@xv97.com>
Link: https://patch.msgid.link/20251113140511.48658-3-m@xv97.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: mac80211: fix CMAC functions not handling errors
Chien Wong [Thu, 13 Nov 2025 14:05:07 +0000 (22:05 +0800)] 
wifi: mac80211: fix CMAC functions not handling errors

The called hash functions could fail thus we should check return values.

Fixes: 26717828b75d ("mac80211: aes-cmac: switch to shash CMAC driver")
Signed-off-by: Chien Wong <m@xv97.com>
Link: https://patch.msgid.link/20251113140511.48658-2-m@xv97.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: ipw2x00: replace use of system_wq with system_percpu_wq
Marco Crivellari [Thu, 20 Nov 2025 09:45:24 +0000 (10:45 +0100)] 
wifi: ipw2x00: replace use of system_wq with system_percpu_wq

This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:

   commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
   commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.

Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:

   system_wq -> system_percpu_wq
   system_unbound_wq -> systemd_dfl_wq

This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251120094524.45264-1-marco.crivellari@suse.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: cfg80211: replace use of system_unbound_wq with system_dfl_wq
Marco Crivellari [Thu, 13 Nov 2025 16:20:32 +0000 (17:20 +0100)] 
wifi: cfg80211: replace use of system_unbound_wq with system_dfl_wq

Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

Switch to using system_dfl_wq because system_unbound_wq is going away as part of
a workqueue restructuring.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Link: https://patch.msgid.link/20251113162032.394804-4-marco.crivellari@suse.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: cw1200: add WQ_PERCPU to alloc_workqueue users
Marco Crivellari [Thu, 13 Nov 2025 16:20:31 +0000 (17:20 +0100)] 
wifi: cw1200: add WQ_PERCPU to alloc_workqueue users

Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Link: https://patch.msgid.link/20251113162032.394804-3-marco.crivellari@suse.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: wfx: add WQ_PERCPU to alloc_workqueue users
Marco Crivellari [Thu, 13 Nov 2025 16:08:25 +0000 (17:08 +0100)] 
wifi: wfx: add WQ_PERCPU to alloc_workqueue users

Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://patch.msgid.link/20251113160825.383883-1-marco.crivellari@suse.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: qtnfmac: add WQ_PERCPU to alloc_workqueue users
Marco Crivellari [Thu, 13 Nov 2025 16:00:35 +0000 (17:00 +0100)] 
wifi: qtnfmac: add WQ_PERCPU to alloc_workqueue users

Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Link: https://patch.msgid.link/20251113160035.376524-1-marco.crivellari@suse.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: cfg80211: Add support for 6GHz AP role not relevant AP type
Pagadala Yesu Anjaneyulu [Wed, 12 Nov 2025 09:10:23 +0000 (11:10 +0200)] 
wifi: cfg80211: Add support for 6GHz AP role not relevant AP type

Add IEEE80211_6GHZ_CTRL_REG_AP_ROLE_NOT_RELEVANT
and map it to IEEE80211_REG_LPI_AP for safe regulatory compliance
when AP role classification is not applicable.
Use LPI as safe fallback to prevent power limit violations.

Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251112110828.856283677cc7.I36138a34847c3b4e680974bf347dde844448f3bc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 weeks agowifi: rtw89: Add default ID 0bda:b831 for RTL8831BU
Zenm Chen [Sun, 16 Nov 2025 23:44:03 +0000 (07:44 +0800)] 
wifi: rtw89: Add default ID 0bda:b831 for RTL8831BU

Add 0bda:b831 for RTL8831BU-based adapters that use this default ID.

Tested with TOTOLINK X900USM in station mode very briefly.

Signed-off-by: Zenm Chen <zenmchen@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251116234403.8803-1-zenmchen@gmail.com
4 weeks agowifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()
Abdun Nihaal [Fri, 14 Nov 2025 09:45:26 +0000 (15:15 +0530)] 
wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()

In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA
allocations in a loop. When an allocation fails, the previously
successful allocations are not freed on exit.

Fix that by jumping to err_free_rings label on error, which calls
rtl8180_free_rx_ring() to free the allocations. Remove the free of
rx_ring in rtl8180_init_rx_ring() error path, and set the freed
priv->rx_buf entry to null, to avoid double free.

Fixes: f653211197f3 ("Add rtl8180 wireless driver")
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114094527.79842-1-nihaal@cse.iitm.ac.in
4 weeks agowifi: rtw89: use separated function to set RX filter
Ping-Ke Shih [Thu, 13 Nov 2025 05:34:59 +0000 (13:34 +0800)] 
wifi: rtw89: use separated function to set RX filter

Normally use rtw89_write32_mask() with a consecutive bit mask, but mask of
RX filter B_AX_RX_FLTR_CFG_MASK is bits 31-22 and 15-0, which excludes bits
of B_AX_RX_MPDU_MAX_LEN_MASK (bits 21-16).

Though the original logic is well to set RX filter, change it to a separate
function to avoid the tricky design.

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251113053459.34995-1-pkshih@realtek.com
4 weeks agowifi: rtw89: correct user macid mask of RX info for RTL8922D
Chih-Kang Chang [Fri, 14 Nov 2025 06:01:28 +0000 (14:01 +0800)] 
wifi: rtw89: correct user macid mask of RX info for RTL8922D

The user MAC ID mask of RX info in MAC PPDU for RTL8922A and RTL8922D
is different, correct it accordingly.

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-15-pkshih@realtek.com
4 weeks agowifi: rtw89: update format of addr cam H2C command
Chih-Kang Chang [Fri, 14 Nov 2025 06:01:27 +0000 (14:01 +0800)] 
wifi: rtw89: update format of addr cam H2C command

The addr cam H2C command is to tell firmware the addr related info.
For RTL8922D and RTL8922A after firmware version 0.35.84.0, the addr cam
must be updated with update mode to avoid clearing previously set
fields. Update it accordingly.

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-14-pkshih@realtek.com
4 weeks agowifi: rtw89: add addr cam H2C command v1
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:26 +0000 (14:01 +0800)] 
wifi: rtw89: add addr cam H2C command v1

The coming RTL8922D uses different format of address CAM command, so add
the new format accordingly.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-13-pkshih@realtek.com
4 weeks agowifi: rtw89: fill addr cam H2C command by struct
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:25 +0000 (14:01 +0800)] 
wifi: rtw89: fill addr cam H2C command by struct

The addr cam is used to tell firmware the MAC address and BSSID associated
to connected stations. Use struct instead of macros with pointer arithmetic
to fill the data.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-12-pkshih@realtek.com
4 weeks agowifi: rtw89: align RA H2C format v1 for RTL8922A
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:24 +0000 (14:01 +0800)] 
wifi: rtw89: align RA H2C format v1 for RTL8922A

For RTL8922A, the bits [16:31] of word 3 of v1 format isn't as WiFi 6
chips. Instead, it only needs to fill additional band type and partial
bandwidth ER.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-11-pkshih@realtek.com
4 weeks agowifi: rtw89: fw: print band and port where beacon update on
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:23 +0000 (14:01 +0800)] 
wifi: rtw89: fw: print band and port where beacon update on

The C2H event of BCN_UPD_DONE is to notify driver that firmware changes
beacon content on certain band/port asked by driver. Print the
notification for debug purpose for now.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-10-pkshih@realtek.com
4 weeks agowifi: rtw89: phy: ignore DCFO if not defined in chip_info
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:22 +0000 (14:01 +0800)] 
wifi: rtw89: phy: ignore DCFO if not defined in chip_info

For WiFi 7 chips, DCFO (digital carrier frequency offset) feature isn't
supported, so the corresponding registers aren't defined in chip_info.
Check and ignore this feature accordingly.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-9-pkshih@realtek.com
4 weeks agowifi: rtw89: phy: consider type 15 in BB gain table
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:21 +0000 (14:01 +0800)] 
wifi: rtw89: phy: consider type 15 in BB gain table

BB gain table is a table to configure gain for certain channels. Newly
added type 15 is considered to write registers accordingly.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-8-pkshih@realtek.com
4 weeks agowifi: rtw89: mac: update wcpu_on to download firmware for RTL8922D
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:20 +0000 (14:01 +0800)] 
wifi: rtw89: mac: update wcpu_on to download firmware for RTL8922D

The RTL8922D does more settings before downloading firmware, so add them
accordingly. Also, update the missed settings for RTL8922A.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-7-pkshih@realtek.com
4 weeks agowifi: rtw89: mac: remove undefined bit B_BE_PPDU_MAC_INFO
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:19 +0000 (14:01 +0800)] 
wifi: rtw89: mac: remove undefined bit B_BE_PPDU_MAC_INFO

The bit is defined during test chip development, but formal chips don't
have this. Remove it.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-6-pkshih@realtek.com
4 weeks agowifi: rtw89: phy: calling BB pre-init by chips with/without BB MCU
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:18 +0000 (14:01 +0800)] 
wifi: rtw89: phy: calling BB pre-init by chips with/without BB MCU

The existing flow is doing BB pre-init before downloading BB MCU firmware,
because existing chip RTL8922A has BB MCU. However, the coming chips don't
have this, and BB pre-init configuring registers can affect downloading
WiFi-CPU firmware. Therefore, calling BB pre-init afterward for new coming
chips without BB MCU.

For existing WiFi 6 chips, no BB pre-init. For RTL8922A, don't change
the logic.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-5-pkshih@realtek.com
4 weeks agowifi: rtw89: mac: separate pre-init code before downloading firmware
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:17 +0000 (14:01 +0800)] 
wifi: rtw89: mac: separate pre-init code before downloading firmware

Driver needs to initialize registers before downloading firmware, so
move pre-init part (power on) from original rtw89_mac_init(). The
consequence patches will add more pre-init codes before downloading
firmware.

Since rtw89_phy_init_bb_afe() is used by coming RTL8922D, don't change
logic at all for existing chips.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-4-pkshih@realtek.com
4 weeks agowifi: rtw89: fw: part size to download firmware by header info
Ping-Ke Shih [Fri, 14 Nov 2025 06:01:16 +0000 (14:01 +0800)] 
wifi: rtw89: fw: part size to download firmware by header info

The part size is the unit to download firmware piece by piece. Old chips
use 2020 bytes as a piece, but in new chips the part size is defined in
firmware header. Change to use the value dynamically.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-3-pkshih@realtek.com
4 weeks agowifi: rtw89: flush TX queue before deleting key
Chih-Kang Chang [Fri, 14 Nov 2025 06:01:15 +0000 (14:01 +0800)] 
wifi: rtw89: flush TX queue before deleting key

In the wpa_supplicant rekey flow, it sends an EAPOL packet 4/4 through
nl80211_tx_control_port() and triggers wake_tx_queue() in the driver.
Then, it sends nl80211_new_key() to configure a new key in mac80211.
However, in wake_tx_queue(), a workqueue is used to process the TX packet,
which might cause the driver to process the EAPOL packet later than
nl80211_new_key(). This results in the EAPOL packet 4/4 being transmitted
with the new key and IV, causing it to be dropped by the AP. Therefore,
needs to flush TX queue before deleting the old key to ensure that the
EAPOL 4/4 packet is transmitted using the old key.

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-2-pkshih@realtek.com
5 weeks agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Jakub Kicinski [Thu, 13 Nov 2025 20:32:50 +0000 (12:32 -0800)] 
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Cross-merge networking fixes after downstream PR (net-6.18-rc6).

No conflicts, adjacent changes in:

drivers/net/phy/micrel.c
  96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface")
  61b7ade9ba8c ("net: phy: micrel: Add support for non PTP SKUs for lan8814")

and a trivial one in tools/testing/selftests/drivers/net/Makefile.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoMerge tag 'net-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Linus Torvalds [Thu, 13 Nov 2025 19:20:25 +0000 (11:20 -0800)] 
Merge tag 'net-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Pull networking fixes from Paolo Abeni:
 "Including fixes from Bluetooth and Wireless. No known outstanding
  regressions.

  Current release - regressions:

   - eth:
      - bonding: fix mii_status when slave is down
      - mlx5e: fix missing error assignment in mlx5e_xfrm_add_state()

  Previous releases - regressions:

   - sched: limit try_bulk_dequeue_skb() batches

   - ipv4: route: prevent rt_bind_exception() from rebinding stale fnhe

   - af_unix: initialise scc_index in unix_add_edge()

   - netpoll: fix incorrect refcount handling causing incorrect cleanup

   - bluetooth: don't hold spin lock over sleeping functions

   - hsr: Fix supervision frame sending on HSRv0

   - sctp: prevent possible shift out-of-bounds

   - tipc: fix use-after-free in tipc_mon_reinit_self().

   - dsa: tag_brcm: do not mark link local traffic as offloaded

   - eth: virtio-net: fix incorrect flags recording in big mode

  Previous releases - always broken:

   - sched: initialize struct tc_ife to fix kernel-infoleak

   - wifi:
      - mac80211: reject address change while connecting
      - iwlwifi: avoid toggling links due to wrong element use

   - bluetooth: cancel mesh send timer when hdev removed

   - strparser: fix signed/unsigned mismatch bug

   - handshake: fix memory leak in tls_handshake_accept()

  Misc:

   - selftests: mptcp: fix some flaky tests"

* tag 'net-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (60 commits)
  hsr: Follow standard for HSRv0 supervision frames
  hsr: Fix supervision frame sending on HSRv0
  virtio-net: fix incorrect flags recording in big mode
  ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
  wifi: iwlwifi: mld: always take beacon ies in link grading
  wifi: iwlwifi: mvm: fix beacon template/fixed rate
  wifi: iwlwifi: fix aux ROC time event iterator usage
  net_sched: limit try_bulk_dequeue_skb() batches
  selftests: mptcp: join: properly kill background tasks
  selftests: mptcp: connect: trunc: read all recv data
  selftests: mptcp: join: userspace: longer transfer
  selftests: mptcp: join: endpoints: longer transfer
  selftests: mptcp: join: rm: set backup flag
  selftests: mptcp: connect: fix fallback note due to OoO
  ethtool: fix incorrect kernel-doc style comment in ethtool.h
  mlx5: Fix default values in create CQ
  Bluetooth: btrtl: Avoid loading the config file on security chips
  net/mlx5e: Fix potentially misleading debug message
  net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps
  net/mlx5e: Fix maxrate wraparound in threshold between units
  ...

5 weeks agonet: stmmac: always allocate mac_device_info
Russell King (Oracle) [Tue, 11 Nov 2025 11:26:44 +0000 (11:26 +0000)] 
net: stmmac: always allocate mac_device_info

The ->setup() method implemented by dwmac-loongson and dwmac-sun8i
allocate the mac_device_info structure, as does stmmac_hwif_init().
This makes no sense.

Have stmmac_hwif_init() always allocate this structure, and pass it to
the ->setup() method to initialise when it is provided. Rename this
method to "mac_setup" to more accurately describe what it is doing.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vImWK-0000000DrIx-28vO@rmk-PC.armlinux.org.uk
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agonet: stmmac: clean up stmmac_reset()
Russell King (Oracle) [Tue, 11 Nov 2025 11:26:39 +0000 (11:26 +0000)] 
net: stmmac: clean up stmmac_reset()

stmmac_reset() takes the stmmac_priv and an ioaddr. It has one call
site, which passes the priv pointer, and dereferences priv for the
ioaddr.

stmmac_reset() then checks whether priv is NULL. If it was, the caller
would have oopsed. Remove the checks for NULL, and move the dereference
for ioaddr into stmmac_reset().

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vImWF-0000000DrIr-1fmn@rmk-PC.armlinux.org.uk
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agoMerge branch 'hsr-send-correct-hsrv0-supervision-frames'
Paolo Abeni [Thu, 13 Nov 2025 14:55:06 +0000 (15:55 +0100)] 
Merge branch 'hsr-send-correct-hsrv0-supervision-frames'

Felix Maurer says:

====================
hsr: Send correct HSRv0 supervision frames

Hangbin recently reported that the hsr selftests were failing and noted
that the entries in the node table were not merged, i.e., had
00:00:00:00:00:00 as MacAddressB forever [1].

This failure only occured with HSRv0 because it was not sending
supervision frames anymore. While debugging this I found that we were
not really following the HSRv0 standard for the supervision frames we
sent, so I additionally made a few changes to get closer to the standard
and restore a more correct behavior we had a while ago.

The selftests can still fail because they take a while and run into the
timeout. I did not include a change of the timeout because I have more
improvements to the selftests mostly ready that change the test duration
but are net-next material.

[1]: https://lore.kernel.org/netdev/aMONxDXkzBZZRfE5@fedora/
====================

Link: https://patch.msgid.link/cover.1762876095.git.fmaurer@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agohsr: Follow standard for HSRv0 supervision frames
Felix Maurer [Tue, 11 Nov 2025 16:29:33 +0000 (17:29 +0100)] 
hsr: Follow standard for HSRv0 supervision frames

For HSRv0, the path_id has the following meaning:
- 0000: PRP supervision frame
- 0001-1001: HSR ring identifier
- 1010-1011: Frames from PRP network (A/B, with RedBoxes)
- 1111: HSR supervision frame

Follow the IEC 62439-3:2010 standard more closely by setting the right
path_id for HSRv0 supervision frames (actually, it is correctly set when
the frame is constructed, but hsr_set_path_id() overwrites it) and set a
fixed HSR ring identifier of 1. The ring identifier seems to be generally
unused and we ignore it anyways on reception, but some fixed identifier is
definitely better than using one identifier in one direction and a wrong
identifier in the other.

This was also the behavior before commit f266a683a480 ("net/hsr: Better
frame dispatch") which introduced the alternating path_id. This was later
moved to hsr_set_path_id() in commit 451d8123f897 ("net: prp: add packet
handling support").

The IEC 62439-3:2010 also contains 6 unused bytes after the MacAddressA in
the HSRv0 supervision frames. Adjust a TODO comment accordingly.

Fixes: f266a683a480 ("net/hsr: Better frame dispatch")
Fixes: 451d8123f897 ("net: prp: add packet handling support")
Signed-off-by: Felix Maurer <fmaurer@redhat.com>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://patch.msgid.link/ea0d5133cd593856b2fa673d6e2067bf1d4d1794.1762876095.git.fmaurer@redhat.com
Tested-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agohsr: Fix supervision frame sending on HSRv0
Felix Maurer [Tue, 11 Nov 2025 16:29:32 +0000 (17:29 +0100)] 
hsr: Fix supervision frame sending on HSRv0

On HSRv0, no supervision frames were sent. The supervison frames were
generated successfully, but failed the check for a sufficiently long mac
header, i.e., at least sizeof(struct hsr_ethhdr), in hsr_fill_frame_info()
because the mac header only contained the ethernet header.

Fix this by including the HSR header in the mac header when generating HSR
supervision frames. Note that the mac header now also includes the TLV
fields. This matches how we set the headers on rx and also the size of
struct hsrv0_ethhdr_sp.

Reported-by: Hangbin Liu <liuhangbin@gmail.com>
Closes: https://lore.kernel.org/netdev/aMONxDXkzBZZRfE5@fedora/
Fixes: 9cfb5e7f0ded ("net: hsr: fix hsr_init_sk() vs network/transport headers.")
Signed-off-by: Felix Maurer <fmaurer@redhat.com>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://patch.msgid.link/4354114fea9a642fe71f49aeeb6c6159d1d61840.1762876095.git.fmaurer@redhat.com
Tested-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agonet: phy: fixed_phy: initialize the link status as up
Heiner Kallweit [Mon, 10 Nov 2025 21:20:26 +0000 (22:20 +0100)] 
net: phy: fixed_phy: initialize the link status as up

All callers initialize the link status as up. This change is in line
with how of_phy_register_fixed_link() behaves.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/45f644e8-2292-4787-a27a-f69084c93218@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agoMerge tag 'erofs-for-6.18-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Thu, 13 Nov 2025 13:02:59 +0000 (05:02 -0800)] 
Merge tag 'erofs-for-6.18-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs

Pull erofs fixes from Gao Xiang:

 - Add Chunhai Guo as a EROFS reviewer to get more eyes from interested
   industry vendors

 - Fix infinite loop caused by incomplete crafted zstd-compressed data
   (thanks to Robert again!)

* tag 'erofs-for-6.18-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
  erofs: avoid infinite loop due to incomplete zstd-compressed data
  MAINTAINERS: erofs: add myself as reviewer

5 weeks agoMerge tag 'v6.18-rc5-smb-server-fixes' of git://git.samba.org/ksmbd
Linus Torvalds [Thu, 13 Nov 2025 12:57:38 +0000 (04:57 -0800)] 
Merge tag 'v6.18-rc5-smb-server-fixes' of git://git.samba.org/ksmbd

Pull smb server fixes from Steve French:

 - Fix smbdirect (RDMA) disconnect hang bug

 - Fix potential Denial of Service when connection limit exceeded

 - Fix smbdirect (RDMA) connection (potentially accessing freed memory)
   bug

* tag 'v6.18-rc5-smb-server-fixes' of git://git.samba.org/ksmbd:
  smb: server: let smb_direct_disconnect_rdma_connection() turn CREATED into DISCONNECTED
  ksmbd: close accepted socket when per-IP limit rejects connection
  smb: server: rdma: avoid unmapping posted recv on accept failure

5 weeks agovirtio-net: fix incorrect flags recording in big mode
Xuan Zhuo [Tue, 11 Nov 2025 09:08:28 +0000 (17:08 +0800)] 
virtio-net: fix incorrect flags recording in big mode

The purpose of commit 703eec1b2422 ("virtio_net: fixing XDP for fully
checksummed packets handling") is to record the flags in advance, as
their value may be overwritten in the XDP case. However, the flags
recorded under big mode are incorrect, because in big mode, the passed
buf does not point to the rx buffer, but rather to the page of the
submitted buffer. This commit fixes this issue.

For the small mode, the commit c11a49d58ad2 ("virtio_net: Fix mismatched
buf address when unmapping for small packets") fixed it.

Tested-by: Alyssa Ross <hi@alyssa.is>
Fixes: 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling")
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://patch.msgid.link/20251111090828.23186-1-xuanzhuo@linux.alibaba.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agoMerge tag 'linux-can-next-for-6.19-20251112-2' of git://git.kernel.org/pub/scm/linux...
Paolo Abeni [Thu, 13 Nov 2025 12:07:47 +0000 (13:07 +0100)] 
Merge tag 'linux-can-next-for-6.19-20251112-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
pull-request: can-next 2025-11-12

this is a pull request of 11 patches for net-next/main.

The first 3 patches are by Vadim Fedorenko and convert the CAN drivers
to use the ndo_hwtstamp callbacks.

Maud Spierings contributes a patch for the mcp251x driver that
converts it to use dev_err_probe().

The next 6 patches target the mcp251xfd driver and are by Gregor
Herburger and me. They add GPIO controller functionality to the
driver.

The final patch is by Chu Guangqing and fixes a typo in the bxcan
driver.

linux-can-next-for-6.19-20251112-2

* tag 'linux-can-next-for-6.19-20251112-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  can: bxcan: Fix a typo error for assign
  dt-bindings: can: mcp251xfd: add gpio-controller property
  can: mcp251xfd: add gpio functionality
  can: mcp251xfd: only configure PIN1 when rx_int is set
  can: mcp251xfd: add workaround for errata 5
  can: mcp251xfd: utilize gather_write function for all non-CRC writes
  can: mcp251xfd: move chip sleep mode into runtime pm
  can: mcp251x: mcp251x_can_probe(): use dev_err_probe()
  can: peak_usb: convert to use ndo_hwtstamp callbacks
  can: peak_canfd: convert to use ndo_hwtstamp callbacks
  can: convert generic HW timestamp ioctl to ndo_hwtstamp callbacks
====================

Link: https://patch.msgid.link/20251112184344.189863-1-mkl@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
5 weeks agoMerge tag 'nfsd-6.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
Linus Torvalds [Thu, 13 Nov 2025 02:41:01 +0000 (18:41 -0800)] 
Merge tag 'nfsd-6.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux

Pull nfsd fixes from Chuck Lever:
 "Address recently reported issues or issues found at the recent NFS
  bake-a-thon held in Raleigh, NC.

  Issues reported with v6.18-rc:
   - Address a kernel build issue
   - Reorder SEQUENCE processing to avoid spurious NFS4ERR_SEQ_MISORDERED

  Issues that need expedient stable backports:
   - Close a refcount leak exposure
   - Report support for NFSv4.2 CLONE correctly
   - Fix oops during COPY_NOTIFY processing
   - Prevent rare crash after XDR encoding failure
   - Prevent crash due to confused or malicious NFSv4.1 client"

* tag 'nfsd-6.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
  Revert "SUNRPC: Make RPCSEC_GSS_KRB5 select CRYPTO instead of depending on it"
  nfsd: ensure SEQUENCE replay sends a valid reply.
  NFSD: Never cache a COMPOUND when the SEQUENCE operation fails
  NFSD: Skip close replay processing if XDR encoding fails
  NFSD: free copynotify stateid in nfs4_free_ol_stateid()
  nfsd: add missing FATTR4_WORD2_CLONE_BLKSIZE from supported attributes
  nfsd: fix refcount leak in nfsd_set_fh_dentry()

5 weeks agoMerge tag 'dma-mapping-6.18-2025-11-12' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Thu, 13 Nov 2025 02:31:22 +0000 (18:31 -0800)] 
Merge tag 'dma-mapping-6.18-2025-11-12' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux

Pull dma-mapping fixes from Marek Szyprowski:

 - two minor fixes for DMA API infrastructure: restoring proper
   structure padding used in benchmark tests (Qinxin Xia) and global
   DMA_BIT_MASK macro rework to make it a bit more clang friendly (James
   Clark)

* tag 'dma-mapping-6.18-2025-11-12' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope
  dma-mapping: benchmark: Restore padding to ensure uABI remained consistent

5 weeks agoMerge tag 'loongarch-fixes-6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Thu, 13 Nov 2025 02:21:30 +0000 (18:21 -0800)] 
Merge tag 'loongarch-fixes-6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson

Pull LoongArch fixes from Huacai Chen:

 - Fix a Rust build error

 - Fix exception/interrupt, memory management, perf event, hardware
   breakpoint, kexec and KVM bugs

* tag 'loongarch-fixes-6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
  LoongArch: KVM: Fix max supported vCPUs set with EIOINTC
  LoongArch: KVM: Skip PMU checking on vCPU context switch
  LoongArch: KVM: Restore guest PMU if it is enabled
  LoongArch: KVM: Add delay until timer interrupt injected
  LoongArch: KVM: Set page with write attribute if dirty track disabled
  LoongArch: kexec: Print out debugging message if required
  LoongArch: kexec: Initialize the kexec_buf structure
  LoongArch: Use correct accessor to read FWPC/MWPC
  LoongArch: Refine the init_hw_perf_events() function
  LoongArch: Remove __GFP_HIGHMEM masking in pud_alloc_one()
  LoongArch: Let {pte,pmd}_modify() record the status of _PAGE_DIRTY
  LoongArch: Consolidate max_pfn & max_low_pfn calculation
  LoongArch: Consolidate early_ioremap()/ioremap_prot()
  LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY
  LoongArch: Clarify 3 MSG interrupt features
  rust: Add -fno-isolate-erroneous-paths-dereference to bindgen_skip_c_flags

5 weeks agoMerge tag 'alpha-fixes-v6.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Thu, 13 Nov 2025 02:18:12 +0000 (18:18 -0800)] 
Merge tag 'alpha-fixes-v6.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha

Pull alpha fix from Matt Turner:
 "Add Magnus as a maintainer of the alpha port"

* tag 'alpha-fixes-v6.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha:
  MAINTAINERS: Add Magnus Lindholm as maintainer for alpha port

5 weeks agoMerge branch 'net-stmmac-convert-glue-drivers-to-use-stmmac_get_phy_intf_sel'
Jakub Kicinski [Thu, 13 Nov 2025 02:13:44 +0000 (18:13 -0800)] 
Merge branch 'net-stmmac-convert-glue-drivers-to-use-stmmac_get_phy_intf_sel'

Russell King says:

====================
net: stmmac: convert glue drivers to use stmmac_get_phy_intf_sel()

This series converts the remaining glue drivers that support
multi-interface to use stmmac_get_phy_intf_sel(). The reason these
drivers are not converted to the set_phy_intf_sel() method is
because it is unclear whether there are ordering dependencies that
would prevent it.

For example, reading the stm32mp2 documentation, it is required to
set the ETH1_SEL field while the dwmac core is in reset and before
clocks are enabled. This requirement can not be satsified at the
moment (but could with further changes.)
====================

Link: https://patch.msgid.link/aRLvrfx6tOa-RhrY@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: visconti: use stmmac_get_phy_intf_sel()
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:48 +0000 (08:12 +0000)] 
net: stmmac: visconti: use stmmac_get_phy_intf_sel()

Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value, validate the result and use that to set the
control register to select the operating mode for the DWMAC core.

Note that this will allow GMII as well as MII as the phy_intf_sel
value is the same for both.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUe-0000000DquB-3JDY@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: visconti: use PHY_INTF_SEL_x to select PHY interface
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:43 +0000 (08:12 +0000)] 
net: stmmac: visconti: use PHY_INTF_SEL_x to select PHY interface

Convert dwmac-visconti to use the PHY_INTF_SEL_x definitions. The
original definitions used constant 0, BIT(0) (==1) and BIT(2) (==4)
to define these, but the values of the bits corresponds with the
PHY_INTF_SEL_x values, so it is highly likely that these are not
individual bits, but the PHY_INTF_SEL_x bitfield.

This removes this incorrect use of BIT().

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUZ-0000000Dqu5-2sDI@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: stm32: use stmmac_get_phy_intf_sel()
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:38 +0000 (08:12 +0000)] 
net: stmmac: stm32: use stmmac_get_phy_intf_sel()

Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value. As both configure functions would end up with the
same code, call this from stm32mp1_set_mode(), validate the result and
pass the resulting value into the stm32 configure function. Use this
value to set the operating mode for the DWMAC core.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUU-0000000Dqtz-2PwT@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: stm32: use PHY_INTF_SEL_x directly
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:33 +0000 (08:12 +0000)] 
net: stmmac: stm32: use PHY_INTF_SEL_x directly

Rather than defining separate constants for each, use the
PHY_INTF_SEL_x definitions in the switch()es configuring the
control register, and use one FIELD_PREP() to convert phy_intf_sel
to the register value.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUP-0000000Dqtt-1bYn@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: stm32: use PHY_INTF_SEL_x to select PHY interface
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:28 +0000 (08:12 +0000)] 
net: stmmac: stm32: use PHY_INTF_SEL_x to select PHY interface

Convert dwmac-stm32 to use the PHY_INTF_SEL_x definitions.

For stm32mp1, the original definitions used constant 0 (GMII, 0 << 21),
BIT(21) (RGMII, 1 << 21) and BIT(23) (RMII, 4 << 21) to define these,
but from the values it can be clearly seen that these are the
PHY_INTF_SEL_x inputs to the dwmac.

For stm32mp2, the original definitions cover a bitfield 6:4 in the
SYSCFG Ethernet1 control register (according to documentation) and use
the PHY_INTF_SEL_x values.

Use the common dwmac definitions for the PHY interface selection field
by adding the bitfield mask, and using FIELD_PREP() for the bitfield
values.

This removes this incorrect use of BIT().

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUK-0000000Dqtn-1AyK@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: starfive: use stmmac_get_phy_intf_sel()
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:23 +0000 (08:12 +0000)] 
net: stmmac: starfive: use stmmac_get_phy_intf_sel()

Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value, validate the result and use that to set the
control register to select the operating mode for the DWMAC core.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Link: https://patch.msgid.link/E1vIjUF-0000000Dqth-0gwD@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: starfive: use PHY_INTF_SEL_x to select PHY interface
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:18 +0000 (08:12 +0000)] 
net: stmmac: starfive: use PHY_INTF_SEL_x to select PHY interface

Use the common dwmac definitions for the PHY interface selection field.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Link: https://patch.msgid.link/E1vIjUA-0000000Dqtb-0AfP@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: mediatek: simplify set_interface() methods
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:12 +0000 (08:12 +0000)] 
net: stmmac: mediatek: simplify set_interface() methods

Use the phy_intf_sel field value when deciding what other options to
apply for the configuration register.

Note that this will allow GMII as well as MII as the phy_intf_sel
value is the same for both.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/E1vIjU4-0000000DqtV-3qsX@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: mediatek: use stmmac_get_phy_intf_sel()
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:07 +0000 (08:12 +0000)] 
net: stmmac: mediatek: use stmmac_get_phy_intf_sel()

Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value, validate the result, and pass that into the
implementation specific ->dwmac_set_phy_interface() method. Use this
to configure the PHY interface selection field.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/E1vIjTz-0000000DqtP-3N9v@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: mediatek: use PHY_INTF_SEL_x
Russell King (Oracle) [Tue, 11 Nov 2025 08:12:02 +0000 (08:12 +0000)] 
net: stmmac: mediatek: use PHY_INTF_SEL_x

Use PHY_INTF_SEL_x definitions for the fields that correspond to the
phy_intf_sel inputs to the dwmac core.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/E1vIjTu-0000000DqtI-2sUB@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: loongson1: use stmmac_get_phy_intf_sel()
Russell King (Oracle) [Tue, 11 Nov 2025 08:11:57 +0000 (08:11 +0000)] 
net: stmmac: loongson1: use stmmac_get_phy_intf_sel()

Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value, validate the result and use that to set the
control register to select the operating mode for the DWMAC core.

Note that this will allow GMII as well as MII as the phy_intf_sel
value is the same for both.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/E1vIjTp-0000000DqtC-2DmI@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: loongson1: use PHY_INTF_SEL_x directly
Russell King (Oracle) [Tue, 11 Nov 2025 08:11:52 +0000 (08:11 +0000)] 
net: stmmac: loongson1: use PHY_INTF_SEL_x directly

Use the PHY_INTF_SEL_xx values directly in ls1c_dwmac_syscon_init(),
converting them to the PHY_INTF_SELI bitfield when calling
regmap_update_bits().

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/E1vIjTk-0000000Dqt6-1gN9@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: loongson1: use PHY_INTF_SEL_x
Russell King (Oracle) [Tue, 11 Nov 2025 08:11:47 +0000 (08:11 +0000)] 
net: stmmac: loongson1: use PHY_INTF_SEL_x

Use PHY_INTF_SEL_x definitions for phy_intf_sel bitfield.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agotools: ynltool: correct install in Makefile
Jakub Kicinski [Tue, 11 Nov 2025 15:52:14 +0000 (07:52 -0800)] 
tools: ynltool: correct install in Makefile

Use the variable in case user has a custom install binary.

Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20251111155214.2760711-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests: drv-net: Limit the max number of queues in procfs_downup_hammer
Dimitri Daskalakis [Tue, 11 Nov 2025 22:53:19 +0000 (14:53 -0800)] 
selftests: drv-net: Limit the max number of queues in procfs_downup_hammer

For NICs with a large (1024+) number of queues, this test can cause
excessive memory fragmentation. This results in OOM errors, and in the
worst case driver/kernel crashes. We don't need to test with the max number
of queues, just enough to create a high likelihood of races between
reconfiguration and stats getting read.

Signed-off-by: Dimitri Daskalakis <dimitri.daskalakis1@gmail.com>
Link: https://patch.msgid.link/20251111225319.3019542-1-dimitri.daskalakis1@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agowifi: rtw89: rtw8852bu: Added dev id for ASUS AX57 NANO USB Wifi dongle
Dan Hamik [Wed, 12 Nov 2025 07:04:51 +0000 (07:04 +0000)] 
wifi: rtw89: rtw8852bu: Added dev id for ASUS AX57 NANO USB Wifi dongle

Add the USB device ID 0x0b05:0x1cb6 to the rtw8852bu driver to support the
ASUS AX57 Nano WiFi 6 USB adapter.This device uses the same Realtek
RTL8852BU chipset as other supported models.

Tested on: Linux Mint 22 with kernel 6.8.0-87-generic.
The adapter initializes successfully and connects to networks.

Signed-off-by: Dan Hamik <dan@hamik.net>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/010f019a76e1a84b-0a6f5e9f-2a43-4a9d-9c30-de4ae6363011-000000@us-east-2.amazonses.com
5 weeks agowifi: rtw89: configure RX antenna if chips can support
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:52 +0000 (10:24 +0800)] 
wifi: rtw89: configure RX antenna if chips can support

If chip->ops->cfg_txrx_path is implemented, a chip can support to configure
RX antenna, so accept setting via iw tool.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-9-pkshih@realtek.com
5 weeks agowifi: rtw89: do RF calibration once setting channel when running pure monitor mode
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:51 +0000 (10:24 +0800)] 
wifi: rtw89: do RF calibration once setting channel when running pure monitor mode

To be able to capture and inject packets in monitor mode, do RF calibration
once setting certain channel. Since calibration costs time, do not change
behavior of normal usage, which do calibration only when starting as AP
or going to connect AP.

Since driver declares IEEE80211_HW_WANT_MONITOR_VIF, the pure monitor vif
must be only one when adding interface with type NL80211_IFTYPE_MONITOR.
Otherwise, monitor vif must be NULL.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-8-pkshih@realtek.com
5 weeks agowifi: rtw89: consider data rate/bandwidth/GI for injected packets
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:50 +0000 (10:24 +0800)] 
wifi: rtw89: consider data rate/bandwidth/GI for injected packets

To send injected packets with configurable rate/bandwidth/GI, fill TXWD
fields according to SKB's info->control.rates[0] annotated by mac80211.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-7-pkshih@realtek.com
5 weeks agowifi: rtw89: phy: fix out-of-bounds access in rtw89_phy_read_txpwr_limit()
Kuan-Chung Chen [Tue, 11 Nov 2025 02:24:49 +0000 (10:24 +0800)] 
wifi: rtw89: phy: fix out-of-bounds access in rtw89_phy_read_txpwr_limit()

Coverity reported a potential out-of-bounds access when 'bw' exceeds the
valid range for the specified band. Add a helper `rtw89_bw_is_valid()`
to check bandwidth validity for each band before accessing limit tables.

Addresses-Coverity-ID: 1598844 ("Out-of-bounds access")
Addresses-Coverity-ID: 1598896 ("Out-of-bounds access")

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-6-pkshih@realtek.com
5 weeks agowifi: rtw89: 8852c: add compensation of thermal value from efuse calibration
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:48 +0000 (10:24 +0800)] 
wifi: rtw89: 8852c: add compensation of thermal value from efuse calibration

The 3th bit of thermal value programmed in efuse means 8 (2 ^ 3) grams.
Check the bit and signed bit, and add compensation to final thermal.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-5-pkshih@realtek.com
5 weeks agowifi: rtw89: debug: add parser to diagnose along DIAG_MAC fw element
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:47 +0000 (10:24 +0800)] 
wifi: rtw89: debug: add parser to diagnose along DIAG_MAC fw element

The rules to diagnose MAC have a common header, and a cmd field is used
to know the exact command and its format. The rules with the same tuple of
fields {sheet, seq} can be seen as a set of compound rules, which treat
it as positive rule if just one of the rules is positive.

Take EQUALV rules as example, if value of {addr, mask} is equal to
predefined value as field val, a rule is positive. Fields addr_name_offset
and msg_offset are offsets related to textual messages for human readable.

Format of common rule header (8 bytes)
 +-------+-----+--------+-----------+-----+---------+
 | sheet | cmd | seq[2] | io / band | len | rsvd[2] |
 +-------+-----+--------+-----------+-----+---------+

Format of rule command is EQUALV (equal value) (24 bytes):
 +------+------------------+------+-----+------------+---------+
 | addr | addr_name_offset | mask | val | msg_offset | rsvd[4] |
 +------+------------------+------+-----+------------+---------+

Format of message:
 +-----+----------+
 | len | string[] |
 +-----+----------+

An example of output:
 Plain(Ignore)/Rules/Positive: 115(4)/86/81

 Where, Plain is total rules written in firmware element.
        Ignore is the ignored rules, such as USB IO, but current is PCIE.
        Rules is number of set of compound rules.
        Positive is number of positive Rules.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-4-pkshih@realtek.com
5 weeks agowifi: rtw89: fw: parse firmware element of DIAG_MAC
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:46 +0000 (10:24 +0800)] 
wifi: rtw89: fw: parse firmware element of DIAG_MAC

The firmware element ID 28 is a set of rules to diagnose if MAC get
abnormal. The latter patch will use these rules via debugfs to know
the status.

The element contains rules with their textual messages shown as below:

   +------------------------------------+
   |                                    |
   |                +-----------+       |
   |                | rule_size |-------|----------+
   +----------------+-----------+-------+ --       |
   |             rule[0]                |   \      |
   |             rule[1]                |   |  <---+
   |                :                   |   /
   +------------------------------------+ --
   | msg[0]      msg[1]                 |  each msg has variable length
   |        msg[2]    msg[3] ...        |  (with address align 2)
   | ...                                |
   +------------------------------------+

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-3-pkshih@realtek.com
5 weeks agowifi: rtw89: pci: add to read PCI configuration space from common code
Ping-Ke Shih [Tue, 11 Nov 2025 02:24:45 +0000 (10:24 +0800)] 
wifi: rtw89: pci: add to read PCI configuration space from common code

Normally only access PCI device in pci.c. However for debug purpose,
a set of registers predefined in firmware element including PCI
configuration space should be read for diagnosis.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-2-pkshih@realtek.com
5 weeks agocan: bxcan: Fix a typo error for assign
Chu Guangqing [Mon, 3 Nov 2025 07:40:09 +0000 (15:40 +0800)] 
can: bxcan: Fix a typo error for assign

Fix the spelling error of "assign".

Signed-off-by: Chu Guangqing <chuguangqing@inspur.com>
Reviewed-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Link: https://patch.msgid.link/20251103074009.4708-1-chuguangqing@inspur.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
5 weeks agoMerge patch series "can: mcp251xfd: add gpio functionality"
Marc Kleine-Budde [Wed, 12 Nov 2025 18:30:55 +0000 (19:30 +0100)] 
Merge patch series "can: mcp251xfd: add gpio functionality"

Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> says:

The mcp251xfd allows two pins to be configured as GPIOs. This series adds
support for this feature.

The GPIO functionality is controlled with the IOCON register which has an
erratum.

Patch 1 from https://lore.kernel.org/linux-can/20240429-mcp251xfd-runtime_pm-v1-3-c26a93a66544@pengutronix.de/
Patch 2 refactor of no-crc functions to prepare workaround for non-crc writes
Patch 3 is the fix/workaround for the aforementioned erratum
Patch 4 only configure pin1 for rx-int
Patch 5 adds the gpio support
Patch 6 updates dt-binding

https://lore.kernel.org/all/20240806-industrious-augmented-crane-44239a-mkl@pengutronix.de/

Link: https://patch.msgid.link/20251001091006.4003841-1-viken.dadhaniya@oss.qualcomm.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
5 weeks agodt-bindings: can: mcp251xfd: add gpio-controller property
Gregor Herburger [Wed, 1 Oct 2025 09:10:06 +0000 (14:40 +0530)] 
dt-bindings: can: mcp251xfd: add gpio-controller property

The mcp251xfd has two pins that can be used as gpio. Add gpio-controller
property to binding description.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251001091006.4003841-7-viken.dadhaniya@oss.qualcomm.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
5 weeks agocan: mcp251xfd: add gpio functionality
Gregor Herburger [Wed, 1 Oct 2025 09:10:05 +0000 (14:40 +0530)] 
can: mcp251xfd: add gpio functionality

The mcp251xfd devices allow two pins to be configured as gpio. Add this
functionality to driver.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Tested-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251001091006.4003841-6-viken.dadhaniya@oss.qualcomm.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
5 weeks agocan: mcp251xfd: only configure PIN1 when rx_int is set
Gregor Herburger [Wed, 1 Oct 2025 09:10:04 +0000 (14:40 +0530)] 
can: mcp251xfd: only configure PIN1 when rx_int is set

When rx_int is used th mcp251xfd_chip_rx_int_enable and
mcp251xfd_chip_rx_int_disable function configure both PIN0 and PIN1. To
prepare the support of the GPIOS only configure PIN1 with
regmap_update_bits.

This way PIN0 can be used as GPIO while PIN1 is used as rx_int
interrupt.

Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Tested-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251001091006.4003841-5-viken.dadhaniya@oss.qualcomm.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
5 weeks agocan: mcp251xfd: add workaround for errata 5
Gregor Herburger [Wed, 1 Oct 2025 09:10:03 +0000 (14:40 +0530)] 
can: mcp251xfd: add workaround for errata 5

According to Errata DS80000789E 5 writing IOCON register using one SPI
write command clears LAT0/LAT1.

Errata Fix/Work Around suggests to write registers with single byte write
instructions. However, it seems that every write to the second byte
causes the overwrite of LAT0/LAT1.

Never write byte 2 of IOCON register to avoid clearing of LAT0/LAT1.

Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Tested-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251001091006.4003841-4-viken.dadhaniya@oss.qualcomm.com
[mkl: add missing MCP251XFD_REG_IOCON_GPIO_MASK]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
5 weeks agoMerge tag 'wireless-next-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel...
Jakub Kicinski [Wed, 12 Nov 2025 17:33:23 +0000 (09:33 -0800)] 
Merge tag 'wireless-next-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

Johannes Berg says:

====================
More -next material, notably:
 - split ieee80211.h file, it's way too big
 - mac80211: initial chanctx work towards NAN
 - mac80211: MU-MIMO sniffer improvements
 - ath12k: statistics improvements

* tag 'wireless-next-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (26 commits)
  wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()
  wifi: mac80211: make monitor link info check more specific
  wifi: mac80211: track MU-MIMO configuration on disabled interfaces
  wifi: cfg80211/mac80211: Add fallback mechanism for INDOOR_SP connection
  wifi: cfg80211/mac80211: clean up duplicate ap_power handling
  wifi: cfg80211: use a C99 initializer in wiphy_register
  wifi: cfg80211: fix doc of struct key_params
  wifi: mac80211: remove unnecessary vlan NULL check
  wifi: mac80211: pass frame type to element parsing
  wifi: mac80211: remove "disabling VHT" message
  wifi: mac80211: add and use chanctx usage iteration
  wifi: mac80211: simplify ieee80211_recalc_chanctx_min_def() API
  wifi: mac80211: remove chanctx to link back-references
  wifi: mac80211: make link iteration safe for 'break'
  wifi: mac80211: fix EHT typo
  wifi: cfg80211: fix EHT typo
  wifi: ieee80211: split NAN definitions out
  wifi: ieee80211: split P2P definitions out
  wifi: ieee80211: split S1G definitions out
  wifi: ieee80211: split EHT definitions out
  ...
====================

Link: https://patch.msgid.link/20251112115126.16223-4-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoMerge tag 'wireless-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git...
Jakub Kicinski [Wed, 12 Nov 2025 17:33:09 +0000 (09:33 -0800)] 
Merge tag 'wireless-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless

Johannes Berg says:

====================
Couple more fixes:
 - mwl8k: work around FW expecting a DSSS element in beacons
 - ath11k: report correct TX status
 - iwlwifi: avoid toggling links due to wrong element use
 - iwlwifi: fix beacon template rate on older devices
 - iwlwifi: fix loop iterator being used after loop
 - mac80211: disallow address changes while using the address
 - mac80211: avoid bad rate warning in monitor/sniffer mode
 - hwsim: fix potential NULL deref (on monitor injection)

* tag 'wireless-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
  wifi: iwlwifi: mld: always take beacon ies in link grading
  wifi: iwlwifi: mvm: fix beacon template/fixed rate
  wifi: iwlwifi: fix aux ROC time event iterator usage
  wifi: mwl8k: inject DSSS Parameter Set element into beacons if missing
  wifi: mac80211_hwsim: Fix possible NULL dereference
  wifi: mac80211: skip rate verification for not captured PSDUs
  wifi: mac80211: reject address change while connecting
  wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp()
====================

Link: https://patch.msgid.link/20251112114621.15716-5-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: stmmac: improve ndev->max_mtu setup readability
Russell King (Oracle) [Tue, 11 Nov 2025 11:26:34 +0000 (11:26 +0000)] 
net: stmmac: improve ndev->max_mtu setup readability

Improve the readibility of the code setting ndev->max_mtu. This depends
on the hardware specific maximum defined by the MAC core, and also a
platform provided maximum.

The code was originally checking that the platform specific maximum was
between ndev->min_mtu..MAC core maximum before reducing ndev->max_mtu,
otherwise if the platform specific maximum was less than ndev->min_mtu,
issuing a warning.

Re-order the code to handle the case where the platform specific max is
below ndev->min_mtu, which then means that the subsequent test is
simply reducing ndev->max_mtu.

Update the comment, and add a few blank lines to separate the blocks of
code.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vImWA-0000000DrIl-1HZY@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agor8169: add support for RTL8125K
javen [Tue, 11 Nov 2025 09:28:51 +0000 (17:28 +0800)] 
r8169: add support for RTL8125K

This adds support for chip RTL8125K. Its XID is 0x68a. It is basically
based on the one with XID 0x688, but with different firmware file.

Signed-off-by: javen <javen_xu@realsil.com.cn>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/20251111092851.3371-1-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agonet: clear skb->sk in skb_release_head_state()
Eric Dumazet [Tue, 11 Nov 2025 15:12:35 +0000 (15:12 +0000)] 
net: clear skb->sk in skb_release_head_state()

skb_release_head_state() inlines skb_orphan().

We need to clear skb->sk otherwise we can freeze TCP flows
on a mostly idle host, because skb_fclone_busy() would
return true as long as the packet is not yet processed by
skb_defer_free_flush().

Fixes: 1fcf572211da ("net: allow skb_release_head_state() to be called multiple times")
Fixes: e20dfbad8aab ("net: fix napi_consume_skb() with alien skbs")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Aditya Garg <gargaditya@linux.microsoft.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20251111151235.1903659-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
Chuang Wang [Tue, 11 Nov 2025 06:43:24 +0000 (14:43 +0800)] 
ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe

The sit driver's packet transmission path calls: sit_tunnel_xmit() ->
update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called
to delete entries exceeding FNHE_RECLAIM_DEPTH+random.

The race window is between fnhe_remove_oldest() selecting fnheX for
deletion and the subsequent kfree_rcu(). During this time, the
concurrent path's __mkroute_output() -> find_exception() can fetch the
soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a
new dst using a dst_hold(). When the original fnheX is freed via RCU,
the dst reference remains permanently leaked.

CPU 0                             CPU 1
__mkroute_output()
  find_exception() [fnheX]
                                  update_or_create_fnhe()
                                    fnhe_remove_oldest() [fnheX]
  rt_bind_exception() [bind dst]
                                  RCU callback [fnheX freed, dst leak]

This issue manifests as a device reference count leak and a warning in
dmesg when unregistering the net device:

  unregister_netdevice: waiting for sitX to become free. Usage count = N

Ido Schimmel provided the simple test validation method [1].

The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().
Since rt_bind_exception() checks this field, setting it to zero prevents
the stale fnhe from being reused and bound to a new dst just before it
is freed.

[1]
ip netns add ns1
ip -n ns1 link set dev lo up
ip -n ns1 address add 192.0.2.1/32 dev lo
ip -n ns1 link add name dummy1 up type dummy
ip -n ns1 route add 192.0.2.2/32 dev dummy1
ip -n ns1 link add name gretap1 up arp off type gretap \
    local 192.0.2.1 remote 192.0.2.2
ip -n ns1 route add 198.51.0.0/16 dev gretap1
taskset -c 0 ip netns exec ns1 mausezahn gretap1 \
    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
taskset -c 2 ip netns exec ns1 mausezahn gretap1 \
    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
sleep 10
ip netns pids ns1 | xargs kill
ip netns del ns1

Cc: stable@vger.kernel.org
Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible")
Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20251111064328.24440-1-nashuiliang@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoMerge branch 'selftests-vsock-refactor-and-improve-vmtest-infrastructure'
Jakub Kicinski [Wed, 12 Nov 2025 14:19:42 +0000 (06:19 -0800)] 
Merge branch 'selftests-vsock-refactor-and-improve-vmtest-infrastructure'

Bobby Eshleman says:

====================
selftests/vsock: refactor and improve vmtest infrastructure

This patch series refactors the vsock selftest VM infrastructure to
improve test run times, improve logging, and prepare for future tests
which make heavy usage of these refactored functions and have new
requirements such as simultaneous QEMU processes.
====================

Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-0-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: disable shellcheck SC2317 and SC2119
Bobby Eshleman [Sat, 8 Nov 2025 16:01:03 +0000 (08:01 -0800)] 
selftests/vsock: disable shellcheck SC2317 and SC2119

Disable shellcheck rules SC2317 and SC2119. These rules are being
triggered due to false positives. For SC2317, many `return
"${KSFT_PASS}"` lines are reported as unreachable, even though they are
executed during normal runs. For SC2119, the fact that
log_guest/log_host accept either stdin or arguments triggers SC2119,
despite being valid.

Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-12-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: add vsock_loopback module loading
Bobby Eshleman [Sat, 8 Nov 2025 16:01:02 +0000 (08:01 -0800)] 
selftests/vsock: add vsock_loopback module loading

Add vsock_loopback module loading to the loopback test so that vmtest.sh
can be used for kernels built with loopback as a module.

This is not technically a fix as kselftest expects loopback to be
built-in already (defined in selftests/vsock/config). This is useful
only for using vmtest.sh outside of kselftest.

Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-11-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: add 1.37 to tested virtme-ng versions
Bobby Eshleman [Sat, 8 Nov 2025 16:01:01 +0000 (08:01 -0800)] 
selftests/vsock: add 1.37 to tested virtme-ng versions

Testing with 1.37 shows all tests passing but emits the warning:

warning: vng version 'virtme-ng 1.37' has not been tested and may not function properly.
The following versions have been tested: 1.33 1.36

This patch adds 1.37 to the virtme-ng versions to get rid of the above
warning.

Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-10-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: add BUILD=0 definition
Bobby Eshleman [Sat, 8 Nov 2025 16:01:00 +0000 (08:01 -0800)] 
selftests/vsock: add BUILD=0 definition

Add the definition for BUILD and initialize it to zero. This avoids
'bash -u vmtest.sh` from throwing 'unbound variable' when BUILD is not
set to 1 and is later checked for its value.

Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-9-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: identify and execute tests that can re-use VM
Bobby Eshleman [Sat, 8 Nov 2025 16:00:59 +0000 (08:00 -0800)] 
selftests/vsock: identify and execute tests that can re-use VM

In preparation for future patches that introduce tests that cannot
re-use the same VM, add functions to identify those that *can* re-use a
VM.

By continuing to re-use the same VM for these tests we can save time by
avoiding the delay of booting a VM for every test.

Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-8-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: add check_result() for pass/fail counting
Bobby Eshleman [Sat, 8 Nov 2025 16:00:58 +0000 (08:00 -0800)] 
selftests/vsock: add check_result() for pass/fail counting

Add check_result() function to reuse logic for incrementing the
pass/fail counters. This function will get used by different callers as
we add different types of tests in future patches (namely, namespace and
non-namespace tests will be called at different places, and re-use this
function).

Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-7-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: speed up tests by reducing the QEMU pidfile timeout
Bobby Eshleman [Sat, 8 Nov 2025 16:00:57 +0000 (08:00 -0800)] 
selftests/vsock: speed up tests by reducing the QEMU pidfile timeout

Reduce the time waiting for the QEMU pidfile from three minutes to five
seconds. The three minute time window was chosen to make sure QEMU had
enough time to fully boot up. This, however, is an unreasonably long
delay for QEMU to write the pidfile, which happens earlier when the QEMU
process starts (not after VM boot). The three minute delay becomes
noticeably wasteful in future tests that expect QEMU to fail and wait a
full three minutes for a pidfile that will never exist.

Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-6-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
5 weeks agoselftests/vsock: do not unconditionally die if qemu fails
Bobby Eshleman [Sat, 8 Nov 2025 16:00:56 +0000 (08:00 -0800)] 
selftests/vsock: do not unconditionally die if qemu fails

If QEMU fails to boot, then set the returncode (via timeout) instead of
unconditionally dying. This is in preparation for tests that expect QEMU
to fail to boot. In that case, we just want to know if the boot failed
or not so we can test the pass/fail criteria, and continue executing the
next test.

Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251108-vsock-selftests-fixes-and-improvements-v4-5-d5e8d6c87289@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>