]> git.ipfire.org Git - thirdparty/kernel/stable.git/log
thirdparty/kernel/stable.git
2 weeks agoplatform/x86: uniwill-laptop: Fix signedness bug
Ethan Tidmore [Fri, 3 Apr 2026 07:09:28 +0000 (02:09 -0500)] 
platform/x86: uniwill-laptop: Fix signedness bug

The function sysfs_match_string() can return negative error codes and
the variable assigned to it is the enum 'option'. Which could be an
unsigned int due to different compiler implementations.

Assign signed variable 'ret' to sysfs_match_string(), check for error,
then assign ret to option.

Detected by Smatch:
drivers/platform/x86/uniwill/uniwill-acpi.c:919 usb_c_power_priority_store()
warn: unsigned 'option' is never less than zero.

Fixes: 03ae0a0d0973b ("platform/x86: uniwill-laptop: Implement USB-C power priority setting")
Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
Link: https://patch.msgid.link/20260403070928.802196-1-ethantidmore06@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agoplatform/x86: dell_rbu: avoid uninit value usage in packet_size_write()
Fedor Pchelkin [Fri, 3 Apr 2026 13:42:39 +0000 (16:42 +0300)] 
platform/x86: dell_rbu: avoid uninit value usage in packet_size_write()

Ensure the temp value has been properly parsed from the user-provided
buffer and initialized to be used in later operations.  While at it,
prefer a convenient kstrtoul() helper.

Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool.

Fixes: ad6ce87e5bd4 ("[PATCH] dell_rbu: changes in packet update mechanism")
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Link: https://patch.msgid.link/20260403134240.604837-1-pchelkin@ispras.ru
[ij: add include]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agonfc: pn533: allocate rx skb before consuming bytes
Pengpeng Hou [Sun, 5 Apr 2026 00:40:00 +0000 (08:40 +0800)] 
nfc: pn533: allocate rx skb before consuming bytes

pn532_receive_buf() reports the number of accepted bytes to the serdev
core. The current code consumes bytes into recv_skb and may already hand
a complete frame to pn533_recv_frame() before allocating a fresh receive
buffer.

If that alloc_skb() fails, the callback returns 0 even though it has
already consumed bytes, and it leaves recv_skb as NULL for the next
receive callback. That breaks the receive_buf() accounting contract and
can also lead to a NULL dereference on the next skb_put_u8().

Allocate the receive skb lazily before consuming the next byte instead.
If allocation fails, return the number of bytes already accepted.

Fixes: c656aa4c27b1 ("nfc: pn533: add UART phy driver")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260405094003.3-pn533-v2-pengpeng@iscas.ac.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agoplatform/x86: hp-wmi: add locking for concurrent hwmon access
Emre Cecanpunar [Tue, 7 Apr 2026 14:25:14 +0000 (17:25 +0300)] 
platform/x86: hp-wmi: add locking for concurrent hwmon access

hp_wmi_hwmon_priv.mode and .pwm are written by hp_wmi_hwmon_write() in
sysfs context and read by hp_wmi_hwmon_keep_alive_handler() in a
workqueue. A concurrent write and keep-alive expiry can observe an
inconsistent mode/pwm pair (e.g. mode=MANUAL with a stale pwm).

Add a mutex to hp_wmi_hwmon_priv protecting mode and pwm. Hold it in
hp_wmi_hwmon_write() across the field update and apply call, and in
hp_wmi_hwmon_keep_alive_handler() before calling apply.

In hp_wmi_hwmon_read(), only the pwm_enable path reads priv->mode; use
scoped_guard() there to avoid holding the lock across unrelated WMI
calls.

Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive")
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Emre Cecanpunar <emreleno@gmail.com>
Link: https://patch.msgid.link/20260407142515.20683-6-emreleno@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agoplatform/x86: hp-wmi: fix u8 underflow in gpu_delta calculation
Emre Cecanpunar [Tue, 7 Apr 2026 14:25:13 +0000 (17:25 +0300)] 
platform/x86: hp-wmi: fix u8 underflow in gpu_delta calculation

gpu_delta was declared as u8. If the firmware specifies a GPU RPM
lower than the CPU RPM, subtracting them causes an underflow
(e.g. 10 - 20 = 246), which forces the GPU fan to remain clamped at
U8_MAX (100% speed) during operation.

Change gpu_delta to int and use signed arithmetic. Existing signed logic
in hp_wmi_fan_speed_set() correctly handles negative deltas.

Fixes: 46be1453e6e6 ("platform/x86: hp-wmi: add manual fan control for Victus S models")
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Emre Cecanpunar <emreleno@gmail.com>
Link: https://patch.msgid.link/20260407142515.20683-5-emreleno@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agoplatform/x86: hp-wmi: use mod_delayed_work to reset keep-alive timer
Emre Cecanpunar [Tue, 7 Apr 2026 14:25:12 +0000 (17:25 +0300)] 
platform/x86: hp-wmi: use mod_delayed_work to reset keep-alive timer

Currently, schedule_delayed_work() is used to queue the 90s keep-alive
timer. If a user manually changes the fan speed at T=85s,
schedule_delayed_work() leaves the existing timer in place as it is a
no-op if the work is already pending. This results in the keep-alive
timer firing unnecessarily at T=90s, just 5 seconds after the user
action.

Replace schedule_delayed_work() with mod_delayed_work() to reset the
90s timer whenever fan settings are applied. This guarantees a full 90s
delay after every user interaction, preventing redundant keep-alive
executions and improving efficiency.

Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive")
Signed-off-by: Emre Cecanpunar <emreleno@gmail.com>
Link: https://patch.msgid.link/20260407142515.20683-4-emreleno@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agoplatform/x86: hp-wmi: avoid cancel_delayed_work_sync from work handler
Emre Cecanpunar [Tue, 7 Apr 2026 14:25:11 +0000 (17:25 +0300)] 
platform/x86: hp-wmi: avoid cancel_delayed_work_sync from work handler

hp_wmi_apply_fan_settings() uses cancel_delayed_work_sync() to stop
the keep-alive timer in AUTO mode. However, since
hp_wmi_apply_fan_settings() is also called from the keep-alive
handler, a race condition with a sysfs write can cause the handler to
wait on itself, leading to a deadlock.

Replace cancel_delayed_work_sync() with cancel_delayed_work() in
hp_wmi_apply_fan_settings() to avoid the self-flush deadlock.

Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive")
Signed-off-by: Emre Cecanpunar <emreleno@gmail.com>
Link: https://patch.msgid.link/20260407142515.20683-3-emreleno@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agoplatform/x86: hp-wmi: fix ignored return values in fan settings
Emre Cecanpunar [Tue, 7 Apr 2026 14:25:10 +0000 (17:25 +0300)] 
platform/x86: hp-wmi: fix ignored return values in fan settings

hp_wmi_get_fan_count_userdefine_trigger() can fail, but its return
value was silently ignored in hp_wmi_apply_fan_settings() for
PWM_MODE_MAX/AUTO. Propagate these errors consistently.

Additionally, handle the return value of hp_wmi_apply_fan_settings()
in its callers by adding appropriate warnings on failure, and remove an
unreachable "return 0" at the end of the function.

Fixes: 46be1453e6e6 ("platform/x86: hp-wmi: add manual fan control for Victus S models")
Signed-off-by: Emre Cecanpunar <emreleno@gmail.com>
Link: https://patch.msgid.link/20260407142515.20683-2-emreleno@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2 weeks agoarm64: dts: ti: k3: Use memory-region-names for r5f
Markus Schneider-Pargmann (TI) [Wed, 18 Mar 2026 15:13:09 +0000 (16:13 +0100)] 
arm64: dts: ti: k3: Use memory-region-names for r5f

Add the newly introduced memory-region-names to all occurences of
ti,*-r5f. This helps adding a name to each memory-region so it is
easier to see what memory regions are for.

Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
Link: https://patch.msgid.link/20260318-topic-am62a-ioddr-dt-v6-19-v3-3-c41473cb23c3@baylibre.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agoKVM: LoongArch: selftests: Add PMU overflow interrupt test
Song Gao [Thu, 9 Apr 2026 10:56:38 +0000 (18:56 +0800)] 
KVM: LoongArch: selftests: Add PMU overflow interrupt test

Extend the PMU test suite to cover overflow interrupts. The test enables
the PMI (Performance Monitor Interrupt), sets counter 0 to one less than
the overflow value, and verifies that an interrupt is raised when the
counter overflows. A guest interrupt handler checks the interrupt cause
and disables further PMU interrupts upon success.

Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoKVM: LoongArch: selftests: Add basic PMU event counting test
Song Gao [Thu, 9 Apr 2026 10:56:37 +0000 (18:56 +0800)] 
KVM: LoongArch: selftests: Add basic PMU event counting test

Introduce a basic PMU test that verifies hardware event counting for
four performance counters. The test enables the events for CPU cycles,
instructions retired, branch instructions, and branch misses, runs a
fixed number of loops, and checks that the counter values fall within
expected ranges. It also validates that the host supports PMU and that
the VM feature is enabled.

Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoKVM: LoongArch: selftests: Add cpucfg read/write helpers
Song Gao [Thu, 9 Apr 2026 10:56:37 +0000 (18:56 +0800)] 
KVM: LoongArch: selftests: Add cpucfg read/write helpers

Add helper macros and functions to read and write CPU configuration
registers (cpucfg) from the guest and from the VMM. This interface is
required in upcoming selftests for querying and setting CPU features,
such as PMU capabilities.

Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Add DMSINTC inject msi to vCPU
Song Gao [Thu, 9 Apr 2026 10:56:37 +0000 (18:56 +0800)] 
LoongArch: KVM: Add DMSINTC inject msi to vCPU

Implement irqfd that deliver msi to vCPU and vCPU dmsintc irq injection.
Add pch_msi_set_irq() choice dmsintc to set msi irq by the msg_addr and
implement dmsintc set msi irq.

Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Add DMSINTC device support
Song Gao [Thu, 9 Apr 2026 10:56:37 +0000 (18:56 +0800)] 
LoongArch: KVM: Add DMSINTC device support

Add device model for DMSINTC interrupt controller, implement basic
create/destroy/set_attr interfaces, and register device model to kvm
device table.

Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Make vcpu_is_preempted() as a macro rather than function
Bibo Mao [Thu, 9 Apr 2026 10:56:36 +0000 (18:56 +0800)] 
LoongArch: KVM: Make vcpu_is_preempted() as a macro rather than function

vcpu_is_preempted() is performance sensitive that called in function
osq_lock(), here make it as a macro. So that parameter is not parsed
at most time, it can avoid cache line thrashing across numa nodes.

Here is part of UnixBench result on Loongson-3C5000 DualWay machine with
32 cores and 2 numa nodes.

          original    inline   macro
execl     7025.7      6991.2   7242.3
fstime    474.6       703.1    1071

From the test result, making vcpu_is_preempted() as a macro is the best,
and there is some improvment compared with the original function method.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Move host CSR_GSTAT save and restore in context switch
Bibo Mao [Thu, 9 Apr 2026 10:56:36 +0000 (18:56 +0800)] 
LoongArch: KVM: Move host CSR_GSTAT save and restore in context switch

CSR register LOONGARCH_CSR_GSTAT stores guest VMID information. With
existing implementation method, VMID is per vCPU, similar with ASID in
kernel. LOONGARCH_CSR_GSTAT is written at VM entry even if VMID is not
changed.

Here move LOONGARCH_CSR_GSTAT save/restore in vCPU context switch, and
update LOONGARCH_CSR_GSTAT only when VMID is updated at VM entry. At
most time VM enter/exit is much more frequent than vCPU thread context
switch.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Move host CSR_EENTRY save and restore in context switch
Bibo Mao [Thu, 9 Apr 2026 10:56:36 +0000 (18:56 +0800)] 
LoongArch: KVM: Move host CSR_EENTRY save and restore in context switch

CSR register LOONGARCH_CSR_EENTRY is shared between host CPU and guest
vCPU, KVM need save and restore LOONGARCH_CSR_EENTRY register. Here move
LOONGARCH_CSR_EENTRY saving in to context switch function rather than VM
entry.

At most time VM enter/exit is much more frequent than vCPU thread context
switch.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Check kvm_request_pending() in kvm_late_check_requests()
Bibo Mao [Thu, 9 Apr 2026 10:56:36 +0000 (18:56 +0800)] 
LoongArch: KVM: Check kvm_request_pending() in kvm_late_check_requests()

Add kvm_request_pending() checking firstly in kvm_late_check_requests(),
at most time there is no pending request, then the following pending bit
checking can be skipped.

Also embed function kvm_check_pmu() in to kvm_late_check_requests(), and
put it after the kvm_request_pending() checking.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoLoongArch: KVM: Use CSR_CRMD_PLV in kvm_arch_vcpu_in_kernel()
Tao Cui [Thu, 9 Apr 2026 10:56:36 +0000 (18:56 +0800)] 
LoongArch: KVM: Use CSR_CRMD_PLV in kvm_arch_vcpu_in_kernel()

The function reads LOONGARCH_CSR_CRMD but uses CSR_PRMD_PPLV to
extract the privilege level. While both masks have the same value
(0x3), CSR_CRMD_PLV is the semantically correct constant for CRMD.

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2 weeks agoMerge branch 'r8152-add-support-for-the-rtl8157-5gbit-usb-ethernet-chip'
Paolo Abeni [Thu, 9 Apr 2026 10:16:47 +0000 (12:16 +0200)] 
Merge branch 'r8152-add-support-for-the-rtl8157-5gbit-usb-ethernet-chip'

Birger Koblitz says:

====================
r8152: Add support for the RTL8157 5Gbit USB Ethernet chip

Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
chip in the RTL815x family of chips.

The RTL8157 uses a different frame descriptor format, and different
SRAM/ADV access methods, plus offers 5GBit/s Ethernet, so support for these
features is added in addition to chip initialization and configuration.

The module was tested with an OEM RTL8157 USB adapter:
[25758.328238] usb 4-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[25758.345565] usb 4-1: New USB device found, idVendor=0bda, idProduct=8157, bcdDevice=30.00
[25758.345585] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[25758.345593] usb 4-1: Product: USB 10/100/1G/2.5G/5G LAN
[25758.345599] usb 4-1: Manufacturer: Realtek
[25758.345605] usb 4-1: SerialNumber: 000300E04C68xxxx
[25758.534241] r8152-cfgselector 4-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[25758.603511] r8152 4-1:1.0: skip request firmware
[25758.653351] r8152 4-1:1.0 eth0: v1.12.13
[25758.689271] r8152 4-1:1.0 enx00e04c68xxxx: renamed from eth0
[25763.271682] r8152 4-1:1.0 enx00e04c68xxxx: carrier on

The RTL8157 adapter was tested against an AQC107 PCIe-card supporting
10GBit/s and an RTL8126 5Gbit PCIe-card supporting 5GBit/s for
performance, link speed and EEE negotiation. Using USB3.2 Gen 1 with
the RTL8157 USB adapter and running iperf3 against the AQC107 PCIe
card resulted in 3.47 Gbits/sec, whereas using USB3.2 Gen2 resulted
in 4.70 Gbits/sec, speeds against the RTL8126-card were the same.

As the code integrates the RTL8157-specific code with existing RTL8156 code
in order to improve code maintainability (instead of adding RTL8157-specific
functions duplicaing most of the RTL8156 code), regression tests were done
with an Edimax EU-4307 V1.0 USB-Ethernet adapter with RTL8156.

The code is based on the out-of-tree r8152 driver published by Realtek under
the GPL.

This patch is on top of linux-next as the code re-uses the 2.5 Gbit EEE
recently added in r8152.c.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
====================

Link: https://patch.msgid.link/20260404-rtl8157_next-v7-0-039121318f23@birger-koblitz.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agor8152: Add support for the RTL8157 hardware
Birger Koblitz [Sat, 4 Apr 2026 07:57:43 +0000 (09:57 +0200)] 
r8152: Add support for the RTL8157 hardware

The RTL8157 uses a different packet descriptor format compared to the
previous generation of chips. Add support for this format by adding a
descriptor format structure into the r8152 structure and corresponding
desc_ops functions which abstract the vlan-tag, tx/rx len and
tx/rx checksum algorithms.

Also, add support for the ADV indirect access interface of the RTL8157
and PHY setup.

For initialization of the RTL8157, combine the existing RTL8156B and
RTL8156 init functions and add RTL8157-specific functinality in order
to improve code readability and maintainability.
r8156_init() is now called with RTL_VER_10 and RTL_VER_11 for the RTL8156,
with RTL_VER_12, RTL_VER_13 and RTL_VER_15 for the RTL8156B and with
RTL_VER_16 for the RTL8157 and checks the version for chip-specific code.
Also add USB power control functions for the RTL8157.

Add support for the USB device ID of Realtek RTL8157-based adapters. Detect
the RTL8157 as RTL_VER_16 and set it up.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Link: https://patch.msgid.link/20260404-rtl8157_next-v7-2-039121318f23@birger-koblitz.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agor8152: Add support for 5Gbit Link Speeds and EEE
Birger Koblitz [Sat, 4 Apr 2026 07:57:42 +0000 (09:57 +0200)] 
r8152: Add support for 5Gbit Link Speeds and EEE

The RTL8157 supports 5GBit Link speeds. Add support for this speed
in the setup and setting/getting through ethtool. Also add 5GBit EEE.
Add functionality for setup and ethtool get/set methods.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Link: https://patch.msgid.link/20260404-rtl8157_next-v7-1-039121318f23@birger-koblitz.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agoALSA: hda/senarytech: Clean up with the new GPIO helper
Takashi Iwai [Thu, 9 Apr 2026 09:38:23 +0000 (11:38 +0200)] 
ALSA: hda/senarytech: Clean up with the new GPIO helper

Use the new GPIO helper function to clean up the open code.

Merely a code refactoring, and no behavior change.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-11-tiwai@suse.de
2 weeks agoALSA: hda/conexant: Clean up with the new GPIO helper
Takashi Iwai [Thu, 9 Apr 2026 09:38:22 +0000 (11:38 +0200)] 
ALSA: hda/conexant: Clean up with the new GPIO helper

Use the new GPIO helper function to clean up the open code.

Merely a code refactoring, and no behavior change.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-10-tiwai@suse.de
2 weeks agoALSA: hda/cirrus: Clean up with the new GPIO helper
Takashi Iwai [Thu, 9 Apr 2026 09:38:21 +0000 (11:38 +0200)] 
ALSA: hda/cirrus: Clean up with the new GPIO helper

Use the new GPIO helper function to clean up the open code.

Merely a code refactoring, and no behavior change.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-9-tiwai@suse.de
2 weeks agoALSA: hda/ca0132: Clean up with the new GPIO helper
Takashi Iwai [Thu, 9 Apr 2026 09:38:20 +0000 (11:38 +0200)] 
ALSA: hda/ca0132: Clean up with the new GPIO helper

Use the new GPIO helper function to clean up the open code.

Merely a code refactoring, and no behavior change.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-8-tiwai@suse.de
2 weeks agoALSA: hda/sigmatel: Clean up with the new GPIO helper
Takashi Iwai [Thu, 9 Apr 2026 09:38:19 +0000 (11:38 +0200)] 
ALSA: hda/sigmatel: Clean up with the new GPIO helper

Use the new GPIO helper function to clean up the open code.

Merely a code refactoring, and no behavior change.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-7-tiwai@suse.de
2 weeks agoALSA: hda/analog: Fix GPIO verb orders
Takashi Iwai [Thu, 9 Apr 2026 09:38:18 +0000 (11:38 +0200)] 
ALSA: hda/analog: Fix GPIO verb orders

So far we used the verb cache to restore the GPIO mask, direction and
data bits at PM resume.  But, due to the nature of the cache resume
mechanism, the calling order isn't guaranteed, and this might lead to
some inconsistency at the restored state.

For assuring the GPIO verb orders, use the new GPIO helper function to
explicitly set up the GPIO bits, instead of using the codec verb
caches, while keeping the current data bits in ad198x_spec.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-6-tiwai@suse.de
2 weeks agoALSA: hda/alc662: Simplify the quirk for CSL Unity BF24B
Takashi Iwai [Thu, 9 Apr 2026 09:38:17 +0000 (11:38 +0200)] 
ALSA: hda/alc662: Simplify the quirk for CSL Unity BF24B

The previous implementation of the quirk for CSL Unity BF24B in commit
de65275fc94e ("ALSA: hda/realtek: Add quirk for CSL Unity BF24B")
introduced the unnecessary GPIO caching which leads to a superfluous
write at each init/resume.

Use the new helper to write GPIO bits directly for optimization.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-5-tiwai@suse.de
2 weeks agoALSA: hda/realtek: Clean up with snd_hda_codec_set_gpio()
Takashi Iwai [Thu, 9 Apr 2026 09:38:16 +0000 (11:38 +0200)] 
ALSA: hda/realtek: Clean up with snd_hda_codec_set_gpio()

Use a new helper function to clean up the code.

Along with it, make alc_write_gpio() static as well, which is used
only locally in realtek.c.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-4-tiwai@suse.de
2 weeks agoALSA: hda: Add a simple GPIO setup helper function
Takashi Iwai [Thu, 9 Apr 2026 09:38:15 +0000 (11:38 +0200)] 
ALSA: hda: Add a simple GPIO setup helper function

Introduce a common GPIO setup helper function, so that we can clean up
the open code found in many codec drivers later.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-3-tiwai@suse.de
2 weeks agoALSA: hda: Add sync version of snd_hda_codec_write()
Takashi Iwai [Thu, 9 Apr 2026 09:38:14 +0000 (11:38 +0200)] 
ALSA: hda: Add sync version of snd_hda_codec_write()

We used snd_hda_codec_read() for the verb write when a synchronization
is needed after the write, e.g. for the power state toggle or such
cases.  It works in principle, but it looks rather confusing and too
hackish.

For improving the code readability, introduce a new helper function,
snd_hda_codec_write_sync(), which is another variant of
snd_hda_codec_write(), and replace the existing snd_hda_codec_read()
calls with this one.

No behavior change but just the code refactoring.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260409093826.1317626-2-tiwai@suse.de
2 weeks agoALSA: usb-audio: Add iface reset and delay quirk for HUAWEI USB-C HEADSET
Lianqin Hu [Thu, 9 Apr 2026 08:21:37 +0000 (08:21 +0000)] 
ALSA: usb-audio: Add iface reset and delay quirk for HUAWEI USB-C HEADSET

Setting up the interface when suspended/resumeing fail on this card.
Adding a reset and delay quirk will eliminate this problem.

usb 1-1: new full-speed USB device number 2 using xhci-hcd
usb 1-1: New USB device found, idVendor=12d1, idProduct=3a07
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: HUAWEI USB-C HEADSET
usb 1-1: Manufacturer: bestechnic
usb 1-1: SerialNumber: 0296C100000000000000000000000

Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Link: https://patch.msgid.link/TYUPR06MB62176A18EA7A9DD0AC2826BCD2582@TYUPR06MB6217.apcprd06.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 weeks agoALSA: msnd: add ISA and PnP system sleep callbacks
Cássio Gabriel [Thu, 9 Apr 2026 05:07:46 +0000 (02:07 -0300)] 
ALSA: msnd: add ISA and PnP system sleep callbacks

The msnd drivers do not implement system sleep callbacks today, so
they have no defined way to recover DSP state after suspend.

Add common card suspend/resume helpers, rerun the DSP
initialization path on resume, restore the cached capture-source
state, and rearm the shared IRQ for already-open users.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260409-msnd-pm-support-v1-2-2abef720d0e7@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 weeks agoALSA: msnd: prepare system sleep support
Cássio Gabriel [Thu, 9 Apr 2026 05:07:45 +0000 (02:07 -0300)] 
ALSA: msnd: prepare system sleep support

System suspend cannot work for msnd today because the PCM trigger
paths reject SNDRV_PCM_TRIGGER_SUSPEND, and the driver has only
refcounted IRQ helpers.

Add the small helpers needed by the PM callbacks and restore master
volume from the cached ALSA mixer state when the DSP is
reinitialized.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260409-msnd-pm-support-v1-1-2abef720d0e7@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 weeks agoALSA: i2c: ak4xxx-adda: seed AK5365 cache with reset defaults
Cássio Gabriel [Wed, 8 Apr 2026 15:17:37 +0000 (12:17 -0300)] 
ALSA: i2c: ak4xxx-adda: seed AK5365 cache with reset defaults

snd_akm4xxx_init() clears the register and volume caches before
dispatching by codec type. The AK5365 case then returns immediately,
leaving the software cache at zero instead of the documented AK5365
reset defaults.

The AK5365 capture volume controls read from volumes[] and the proc
register dump reads from images[], so the initial capture volume state
and proc output are wrong until a control write happens.

Seed the AK5365 cache with its documented reset defaults instead of
adding a guessed init sequence. The datasheet documents the reset
values and states that MCLK/LRCK changes do not require a PDN/PWN
reset because the chip has a built-in reset-free circuit.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260408-ak5365-cache-defaults-v1-1-fff639aca3e3@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 weeks agodrm/i915/gem: Drop check for changed VM in EXECBUF
Joonas Lahtinen [Thu, 9 Apr 2026 05:31:11 +0000 (08:31 +0300)] 
drm/i915/gem: Drop check for changed VM in EXECBUF

Since the introduction of d4433c7600f7 ("drm/i915/gem: Use the proto-context
to handle create parameters (v5)") it has not been possible for VM to change
after context creation so the check will never fail.

Sima's analysis:

  This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's
  obj:vma lut into its own mutex") but without any hint in the commit
  message as to why. In another hunk of that commit there's a hint though in
  __eb_add_lut:

          /* user racing with ctx set-vm */

  This would mean that this bug was introduced in e0695db7298e ("drm/i915:
  Create/destroy VM (ppGTT) for use with contexts"), which allowed to change
  the gem_ctx->vm at runtime, opening up the race that was partially fixed
  in the earlier referenced commit about a year later.

  But it cannot be exploited anymore in anything remotely recent because
  with the introduction of proto-contexts we've made gem_ctx->vm invariant
  again, exactly to preemptively close all these potential issues.
  Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
  create parameters (v5)") is the vm specific part of the proto-context
  work.

v3:
- Include Sima's analysis and WARN_ON_ONCE

v4:
- Focus only on latest mainline codebase

References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Simona Vetter <simona.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://patch.msgid.link/20260409053111.8914-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit f6d4afc9ec6a0bc326151b35a7a3369369180079)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2 weeks agonet/mlx5: Add icm_mng_function_id_mode cap bit
Moshe Shemesh [Fri, 3 Apr 2026 09:00:28 +0000 (12:00 +0300)] 
net/mlx5: Add icm_mng_function_id_mode cap bit

Introduce the capability bit icm_mng_function_id_mode to indicate that
the device firmware uses vhca_id instead of function_id as the effective
identifier for the firmware commands MANAGE_PAGES, QUERY_PAGES, and page
request event.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260403090028.137783-3-tariqt@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
2 weeks agonet/mlx5: Rename MLX5_PF page counter type to MLX5_SELF
Moshe Shemesh [Fri, 3 Apr 2026 09:00:27 +0000 (12:00 +0300)] 
net/mlx5: Rename MLX5_PF page counter type to MLX5_SELF

The MLX5_PF enum value in mlx5_func_type is used to track firmware
page allocations for the page manager function itself, which is either
the ECPF on SmartNIC systems or the host PF when there is no ECPF.

Rename it to MLX5_SELF to accurately reflect that this counter tracks
pages allocated by the manager for its own use, regardless of whether
it is a PF or ECPF.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260403090028.137783-2-tariqt@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
2 weeks agopinctrl: qcom: Add Hawi pinctrl driver
Mukesh Ojha [Wed, 8 Apr 2026 14:15:48 +0000 (19:45 +0530)] 
pinctrl: qcom: Add Hawi pinctrl driver

Add pinctrl driver for TLMM block found in the Hawi SoC.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agodt-bindings: pinctrl: qcom: Describe Hawi TLMM block
Mukesh Ojha [Wed, 8 Apr 2026 14:15:47 +0000 (19:45 +0530)] 
dt-bindings: pinctrl: qcom: Describe Hawi TLMM block

The Top Level Mode Multiplexer (TLMM) in the Qualcomm Hawi SoC
provides GPIO and pinctrl functionality for UFS, SDC and 226
GPIO pins.

Add a DeviceTree binding to describe the TLMM block on Qualcomm's
Hawi SoC.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agodt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
Svyatoslav Ryhel [Mon, 6 Apr 2026 07:51:14 +0000 (10:51 +0300)] 
dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema

Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agodt-bindings: gpio: cavium,thunder-8890: Remove DT binding
Shi Hao [Wed, 8 Apr 2026 09:33:13 +0000 (15:03 +0530)] 
dt-bindings: gpio: cavium,thunder-8890: Remove DT binding

Remove the cavium,thunder-8890 GPIO binding as there are no active
use cases. The binding is unused as the corresponding kernel driver
binds via PCI and not the compatible.

Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260408093313.17025-1-i.shihao.999@gmail.com
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2 weeks agogpio: tegra: fix irq_release_resources calling enable instead of disable
Samasth Norway Ananda [Tue, 7 Apr 2026 21:02:47 +0000 (14:02 -0700)] 
gpio: tegra: fix irq_release_resources calling enable instead of disable

tegra_gpio_irq_release_resources() erroneously calls tegra_gpio_enable()
instead of tegra_gpio_disable(). When IRQ resources are released, the
GPIO configuration bit (CNF) should be cleared to deconfigure the pin as
a GPIO. Leaving it enabled wastes power and can cause unexpected behavior
if the pin is later reused for an alternate function via pinctrl.

Fixes: 66fecef5bde0 ("gpio: tegra: Convert to gpio_irq_chip")
Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Link: https://patch.msgid.link/20260407210247.1737938-1-samasth.norway.ananda@oracle.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2 weeks agopinctrl: single: Add bcm7038-padconf compatible matching
Florian Fainelli [Tue, 7 Apr 2026 23:56:11 +0000 (16:56 -0700)] 
pinctrl: single: Add bcm7038-padconf compatible matching

Just like the TI J7200 padconf, we lose the context and therefore need
to save it and restore it across suspend/resume states.

Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
[linusw@kernel.org: rebased on am62l changes]
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agodt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
Florian Fainelli [Tue, 7 Apr 2026 23:56:10 +0000 (16:56 -0700)] 
dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf

Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.

Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agodt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
Janne Grunau [Fri, 20 Mar 2026 12:23:23 +0000 (13:23 +0100)] 
dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible

The pin controller on the Apple silicon t8122 (M3) SoC is compatible
with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
compatible under "apple,t8103-pinctrl" used by the driver.

Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agofbdev: omap2: fix inconsistent lock returns in omapfb_mmap
Hongling Zeng [Thu, 2 Apr 2026 09:34:03 +0000 (17:34 +0800)] 
fbdev: omap2: fix inconsistent lock returns in omapfb_mmap

Fix the warning about inconsistent returns for '&rg->lock' in
omapfb_mmap() function. The warning arises because the error path
uses 'ofbi->region' while the normal path uses 'rg'.

smatch warnings:
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1126 omapfb_mmap()
warn: inconsistent returns '&rg->lock'.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Signed-off-by: Helge Deller <deller@gmx.de>
2 weeks agol2tp: Drop large packets with UDP encap
Alice Mikityanska [Fri, 3 Apr 2026 17:49:49 +0000 (20:49 +0300)] 
l2tp: Drop large packets with UDP encap

syzbot reported a WARN on my patch series [1]. The actual issue is an
overflow of 16-bit UDP length field, and it exists in the upstream code.
My series added a debug WARN with an overflow check that exposed the
issue, that's why syzbot tripped on my patches, rather than on upstream
code.

syzbot's repro:

r0 = socket$pppl2tp(0x18, 0x1, 0x1)
r1 = socket$inet6_udp(0xa, 0x2, 0x0)
connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)
connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32)
writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)

It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP
encapsulation, and l2tp_xmit_core doesn't check for overflows when it
assigns the UDP length field. The value gets trimmed to 16 bites.

Add an overflow check that drops oversized packets and avoids sending
packets with trimmed UDP length to the wire.

syzbot's stack trace (with my patch applied):

len >= 65536u
WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957
WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957
WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957
Modules linked in:
CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]
RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]
RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327
Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f
RSP: 0018:ffffc90003d67878 EFLAGS: 00010293
RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000
RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff
RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900
R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000
FS:  000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg net/socket.c:742 [inline]
 sock_write_iter+0x503/0x550 net/socket.c:1195
 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1
 vfs_writev+0x33c/0x990 fs/read_write.c:1059
 do_writev+0x154/0x2e0 fs/read_write.c:1105
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f636479c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629
RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003
RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0
 </TASK>

[1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/

Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
Reported-by: syzbot+ci3edea60a44225dec@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Link: https://patch.msgid.link/20260403174949.843941-1-alice.kernel@fastmail.im
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agoarm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
Gabor Juhos [Mon, 30 Mar 2026 15:25:17 +0000 (17:25 +0200)] 
arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node

It seems that the Armada 3700 is the only platform where the USB3 specific
PHY is defined before the USB2 specific one in the device tree:

  $ git grep -E 'phy-names[ \t]*=[ \t]*"usb3-phy"[ \t]*,' next-20260327 -- *.dts *.dtsi | tr '\t' ' '
  next-20260327:arch/arm64/boot/dts/marvell/armada-37xx.dtsi:    phy-names = "usb3-phy", "usb2-utmi-otg-phy";

In contrary to this, there are 93 other platforms/boards where 'usb2-phy'
is defined first:

  $ git grep -E 'phy-names[ \t]*=[ \t]*"usb2-phy"[ \t]*,' next-20260327 -- *.dts *.dtsi | wc -l
  93

Swap the order of the USB3 and USB2 PHYs to follow the common pattern
used on other platforms.

No functional changes intended.

Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2 weeks agoarm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
Gabor Juhos [Mon, 30 Mar 2026 15:25:16 +0000 (17:25 +0200)] 
arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names

Instead of the generic 'usb2-phy' name, the Armada 37xx device trees
are using a custom 'usb2-utmi-otg-phy' name for the USB2 PHY in the USB3
controller node. Since commit 53a2d95df836 ("usb: core: add phy notify
connect and disconnect"), this triggers a bug [1] in the USB core which
causes double use of the USB3 PHY.

Change the PHY name to 'usb2-phy' in the SoC and in the uDPU specific
dtsi files in order to avoid triggering the bug and also to keep the
names in line with the ones used by other platforms.

Link: https://lore.kernel.org/r/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com
Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2 weeks agoMAINTAINERS: Add dedicated entry for fbcon
Thomas Zimmermann [Thu, 9 Apr 2026 07:26:09 +0000 (09:26 +0200)] 
MAINTAINERS: Add dedicated entry for fbcon

Add an own entry for the framebuffer console code, which is jointly
used by the fbdev and DRM drivers.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
2 weeks agonet: ipa: fix event ring index not programmed for IPA v5.0+
Alexander Koskovich [Fri, 3 Apr 2026 16:43:48 +0000 (18:43 +0200)] 
net: ipa: fix event ring index not programmed for IPA v5.0+

For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to
CH_C_CNTXT_1. The v5.0 register definition intended to define this
field in the CH_C_CNTXT_1 fmask array but used the old identifier of
ERINDEX instead of CH_ERINDEX.

Without a valid event ring, GSI channels could never signal transfer
completions. This caused gsi_channel_trans_quiesce() to block
forever in wait_for_completion().

At least for IPA v5.2 this resolves an issue seen where runtime
suspend, system suspend, and remoteproc stop all hanged forever. It
also meant the IPA data path was completely non functional.

Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions")
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260403-milos-ipa-v1-2-01e9e4e03d3e@fairphone.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agonet: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
Alexander Koskovich [Fri, 3 Apr 2026 16:43:47 +0000 (18:43 +0200)] 
net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+

Fix the field masks to match the hardware layout documented in
downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*).

Notably this fixes a WARN I was seeing when I tried to send "stop"
to the MPSS remoteproc while IPA was up.

Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions")
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260403-milos-ipa-v1-1-01e9e4e03d3e@fairphone.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2 weeks agodrm/vram: remove DRM_VRAM_MM_FILE_OPERATIONS from docs
Thadeu Lima de Souza Cascardo [Wed, 8 Apr 2026 19:31:00 +0000 (16:31 -0300)] 
drm/vram: remove DRM_VRAM_MM_FILE_OPERATIONS from docs

Commit 02f64b2d8605 ("drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS") dropped
DRM_VRAM_MM_FILE_OPERATIONS in preference for using DEFINE_DRM_GEM_OPS.

However, it was not dropped from the kernel docs.

Use DEFINE_DRM_GEM_OPS in the illustration on how to define a
struct file_operations for such a DRM driver and remove any reference
to DRM_VRAM_MM_FILE_OPERATIONS.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 02f64b2d8605 ("drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260408-drm_gem_vram_helper_docs-v1-1-4d667a768f75@igalia.com
2 weeks agodrm/fb-helper: Fix a locking bug in an error path
Bart Van Assche [Fri, 3 Apr 2026 20:53:54 +0000 (13:53 -0700)] 
drm/fb-helper: Fix a locking bug in an error path

The name of the function __drm_fb_helper_initial_config_and_unlock() and
also the comment above that function make it clear that all code paths
in this function should unlock fb_helper->lock before returning. Add a
mutex_unlock() call in the only code path where it is missing. This has
been detected by the Clang thread-safety analyzer.

Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Christian König <christian.koenig@amd.com> # radeon
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # msm
Cc: Javier Martinez Canillas <javierm@redhat.com>
Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260403205355.1181984-1-bvanassche@acm.org
2 weeks agoMerge tag 'coresight-next-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel...
Greg Kroah-Hartman [Thu, 9 Apr 2026 07:21:13 +0000 (09:21 +0200)] 
Merge tag 'coresight-next-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux into char-misc-next

Suzuki writes:

coresight: Updates for Linux v7.1

CoreSight self hosted tracing subsystem updates for Linux v7.1, includes:

 - Fix unregistration related issues
 - Clean up CTI power management and sysfs code
 - Miscellaneous fixes
 - MAINTAINERS: Add Leo Yan as Reviewer
 - MAINTAINERS: Update Mike's email address

Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
* tag 'coresight-next-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux: (25 commits)
  coresight: tpdm: fix invalid MMIO access issue
  coresight: tpdm: add traceid_show for checking traceid
  coresight: platform: check the availability of the endpoint before parse
  coresight: cti: fix the check condition in inout_sel_store
  MAINTAINERS: coresight: Add Leo Yan as Reviewer
  coresight: cti: Properly handle negative offsets in cti_reg32_{show|store}()
  coresight: cti: Remove hw_enabled flag
  coresight: cti: Remove hw_powered flag
  coresight: cti: Rename cti_active() to cti_is_active()
  coresight: cti: Remove CPU power management code
  coresight: cti: Access ASICCTL only when implemented
  coresight: cti: Fix register reads
  coresight: cti: Make spinlock usage consistent
  drivers/hwtracing/coresight: remove unneeded variable in tmc_crashdata_release()
  MAINTAINERS: Change e-mail address for reviewer
  coresight: ctcu: fix the spin_bug
  coresight: Unify bus unregistration via coresight_unregister()
  coresight: Do not mix success path with failure handling
  coresight: Move sink validation into etm_perf_add_symlink_sink()
  coresight: Refactor sysfs connection group cleanup
  ...

2 weeks agopinctrl: qcom: sdm670-lpass-lpi: label variables as static
Richard Acayan [Wed, 8 Apr 2026 22:30:38 +0000 (18:30 -0400)] 
pinctrl: qcom: sdm670-lpass-lpi: label variables as static

These variables are local to the driver and have no need to be exported
to the global namespace. Label them as static to fix compiler warnings.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604080950.Mvm8aN0a-lkp@intel.com/
Fixes: 9826035a75da ("pinctrl: qcom: add sdm670 lpi tlmm")
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
2 weeks agowifi: cfg80211: Explicitly include <linux/export.h> in michael-mic.c
Eric Biggers [Thu, 9 Apr 2026 03:03:33 +0000 (20:03 -0700)] 
wifi: cfg80211: Explicitly include <linux/export.h> in michael-mic.c

This happened to be included transitively via a long chain starting with
<linux/bitops.h>, but it's less fragile to include it explicitly.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260409030333.13024-1-ebiggers@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2 weeks agoALSA: hda/realtek: Add quirk for CSL Unity BF24B
Zhang Heng [Thu, 9 Apr 2026 02:40:28 +0000 (10:40 +0800)] 
ALSA: hda/realtek: Add quirk for CSL Unity BF24B

The CSL Unity BF24B all-in-one PC uses a Realtek ALC662 rev3 audio
codec and requires the correct GPIO configuration to enable sound
output from both the speakers and the headphone.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221258
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260409024028.1297587-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 weeks agoMerge branch 'for-linus' into for-next
Takashi Iwai [Thu, 9 Apr 2026 06:31:21 +0000 (08:31 +0200)] 
Merge branch 'for-linus' into for-next

Pull 7.0-devel branch for further development of HD-audio codec quirks.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 weeks agomailmap: Add entry for Andrew Donnellan
Andrew Donnellan [Mon, 8 Dec 2025 05:13:33 +0000 (16:13 +1100)] 
mailmap: Add entry for Andrew Donnellan

I'm leaving IBM in January 2026. Add mailmap aliases to switch to using my
personal email for now.

(I will send a patch to update MAINTAINERS soon, hopefully after I can get
someone to replace me.)

Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20251208-mailmap-v1-1-524d5b9d175b@linux.ibm.com
2 weeks agoMerge tag 'asoc-fix-v7.0-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git...
Takashi Iwai [Thu, 9 Apr 2026 05:00:53 +0000 (07:00 +0200)] 
Merge tag 'asoc-fix-v7.0-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v7.0

A somewhat larger set of fixes than I'd like unfortunatey, not from any
one place but rather spread out over different drivers.  We've got a
bunch more fixes for the SDCA interrupt support, several relatively
minor SOF fixes, a few more driver specific fixes and a couple more AMD
quirks.

2 weeks agoperf test: Make perf trace BTF general tests exclusive
Thomas Richter [Wed, 8 Apr 2026 11:31:43 +0000 (13:31 +0200)] 
perf test: Make perf trace BTF general tests exclusive

Running both tests cases 126 128 together causes the first test case
126 to fail:
 # for i in $(seq 3); do ./perf test 'perf trace BTF general tests' \
'perf trace record and replay'; done
 126: perf trace BTF general tests    : FAILED!
 128: perf trace record and replay    : Ok
 126: perf trace BTF general tests    : FAILED!
 128: perf trace record and replay    : Ok
 126: perf trace BTF general tests    : FAILED!
 128: perf trace record and replay    : Ok
 #

Test case 126 fails because test case 128 runs concurrently as can
be observed using a ps -ef | grep perf output list on a different
window. Both do a perf trace command concurrently.
Make test case 'perf trace BTF general tests' exclusive.

Output after:
 # for i in $(seq 3); do ./perf test 'perf trace BTF general tests' \
'perf trace record and replay'; done
 127: perf trace BTF general tests                   : Ok
 155: perf trace record and replay                   : Ok
 127: perf trace BTF general tests                   : Ok
 155: perf trace record and replay                   : Ok
 127: perf trace BTF general tests                   : Ok
 155: perf trace record and replay                   : Ok
 #

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Acked-by: Howard Chu <howardchu95@gmail.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2 weeks agoMerge tag 'drm-xe-fixes-2026-04-08' of https://gitlab.freedesktop.org/drm/xe/kernel...
Dave Airlie [Thu, 9 Apr 2026 04:38:01 +0000 (14:38 +1000)] 
Merge tag 'drm-xe-fixes-2026-04-08' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

- Fix HW engine idleness unit conversion (Vinay)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/ada0IQSyELI2V0Og@intel.com
2 weeks agoMerge branch '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net...
Jakub Kicinski [Thu, 9 Apr 2026 03:05:10 +0000 (20:05 -0700)] 
Merge branch '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue

Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2026-04-06 (idpf, ice, ixgbe, ixgbevf, igb, e1000)

Emil converts to use spinlock_t for virtchnl transactions to make
consistent use of the xn_bm_lock when accessing the free_xn_bm bitmap,
while also avoiding nested raw/bh spinlock issue on PREEMPT_RT kernels.
He also sets payload size before calling the async handler, to make sure
it doesn't error out prematurely due to invalid size check for idpf.

Kohei Enju changes WARN_ON for missing PTP control PF to a dev_info() on
ice as there are cases where this is expected and acceptable.

Petr Oros fixes conditions in which error paths failed to call
ice_ptp_port_phy_restart() breaking PTP functionality on ice.

Alex significantly reduces reporting of driver information, and time
under RTNL locl, on ixgbe e610 devices by reducing reads of flash info
only on events that could change it.

Michal Schmidt adds missing Hyper-V op on ixgbevf.

Alex Dvoretsky removes call to napi_synchronize() in igb_down() to
resolve a deadlock.

Agalakov Daniil adds error check on e1000 for failed EEPROM read.

* '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
  e1000: check return value of e1000_read_eeprom
  igb: remove napi_synchronize() in igb_down()
  ixgbevf: add missing negotiate_features op to Hyper-V ops table
  ixgbe: stop re-reading flash on every get_drvinfo for e610
  ice: fix PTP timestamping broken by SyncE code on E825C
  ice: ptp: don't WARN when controlling PF is unavailable
  idpf: set the payload size before calling the async handler
  idpf: improve locking around idpf_vc_xn_push_free()
  idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
====================

Link: https://patch.msgid.link/20260406213038.444732-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoMerge branch 'devlink-add-per-port-resource-support'
Jakub Kicinski [Thu, 9 Apr 2026 02:55:43 +0000 (19:55 -0700)] 
Merge branch 'devlink-add-per-port-resource-support'

Tariq Toukan says:

====================
devlink: add per-port resource support

This series by Or adds devlink per-port resource support:

Currently, devlink resources are only available at the device level.
However, some resources are inherently per-port, such as the maximum
number of subfunctions (SFs) that can be created on a specific PF port.
This limitation prevents user space from obtaining accurate per-port
capacity information.
This series adds infrastructure for per-port resources in devlink core
and implements it in the mlx5 driver to expose the max_SFs resource
on PF devlink ports.

Patch #1  refactors resource functions to be generic
Patch #2  adds port-level resource registration infrastructure
Patch #3  registers SF resource on PF port representor in mlx5
Patch #4  adds devlink port resource registration to netdevsim for testing
Patch #5  adds dump support for device-level resources
Patch #6  includes port resources in the resource dump dumpit path
Patch #7  adds port-specific option to resource dump doit path
Patch #8  adds selftest for devlink port resource doit
Patch #9  documents port-level resources and full dump
Patch #10 adds resource scope filtering to resource dump
Patch #11 adds selftest for resource dump and scope filter
Patch #12 documents resource scope filtering
====================

Link: https://patch.msgid.link/20260407194107.148063-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Document resource scope filtering
Or Har-Toov [Tue, 7 Apr 2026 19:41:07 +0000 (22:41 +0300)] 
devlink: Document resource scope filtering

Document the scope parameter for devlink resource show, which allows
filtering the dump to device-level or port-level resources only.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-13-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoselftest: netdevsim: Add resource dump and scope filter test
Or Har-Toov [Tue, 7 Apr 2026 19:41:06 +0000 (22:41 +0300)] 
selftest: netdevsim: Add resource dump and scope filter test

Add resource_dump_test() which verifies dumping resources for all
devices and ports, and tests that scope=dev returns only device-level
resources and scope=port returns only port resources.

Skip if userspace does not support the scope parameter.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-12-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Add resource scope filtering to resource dump
Or Har-Toov [Tue, 7 Apr 2026 19:41:05 +0000 (22:41 +0300)] 
devlink: Add resource scope filtering to resource dump

Allow filtering the resource dump to device-level or port-level
resources using the 'scope' option.

Example - dump only device-level resources:

  $ devlink resource show scope dev
  pci/0000:03:00.0:
    name max_local_SFs size 128 unit entry dpipe_tables none
    name max_external_SFs size 128 unit entry dpipe_tables none
  pci/0000:03:00.1:
    name max_local_SFs size 128 unit entry dpipe_tables none
    name max_external_SFs size 128 unit entry dpipe_tables none

Example - dump only port-level resources:

  $ devlink resource show scope port
  pci/0000:03:00.0/196608:
    name max_SFs size 128 unit entry dpipe_tables none
  pci/0000:03:00.0/196609:
    name max_SFs size 128 unit entry dpipe_tables none
  pci/0000:03:00.1/196708:
    name max_SFs size 128 unit entry dpipe_tables none
  pci/0000:03:00.1/196709:
    name max_SFs size 128 unit entry dpipe_tables none

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-11-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Document port-level resources and full dump
Or Har-Toov [Tue, 7 Apr 2026 19:41:04 +0000 (22:41 +0300)] 
devlink: Document port-level resources and full dump

Document the port-level resource support and the option to dump all
resources, including both device-level and port-level entries.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-10-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoselftest: netdevsim: Add devlink port resource doit test
Or Har-Toov [Tue, 7 Apr 2026 19:41:03 +0000 (22:41 +0300)] 
selftest: netdevsim: Add devlink port resource doit test

Tests that querying a specific port handle returns the expected
resource name and size.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-9-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Add port-specific option to resource dump doit
Or Har-Toov [Tue, 7 Apr 2026 19:41:02 +0000 (22:41 +0300)] 
devlink: Add port-specific option to resource dump doit

Allow querying devlink resources per-port via the resource-dump doit
handler. When a port-index attribute is provided, only that port's
resources are returned. When no port-index is given, only device-level
resources are returned, preserving backward compatibility.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-8-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Include port resources in resource dump dumpit
Or Har-Toov [Tue, 7 Apr 2026 19:41:01 +0000 (22:41 +0300)] 
devlink: Include port resources in resource dump dumpit

Allow querying devlink resources per-port via the resource-dump dumpit
handler. Both device-level and all ports resources are included in the
reply.

For example:

$ devlink resource show
pci/0000:03:00.0:
  name local_max_SFs size 508 unit entry
  name external_max_SFs size 508 unit entry
pci/0000:03:00.0/196608:
  name max_SFs size 20 unit entry
pci/0000:03:00.1:
  name local_max_SFs size 508 unit entry
  name external_max_SFs size 508 unit entry
pci/0000:03:00.1/262144:
  name max_SFs size 20 unit entry

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-7-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Add dump support for device-level resources
Or Har-Toov [Tue, 7 Apr 2026 19:41:00 +0000 (22:41 +0300)] 
devlink: Add dump support for device-level resources

Add dumpit handler for resource-dump command to iterate over all devlink
devices and show their resources.

  $ devlink resource show
  pci/0000:08:00.0:
    name local_max_SFs size 508 unit entry
    name external_max_SFs size 508 unit entry
  pci/0000:08:00.1:
    name local_max_SFs size 508 unit entry
    name external_max_SFs size 508 unit entry

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-6-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonetdevsim: Add devlink port resource registration
Or Har-Toov [Tue, 7 Apr 2026 19:40:59 +0000 (22:40 +0300)] 
netdevsim: Add devlink port resource registration

Register port-level resources for netdevsim ports to enable testing
of the port resource infrastructure.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-5-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonet/mlx5: Register SF resource on PF port representor
Or Har-Toov [Tue, 7 Apr 2026 19:40:58 +0000 (22:40 +0300)] 
net/mlx5: Register SF resource on PF port representor

The device-level "resource show" displays max_local_SFs and
max_external_SFs without indicating which port each resource belongs
to. Users cannot determine the controller number and pfnum associated
with each SF pool.

Register max_SFs resource on the host PF representor port to expose
per-port SF limits. Users can correlate the port resource with the
controller number and pfnum shown in 'devlink port show'.

Future patches will introduce an ECPF that manages multiple PFs,
where each PF has its own SF pool.

Example usage:

  $ devlink resource show pci/0000:03:00.0/196608
  pci/0000:03:00.0/196608:
    name max_SFs size 20 unit entry

  $ devlink port show pci/0000:03:00.0/196608
  pci/0000:03:00.0/196608: type eth netdev pf0hpf flavour pcipf
    controller 1 pfnum 0 external true splittable false
    function:
      hw_addr b8:3f:d2:e1:8f:dc roce enable max_io_eqs 120

We can create up to 20 SFs over devlink port pci/0000:03:00.0/196608,
with pfnum 0 and controller 1.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-4-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Add port-level resource registration infrastructure
Or Har-Toov [Tue, 7 Apr 2026 19:40:57 +0000 (22:40 +0300)] 
devlink: Add port-level resource registration infrastructure

The current devlink resource infrastructure supports only device-level
resources. Some hardware resources are associated with specific ports
rather than the entire device, and today we have no way to show resource
per-port.

Add support for registering resources at the port level.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agodevlink: Refactor resource functions to be generic
Or Har-Toov [Tue, 7 Apr 2026 19:40:56 +0000 (22:40 +0300)] 
devlink: Refactor resource functions to be generic

Currently the resource functions take devlink pointer as parameter
and take the resource list from there.
Allow resource functions to work with other resource lists that will
be added in next patches and not only with the devlink's resource list.

Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260407194107.148063-2-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoselftests/drivers/net: Add an xdp test to xdp.py
Leon Hwang [Mon, 6 Apr 2026 07:26:54 +0000 (15:26 +0800)] 
selftests/drivers/net: Add an xdp test to xdp.py

In "bpf: Disallow freplace on XDP with mismatched xdp_has_frags values" [1],
this XDP test is suggested to add to xdp.py.

1. Verify the failure of updating frag-capable prog with non-frag-capable
   prog, when the frag-capable prog attaches to mtu=9k driver.

The test has been verified against Mellanox CX6 and Intel 82599ES NICs.

With dropping other tests, here is the test log.

 # ethtool -i eth0
 driver: mlx5_core
 version: 6.19.0-061900-generic

 # NETIF=eth0 python3 xdp.py
 TAP version 13
 1..1
 ok 1 xdp.test_xdp_native_update_mb_to_sb
 # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0

 # ethtool -i eth0
 driver: ixgbe
 version: 6.19.0-061900-generic

 # NETIF=eth0 python3 xdp.py
 TAP version 13
 1..1
 # CMD: ip  link set dev eth0 xdpdrv obj /path/to/tools/testing/selftests/net/lib/xdp_dummy.bpf.o sec xdp.frags
 #   EXIT: 2
 #   STDERR: RTNETLINK answers: Invalid argument
 ok 1 xdp.test_xdp_native_update_mb_to_sb # SKIP device does not support multi-buffer XDP
 # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0

Signed-off-by: Leon Hwang <leon.huangfu@shopee.com>
Link: https://patch.msgid.link/20260406072655.368173-1-leon.huangfu@shopee.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoMAINTAINERS: Add Prashanth as additional maintainer for amd-xgbe driver
Raju Rangoju [Mon, 6 Apr 2026 07:38:16 +0000 (13:08 +0530)] 
MAINTAINERS: Add Prashanth as additional maintainer for amd-xgbe driver

Add Prashanth as an additional maintainer for the amd-xgbe Ethernet
driver to help with ongoing development and maintenance.

Cc: Prashanth Kumar K R <PrashanthKumar.K.R@amd.com>
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
Link: https://patch.msgid.link/20260406073816.3218387-1-Raju.Rangoju@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoMerge branch 'dsa_loop-and-platform_data-cleanups'
Jakub Kicinski [Thu, 9 Apr 2026 02:38:55 +0000 (19:38 -0700)] 
Merge branch 'dsa_loop-and-platform_data-cleanups'

Vladimir Oltean says:

====================
dsa_loop and platform_data cleanups

While working to add some new features to dsa_loop, I gathered a number
of cleanup patches. They mostly remove some data structures that became
unused after the multi-switch platforms were migrated to the modern DT
bindings.
====================

Link: https://patch.msgid.link/20260406212158.721806-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonet: dsa: eliminate <linux/dsa/loop.h>
Vladimir Oltean [Mon, 6 Apr 2026 21:21:58 +0000 (00:21 +0300)] 
net: dsa: eliminate <linux/dsa/loop.h>

There is no reason at all to export these data types to the global
include directory.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260406212158.721806-5-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonet: dsa: remove unused platform_data definitions
Vladimir Oltean [Mon, 6 Apr 2026 21:21:57 +0000 (00:21 +0300)] 
net: dsa: remove unused platform_data definitions

Pretty self-explanatory, nobody needs these.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260406212158.721806-4-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonet: dsa: clean up struct dsa_chip_data
Vladimir Oltean [Mon, 6 Apr 2026 21:21:56 +0000 (00:21 +0300)] 
net: dsa: clean up struct dsa_chip_data

This has accumulated some fields which are no longer parsed by the core
or set by any driver. Remove them.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260406212158.721806-3-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonet: dsa: remove struct platform_data
Vladimir Oltean [Mon, 6 Apr 2026 21:21:55 +0000 (00:21 +0300)] 
net: dsa: remove struct platform_data

This is not used anywhere in the kernel.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260406212158.721806-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoscsi: target: Don't validate ignored fields in PROUT PREEMPT
Stefan Hajnoczi [Thu, 2 Apr 2026 18:03:42 +0000 (14:03 -0400)] 
scsi: target: Don't validate ignored fields in PROUT PREEMPT

The PERSISTENT RESERVE OUT command's PREEMPT service action provides two
different functions: 1. preempting persistent reservations and 2.
removing registrations. In the latter case the spec says:

  b) ignore the contents of the SCOPE field and the TYPE field;

The code currently validates the SCOPE and TYPE fields even when PREEMPT
is called to remove registrations.

This patch achieves spec compliance by validating the SCOPE and TYPE
fields only when they will actually be used.

To confirm my interpretation of the specification I tested against HPE
3PAR storage and found the TYPE field is indeed ignored in this case.

Cc: Maurizio Lombardi <mlombard@redhat.com>
Cc: Dmitry Bogdanov <d.bogdanov@yadro.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Link: https://patch.msgid.link/20260402180342.126583-1-stefanha@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2 weeks agodevlink: Fix incorrect skb socket family dumping
Li RongQing [Tue, 7 Apr 2026 02:27:30 +0000 (22:27 -0400)] 
devlink: Fix incorrect skb socket family dumping

The devlink_fmsg_dump_skb function was incorrectly using the socket
type (sk->sk_type) instead of the socket family (sk->sk_family)
when filling the "family" field in the fast message dump.

This patch fixes this to properly display the socket family.

Fixes: 3dbfde7f6bc7b8 ("devlink: add devlink_fmsg_dump_skb() function")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://patch.msgid.link/20260407022730.2393-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoaf_unix: read UNIX_DIAG_VFS data under unix_state_lock
Jiexun Wang [Tue, 7 Apr 2026 08:00:14 +0000 (16:00 +0800)] 
af_unix: read UNIX_DIAG_VFS data under unix_state_lock

Exact UNIX diag lookups hold a reference to the socket, but not to
u->path. Meanwhile, unix_release_sock() clears u->path under
unix_state_lock() and drops the path reference after unlocking.

Read the inode and device numbers for UNIX_DIAG_VFS while holding
unix_state_lock(), then emit the netlink attribute after dropping the
lock.

This keeps the VFS data stable while the reply is being built.

Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260407080015.1744197-1-n05ec@lzu.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoscsi: qla2xxx: Use nr_cpu_ids instead of NR_CPUS for qp_cpu_map allocation
Li RongQing [Tue, 31 Mar 2026 05:32:45 +0000 (01:32 -0400)] 
scsi: qla2xxx: Use nr_cpu_ids instead of NR_CPUS for qp_cpu_map allocation

Change the memory allocation for qp_cpu_map to use the actual number of
CPUs ('nr_cpu_ids') instead of the maximum possible CPUs ('NR_CPUS').
This saves memory on systems where the maximum CPU limit is much higher
than the active CPU count.

Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://patch.msgid.link/20260331053245.1839-1-lirongqing@baidu.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2 weeks agoMerge branch 'mptcp-autotune-related-improvement'
Jakub Kicinski [Thu, 9 Apr 2026 02:32:05 +0000 (19:32 -0700)] 
Merge branch 'mptcp-autotune-related-improvement'

Matthieu Baerts says:

====================
mptcp: autotune related improvement

Here are two patches from Paolo that have been crafted a couple of
months ago, but needed more validation because they were indirectly
causing instabilities in the sefltests. The root cause has been fixed in
'net' recently in commit 8c09412e584d ("selftests: mptcp: more stable
simult_flows tests").

These patches refactor the receive space and RTT estimator, overall
making DRS more correct while avoiding receive buffer drifting to
tcp_rmem[2], which in turn makes the throughput more stable and less
bursty, especially with high bandwidth and low delay environments.

Note that the first patch addresses a very old issue. 'net-next' is
targeted because the change is quite invasive and based on a recent
backlog refactor. The 'Fixes' tag is then there more as a FYI, because
backporting this patch will quickly be blocked due to large conflicts.
====================

Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-0-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agomptcp: add receive queue awareness in tcp_rcv_space_adjust()
Paolo Abeni [Tue, 7 Apr 2026 08:45:18 +0000 (10:45 +0200)] 
mptcp: add receive queue awareness in tcp_rcv_space_adjust()

This is the MPTCP counter-part of commit ea33537d8292 ("tcp: add receive
queue awareness in tcp_rcv_space_adjust()").

Prior to this commit:

  ESTAB 33165568 0      192.168.255.2:5201 192.168.255.1:53380 \
        skmem:(r33076416,rb33554432,t0,tb91136,f448,w0,o0,bl0,d0)

After:

  ESTAB 3279168 0      192.168.255.2:5201 192.168.255.1]:53042 \
        skmem:(r3190912,rb3719956,t0,tb91136,f1536,w0,o0,bl0,d0)

Same throughput.

Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-2-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agomptcp: better mptcp-level RTT estimator
Paolo Abeni [Tue, 7 Apr 2026 08:45:17 +0000 (10:45 +0200)] 
mptcp: better mptcp-level RTT estimator

The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.

On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.

Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
  DRS constantly overshooting the rcvbuf size when a subflow has
  considerable higher latency than the other(s).

- during unidirectional bulk transfers with multiple active subflows,
  the TCP-level RTT estimator occasionally sees considerably higher
  value than the real link delay, i.e. when the packet scheduler reacts
  to an incoming ACK on given subflow pushing data on a different
  subflow.

- currently inactive but still open subflows (i.e. switched to backup
  mode) are always considered when computing the msk-level RTT.

Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.

While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().

Use some care to avoid updating msk and ssk level fields too often.

Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoRevert "mptcp: add needs_id for netlink appending addr"
Matthieu Baerts (NGI0) [Tue, 7 Apr 2026 08:41:41 +0000 (10:41 +0200)] 
Revert "mptcp: add needs_id for netlink appending addr"

This commit was originally adding the ability to add MPTCP endpoints
with ID 0 by accident. The in-kernel PM, handling MPTCP endpoints at the
net namespace level, is not supposed to handle endpoints with such ID,
because this ID 0 is reserved to the initial subflow, as mentioned in
the MPTCPv1 protocol [1], a per-connection setting.

Note that 'ip mptcp endpoint add id 0' stops early with an error, but
other tools might still request the in-kernel PM to create MPTCP
endpoints with this restricted ID 0.

In other words, it was wrong to call the mptcp_pm_has_addr_attr_id
helper to check whether the address ID attribute is set: if it was set
to 0, a new MPTCP endpoint would be created with ID 0, which is not
expected, and might cause various issues later.

Fixes: 584f38942626 ("mptcp: add needs_id for netlink appending addr")
Cc: stable@vger.kernel.org
Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.2-9
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260407-net-mptcp-revert-pm-needs-id-v2-1-7a25cbc324f8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agomptcp: fix slab-use-after-free in __inet_lookup_established
Jiayuan Chen [Mon, 6 Apr 2026 03:15:10 +0000 (11:15 +0800)] 
mptcp: fix slab-use-after-free in __inet_lookup_established

The ehash table lookups are lockless and rely on
SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability
during RCU read-side critical sections. Both tcp_prot and
tcpv6_prot have their slab caches created with this flag
via proto_register().

However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into
tcpv6_prot_override during inet_init() (fs_initcall, level 5),
before inet6_init() (module_init/device_initcall, level 6) has
called proto_register(&tcpv6_prot). At that point,
tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab
remains NULL permanently.

This causes MPTCP v6 subflow child sockets to be allocated via
kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab
cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so
when these sockets are freed without SOCK_RCU_FREE (which is
cleared for child sockets by design), the memory can be
immediately reused. Concurrent ehash lookups under
rcu_read_lock can then access freed memory, triggering a
slab-use-after-free in __inet_lookup_established.

Fix this by splitting the IPv6-specific initialization out of
mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called
from mptcp_proto_v6_init() before protocol registration. This
ensures tcpv6_prot_override.slab correctly inherits the
SLAB_TYPESAFE_BY_RCU slab cache.

Fixes: b19bc2945b40 ("mptcp: implement delegated actions")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260406031512.189159-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agonet: initialize sk_rx_queue_mapping in sk_clone()
Jiayuan Chen [Tue, 7 Apr 2026 08:42:18 +0000 (16:42 +0800)] 
net: initialize sk_rx_queue_mapping in sk_clone()

sk_clone() initializes sk_tx_queue_mapping via sk_tx_queue_clear()
but does not initialize sk_rx_queue_mapping. Since this field is in
the sk_dontcopy region, it is neither copied from the parent socket
by sock_copy() nor zeroed by sk_prot_alloc() (called without
__GFP_ZERO from sk_clone).

Commit 03cfda4fa6ea ("tcp: fix another uninit-value
(sk_rx_queue_mapping)") attempted to fix this by introducing
sk_mark_napi_id_set() with force_set=true in tcp_child_process().
However, sk_mark_napi_id_set() -> sk_rx_queue_set() only writes
when skb_rx_queue_recorded(skb) is true. If the 3-way handshake
ACK arrives through a device that does not record rx_queue (e.g.
loopback or veth), sk_rx_queue_mapping remains uninitialized.

When a subsequent data packet arrives with a recorded rx_queue,
sk_mark_napi_id() -> sk_rx_queue_update() reads the uninitialized
field for comparison (force_set=false path), triggering KMSAN.

This was reproduced by establishing a TCP connection over loopback
(which does not call skb_record_rx_queue), then attaching a BPF TC
program on lo ingress to set skb->queue_mapping on data packets:

BUG: KMSAN: uninit-value in tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1875)
 tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1875)
 tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2287)
 ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)
 ip_local_deliver_finish (net/ipv4/ip_input.c:242)
 ip_local_deliver (net/ipv4/ip_input.c:262)
 ip_rcv (net/ipv4/ip_input.c:573)
 __netif_receive_skb (net/core/dev.c:6294)
 process_backlog (net/core/dev.c:6646)
 __napi_poll (net/core/dev.c:7710)
 net_rx_action (net/core/dev.c:7929)
 handle_softirqs (kernel/softirq.c:623)
 do_softirq (kernel/softirq.c:523)
 __local_bh_enable_ip (kernel/softirq.c:?)
 __dev_queue_xmit (net/core/dev.c:?)
 ip_finish_output2 (net/ipv4/ip_output.c:237)
 ip_output (net/ipv4/ip_output.c:438)
 __ip_queue_xmit (net/ipv4/ip_output.c:534)
 __tcp_transmit_skb (net/ipv4/tcp_output.c:1693)
 tcp_write_xmit (net/ipv4/tcp_output.c:3064)
 tcp_sendmsg_locked (net/ipv4/tcp.c:?)
 tcp_sendmsg (net/ipv4/tcp.c:1465)
 inet_sendmsg (net/ipv4/af_inet.c:865)
 sock_write_iter (net/socket.c:1195)
 vfs_write (fs/read_write.c:688)
 ...
Uninit was created at:
 kmem_cache_alloc_noprof (mm/slub.c:4873)
 sk_prot_alloc (net/core/sock.c:2239)
 sk_alloc (net/core/sock.c:2301)
 inet_create (net/ipv4/af_inet.c:334)
 __sock_create (net/socket.c:1605)
 __sys_socket (net/socket.c:1747)

Fix this at the root by adding sk_rx_queue_clear() alongside
sk_tx_queue_clear() in sk_clone().

Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260407084219.95718-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoscsi: ufs: core: Disable timestamp for Kioxia THGJFJT0E25BAIP
Aaron Kling [Fri, 3 Apr 2026 18:41:34 +0000 (13:41 -0500)] 
scsi: ufs: core: Disable timestamp for Kioxia THGJFJT0E25BAIP

Kioxia has another product that does not support the qTimestamp
attribute.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260403-thgjfjt0e25baip-no-timestamp-v1-1-1ddb34225133@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2 weeks agoselftests: forwarding: lib: rewrite processing of command line arguments
Ioana Ciornei [Tue, 7 Apr 2026 10:20:58 +0000 (13:20 +0300)] 
selftests: forwarding: lib: rewrite processing of command line arguments

The piece of code which processes the command line arguments and
populates NETIFS based on them is really unobvious. Rewrite it so that
the intention is clear and the code is easy to follow.

Suggested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260407102058.867279-1-ioana.ciornei@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 weeks agoscsi: mpi3mr: Fix typo
Claudiu Beznea [Fri, 3 Apr 2026 13:31:09 +0000 (16:31 +0300)] 
scsi: mpi3mr: Fix typo

Fix typo in "synchronize".

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260403133109.2744351-1-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2 weeks agonet: bcmasp: Switch to page pool for RX path
Florian Fainelli [Wed, 8 Apr 2026 00:18:13 +0000 (17:18 -0700)] 
net: bcmasp: Switch to page pool for RX path

This shows an improvement of 1.9% in reducing the CPU cycles and data
cache misses.

Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260408001813.635679-1-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>