]> git.ipfire.org Git - thirdparty/kernel/linux.git/log
thirdparty/kernel/linux.git
13 days agopinctrl: qcom: Register functions before enabling pinctrl
Alexandre MINETTE [Tue, 19 May 2026 07:16:33 +0000 (09:16 +0200)] 
pinctrl: qcom: Register functions before enabling pinctrl

pinctrl consumers can request states while the pinctrl core enables the
controller. On Qualcomm pinctrl drivers this can happen before the SoC
function list has been registered, which leaves the function table
incomplete during state lookup.

On APQ8064 this can fail while claiming pinctrl hogs:

   apq8064-pinctrl 800000.pinctrl: invalid function ps_hold in map table
   apq8064-pinctrl 800000.pinctrl: error claiming hogs: -22
   apq8064-pinctrl 800000.pinctrl: could not claim hogs: -22

Register Qualcomm pinctrl with devm_pinctrl_register_and_init(), add the
SoC pin functions, and only then enable the pinctrl device.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: meson: amlogic-a4: use nolock get range
Xianwei Zhao [Thu, 11 Jun 2026 07:10:49 +0000 (07:10 +0000)] 
pinctrl: meson: amlogic-a4: use nolock get range

Use pinctrl_find_gpio_range_from_pin_nolock() instead of
pinctrl_find_gpio_range_from_pin() when configuring a pin or
setting a GPIO value.

This avoids taking the lock and allows the code to be safely
called from interrupt context.

Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver
Jia Wang [Wed, 10 Jun 2026 05:29:56 +0000 (13:29 +0800)] 
pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver

Add support for the pin controller on the UltraRISC DP1000 SoC.

The controller provides mux selection for pins in ports A, B, C, D, and
LPC. Ports A-D default to GPIO and support peripheral muxing. LPC pins
can be switched to eSPI, but are not available as GPIOs. Basic pin
configuration controls such as drive strength, pull-up, and pull-down
are also supported.

Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agodt-bindings: pinctrl: Add UltraRISC DP1000 pinctrl controller
Jia Wang [Wed, 10 Jun 2026 05:29:55 +0000 (13:29 +0800)] 
dt-bindings: pinctrl: Add UltraRISC DP1000 pinctrl controller

Add doc for the pinctrl controllers on the UltraRISC DP1000 RISC-V SoC.

Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agoMerge branch 'acpica'
Rafael J. Wysocki [Thu, 11 Jun 2026 12:57:55 +0000 (14:57 +0200)] 
Merge branch 'acpica'

Merge ACPICA updates for 7.2-rc1 including the following changes:

 - Add support for the Legacy Virtual Register (LVR) field in I2C serial
   bus resource descriptors to ACPICA (Akhil R)

 - Fix multiple issues related to bounds checks, input validation,
   use-after-free, and integer overflow checks in the AML interpreter
   in ACPICA (ikaros)

 - Update the copyright year to 2026 in ACPICA files and make minor
   changes related to ACPI 6.6 support (Pawel Chmielewski)

 - Remove spurious precision from format used to dump parse trees in
   ACPICA (David Laight)

 - Add modern standby DSM GUIDs to ACPICA header files (Daniel Schaefer)

 - Fix FADT 32/64X length mismatch warning in ACPICA (Abdelkader Boudih)

 - Update D3hot/cold device power states definitions in ACPICA header
   files (Aymeric Wibo)

 - Fix NULL pointer dereference in acpi_ns_custom_package() (Weiming
   Shi)

 - Update ACPICA version to 20260408 (Saket Dumbre)

* acpica: (27 commits)
  ACPICA: add boundary checks in two places
  ACPICA: Add package limit checks in parser functions
  ACPICA: Update version to 20260408
  ACPICA: Update the copyright year to 2026
  ACPICA: Remove spurious precision from format used to dump parse trees
  ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op()
  ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()
  ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()
  ACPICA: Add validation for node in acpi_ns_build_normalized_path()
  ACPICA: validate handler object type in two places
  ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()
  ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)
  ACPICA: Prevent adding invalid references
  ACPICA: add boundary checks in acpi_ps_get_next_field()
  ACPICA: validate byte_count in acpi_ps_get_next_package_length()
  ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()
  ACPICA: fix I2C LVR item count in the conversion table
  ACPICA: Mention the LVR bits
  ACPICA: Change LVR to 8 bit value
  ACPICA: Fetch LVR I2C resource descriptor
  ...

13 days agoliveupdate: Document that retrieve failure is permanent
Tarun Sahu [Thu, 11 Jun 2026 09:30:40 +0000 (09:30 +0000)] 
liveupdate: Document that retrieve failure is permanent

Signed-off-by: Tarun Sahu <tarunsahu@google.com>
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Link: https://patch.msgid.link/faec5df2a3e90240cde5897bae2250cd7d44aeac.1781170056.git.tarunsahu@google.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
13 days agoLoongArch: KVM: Add missing slots_lock for device register/unregister
Zeng Chi [Thu, 11 Jun 2026 12:46:44 +0000 (20:46 +0800)] 
LoongArch: KVM: Add missing slots_lock for device register/unregister

kvm_io_bus_register_dev() and kvm_io_bus_unregister_dev() should be
called under kvm->slots_lock. The unregister calls in ipi.c, eiointc.c
and pch_pic.c were also missing this protection. Add it to match the
register side.

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Validate irqchip index in irqfd routing
Yanfei Xu [Thu, 11 Jun 2026 12:46:43 +0000 (20:46 +0800)] 
LoongArch: KVM: Validate irqchip index in irqfd routing

Sashiko reported that the irqchip index is not validated for LoongArch.
Add validation and reject out-of-range irqchip indexes to avoid indexing
past the routing table's chip array.

Cc: stable@vger.kernel.org
Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support")
Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/
Reported-by: Sashiko <sashiko-bot@kernel.org>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()
Qiang Ma [Thu, 11 Jun 2026 12:46:43 +0000 (20:46 +0800)] 
LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()

The LoongArch CSRXCHG instruction returns the full old CSR value in rd
after applying the masked update. kvm_emu_xchg_csr() currently masks
the saved value before returning it to the guest, so rd receives only
the bits selected by the write mask.

That breaks the architectural behavior and makes a zero mask return 0
instead of the previous CSR value. So, keep the masked CSR update, but
return the unmodified old CSR value.

Cc: stable@vger.kernel.org
Fixes: da50f5a693ff ("LoongArch: KVM: Implement handle csr exception")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Check the return values for put_user()
Qiang Ma [Thu, 11 Jun 2026 12:46:43 +0000 (20:46 +0800)] 
LoongArch: KVM: Check the return values for put_user()

put_user() may return -EFAULT, so, when the user space address is
invalid, the caller should return -EFAULT.

Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Remove timer interrupt injection when SW timer expired
Bibo Mao [Thu, 11 Jun 2026 12:46:43 +0000 (20:46 +0800)] 
LoongArch: KVM: Remove timer interrupt injection when SW timer expired

The software timer emulation is to wake up vCPU when the vCPU executes
idle instruction and gives up host CPU, the vCPU timer tick value and
interrupt is set when vCPU is scheduled in.

It is not necessary to inject timer interrupt when SW timer is expired.
Here remove it, also use common API kvm_vcpu_wake_up() to wake up vCPU.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Deliver interrupt after IN_GUEST_MODE is set
Bibo Mao [Thu, 11 Jun 2026 12:46:43 +0000 (20:46 +0800)] 
LoongArch: KVM: Deliver interrupt after IN_GUEST_MODE is set

Interrupt delivery should be called after IN_GUEST_MODE is set. Other
threads may be posting interrupt however does not send IPI to the vCPU,
since the vCPU is not in IN_GUEST_MODE yet.

Here move function call with kvm_deliver_intr() after IN_GUEST_MODE is
set, and set mode with OUTSIDE_GUEST_MODE with atomic method.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Add valid bit check when set CSR.ESTAT register
Bibo Mao [Thu, 11 Jun 2026 12:46:42 +0000 (20:46 +0800)] 
LoongArch: KVM: Add valid bit check when set CSR.ESTAT register

When set CSR.ESTAT register in function _kvm_setcsr(), valid bit check
is added here. Also interrupt CPU_AVEC is checked by msgint feature.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Inject interrupts with batch method
Bibo Mao [Thu, 11 Jun 2026 12:46:42 +0000 (20:46 +0800)] 
LoongArch: KVM: Inject interrupts with batch method

With bitmask method, interrupts can be injected with batch mode rather
than one by one. Also remove unused array priority_to_irq[] here.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Check msgint feature in interrupt post
Bibo Mao [Thu, 11 Jun 2026 12:46:41 +0000 (20:46 +0800)] 
LoongArch: KVM: Check msgint feature in interrupt post

Interrupt AVEC is valid only if VM has msgint feature, and this feature
is checked in interrupt handling. Since interrupt handling is executing
in VM context switch, and it is hot path, here move the feature checking
in interrupt post rather than interrupt handling.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()
Bibo Mao [Thu, 11 Jun 2026 12:46:40 +0000 (20:46 +0800)] 
LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()

Function kvm_vcpu_ioctl_interrupt() can be called from userspace, here
add irq validility cheking in kvm_vcpu_ioctl_interrupt().

Cc: stable@vger.kernel.org
Fixes: f45ad5b8aa93 ("LoongArch: KVM: Implement vcpu interrupt operations")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Use existing macro about interrupt bit mask
Bibo Mao [Thu, 11 Jun 2026 12:46:40 +0000 (20:46 +0800)] 
LoongArch: KVM: Use existing macro about interrupt bit mask

With interrupt post, register CSR.GINTC and CSR.ESTAT is used, and
CSR.ESTAT is used for percpu interrupt injection and CSR.GINTC is for
external hardware interrupt injection.

Here use existing macro about interrupt bit of register CSR.GINTC and
CSR.ESTAT, rather than hard coded constant value.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Fix FPU register width with user access API
Bibo Mao [Thu, 11 Jun 2026 12:46:40 +0000 (20:46 +0800)] 
LoongArch: KVM: Fix FPU register width with user access API

At the beginning, only 64 bit FPU is supported. With FPU register get
interface, 64 bit FPU data is copied to user space, the same with FPU
register set API. However with LSX and LASX supported in later, there
should be FPU data copied with bigger width. So here fixes this issue,
copy the whole 256 bit FPU data from/to user space.

Cc: stable@vger.kernel.org
Fixes: db1ecca22edf ("LoongArch: KVM: Add LSX (128bit SIMD) support")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Remove KVM_LARCH_LSX and KVM_LARCH_LASX
Bibo Mao [Thu, 11 Jun 2026 12:46:40 +0000 (20:46 +0800)] 
LoongArch: KVM: Remove KVM_LARCH_LSX and KVM_LARCH_LASX

In kvm_lose_fpu() FPU state is save in vcpu::arch::fpu, its FPU status
comes from vcpu->arch.aux_inuse. Instead existing API vm_guest_has_xxx()
can be used also, moreover, the bits KVM_LARCH_LSX and KVM_LARCH_LASX in
arch.aux_inuse are removed. It makes the logic simpler than ever.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Remove some middle FPU states
Bibo Mao [Thu, 11 Jun 2026 12:46:40 +0000 (20:46 +0800)] 
LoongArch: KVM: Remove some middle FPU states

With max VM supported FPU type enabled, if VM supports LASX, there is
only NONE --> LASX, no middle FPU state such as NONE --> FPU --> LASX
or NONE --> FPU --> LSX --> LASX. Here remove the middle FPU states in
function kvm_own_lsx() and kvm_own_lasx(). And it becomes simpler than
before.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Enable FPU with max supported FPU type
Bibo Mao [Thu, 11 Jun 2026 12:46:40 +0000 (20:46 +0800)] 
LoongArch: KVM: Enable FPU with max supported FPU type

There are three FPU types FPU/LSX/LASX, which represents FPU64, FPU128
and FPU256, and now lazy FPU method is used with FPU enabling. There are
three different HW FPU exception code with different FPU type.

The exising method is to enable specified FPU type with responding FPU
exeception. Supposing application uses FPU64 and FPU256, there will be
FPU256 exception when FPU256 type is used.

Here enable FPU with the max VM supported type directly, so it can avoid
unnecessary FPU exception in future if further FPU type is used.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agoLoongArch: KVM: Add separate KVM_REQ_LBT_LOAD bit
Bibo Mao [Thu, 11 Jun 2026 12:46:39 +0000 (20:46 +0800)] 
LoongArch: KVM: Add separate KVM_REQ_LBT_LOAD bit

There are different structures with FPU and LBT register restore, with
FPU the structure is vcpu::arch::fpu, with LBT the structure is vcpu::
arch::lbt. Moreover, FPU/LSX/LASX saving and restoring share the common
structure vcpu::arch::fpu.

New request bit KVM_REQ_LBT_LOAD is used for LBT register restore, and
rename KVM_REQ_AUX_LOAD with KVM_REQ_FPU_LOAD for FPU register restore.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
13 days agopinctrl: qcom: Remove unused macro definitions
Navya Malempati [Fri, 29 May 2026 10:43:01 +0000 (16:13 +0530)] 
pinctrl: qcom: Remove unused macro definitions

The macros QUP_I3C and UFS_RESET are defined in some platforms
and yet not used. Remove these macros as they are unnecessary.

Signed-off-by: Navya Malempati <navya.malempati@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: tegra: PINCTRL_TEGRA264 should depend on ARCH_TEGRA
Geert Uytterhoeven [Tue, 9 Jun 2026 15:08:35 +0000 (17:08 +0200)] 
pinctrl: tegra: PINCTRL_TEGRA264 should depend on ARCH_TEGRA

The NVIDIA Tegra264 MAIN, AON, and UPHY pin controllers are only present
on NVIDIA Tegra264 SoCs.  Hence add a dependency on ARCH_TEGRA, to
prevent asking the user about this driver when configuring a kernel
without NVIDIA Tegra SoC support.

Fixes: c98506206912dd0d ("pinctrl: tegra: Add Tegra264 pinmux driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: tegra: PINCTRL_TEGRA238 should depend on ARCH_TEGRA
Geert Uytterhoeven [Tue, 9 Jun 2026 15:08:34 +0000 (17:08 +0200)] 
pinctrl: tegra: PINCTRL_TEGRA238 should depend on ARCH_TEGRA

The NVIDIA Tegra238 MAIN and AON pin controllers are only present on
NVIDIA Tegra238 SoCs.  Hence add a dependency on ARCH_TEGRA, to prevent
asking the user about this driver when configuring a kernel without
NVIDIA Tegra SoC support.

Fixes: 25cac7292d49f4fc ("pinctrl: tegra: Add Tegra238 pinmux driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: tegra238: add missing AON pin groups
Prathamesh Shete [Mon, 8 Jun 2026 09:41:22 +0000 (09:41 +0000)] 
pinctrl: tegra238: add missing AON pin groups

Add 24 pin groups on ports EE, FF, GG and HH to the AON pin controller
group table (tegra238_aon_groups[]). Their pin arrays, drive-group
macros and pin descriptors were already defined, but the matching
PINGROUP() entries were not present, so these pins could not be muxed
or configured through the AON pin controller.

The pin arrays were not referenced, so the build emitted
-Wunused-const-variable warnings, and commit 119de2c33d96 ("pinctrl:
tegra238: remove unused entries") removed three of them. Restore those
arrays and add the full set of PINGROUP() entries to make the pins
usable.

Fixes: 25cac7292d49 ("pinctrl: tegra: Add Tegra238 pinmux driver")
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agodt-bindings: pinctrl: tegra238: add missing AON pin groups
Prathamesh Shete [Mon, 8 Jun 2026 09:41:21 +0000 (09:41 +0000)] 
dt-bindings: pinctrl: tegra238: add missing AON pin groups

Add 24 pin groups, and their matching drive groups, on ports EE, FF,
GG and HH to the Tegra238 AON pinmux binding. These groups are present
on the AON pin controller, so device trees that mux these pins through
it validate against the schema.

Fixes: 9323f8a0e12c ("dt-bindings: pinctrl: Document Tegra238 pin controllers")
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agoplatform/x86: dell-privacy: correct CONFIG_DELL_WMI_PRIVACY macro name in comments
Ethan Nelson-Moore [Thu, 11 Jun 2026 00:12:34 +0000 (17:12 -0700)] 
platform/x86: dell-privacy: correct CONFIG_DELL_WMI_PRIVACY macro name in comments

Comments in drivers/platform/x86/dell/dell-wmi-privacy.h incorrectly
refer to CONFIG_DELL_PRIVACY instead of CONFIG_DELL_WMI_PRIVACY.
Correct them.

Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Link: https://patch.msgid.link/20260611001238.391045-1-enelsonmoore@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
13 days agoplatform/x86: asus-armoury: add support for G614PR
Marco Scardovi [Wed, 10 Jun 2026 15:21:30 +0000 (17:21 +0200)] 
platform/x86: asus-armoury: add support for G614PR

Add TDP power limits and fan curve requirements for the ASUS ROG Strix
G16 G614PR laptop model.

The ASUS ROG Strix G16 G614PR requires specific AC/DC power limits
(PPT PL1/PL2/PL3, dynamic boost, and NV TGP targets) to function
correctly under various power profiles. Without these limits, the Asus
Armoury driver cannot configure the correct power envelopes or enable custom
fan curves, leading to suboptimal performance or noise management.

This patch adds the corresponding DMI board name matching entry ("G614PR")
under the power_limits table in asus-armoury.h, populating the AC and DC
limits based on the platform's hardware specification.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260610152130.25892-1-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
13 days agopinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:42 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function

pcm_spi_int, pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4 pin groups are not
defined, so pcm_spi function can't be applied to these groups.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7583: fix phy1_led1 pin function
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:41 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: fix phy1_led1 pin function

phy1_led1 pin function wrongly refers to gpio1 instead of gpio11.
Fix it.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7583: add missed gpio22 pin group
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:40 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: add missed gpio22 pin group

gpio22 pin group is missed, fix it.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7583: fix gpio21 pin group
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:39 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: fix gpio21 pin group

gpio21 pin group refers to gpio22 pin, this is wrong.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: fix pwm pin function for an7581 and an7583
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:38 +0000 (05:03 +0300)] 
pinctrl: airoha: fix pwm pin function for an7581 and an7583

AN7581 have 47 valid GPIOs only (gpio0-gpio46), so gpio47 is a fiction.
AN7583 have 49 valid GPIOs (gpio0-gpio48), so gpio48 is missed

To fix an issue
 * create AN7583 specific pwm pin function,
 * remove gpio47 from AN7581 pwm pin function.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:37 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function

phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:36 +0000 (05:03 +0300)] 
pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function

phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).

Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7583: fix misprint in gpio19 pinconf
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:35 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: fix misprint in gpio19 pinconf

Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
a proper bit number in the configuration register.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7581: fix misprint in gpio19 pinconf
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:34 +0000 (05:03 +0300)] 
pinctrl: airoha: an7581: fix misprint in gpio19 pinconf

Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
a proper bit number in the configuration register.

Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7583: add missed gpio32 pin group
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:33 +0000 (05:03 +0300)] 
pinctrl: airoha: an7583: add missed gpio32 pin group

gpio32 pin group is missed for an7583 SoC. This patch add it.

Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: airoha: an7581: add missed gpio32 pin group
Mikhail Kshevetskiy [Sat, 6 Jun 2026 02:03:32 +0000 (05:03 +0300)] 
pinctrl: airoha: an7581: add missed gpio32 pin group

gpio32 pin group is missed for an7581 SoC. This patch add it.

Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agoplatform/x86: asus-wmi: add keystone dongle support
Dariusz Figzał [Wed, 10 Jun 2026 16:49:42 +0000 (18:49 +0200)] 
platform/x86: asus-wmi: add keystone dongle support

The ASUS Keystone is a physical NFC-like dongle that slots into supported
ASUS laptops. The EC fires WMI notify code 0xB4 on insert/remove events.

Expose the current insert state via a sysfs attribute by querying WMI
device ID 0x00120091 (DSTS). This devid does not follow the standard DSTS
convention: PRESENCE_BIT (0x00010000) encodes the insert state rather than
feature presence, and STATUS_BIT is never set. Presence of a keystone slot
is detected by a successful DSTS call.

Reviewed-by: Denis Benato <denis.benato@linux.dev>
Signed-off-by: Dariusz Figzał <dariuszfigzal@gmail.com>
Link: https://patch.msgid.link/20260610164942.74956-1-dariuszfigzal@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
13 days agoKVM: s390: vsie: Use mmu cache to allocate rmap
Claudio Imbrenda [Thu, 11 Jun 2026 10:48:50 +0000 (12:48 +0200)] 
KVM: s390: vsie: Use mmu cache to allocate rmap

Use kvm_s390_mmu_cache_alloc_rmap() to allocate the rmap in
gmap_insert_rmap(), instead of a normal kzalloc_obj() with GFP_ATOMIC.

This guarantees forward progress.

Fixes: a2c17f9270cc ("KVM: s390: New gmap code")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-6-imbrenda@linux.ibm.com>

13 days agoKVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault()
Claudio Imbrenda [Thu, 11 Jun 2026 10:48:49 +0000 (12:48 +0200)] 
KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault()

Add missing radix_tree_preload() in _gaccess_shadow_fault() to
guarantee forward progress. The core of _gaccess_shadow_fault() has
been split into ___gaccess_shadow_fault() in order to simplify locking.

Fixes: e38c884df921 ("KVM: s390: Switch to new gmap")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-5-imbrenda@linux.ibm.com>

13 days agoKVM: s390: vsie: Fix allocation of struct vsie_rmap
Claudio Imbrenda [Thu, 11 Jun 2026 10:48:48 +0000 (12:48 +0200)] 
KVM: s390: vsie: Fix allocation of struct vsie_rmap

The allocation size for struct vsie_rmap in kvm_s390_mmu_cache_topup()
was wrong due to a copy-paste error.

Fix it by using the type name.

Fixes: 12f2f61a9e1a ("KVM: s390: KVM page table management functions: allocation")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-4-imbrenda@linux.ibm.com>

13 days agoKVM: s390: Fix unlikely race in try_get_locked_pte()
Claudio Imbrenda [Thu, 11 Jun 2026 10:48:47 +0000 (12:48 +0200)] 
KVM: s390: Fix unlikely race in try_get_locked_pte()

Fix an unlikely race in try_get_locked_pte(), which could have happened
if puds or pmds get unmapped between the p?dp_get() and p?d_offset()
functions.

Fixes: 89fa757931dc ("KVM: s390: Avoid potentially sleeping while atomic when zapping pages")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-3-imbrenda@linux.ibm.com>

13 days agoKVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic()
Claudio Imbrenda [Thu, 11 Jun 2026 10:48:46 +0000 (12:48 +0200)] 
KVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic()

While dat_crstep_xchg_atomic() is marked as __must_check, in this
particular case the return value should be ignored.

Silence potential compiler warnings with a pointless check, and add a
comment to explain the situation.

Fixes: d1adc098ce08 ("KVM: s390: Fix _gmap_crstep_xchg_atomic()")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-2-imbrenda@linux.ibm.com>

13 days agodt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
Andre Przywara [Fri, 27 Mar 2026 11:30:05 +0000 (11:30 +0000)] 
dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number

The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
instance, but it skips the first bank (PortA), so their index goes from
1 to 10. The same is actually true for the IRQ banks: there are registers
for 11 banks, though the first bank is not implemented (RAZ/WI).
In contrast to previous SoCs, the count of the IRQ banks starts with this
first unimplemented bank, so we need to provide an interrupt for it.
And indeed the A523 user manual lists an interrupt number for PortA, so we
need to increase the maximum number of interrupts per pin controller to 11,
to be able to assign the correct interrupt number for each bank.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agopinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
Andre Przywara [Fri, 27 Mar 2026 11:30:04 +0000 (11:30 +0000)] 
pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag

The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
that line is muxed for IRQ triggering (muxval 6), but only if it's
explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
behaviour, so we added a optional workaround, triggered by a quirk bit,
which triggers remuxing the pin when it's configured for IRQ, while we
need to read its value.

For some reasons this quirk flag was copied over to newer SoCs, even
though they don't show this behaviour, and the GPIO data register
reflects the true GPIO state even with a pin muxed to IRQ trigger.

Remove the unneeded quirk from the A523 family, where it's definitely
not needed (confirmed by experiments), and where it actually breaks,
because the workaround is not compatible with the newer generation
pinctrl IP used in that chip.

Together with a DT change this fixes GPIO IRQ operation on the A523
family of SoCs, as for instance used for the SD card detection.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
13 days agolocking: Add contended_release tracepoint to sleepable locks
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:07 +0000 (07:15 +0000)] 
locking: Add contended_release tracepoint to sleepable locks

Add the contended_release trace event. This tracepoint fires on the
holder side when a contended lock is released, complementing the
existing contention_begin/contention_end tracepoints which fire on the
waiter side.

This enables correlating lock hold time under contention with waiter
events by lock address.

Add trace_contended_release()/trace_call__contended_release() calls to
the slowpath unlock paths of sleepable locks: mutex, rtmutex, semaphore,
rwsem, percpu-rwsem, and RT-specific rwbase locks.

Where possible, trace_contended_release() fires before the lock is
released and before the waiter is woken. For some lock types, the
tracepoint fires after the release but before the wake. Making the
placement consistent across all lock types is not worth the added
complexity.

For reader/writer locks, the tracepoint fires for every reader releasing
while a writer is waiting, not only for the last reader.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/02f4f6c5ce6761e7f6587cf0ff2289d962ecddd4.1780506267.git.d@ilvokhin.com
13 days agolocking/percpu-rwsem: Extract __percpu_up_read()
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:06 +0000 (07:15 +0000)] 
locking/percpu-rwsem: Extract __percpu_up_read()

Move the percpu_up_read() slowpath out of the inline function into a new
__percpu_up_read() to avoid binary size increase from adding a
tracepoint to an inlined function.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/3dd2a1b9ab4f469e1892766cb63f41d6b0f53d29.1780506267.git.d@ilvokhin.com
13 days agotracing/lock: Remove unnecessary linux/sched.h include
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:05 +0000 (07:15 +0000)] 
tracing/lock: Remove unnecessary linux/sched.h include

None of the trace events in lock.h reference anything from
linux/sched.h. Remove the unnecessary include.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/85e14a0685c1d46c3e80de2dc01358a48169b263.1780506267.git.d@ilvokhin.com
13 days agofutex: Optimize futex hash bucket access patterns
Peter Zijlstra [Wed, 10 Jun 2026 21:20:09 +0000 (23:20 +0200)] 
futex: Optimize futex hash bucket access patterns

Breno reported significant c2c HITM in a futex hash heavy workload.

It turns out that the hash bucket to private hash table reverse pointer
(futex_hash_bucket::priv) was to blame. Notably when the hash buckets are
heavily contended, the: 'fph = bh->priv;' load in futex_hash() will typically
miss and consequently become quite expensive.

Since this load in particular is quite superfluous, removing it is fairly
straight forward. However, removing it does not in fact achieve anything much.
The pain moves to the next user, notably: futex_hash_put().

Therefore rework the whole private hash refcounting to avoid needing this back
pointer (and removing it). Instead of passing around 'struct futex_hash_bucket
*hb', pass around a new structure that contains it and the related 'struct
futex_private_hash *fph' pointer in tandem.

Funnily this turns out to remove more code than it adds and significantly
improves futex hash performance (as measured by 'perf bench futex hash'):

SKL dual socket 112 threads:

  Baseline        Patched
  shared (16k)    1571857         1641435         + 4.4%
  autosize (512)   646390          903371         +39.7%
  -b 256           464395          587014         +26.4%
  -b 512           715687          995943         +39.2%
  -b 1024          995085         1396328         +40.3%
  -b 2048         1293114         1668395         +29.0%
  -b 4096         2124438         2240228         + 5.5%

Zen3 dual socket 256 threads:

                  Baseline        Patched
  shared  (16k)   1275840         1381279         + 8.2%
  autosize (512)  1252745         1482179         +18.3%
  -b 256           856274          955455         +11.5%
  -b 512          1267490         1544010         +21.8%
  -b 1024         1424013         1625424         +14.1%
  -b 2048         1505181         1669342         +10.9%
  -b 4096         1465993         1688932         +15.2%

AMD EPYC 9D64 (Zen4, single socket) 176 threads:

                       Baseline       Patched      Delta
  shared (16k)         1,230,599      1,368,655    +11.2%
  autosize (1024)      1,285,440      1,556,946    +21.1%
  -b 256               1,341,471      1,520,303    +13.3%
  -b 512               1,438,330      1,599,319    +11.2%
  -b 1024              1,443,772      1,622,493    +12.4%
  -b 2048              1,472,108      1,643,975    +11.7%
  -b 4096              1,333,098      1,570,897    +17.8%

Reported-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Breno Leitao <leitao@debian.org>
Tested-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260610135510.GB1430057@noisy.programming.kicks-ass.net
13 days agosched/fair: Fix newidle vs core-sched
Aaron Lu [Wed, 3 Jun 2026 09:51:08 +0000 (17:51 +0800)] 
sched/fair: Fix newidle vs core-sched

While testing Prateek's throttle series, I noticed a panic issue when
coresched is enabled and bisected to this patch.

I fed the panic log and this patch to an agent and its analysis looks
correct to me(cpu56 and cpu57 are siblings in a VM):

       cpu57 (holds core-wide lock)

     pick_next_task() [core scheduling]
     for_each_cpu_wrap(i, smt_mask, 57):
       i=57: pick_task(rq_57)
             pick_task_fair(rq_57)
             -> picks task A
       rq_57->core_pick = task A
       // task_rq(A) == rq_57

       i=56: pick_task(rq_56)
             pick_task_fair(rq_56)
             cfs_rq->nr_queued == 0
             goto idle
             sched_balance_newidle(rq_56)
             raw_spin_rq_unlock(rq_56)
             // core-wide lock released
             newidle_balance() pulls
               task A: rq_57 -> rq_56
             // task_rq(A) == rq_56 now
             raw_spin_rq_lock(rq_56)
             // core-wide lock re-acquired
             return > 0
             goto again
             pick_task_fair(rq_56)
             -> picks task A
       rq_56->core_pick = task A

     // first loop done
     // rq_57->core_pick is still task A (set before lock release)
     // but task_rq(A) == rq_56 now
     next = rq_57->core_pick  // = task A

     put_prev_set_next_task(rq_57, prev, task A)
     __set_next_task_fair(rq_57, task A)
     hrtick_start_fair(rq_57, task A)
     WARN_ON_ONCE(task_rq(task A) != rq_57)
     // task_rq(A) == rq_56

IOW: by allowing pick_task_fair() to do newidle_balance and not returning
RETRY_TASK, it can end up selecting the same task on two CPUs. Restore the
previous state by never doing newidle when core scheduling is enabled.

Tested-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: "Aaron Lu" <ziqianlu@bytedance.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260603095108.GA1684319@bytedance.com
13 days agohwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i
Potin Lai [Thu, 11 Jun 2026 05:46:18 +0000 (13:46 +0800)] 
hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i

Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.

Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).

Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
13 days agodt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
Varadarajan Narayanan [Mon, 8 Jun 2026 10:33:44 +0000 (16:03 +0530)] 
dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY

Add dt-bindings for the USB3 QMP PHY found on the Qualcomm IPQ5210 SoC. The
IPQ5210 PHY is compatible with the IPQ9574 PHY, so add it as a fallback-
compatible entry using a oneOf construct rather than a plain enum entry.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260608103344.2740174-3-varadarajan.narayanan@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
13 days agodt-bindings: phy: qcom,qusb2: Document IPQ5210 compatible
Varadarajan Narayanan [Mon, 8 Jun 2026 10:33:43 +0000 (16:03 +0530)] 
dt-bindings: phy: qcom,qusb2: Document IPQ5210 compatible

Document the QUSB2 PHY compatible for the IPQ5210 SoC. The IPQ5210 PHY is
compatible with the IPQ6018 QUSB2 PHY, so allow it to use
qcom,ipq6018-qusb2-phy as the fallback compatible.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260608103344.2740174-2-varadarajan.narayanan@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
13 days agoIB/core: Delegate IB_QP_RATE_LIMIT validation to drivers
Maher Sanalla [Sun, 24 May 2026 15:38:09 +0000 (18:38 +0300)] 
IB/core: Delegate IB_QP_RATE_LIMIT validation to drivers

Remove IB_QP_RATE_LIMIT from the qp_state_table and instead
pass it through ib_modify_qp_is_ok() unconditionally. This
delegates rate limit attribute validation to the individual
drivers that support it.

As rate limit support expands to additional QP types and transitions
across different vendors, centralizing this policy in the core becomes
impractical. Each driver is better positioned to enforce its own
supported QP types and transitions over non-standard attributes.

Future support for non-standard attributes will be handled per vendor
driver instead of in generic IB core qp_state_table.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-8-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agoRDMA/ionic: Validate rate limit attribute in modify QP
Maher Sanalla [Sun, 24 May 2026 15:38:08 +0000 (18:38 +0300)] 
RDMA/ionic: Validate rate limit attribute in modify QP

Rate limit transition validation for RC QPs currently relies on
the IB core qp_state_table. Add a driver-level helper to validate
the rate limit attribute directly during QP modify, ensuring it
is only accepted for RC QPs in INIT->RTR, RTR->RTS and RTS->RTS
transitions.

This makes the driver responsible for rate limit validation
and prepares for a follow-up IB core change that delegates
IB_QP_RATE_LIMIT and all future non-standard modify attributes
handling to individual vendor drivers.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-7-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agoRDMA/bnxt_re: Validate rate limit attribute in modify QP
Maher Sanalla [Sun, 24 May 2026 15:38:07 +0000 (18:38 +0300)] 
RDMA/bnxt_re: Validate rate limit attribute in modify QP

Rate limit transition validation for RC QPs currently relies on
the IB core qp_state_table. Add a driver-level helper to validate
the rate limit attribute directly during QP modify, ensuring it
is only accepted for RC QPs in INIT->RTR, RTR->RTS and RTS->RTS
transitions.

This makes the driver responsible for rate limit validation
and prepares for a follow-up IB core change that delegates
IB_QP_RATE_LIMIT and all future non-standard modify attributes
handling to individual vendor drivers.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-6-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agoRDMA/mlx5: Report packet pacing capabilities when querying device
Maher Sanalla [Sun, 24 May 2026 15:38:06 +0000 (18:38 +0300)] 
RDMA/mlx5: Report packet pacing capabilities when querying device

When querying device, report packet pacing capabilities for UD and
UC QPs when device supports it.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-5-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agoRDMA/mlx5: Support deferred rate limit configuration
Maher Sanalla [Sun, 24 May 2026 15:38:05 +0000 (18:38 +0300)] 
RDMA/mlx5: Support deferred rate limit configuration

Allow passing a rate limit attribute in modify QP flows even when the
QP is in a state that does not support packet pacing programming in
the lower layers.

When the user sets a rate limit during a QP transition that is not to
RTS, store the value in the mlx5 QP struct and program it to FW when
the QP later transitions to RTS, which is the state that allows
configuring the rate limit index in the QP context.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-4-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agoRDMA/mlx5: Add support for rate limit in UD and UC QPs
Maher Sanalla [Sun, 24 May 2026 15:38:04 +0000 (18:38 +0300)] 
RDMA/mlx5: Add support for rate limit in UD and UC QPs

Rate limiting is currently supported only for raw packet QPs, where
the packet pacing index is programmed into the SQC during SQ modify.

Extend rate limit support to UD and UC QPs by setting the pacing
index in the QPC during RTR2RTS and RTS2RTS transitions.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-3-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agoRDMA/mlx5: Refactor raw packet QP rate limit handling
Maher Sanalla [Sun, 24 May 2026 15:38:03 +0000 (18:38 +0300)] 
RDMA/mlx5: Refactor raw packet QP rate limit handling

Refactor the raw packet QP modify path to extract rate limit
configuration into a qp_rl_parse() helper that parses user attributes,
and a qp_rl_prepare() helper that handles FW rate limit table
adjustments before the SQ modify itself.

Use qp_rl_commit() to commit changes to QP once FW call
succeeds, and qp_rl_rollback() to rollback changes done to
the FW rate limit table in the prepare stage, in case the
modify operation fails.

These helpers will be reused for extending rate limit support to
additional QP types in the following patch.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-2-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agonet/mlx5: Add UD and UC packet pacing caps
Maher Sanalla [Sun, 24 May 2026 15:38:02 +0000 (18:38 +0300)] 
net/mlx5: Add UD and UC packet pacing caps

Add the needed capabilities in mlx5_ifc to support packet pacing for UC
and UD QPs.

Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260524-packet-pacing-v1-1-3d79439f8d08@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
13 days agophy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
Felix Gu [Tue, 9 Jun 2026 14:48:50 +0000 (22:48 +0800)] 
phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset

The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
with pm_runtime_put(). The asynchronous variant queues a work item
to handle the idle check and potential suspend, which can be cancelled
by a subsequent pm_runtime_disable() call if probe fails after the reset.

Switch to pm_runtime_put_sync() to run the idle check and suspend
synchronously.

Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support")
Reported-by: sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
13 days agoocteontx2-af: fix IP fragment flag corruption on custom KPU profile load
Kiran Kumar K [Mon, 8 Jun 2026 09:54:55 +0000 (15:24 +0530)] 
octeontx2-af: fix IP fragment flag corruption on custom KPU profile load

npc_cn20k_apply_custom_kpu() overwrites KPU profile entries with custom
firmware values and then calls npc_cn20k_update_action_entries_n_flags()
over all entries.  Since the same function already ran during default
profile initialisation, entries not overridden by the custom firmware
get their flags translated twice, corrupting the CN20K-specific values.

Fix this by extracting the per-entry translation into a helper
npc_cn20k_translate_action_flags() and calling it as each custom entry
is loaded, removing the redundant batch call at the end.

Fixes: ef992a0f12e8 ("octeontx2-af: npc: cn20k: MKEX profile support")
Cc: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260608095455.1499203-1-nshettyj@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoMerge branch 'net-shaper-follow-ups-to-recent-fixes'
Paolo Abeni [Thu, 11 Jun 2026 10:55:25 +0000 (12:55 +0200)] 
Merge branch 'net-shaper-follow-ups-to-recent-fixes'

Jakub Kicinski says:

====================
net: shaper: follow ups to recent fixes

As discussed previously on the patch set with real fixes the xa_locking
in shapers is a little confusing, remove it.
Link: https://lore.kernel.org/20260506000628.1501691-2-kuba@kernel.org
The remaining three patches are an attempt to silence AI reviewers,
I believe Sashiko was complaining about these non-issues. Not adding
Reported tags since these are false positives.
====================

Link: https://patch.msgid.link/20260609183224.1108521-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: shaper: add a note that we expect cap dumps to be tiny
Jakub Kicinski [Tue, 9 Jun 2026 18:32:24 +0000 (11:32 -0700)] 
net: shaper: add a note that we expect cap dumps to be tiny

Various AI scan tools may complain that we don't support resuming
the cap dump. This is true, but the cap dumps are tiny.
net_shaper_nl_cap_pre_dumpit() sets up the dump for just
one device, so the size of the dump scales with NET_SHAPER_SCOPE_MAX (3).

We don't expect them to ever need more than a 4kB page.
Document this.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-5-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: shaper: add a comment why we don't need kfree_rcu() in flush
Jakub Kicinski [Tue, 9 Jun 2026 18:32:23 +0000 (11:32 -0700)] 
net: shaper: add a comment why we don't need kfree_rcu() in flush

We keep getting misguided patches to fix the flush.
Add a comment.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-4-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: shaper: drop unnecessary kfree_rcu in pre_insert
Jakub Kicinski [Tue, 9 Jun 2026 18:32:22 +0000 (11:32 -0700)] 
net: shaper: drop unnecessary kfree_rcu in pre_insert

If we fail to insert a node into the XArray in net_shaper_pre_insert()
we can free it directly - it was never visible to the RCU readers.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: shaper: drop redundant xa_lock() bracketing
Jakub Kicinski [Tue, 9 Jun 2026 18:32:21 +0000 (11:32 -0700)] 
net: shaper: drop redundant xa_lock() bracketing

The shaper insertion and update code takes xa_lock() explicitly.
Paolo explained that the locking was purely to avoid re-taking
the lock in loops. But it may be mis-read as if it was expecting
readers to be fenced off by xa_lock. Readers of XArray are purely
under RCU. Remove explicit taking of xa_lock().

All writers to hierarchy->shapers are serialized by the netdev
instance lock (or run after netdev is made inaccessible to readers).

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609183224.1108521-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoMerge tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Paolo Abeni [Thu, 11 Jun 2026 10:29:59 +0000 (12:29 +0200)] 
Merge tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf

Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains Netfilter fixes for net:

1) Revalidate bridge ports, add missing NULL checks to fetch the bridge
   device by the port. From Florian Westphal.

2) Fix netdevice refcount leak in the error path of nft_fwd hardware
   offload function, also from Florian.

3) Unregister helper expectfn callback on conntrack helper module
   removal, otherwise dangling pointer remains in place,
   from Weiming Shi.

4) Fix possible pointer infoleak in getsockopt() IPT_SO_GET_ENTRIES,
   From Kyle Zeng.

5) Validate that device MAC header is present before nf_syslog
   accesses it. From Xiang Mei.

6-8) Three patches to address a possible infoleak of stale stack
     data in three nf_tables expressions, due to mismatch in the
     _init() and _eval() function which is possible since 14fb07130c7d.
     From Davide Ornaghi and Florian Westphal.

netfilter pull request 26-06-10

* tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
  netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register
  netfilter: nft_fib: fix stale stack leak via the OIFNAME register
  netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
  netfilter: nf_log: validate MAC header was set before dumping it
  netfilter: x_tables: avoid leaking percpu counter pointers
  netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
  netfilter: nf_tables_offload: drop device refcount on error
  netfilter: revalidate bridge ports
====================

Link: https://patch.msgid.link/20260610161629.214092-1-pablo@netfilter.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoASoC: loongson: Fix invalid position error in ls_pcm_pointer
Li Jun [Thu, 11 Jun 2026 01:00:45 +0000 (09:00 +0800)] 
ASoC: loongson: Fix invalid position error in ls_pcm_pointer

The "invalid position" error occurred when the DMA position descriptor
returned an invalid address value (e.g., pos = -1048838144). This happened
because the `bytes_to_frames()` function returns a signed value, but when
`addr < runtime->dma_addr`, the subtraction produces a negative result that
gets interpreted as a large unsigned integer in comparisons.
when the addr is abnormal, for example,the DMA controller is abnormal in
hardware,x=0 should not be a point(x == runtime->buffer_size),but a range,
which includes the addr address being less than runtime ->dma1-adr, and
the addr exceeding the DMA address range.the value of pos should not better
a negative,return 0, maybe better.

[   32.834431][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.845019][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.855588][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.866145][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   32.995394][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   33.006025][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144
[   33.016748][ 2]  soc-audio soc-audio: invalid position: , pos = -1048838144

Signed-off-by: Li Jun <lijun01@kylinos.cn>
[Remove XRUN reporting I'd mistakenly avised adding on prior review -- broonie]
Link: https://patch.msgid.link/20260611010045.3668574-1-lijun01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
13 days agoMerge branch 'net-rds-convert-rds-to-getsockopt_iter'
Paolo Abeni [Thu, 11 Jun 2026 10:19:07 +0000 (12:19 +0200)] 
Merge branch 'net-rds-convert-rds-to-getsockopt_iter'

Breno Leitao says:

====================
net: rds: convert rds to getsockopt_iter

This series continues the conversion of the remaining proto_ops getsockopt
callbacks to the new getsockopt_iter callback introduced in commit
67fab22a7adc ("net: add getsockopt_iter callback to proto_ops"), this time
for RDS.

RDS is a little more involved than the protocols converted so far, because
the RDS_INFO_* options snapshot kernel state directly into the destination
buffer: the info producers memcpy into the pages under a spinlock via
kmap_atomic() and so must not fault.

The conversion preserves that model — it obtains the same page array and
starting offset from opt->iter_out with iov_iter_extract_pages(),
preallocating the array so the iterator fills it in place, and leaves
the rds_info_iterator / rds_info_copy machinery and all producer
callbacks unchanged; kernel (ITER_KVEC) buffers remain unsupported on
the RDS_INFO path, as before.

I've vibe-coded a kselftest exercising both the simple options and the
RDS_INFO_* snapshot path, feel free to drop it in case this is not
useful.

Signed-off-by: Breno Leitao <leitao@debian.org>
====================

Link: https://patch.msgid.link/20260608-getsock_more-v3-0-706ecf2ea332@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agords: convert to getsockopt_iter
Breno Leitao [Mon, 8 Jun 2026 09:44:58 +0000 (02:44 -0700)] 
rds: convert to getsockopt_iter

Convert RDS socket's getsockopt implementation to use the new
getsockopt_iter callback with sockopt_t.

Key changes:
- Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
- Use opt->optlen for buffer length (input) and returned size (output)
- Use copy_to_iter() instead of put_user()/copy_to_user()

The RDS_INFO_* snapshot path in rds_info_getsockopt() used to pin the
userspace buffer with pin_user_pages_fast() on the raw optval address;
the info producers then memcpy into those pages under a spinlock via
kmap_atomic() and so must not fault. Obtain the same page array and
starting offset from opt->iter_out with iov_iter_extract_pages(), which
pins for write because iter_out is ITER_DEST.

The page array is preallocated here (sized with iov_iter_npages()) and
passed in, so iov_iter_extract_pages() fills it in place rather than
allocating one for us; RDS therefore keeps ownership of the array on
every return path and frees it itself. The rds_info_iterator /
rds_info_copy machinery and all producer callbacks are unchanged.

Kernel buffers (ITER_KVEC) are not page-backed in a way the info
producers can use, so the RDS_INFO path returns -EOPNOTSUPP for them;
this matches the previous behaviour, where a kernel-buffer getsockopt
hit the WARN_ONCE() path in do_sock_getsockopt() and returned
-EOPNOTSUPP. The simple RDS_RECVERR and SO_RDS_TRANSPORT options keep
working for kernel buffers via copy_to_iter().

Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260608-getsock_more-v3-2-706ecf2ea332@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoselftests: net: rds: add getsockopt() conversion test
Breno Leitao [Mon, 8 Jun 2026 09:44:57 +0000 (02:44 -0700)] 
selftests: net: rds: add getsockopt() conversion test

Add a kselftest that exercises the RDS getsockopt() paths converted to
the getsockopt_iter() / sockopt_t callback:

- RDS_RECVERR and SO_RDS_TRANSPORT, which return their int value through
  copy_to_iter() and report the written length in opt->optlen.

- RDS_INFO_*, which obtains the userspace buffer pages with
  iov_iter_extract_pages() (including a non-zero starting page offset)
  and lets the info producers copy the snapshot in under a spinlock.

Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260608-getsock_more-v3-1-706ecf2ea332@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoMerge tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klasser...
Paolo Abeni [Thu, 11 Jun 2026 10:00:49 +0000 (12:00 +0200)] 
Merge tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

Steffen Klassert says:

====================
pull request (net): ipsec 2026-06-10

1) xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
   Propagate SKBFL_SHARED_FRAG when paged fragments are moved between
   skbs so ESP can decide whether in-place crypto is safe.

2) xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
   Replace the unlocked read of xtfs->ra_newskb with a local flag so a
   concurrent reassembly can no longer free first_skb between
   spin_unlock and the post-loop check.

3) xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
   Prune the inexact bin under xfrm_policy_lock so a concurrent
   xfrm_hash_rebuild() can no longer free it before xfrm_policy_kill()
   dereferences it.

4) xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
   Move hrtimer_cancel() for the output and drop timers ahead of their
   spinlocks, breaking the softirq/lock cycle that could deadlock
   against the timer callbacks on SMP.

5) xfrm: espintcp: do not reuse an in-progress partial send
   Fail a new send when espintcp_push_msgs() returns with emsg->len
   still set, so a blocking caller can no longer overwrite ctx->partial
   while a previous transfer still owns it.

6) esp: fix page frag reference leak on skb_to_sgvec failure
   Add a flag to esp_ssg_unref() to unconditionally unref the source
   scatterlist, releasing the old page references that are otherwise
   leaked when the second skb_to_sgvec() in esp_output_tail() fails.

Please pull or let me know if there are problems.

ipsec-2026-06-10

* tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
  esp: fix page frag reference leak on skb_to_sgvec failure
  xfrm: espintcp: do not reuse an in-progress partial send
  xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
  xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
  xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
  xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
====================

Link: https://patch.msgid.link/20260610140800.2562818-1-steffen.klassert@secunet.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoipv6: Fix a potential NPD in cleanup_prefix_route()
Ido Schimmel [Tue, 9 Jun 2026 14:54:48 +0000 (17:54 +0300)] 
ipv6: Fix a potential NPD in cleanup_prefix_route()

addrconf_get_prefix_route() can return the fib6_null_entry sentinel
entry which has a NULL fib6_table pointer. Therefore, before setting the
route's expiration time, check that we are not working with this entry,
as otherwise a NPD will be triggered [1].

Note that the other callers of addrconf_get_prefix_route() are not
susceptible to this bug:

1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF |
   RTF_PREFIX_RT' flags which are not set on fib6_null_entry.

2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid
   possible NULL deref in modify_prefix_route()").

3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for
   fib6_null_entry and returns an error.

[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[...]
Call Trace:
<TASK>
__kasan_check_byte (mm/kasan/common.c:573)
lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1))
_raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1))
cleanup_prefix_route (net/ipv6/addrconf.c:1280)
ipv6_del_addr (net/ipv6/addrconf.c:1342)
inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119)
inet6_rtm_deladdr (net/ipv6/addrconf.c:4812)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6997)
netlink_rcv_skb (net/netlink/af_netlink.c:2555)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1899)
__sock_sendmsg (net/socket.c:802 (discriminator 4))
____sys_sendmsg (net/socket.c:2698)
___sys_sendmsg (net/socket.c:2752)
__sys_sendmsg (net/socket.c:2784)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

Fixes: 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.")
Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com>
Reviewed-by: David Ahern <dahern@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260609145448.768318-1-idosch@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoMerge branch 'selftests-drv-net-so_txtime-trivial-fixes'
Paolo Abeni [Thu, 11 Jun 2026 09:39:14 +0000 (11:39 +0200)] 
Merge branch 'selftests-drv-net-so_txtime-trivial-fixes'

Jakub Kicinski says:

====================
selftests: drv-net: so_txtime: trivial fixes

I noticed that so_txtime is only passing on NIPA setups which are
looped within a single host. The cross-machine cases just flat out
fail. The initial bug is obvious - the test does not deploy the binary.
But even with that I think more work would be needed to sync the
time / adjust the expectations for a dual-machine test.

Willem promised to follow up on the fundamental issues with 2-host
setups :)

v1: https://lore.kernel.org/20260608173305.372987-1-kuba@kernel.org
====================

Link: https://patch.msgid.link/20260609180803.1093428-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoselftests: drv-net: so_txtime: check IP versions
Jakub Kicinski [Tue, 9 Jun 2026 18:08:03 +0000 (11:08 -0700)] 
selftests: drv-net: so_txtime: check IP versions

This test needs more work, and it fails in non-obvious way
when IPv4 connectivity is not available:

  # Exception| CMD[remote]: /tmp/vjquwblf/gukinuzqso_txtime -4 -c mono -t 1780939014114542914 -S None -D None a,0 -r
  # Exception|   EXIT: -15

Explicitly check for IPv4 support to make the future triage
less painful.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609180803.1093428-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoselftests: drv-net: so_txtime: remember to deploy the binaries
Jakub Kicinski [Tue, 9 Jun 2026 18:08:02 +0000 (11:08 -0700)] 
selftests: drv-net: so_txtime: remember to deploy the binaries

The test seems to be written with a single-host loopback
in mind. We need to deploy the binary to remote before
we run it. This is just fixing an obvious issue, but
more work will be needed to make the dual-host setup
work reliably. Most of the runs still fail with:

  FAIL: start time already passed

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260609180803.1093428-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agoMerge branch 'net-txgbe-fix-module-identification'
Paolo Abeni [Thu, 11 Jun 2026 08:55:15 +0000 (10:55 +0200)] 
Merge branch 'net-txgbe-fix-module-identification'

Jiawen Wu says:

====================
net: txgbe: fix module identification

For AML devices, there are some issues where the wrong module
indentified then configure PHY failed.

The module info buffers should be initialized to 0 before the firmware
returns information. And DECLARE_PHY_INTERFACE_MASK() does not guarantee
zeroed contents, so explicitly clear the temporary interface masks before
setting supported interfaces.

Rework txgbe_identify_module() to validate module identifiers through
explicit type checks instead of relying on transceiver_type heuristics.
When using the SFP module, transceiver_type could be a random value,
because it was read from an invalid register.
====================

Link: https://patch.msgid.link/20260608070842.36504-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: txgbe: initialize PHY interface to 0
Jiawen Wu [Mon, 8 Jun 2026 07:08:42 +0000 (15:08 +0800)] 
net: txgbe: initialize PHY interface to 0

DECLARE_PHY_INTERFACE_MASK() does not guarantee zeroed contents. Add a
new macro DECLARE_PHY_INTERFACE_MASK_ZERO(), make the stack variable to
be zeroed before setting supported interfaces.

Fixes: 57d39faed4c9 ("net: txgbe: improve functions of AML 40G devices")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/20260608070842.36504-4-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: txgbe: distinguish module types by checking identifier
Jiawen Wu [Mon, 8 Jun 2026 07:08:41 +0000 (15:08 +0800)] 
net: txgbe: distinguish module types by checking identifier

Rework txgbe_identify_module() to validate module identifiers through
explicit type checks instead of relying on transceiver_type heuristics.
When using the SFP module, transceiver_type could be a random value,
because it was read from an invalid register.

Fixes: 57d39faed4c9 ("net: txgbe: improve functions of AML 40G devices")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/20260608070842.36504-3-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: txgbe: initialize module info buffer
Jiawen Wu [Mon, 8 Jun 2026 07:08:40 +0000 (15:08 +0800)] 
net: txgbe: initialize module info buffer

The module info buffer should be initialized to 0 before the firmware
returns information. Otherwise, there is a risk that the buffer field
not filled by the firmware is random value.

Fixes: 343929799ace ("net: txgbe: Support to handle GPIO IRQs for AML devices")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/20260608070842.36504-2-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agogpio: nomadik: remove dead DB8540 code from <gpio/gpio-nomadik.h>
Ethan Nelson-Moore [Wed, 10 Jun 2026 20:50:07 +0000 (13:50 -0700)] 
gpio: nomadik: remove dead DB8540 code from <gpio/gpio-nomadik.h>

DB8540 support was removed in commit b6d09f780761 ("pinctrl: nomadik:
Drop U8540/9540 support"), but a couple small pieces of related code
remained in <gpio/gpio-nomadik.h>. Remove them.

Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260610205007.44881-1-enelsonmoore@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
13 days agox86/cpu: Make CONFIG_X86_CX8 unconditional
Ingo Molnar [Mon, 27 Apr 2026 06:11:18 +0000 (08:11 +0200)] 
x86/cpu: Make CONFIG_X86_CX8 unconditional

I.e. from now on it's a boot time requirement for the CPU to support it.

( This was preceded by the removal of all non-CX8 platform build
  options, so it should have no functional effects in theory. )

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ahmed S . Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250425084216.3913608-14-mingo@kernel.org
13 days agox86/cpu: Remove unused !CONFIG_X86_TSC code
Ingo Molnar [Mon, 27 Apr 2026 06:07:02 +0000 (08:07 +0200)] 
x86/cpu: Remove unused !CONFIG_X86_TSC code

Now that the Kconfig space always enables CONFIG_X86_TSC (on x86),
remove !CONFIG_X86_TSC code from the x86 arch code.

We still keep the Kconfig option to catch any eventual code still
pending in maintainer or non-mainline trees, plus some drivers
have raw TSC timestamping hacks that use CONFIG_X86_TSC.

It's also still possible to disable TSC support runtime.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ahmed S . Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250425084216.3913608-13-mingo@kernel.org
13 days agom68k: stmark2: enable DACs outputs
Angelo Dureghello [Wed, 10 Jun 2026 20:35:13 +0000 (22:35 +0200)] 
m68k: stmark2: enable DACs outputs

Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7.

Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: stmark2: add mcf5441x DAC platform devices
Angelo Dureghello [Wed, 10 Jun 2026 20:35:12 +0000 (22:35 +0200)] 
m68k: stmark2: add mcf5441x DAC platform devices

Add mcf5441x DAC platform devices.

Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: stmark2: use ioport.h macros for resources
Angelo Dureghello [Wed, 10 Jun 2026 20:35:11 +0000 (22:35 +0200)] 
m68k: stmark2: use ioport.h macros for resources

Change resource declaration using DEFINE_RES_*() macros.
DEFINE_DMA_RES() is for a single dma channel, not a range, so used twice.

Also, some drivers assume IRQ resources are from index 1, so just to stay
uniform, moved IRQ resource at index 1.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: mcf5441x: add CCR MISCCR2 bitfields
Angelo Dureghello [Wed, 10 Jun 2026 20:35:10 +0000 (22:35 +0200)] 
m68k: mcf5441x: add CCR MISCCR2 bitfields

Add CCR MISCCR2 register bitfields.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: mcf5441x: add CCM registers
Angelo Dureghello [Wed, 10 Jun 2026 20:35:09 +0000 (22:35 +0200)] 
m68k: mcf5441x: add CCM registers

Add CCM module register offsets.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: add DAC modules base addresses
Angelo Dureghello [Wed, 10 Jun 2026 20:35:08 +0000 (22:35 +0200)] 
m68k: add DAC modules base addresses

Add DAC controller 0 and 1 base addresses.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: mcf5441x: add clock for DAC channel 1
Angelo Dureghello [Wed, 10 Jun 2026 20:35:07 +0000 (22:35 +0200)] 
m68k: mcf5441x: add clock for DAC channel 1

Add missing clock for mcf5441x DAC channel 1.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agom68k: mcf5441x: fix clocks numbering
Angelo Dureghello [Wed, 10 Jun 2026 20:35:06 +0000 (22:35 +0200)] 
m68k: mcf5441x: fix clocks numbering

Fix clocks numbering, set correct values for eport and DAC,
as per RM Rev 5, 05/2018, table 9.5.

Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.")
Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put")
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
13 days agoMerge branch 'net-mvpp2-fix-xdp-rx-buffer-handling'
Paolo Abeni [Thu, 11 Jun 2026 07:57:33 +0000 (09:57 +0200)] 
Merge branch 'net-mvpp2-fix-xdp-rx-buffer-handling'

Til Kaiser says:

====================
net: mvpp2: fix XDP RX buffer handling

This is v5 of the earlier XDP_PASS fix. The XDP_PASS change is
retained, and the series also fixes related RX/XDP buffer handling
issues found during review.

Tested with tools/testing/selftests/drivers/net/xdp.py on mvpp2
hardware.
====================

Link: https://patch.msgid.link/20260607134943.21996-1-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: mvpp2: build skb from XDP-adjusted data on XDP_PASS
Til Kaiser [Sun, 7 Jun 2026 13:49:43 +0000 (15:49 +0200)] 
net: mvpp2: build skb from XDP-adjusted data on XDP_PASS

When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail()
and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets
derived from the original RX descriptor. Packet geometry changes made by
the XDP program are therefore discarded before the skb reaches the stack.

Update rx_offset and rx_bytes from xdp.data and xdp.data_end for
XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen
by XDP, and makes RX byte accounting for XDP_PASS follow the length of the
skb passed to the network stack.

Keep a separate rx_sync_size for page-pool recycling on skb allocation
failure, which must stay tied to the received buffer range.

Non-PASS verdicts continue to account the descriptor length because no skb
is passed up in those cases.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-5-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: mvpp2: refill RX buffers before XDP or skb use
Til Kaiser [Sun, 7 Jun 2026 13:49:42 +0000 (15:49 +0200)] 
net: mvpp2: refill RX buffers before XDP or skb use

The RX error path returns the current descriptor buffer to the hardware
BM pool. That is only valid while the driver still owns the buffer.

mvpp2_rx_refill() can fail after the current buffer has been handed to
XDP or attached to an skb. In those cases mvpp2_run_xdp() may have
recycled, redirected, or queued the page for XDP_TX, and an skb free also
retires the data buffer. Returning such a buffer to BM lets hardware DMA
into memory that is no longer owned by the RX ring.

Refill the BM pool before handing the current buffer to XDP or to the
skb. If the allocation fails there, drop the packet and return the
still-owned current buffer to BM, preserving the pool depth. Once the
refill succeeds, later local drops retire/free the current buffer instead
of returning it to BM.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-4-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 days agonet: mvpp2: limit XDP frame size to the RX buffer
Til Kaiser [Sun, 7 Jun 2026 13:49:41 +0000 (15:49 +0200)] 
net: mvpp2: limit XDP frame size to the RX buffer

mvpp2 has short and long BM pools, and short pool buffers can be smaller
than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with
PAGE_SIZE as frame size.

XDP helpers use frame_sz to validate tail growth and to derive the hard
end of the data area. Advertising PAGE_SIZE for short buffers can let
bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting
memory or later tripping skb tailroom checks.

Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches
the actual buffer backing the packet.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://patch.msgid.link/20260607134943.21996-3-mail@tk154.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>