Changelog in Linux kernel 6.17.3

 
accel/amdxdna: Use int instead of u32 to store error codes [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Thu Aug 28 11:39:17 2025 +0800

    accel/amdxdna: Use int instead of u32 to store error codes
    
    [ Upstream commit 24de3daf6179bce3710527b8292d7ee6f1b56393 ]
    
    Change the 'ret' variable from u32 to int to store -EINVAL.  Storing the
    negative error codes in unsigned type, doesn't cause an issue at runtime
    but it's ugly as pants.
    
    Additionally, assigning -EINVAL to u32 ret (i.e., u32 ret = -EINVAL) may
    trigger a GCC warning when the -Wsign-conversion flag is enabled.
    
    Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Reviewed-by: Lizhi Hou <[email protected]>
    Signed-off-by: Lizhi Hou <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ACPI: NFIT: Fix incorrect ndr_desc being reportedin dev_err message [+ + +]
Author: Colin Ian King <[email protected]>
Date:   Tue Sep 2 12:45:18 2025 +0100

    ACPI: NFIT: Fix incorrect ndr_desc being reportedin dev_err message
    
    [ Upstream commit d1a599a8136b16522b5afebd122395524496d549 ]
    
    There appears to be a cut-n-paste error with the incorrect field
    ndr_desc->numa_node being reported for the target node. Fix this by
    using ndr_desc->target_node instead.
    
    Fixes: f060db99374e ("ACPI: NFIT: Use fallback node id when numa info in NFIT table is incorrect")
    Signed-off-by: Colin Ian King <[email protected]>
    Reviewed-by: Ira Weiny <[email protected]>
    Signed-off-by: Ira Weiny <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: processor: idle: Fix memory leak when register cpuidle device failed [+ + +]
Author: Huisong Li <[email protected]>
Date:   Mon Jul 28 15:06:11 2025 +0800

    ACPI: processor: idle: Fix memory leak when register cpuidle device failed
    
    [ Upstream commit 11b3de1c03fa9f3b5d17e6d48050bc98b3704420 ]
    
    The cpuidle device's memory is leaked when cpuidle device registration
    fails in acpi_processor_power_init().  Free it as appropriate.
    
    Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure")
    Signed-off-by: Huisong Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Changed the order of the new statements, added empty line after if () ]
    [ rjw: Changelog edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ACPICA: Apply ACPI_NONSTRING [+ + +]
Author: Ahmed Salem <[email protected]>
Date:   Fri Sep 12 21:55:35 2025 +0200

    ACPICA: Apply ACPI_NONSTRING
    
    [ Upstream commit 12fd607554c4efb4856959f0e5823f541bc0e701 ]
    
    Add ACPI_NONSTRING for destination char arrays without a terminating NUL
    character.
    
    This is a follow-up to commit 2b82118845e0 ("ACPICA: Apply ACPI_NONSTRING")
    where a few more destination arrays were missed.
    
    Link: https://github.com/acpica/acpica/commit/f359e5ed
    Fixes: 2b82118845e0 ("ACPICA: Apply ACPI_NONSTRING")
    Signed-off-by: Ahmed Salem <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPICA: Fix largest possible resource descriptor index [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Fri Sep 12 22:03:16 2025 +0200

    ACPICA: Fix largest possible resource descriptor index
    
    [ Upstream commit 8ca944fea4d6d9019e01f2d6f6e766f315a9d73f ]
    
    ACPI_RESOURCE_NAME_LARGE_MAX should be equal to the last actually
    used resource descriptor index (ACPI_RESOURCE_NAME_CLOCK_INPUT).
    
    Otherwise 'resource_index' in 'acpi_ut_validate_resource()' may be
    clamped incorrectly and resulting value may issue an out-of-bounds
    access for 'acpi_gbl_resource_types' array. Compile tested only.
    
    Fixes: 520d4a0ee5b6 ("ACPICA: add support for ClockInput resource (v6.5)")
    Link: https://github.com/acpica/acpica/commit/cf00116c
    Link: https://marc.info/?l=linux-acpi&m=175449676131260&w=2
    Signed-off-by: Dmitry Antipov <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: hda/hdmi: Add pin fix for HP ProDesk model [+ + +]
Author: Steven 'Steve' Kendall <[email protected]>
Date:   Mon Sep 29 21:33:34 2025 +0000

    ALSA: hda/hdmi: Add pin fix for HP ProDesk model
    
    commit 74662f9f92b67c0ca55139c5aa392da0f0a26c08 upstream.
    
    The HP ProDesk 400 (SSID 103c:83f3) also needs a quirk for
    enabling HDMI outputs.  This patch adds the required quirk
    entry.
    
    Signed-off-by: Steven 'Steve' Kendall <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Add quirk for HP Spectre 14t-ea100 [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Sat Sep 27 11:47:23 2025 +0200

    ALSA: hda/realtek: Add quirk for HP Spectre 14t-ea100
    
    commit 50a098e3e9b1bb30cefc43cdfba3c7b9b32e14a7 upstream.
    
    HP-Spectre 14t-ea100 model has no speaker output unless booting
    previously from Windows on dual boot, a reboot while on Linux will
    stop the speakers working.  Applying the existing quirk for HP Spectre
    X360 EU0xxx seems fixing this speaker problem.
    
    Reported-by: Kaden Berger <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/aMxdGAmfOQ6VPNU8@archlinux
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: lx_core: use int type to store negative error codes [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Thu Aug 28 16:13:10 2025 +0800

    ALSA: lx_core: use int type to store negative error codes
    
    [ Upstream commit 4ef353d546cda466fc39b7daca558d7bcec21c09 ]
    
    Change the 'ret' variable from u16 to int to store negative error codes or
    zero returned by lx_message_send_atomic().
    
    Storing the negative error codes in unsigned type, doesn't cause an issue
    at runtime but it's ugly as pants. Additionally, assigning negative error
    codes to unsigned type may trigger a GCC warning when the -Wsign-conversion
    flag is enabled.
    
    No effect on runtime.
    
    Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Mon Sep 15 17:28:51 2025 +0200

    ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT
    
    [ Upstream commit 9fc4a3da9a0259a0500848b5d8657918efde176b ]
    
    snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts
    via spin_lock_irq(). This also implicitly disables the handling of
    softirqs such as TIMER_SOFTIRQ.
    On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not
    disable them. That means a timer can be invoked during spin_lock_irq()
    on the same CPU. Due to synchronisations reasons local_bh_disable() has
    a per-CPU lock named softirq_ctrl.lock which synchronizes individual
    softirq against each other.
    syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is
    acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This
    is a possible deadlock.
    
    The softirq_ctrl.lock can not be made part of spin_lock_irq() as this
    would lead to too much synchronisation against individual threads on the
    system. To avoid the possible deadlock, softirqs must be manually
    disabled before the lock is acquired.
    
    Disable softirqs before the lock is acquired on PREEMPT_RT.
    
    Reported-by: [email protected]
    Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.")
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arch: copy_thread: pass clone_flags as u64 [+ + +]
Author: Simon Schuster <[email protected]>
Date:   Mon Sep 1 15:09:52 2025 +0200

    arch: copy_thread: pass clone_flags as u64
    
    [ Upstream commit bbc46b23af5bb934cd1cf066ef4342cee457a24e ]
    
    With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
    clone3") the effective bit width of clone_flags on all architectures was
    increased from 32-bit to 64-bit, with a new type of u64 for the flags.
    However, for most consumers of clone_flags the interface was not
    changed from the previous type of unsigned long.
    
    While this works fine as long as none of the new 64-bit flag bits
    (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
    undesirable in terms of the principle of least surprise.
    
    Thus, this commit fixes all relevant interfaces of the copy_thread
    function that is called from copy_process to consistently pass
    clone_flags as u64, so that no truncation to 32-bit integers occurs on
    32-bit architectures.
    
    Signed-off-by: Simon Schuster <[email protected]>
    Link: https://lore.kernel.org/20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com
    Fixes: c5febea0956fd387 ("fork: Pass struct kernel_clone_args into copy_thread")
    Acked-by: Guo Ren (Alibaba Damo Academy) <[email protected]>
    Acked-by: Andreas Larsson <[email protected]> # sparc
    Acked-by: David Hildenbrand <[email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]> # m68k
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
 
arm64: dts: allwinner: a527: cubie-a5e: Add ethernet PHY reset setting [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Tue Sep 9 02:10:55 2025 +0800

    arm64: dts: allwinner: a527: cubie-a5e: Add ethernet PHY reset setting
    
    [ Upstream commit a15f095b590bcc1968fbf2ced8fe87fbd8d012e0 ]
    
    The external Ethernet PHY has a reset pin that is connected to the SoC.
    It is missing from the original submission.
    
    Add it to complete the description.
    
    Fixes: acca163f3f51 ("arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E board")
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: allwinner: a527: cubie-a5e: Add LEDs [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Wed Aug 13 01:59:27 2025 +0800

    arm64: dts: allwinner: a527: cubie-a5e: Add LEDs
    
    [ Upstream commit 4184f0190792aea06553af963741a24cc9b47689 ]
    
    The Radxa Cubie A5E has a 3-color LED. The green and blue LEDs are wired
    to GPIO pins on the SoC, and the green one is lit by default to serve as
    a power indicator. The red LED is wired to the M.2 slot.
    
    Add device nodes for the green and blue LEDs.
    
    A default "heartbeat" trigger is set for the green power LED, though in
    practice it might be better if it were inverted, i.e. lit most of the
    time.
    
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Stable-dep-of: 9f01e1e14e71 ("arm64: dts: allwinner: a527: cubie-a5e: Drop external 32.768 KHz crystal")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: allwinner: a527: cubie-a5e: Drop external 32.768 KHz crystal [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Sat Sep 13 18:24:48 2025 +0800

    arm64: dts: allwinner: a527: cubie-a5e: Drop external 32.768 KHz crystal
    
    [ Upstream commit 9f01e1e14e71defefcb4d6823b8476a15f3cf04a ]
    
    The Radxa Cubie A5E has empty pads for a 32.768 KHz crystal, but it is
    left unpopulated, as per the schematics and seen on board images. A dead
    give away is the RTC's LOSC auto switch register showing the external
    OSC to be abnormal.
    
    Drop the external crystal from the device tree. It was not referenced
    anyway.
    
    Fixes: c2520cd032ae ("arm64: dts: allwinner: a523: add Radxa A5E support")
    Reviewed-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: allwinner: t527: avaota-a1: Add ethernet PHY reset setting [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Tue Sep 9 02:10:57 2025 +0800

    arm64: dts: allwinner: t527: avaota-a1: Add ethernet PHY reset setting
    
    [ Upstream commit 8dc3f973b2ff7ea19f7637983c11b005daa8fe45 ]
    
    The external Ethernet PHY has a reset pin that is connected to the SoC.
    It is missing from the original submission.
    
    Add it to complete the description.
    
    Fixes: c6800f15998b ("arm64: dts: allwinner: t527: add EMAC0 to Avaota-A1 board")
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: allwinner: t527: avaota-a1: hook up external 32k crystal [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Sat Sep 13 18:24:49 2025 +0800

    arm64: dts: allwinner: t527: avaota-a1: hook up external 32k crystal
    
    [ Upstream commit 3d5e1ba00af8dd34ae1e573c2c07e00b5ec65267 ]
    
    When the board was added, its external 32.768 KHz crystal was described
    but not hooked up correctly. This meant the device had to fall back to
    the SoC's internal oscillator or divide a 32 KHz clock from the main
    oscillator, neither of which are accurate for the RTC. As a result the
    RTC clock will drift badly.
    
    Hook the crystal up to the RTC block and request the correct clock rate.
    
    Fixes: dbe54efa32af ("arm64: dts: allwinner: a523: add Avaota-A1 router support")
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: allwinner: t527: orangepi-4a: hook up external 32k crystal [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Sat Sep 13 18:24:50 2025 +0800

    arm64: dts: allwinner: t527: orangepi-4a: hook up external 32k crystal
    
    [ Upstream commit bd1ce7ef6aef4ee7349eb3124166e712693650ce ]
    
    When the board was added, its external 32.768 KHz crystal was described
    but not hooked up correctly. This meant the device had to fall back to
    the SoC's internal oscillator or divide a 32 KHz clock from the main
    oscillator, neither of which are accurate for the RTC. As a result the
    RTC clock will drift badly.
    
    Hook the crystal up to the RTC block and request the correct clock rate.
    
    Fixes: de713ccb9934 ("arm64: dts: allwinner: t527: Add OrangePi 4A board")
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: apple: Add ethernet0 alias for J375 template [+ + +]
Author: Janne Grunau <[email protected]>
Date:   Sun Sep 14 21:38:45 2025 +0200

    arm64: dts: apple: Add ethernet0 alias for J375 template
    
    [ Upstream commit 6313115c55f44f7bee3f469c91d3de60d724eabd ]
    
    The alias is used by the boot loader to fill the MAC address.
    
    Fixes: aaa1d42a4ce3 ("arm64: dts: apple: Add J375 devicetrees")
    Reviewed-by: Neal Gompa <[email protected]>
    Signed-off-by: Janne Grunau <[email protected]>
    Reviewed-by: Sven Peter <[email protected]>
    Signed-off-by: Sven Peter <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: apple: t600x: Add bluetooth device nodes [+ + +]
Author: Hector Martin <[email protected]>
Date:   Sat Aug 23 11:49:46 2025 +0200

    arm64: dts: apple: t600x: Add bluetooth device nodes
    
    [ Upstream commit c34e2ec6a84ea3f7a01d8fcd3073f858c4f47605 ]
    
    Add bluetooth PCIe device nodes to specify per device brcm,board-type
    and provide the bootloader filled "local-bd-address" and calibration
    data.
    
    Signed-off-by: Hector Martin <[email protected]>
    Reviewed-by: Neal Gompa <[email protected]>
    Reviewed-by: Sven Peter <[email protected]>
    Signed-off-by: Janne Grunau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sven Peter <[email protected]>
    Stable-dep-of: 6313115c55f4 ("arm64: dts: apple: Add ethernet0 alias for J375 template")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: apple: t600x: Add missing WiFi properties [+ + +]
Author: Hector Martin <[email protected]>
Date:   Sat Aug 23 11:49:45 2025 +0200

    arm64: dts: apple: t600x: Add missing WiFi properties
    
    [ Upstream commit 3050713d84f58d2e4ba463c5474092fa6738c527 ]
    
    Add compatible and antenna-sku properties to the shared node and
    brcm,board-type property to individuall board device trees.
    
    Signed-off-by: Hector Martin <[email protected]>
    Reviewed-by: Neal Gompa <[email protected]>
    Reviewed-by: Sven Peter <[email protected]>
    Signed-off-by: Janne Grunau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sven Peter <[email protected]>
    Stable-dep-of: 6313115c55f4 ("arm64: dts: apple: Add ethernet0 alias for J375 template")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: apple: t8103-j457: Fix PCIe ethernet iommu-map [+ + +]
Author: Janne Grunau <[email protected]>
Date:   Sat Aug 23 11:49:44 2025 +0200

    arm64: dts: apple: t8103-j457: Fix PCIe ethernet iommu-map
    
    [ Upstream commit 6e08cdd604edcec2c277af17c7d36caf827057ff ]
    
    PCIe `port01` of t8103-j457 (iMac, M1, 2 USB-C ports, 2021) is unused
    and disabled. Linux' PCI subsystem assigns the ethernet nic from
    `port02` to bus 02. This results into assigning `pcie0_dart_1` from the
    disabled port as iommu. The `pcie0_dart_1` instance is disabled and
    probably fused off (it is on the M2 Pro Mac mini which has a disabled
    PCIe port as well).
    Without iommu the ethernet nic is not expected work.
    Adjusts the "bus-range" and the PCIe devices "reg" property to PCI
    subsystem's bus number.
    
    Fixes: 7c77ab91b33d ("arm64: dts: apple: Add missing M1 (t8103) devices")
    Reviewed-by: Neal Gompa <[email protected]>
    Reviewed-by: Sven Peter <[email protected]>
    Signed-off-by: Janne Grunau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sven Peter <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx93-kontron: Fix GPIO for panel regulator [+ + +]
Author: Annette Kobou <[email protected]>
Date:   Mon Jul 21 12:05:45 2025 +0200

    arm64: dts: imx93-kontron: Fix GPIO for panel regulator
    
    [ Upstream commit f3e011388dd08d15e0414e3b6b974f946305e7af ]
    
    The regulator uses the wrong GPIO. Fix this.
    
    Signed-off-by: Annette Kobou <[email protected]>
    Signed-off-by: Frieder Schrempf <[email protected]>
    Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board")
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx93-kontron: Fix USB port assignment [+ + +]
Author: Frieder Schrempf <[email protected]>
Date:   Mon Jul 21 12:05:46 2025 +0200

    arm64: dts: imx93-kontron: Fix USB port assignment
    
    [ Upstream commit c94737568b290e0547bff344046f02df49ed6373 ]
    
    The assignment of the USB ports is wrong and needs to be swapped.
    The OTG (USB-C) port is on the first port and the host port with
    the onboard hub is on the second port.
    
    Signed-off-by: Frieder Schrempf <[email protected]>
    Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board")
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx95: Correct the lpuart7 and lpuart8 srcid [+ + +]
Author: Joy Zou <[email protected]>
Date:   Mon Aug 18 09:25:31 2025 +0800

    arm64: dts: imx95: Correct the lpuart7 and lpuart8 srcid
    
    [ Upstream commit 6fdaf3b1839c861931db0dd11747c056a76b68f9 ]
    
    According to the imx95 RM, the lpuart7 rx and tx DMA's srcid are 88 and 87,
    and the lpuart8 rx and tx DMA's srcid are 90 and 89. So correct them.
    
    Fixes: 915fd2e127e8 ("arm64: dts: imx95: add edma[1..3] nodes")
    Signed-off-by: Joy Zou <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt6331: Fix pmic, regulators, rtc, keys node names [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jul 24 10:38:52 2025 +0200

    arm64: dts: mediatek: mt6331: Fix pmic, regulators, rtc, keys node names
    
    [ Upstream commit 98967109c9c0e2de4140827628c63f96314099ab ]
    
    The node names for "pmic", "regulators", "rtc", and "keys" are
    dictated by the PMIC MFD binding: change those to adhere to it.
    
    Fixes: aef783f3e0ca ("arm64: dts: mediatek: Add MT6331 PMIC devicetree")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Fei Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt6795-xperia-m5: Fix mmc0 latch-ck value [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jul 24 10:38:56 2025 +0200

    arm64: dts: mediatek: mt6795-xperia-m5: Fix mmc0 latch-ck value
    
    [ Upstream commit 236681fb64102f25ed11df55999e6985c1bc2f7d ]
    
    Change the latch-ck value from 0x14 to 4: as only bits [0-3] are
    actually used, the final value that gets written to the register
    field for DAT_LATCH_CK_SEL is just 0x4.
    
    This also fixes dtbs_check warnings.
    
    Fixes: 5a65dcccf483 ("arm64: dts: mediatek: mt6795-xperia-m5: Add eMMC, MicroSD slot, SDIO")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt7986a: Fix PCI-Express T-PHY node address [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jul 24 10:38:59 2025 +0200

    arm64: dts: mediatek: mt7986a: Fix PCI-Express T-PHY node address
    
    [ Upstream commit 6b3fff78c13f1a2ba5a355a101fa1ca0a13054ad ]
    
    The PCIe TPHY is under the soc bus, which provides MMIO, and all
    nodes under that must use the bus, otherwise those would clearly
    be out of place.
    
    Add ranges to the PCIe tphy and assign the address to the main
    node to silence a dtbs_check warning, and fix the children to
    use the MMIO range of t-phy.
    
    Fixes: 963c3b0c47ec ("arm64: dts: mediatek: fix t-phy unit name")
    Fixes: 918aed7abd2d ("arm64: dts: mt7986: add pcie related device nodes")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Fei Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8183: Fix out of range pull values [+ + +]
Author: Rob Herring (Arm) <[email protected]>
Date:   Tue Jul 22 12:11:52 2025 -0500

    arm64: dts: mediatek: mt8183: Fix out of range pull values
    
    [ Upstream commit 0aeb7ed4bcb244862a35f880053cd64d28c6fb04 ]
    
    A value of 10 is not valid for "mediatek,pull-down-adv" and
    "mediatek,pull-up-adv" properties which have defined values of 0-3. It
    appears the "10" was written as a binary value. The driver only looks at
    the lowest 2 bits, so the value "10" decimal works out the same as if
    "2" was used.
    
    Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board")
    Fixes: 19b6403f1e2a ("arm64: dts: mt8183: add mt8183 pumpkin board")
    Signed-off-by: Rob Herring (Arm) <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8186-tentacruel: Fix touchscreen model [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Tue Aug 12 17:01:34 2025 +0800

    arm64: dts: mediatek: mt8186-tentacruel: Fix touchscreen model
    
    [ Upstream commit 0370911565869384f19b35ea9e71ee7a57b48a33 ]
    
    The touchscreen controller used with the original Krabby design is the
    Elan eKTH6918, which is in the same family as eKTH6915, but supporting
    a larger screen size with more sense lines.
    
    OTOH, the touchscreen controller that actually shipped on the Tentacruel
    devices is the Elan eKTH6A12NAY. A compatible string was added for it
    specifically because it has different power sequencing timings.
    
    Fix up the touchscreen nodes for both these. This also includes adding
    a previously missing reset line. Also add "no-reset-on-power-off" since
    the power is always on, and putting it in reset would consume more
    power.
    
    Fixes: 8855d01fb81f ("arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8188: Change efuse fallback compatible to mt8186 [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Tue Jun 10 14:34:30 2025 +0800

    arm64: dts: mediatek: mt8188: Change efuse fallback compatible to mt8186
    
    [ Upstream commit c881d1c37b2c159d908203dba5c4920bc776046f ]
    
    The efuse block in the MT8188 contains the GPU speed bin cell, and like
    the MT8186 one, has the same conversion scheme to work with the GPU OPP
    binding. This was reflected in a corresponding change to the efuse DT
    binding.
    
    Change the fallback compatible of the MT8188's efuse block from the
    generic one to the MT8186 one. This also makes GPU DVFS work properly.
    
    Fixes: d39aacd1021a ("arm64: dts: mediatek: mt8188: add lvts definitions")
    Fixes: 50e7592cb696 ("arm64: dts: mediatek: mt8188: Add GPU speed bin NVMEM cells")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie0 [+ + +]
Author: Guoqing Jiang <[email protected]>
Date:   Mon Jul 21 17:59:59 2025 +0800

    arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie0
    
    [ Upstream commit 3374b5fb26b300809ecd6aed9f414987dd17c313 ]
    
    When test suspend resume with 6.8 based kernel, system can't resume
    and I got below error which can be also reproduced with 6.16 rc6+
    kernel.
    
    mtk-pcie-gen3 112f0000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x0)
    mtk-pcie-gen3 112f0000.pcie: PM: dpm_run_callback(): genpd_resume_noirq returns -110
    mtk-pcie-gen3 112f0000.pcie: PM: failed to resume noirq: error -110
    
    After investigation, looks pcie0 has the same problem as pcie1 as
    decribed in commit 3d7fdd8e38aa ("arm64: dts: mediatek: mt8195:
    Remove suspend-breaking reset from pcie1").
    
    Fixes: ecc0af6a3fe6 ("arm64: dts: mt8195: Add pcie and pcie phy nodes")
    Signed-off-by: Guoqing Jiang <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Macpaul Lin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8395-kontron-i1200: Fix MT6360 regulator nodes [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jul 24 10:39:13 2025 +0200

    arm64: dts: mediatek: mt8395-kontron-i1200: Fix MT6360 regulator nodes
    
    [ Upstream commit 09a1e9c973973aff26e66a5673c19442d91b9e3d ]
    
    All of the MT6360 regulator nodes were wrong and would not probe
    because the regulator names are supposed to be lower case, but
    they are upper case in this devicetree.
    
    Change all nodes to be lower case to get working regulators.
    
    Fixes: 94aaf79a6af5 ("arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Fei Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8516-pumpkin: Fix machine compatible [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jul 24 10:39:14 2025 +0200

    arm64: dts: mediatek: mt8516-pumpkin: Fix machine compatible
    
    [ Upstream commit ffe6a5d1dd4d4d8af0779526cf4e40522647b25f ]
    
    This devicetree contained only the SoC compatible but lacked the
    machine specific one: add a "mediatek,mt8516-pumpkin" compatible
    to the list to fix dtbs_check warnings.
    
    Fixes: 9983822c8cf9 ("arm64: dts: mediatek: add pumpkin board dts")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Fei Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Jul 8 12:28:42 2025 +0200

    arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode
    
    commit 27f94b71532203b079537180924023a5f636fca1 upstream.
    
    2290 was found in the field to also require this quirk, as long &
    high-bandwidth workloads (e.g. USB ethernet) are consistently able to
    crash the controller otherwise.
    
    The same change has been made for a number of SoCs in [1], but QCM2290
    somehow escaped the list (even though the very closely related SM6115
    was there).
    
    Upon a controller crash, the log would read:
    
    xhci-hcd.12.auto: xHCI host not responding to stop endpoint command
    xhci-hcd.12.auto: xHCI host controller not responding, assume dead
    xhci-hcd.12.auto: HC died; cleaning up
    
    Add snps,parkmode-disable-ss-quirk to the DWC3 instance in order to
    prevent the aforementioned breakage.
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Cc: [email protected]
    Reported-by: Rob Clark <[email protected]>
    Fixes: a64a0192b70c ("arm64: dts: qcom: Add initial QCM2290 device tree")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: renesas: r9a09g047e57-smarc: Fix gpio key's pin control node [+ + +]
Author: Biju Das <[email protected]>
Date:   Sun Aug 17 15:51:30 2025 +0100

    arm64: dts: renesas: r9a09g047e57-smarc: Fix gpio key's pin control node
    
    [ Upstream commit 3e5df910b592d47734b6dcd03d57498d4766bf6c ]
    
    Adding pin control node to the child won't parse the pins during driver
    bind. Fix the issue by moving it to parent node.
    
    This issue is observed while adding Schmitt input enable for PS0 pin on
    later patch. Currently the reset value of the PIN is set to NMI function
    and hence there is no breakage.
    
    Fixes: 9e95446b0cf9 ("arm64: dts: renesas: r9a09g047e57-smarc: Add gpio keys")
    Signed-off-by: Biju Das <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: rzg2lc-smarc: Disable CAN-FD channel0 [+ + +]
Author: Biju Das <[email protected]>
Date:   Fri Aug 1 13:19:53 2025 +0100

    arm64: dts: renesas: rzg2lc-smarc: Disable CAN-FD channel0
    
    [ Upstream commit ae014fbc99c7f986ee785233e7a5336834e39af4 ]
    
    On RZ/G2LC SMARC EVK, CAN-FD channel0 is not populated, and currently we
    are deleting a wrong and nonexistent node.  Fixing the wrong node would
    invoke a dtb warning message, as channel0 is a required property.
    Disable CAN-FD channel0 instead of deleting the node.
    
    Fixes: 46da632734a5 ("arm64: dts: renesas: rzg2lc-smarc: Enable CANFD channel 1")
    Signed-off-by: Biju Das <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: sparrow-hawk: Invert microSD voltage selector on EVTB1 [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Mon Jul 28 01:58:11 2025 +0200

    arm64: dts: renesas: sparrow-hawk: Invert microSD voltage selector on EVTB1
    
    [ Upstream commit ae95807b00e1639b3f6ab94eb2cd887266e4f766 ]
    
    Invert the polarity of microSD voltage selector on Retronix R-Car V4H
    Sparrow Hawk board. The voltage selector was not populated on prototype
    EVTA1 boards, and is implemented slightly different on EVTB1 boards. As
    the EVTA1 boards are from a limited run and generally not available,
    update the DT to make it compatible with EVTB1 microSD voltage selector.
    
    Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support")
    Signed-off-by: Marek Vasut <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: sparrow-hawk: Set VDDQ18_25_AVB voltage on EVTB1 [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Wed Aug 6 21:28:04 2025 +0200

    arm64: dts: renesas: sparrow-hawk: Set VDDQ18_25_AVB voltage on EVTB1
    
    [ Upstream commit 7d1e3aa2826a22f68f1850c31ac96348272fa356 ]
    
    The Retronix R-Car V4H Sparrow Hawk EVTB1 uses 1V8 IO voltage supply
    for VDDQ18_25_AVB power rail. Update the AVB0 pinmux to reflect the
    change in IO voltage. Since the VDDQ18_25_AVB power rail is shared,
    all four AVB0, AVB1, AVB2, TSN0 PFC/GPIO POC[7..4] registers have to
    be configured the same way. As the EVTA1 boards are from a limited run
    and generally not available, update the DT to make it compatible with
    EVTB1 IO voltage settings.
    
    Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support")
    Signed-off-by: Marek Vasut <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Add RTC on rk3576-evb1-v10 [+ + +]
Author: Alexey Charkov <[email protected]>
Date:   Wed Aug 13 00:30:23 2025 +0400

    arm64: dts: rockchip: Add RTC on rk3576-evb1-v10
    
    [ Upstream commit 0adaae77862932a19cc14c086d7fd15ec0ef7703 ]
    
    Add the I2C connected RTC chip to the Rockchip RK3576 EVB1 board.
    
    Apart from the realtime clock functionality, it also provides a 32 kHz
    clock source for the onboard WiFi chip.
    
    Tested-by: Pavel Zhovner <[email protected]>
    Signed-off-by: Alexey Charkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Stable-dep-of: 843367c7ed19 ("arm64: dts: rockchip: Fix network on rk3576 evb1 board")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Add WiFi on rk3576-evb1-v10 [+ + +]
Author: Alexey Charkov <[email protected]>
Date:   Wed Aug 13 00:30:24 2025 +0400

    arm64: dts: rockchip: Add WiFi on rk3576-evb1-v10
    
    [ Upstream commit ebf8183ad08afc4fcabe1379a5098354829d950d ]
    
    Add device tree nodes to enable the onboard Ampak AP6275P WiFi chip
    connected over a PCIe link on Rockchip RK3576 EVB1.
    
    It takes an external 32 kHz clock from the RTC chip and requires the
    WIFI_REG_ON signal to be enabled before the bus is enumerated to
    initialize properly.
    
    Tested-by: Pavel Zhovner <[email protected]>
    Signed-off-by: Alexey Charkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Stable-dep-of: 843367c7ed19 ("arm64: dts: rockchip: Fix network on rk3576 evb1 board")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Fix network on rk3576 evb1 board [+ + +]
Author: Sebastian Reichel <[email protected]>
Date:   Wed Sep 10 15:54:51 2025 +0200

    arm64: dts: rockchip: Fix network on rk3576 evb1 board
    
    [ Upstream commit 843367c7ed196bd0806c8776cba108aaf6923b82 ]
    
    The RK3576 EVB1 has a RTL8211F PHY for each GMAC interface with
    a dedicated reset line and the 25MHz clock provided by the SoC.
    The current description results in non-working Ethernet as the
    clocks are only enabled by the PHY driver, but probing the right
    PHY driver currently requires that the PHY ID register can be read
    for automatic identification.
    
    This fixes up the network description to get the network functionality
    working reliably and cleans up usage of deprecated DT properties while
    at it.
    
    Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board")
    Signed-off-by: Sebastian Reichel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j742s2-mcu-wakeup: Override firmware-name for MCU R5F cores [+ + +]
Author: Beleswar Padhi <[email protected]>
Date:   Sat Aug 23 22:01:11 2025 +0530

    arm64: dts: ti: k3-j742s2-mcu-wakeup: Override firmware-name for MCU R5F cores
    
    [ Upstream commit 00c8fdc2809f05422d919809106f54c23de3cba3 ]
    
    The J742S2 SoC reuses the common k3-j784s4-j742s2-mcu-wakeup-common.dtsi
    for its MCU domain, but it does not override the firmware-name property
    for its R5F cores. This causes the wrong firmware binaries to be
    referenced.
    
    Introduce a new k3-j742s2-mcu-wakeup.dtsi file to override the
    firmware-name property with correct names for J742s2.
    
    Fixes: 38fd90a3e1ac ("arm64: dts: ti: Introduce J742S2 SoC family")
    Signed-off-by: Beleswar Padhi <[email protected]>
    Reviewed-by: Udit Kumar <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-pinctrl: Fix the bug in existing macros [+ + +]
Author: Akashdeep Kaur <[email protected]>
Date:   Tue Sep 9 10:11:08 2025 +0530

    arm64: dts: ti: k3-pinctrl: Fix the bug in existing macros
    
    [ Upstream commit 2e79ee4d64e9ba4a3fc90e91dfd715407efab16d ]
    
    Currently, DS_IO_OVERRIDE_EN_SHIFT macro is not defined anywhere but
    used for defining other macro.
    Replace this undefined macro with valid macro. Rename the existing macro
    to reflect the actual behavior.
    
    Fixes: 325aa0f6b36e ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros")
    
    Reviewed-by: Kendall Willis <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Reviewed-by: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Akashdeep Kaur <[email protected]>
    Fixes: 325aa0f6b36e ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3: Rename rproc reserved-mem nodes to 'memory@addr' [+ + +]
Author: Beleswar Padhi <[email protected]>
Date:   Mon Sep 8 19:58:05 2025 +0530

    arm64: dts: ti: k3: Rename rproc reserved-mem nodes to 'memory@addr'
    
    [ Upstream commit aee0678597c63e5427e91b2e49a6c5ed4951f277 ]
    
    Currently, the reserved memory carveouts used by remote processors are
    named like 'rproc-name-<dma>-memory-region@addr'. While it is
    descriptive, the node label already serves that purpose. Rename reserved
    memory nodes to generic 'memory@addr' to align with the device tree
    specifications. This is done for all TI K3 based boards.
    
    Signed-off-by: Beleswar Padhi <[email protected]>
    Reviewed-by: Francesco Dolcini <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Stable-dep-of: 79a1778c7819 ("Revert "arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations"")
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: at91: pm: fix MCKx restore routine [+ + +]
Author: Nicolas Ferre <[email protected]>
Date:   Wed Aug 27 16:54:26 2025 +0200

    ARM: at91: pm: fix MCKx restore routine
    
    [ Upstream commit 296302d3d81360e09fa956e9be9edc8223b69a12 ]
    
    The at91_mckx_ps_restore() assembly function is responsible for setting
    back MCKx system bus clocks after exiting low power modes.
    
    Fix a typo and use tmp3 variable instead of tmp2 to correctly set MCKx
    to previously saved state.
    Tmp2 was used without the needed changes in CSS and DIV. Moreover the
    required bit 7, telling that MCR register's content is to be changed
    (CMD/write), was not set.
    
    Fix function comment to match tmp variables actually used.
    
    Signed-off-by: Nicolas Ferre <[email protected]>
    Fixes: 28eb1d40fe57 ("ARM: at91: pm: add support for MCK1..4 save/restore for ulp modes")
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Alexandre Belloni <[email protected]>
    [claudiu.beznea: s/sate/state in commit description]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: omap: am335x-cm-t335: Remove unused mcasp num-serializer property [+ + +]
Author: Jihed Chaibi <[email protected]>
Date:   Sat Aug 30 23:59:57 2025 +0200

    ARM: dts: omap: am335x-cm-t335: Remove unused mcasp num-serializer property
    
    [ Upstream commit 27322753c8b913fba05250e7b5abb1da31e6ed23 ]
    
    The dtbs_check validation for am335x-cm-t335.dtb flags an error
    for an unevaluated 'num-serializer' property in the mcasp0 node.
    
    This property is obsolete; it is not defined in the davinci-mcasp-audio
    schema and is not used by the corresponding (or any) driver.
    
    Remove this unused property to fix the schema validation warning.
    
    Fixes: 48ab364478e77 ("ARM: dts: cm-t335: add audio support")
    Signed-off-by: Jihed Chaibi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kevin Hilman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: renesas: porter: Fix CAN pin group [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Fri Jun 27 15:49:48 2025 +0200

    ARM: dts: renesas: porter: Fix CAN pin group
    
    [ Upstream commit 287066b295051729fb08c3cff12ae17c6fe66133 ]
    
    According to the schematics, the CAN transceiver is connected to pins
    GP7_3 and GP7_4, which correspond to CAN0 data group B.
    
    Fixes: 0768fbad7fba1d27 ("ARM: shmobile: porter: add CAN0 DT support")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/70ad9bc44d6cea92197c42eedcad6b3d0641d26a.1751032025.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: stm32: stm32mp151c-plyaqm: Use correct dai-format property [+ + +]
Author: Jihed Chaibi <[email protected]>
Date:   Sun Aug 31 00:51:15 2025 +0200

    ARM: dts: stm32: stm32mp151c-plyaqm: Use correct dai-format property
    
    [ Upstream commit 0b367e60c73c05721cf2156fe8fe077320115ffd ]
    
    The stm32-i2s binding inherits from the standard audio-graph-port
    schema for its 'port' subnode, audio-graph-port requires the use
    of the 'dai-format' property. The stm32mp151c-plyaqm dts file was
    using the non-standard name 'format'.
    
    Correct the property name to 'dai-format' to fix the dtbs_check
    validation error.
    
    Fixes: 9365fa46be358 ("ARM: dts: stm32: Add Plymovent AQM devicetree")
    Signed-off-by: Jihed Chaibi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Torgue <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: ti: omap: am335x-baltos: Fix ti,en-ck32k-xtal property in DTS to use correct boolean syntax [+ + +]
Author: Jihed Chaibi <[email protected]>
Date:   Sat Aug 23 00:25:30 2025 +0200

    ARM: dts: ti: omap: am335x-baltos: Fix ti,en-ck32k-xtal property in DTS to use correct boolean syntax
    
    [ Upstream commit 9658a92fad1889ff92fa4bd668cd61052687245a ]
    
    The ti,en-ck32k-xtal property, defined as a boolean in the Device Tree
    schema, was incorrectly assigned a value (<1>) in the DTS file, causing
    a validation error: "size (4) error for type flag". The driver uses
    of_property_read_bool(), expecting a boolean. Remove the value to fix
    the dtbs_check error.
    
    Fixes: 262178b6b8e5 ("ARM: dts: split am335x-baltos-ir5221 into dts and dtsi files")
    Signed-off-by: Jihed Chaibi <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kevin Hilman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: ti: omap: omap3-devkit8000-lcd: Fix ti,keep-vref-on property to use correct boolean syntax in DTS [+ + +]
Author: Jihed Chaibi <[email protected]>
Date:   Sat Aug 23 00:50:52 2025 +0200

    ARM: dts: ti: omap: omap3-devkit8000-lcd: Fix ti,keep-vref-on property to use correct boolean syntax in DTS
    
    [ Upstream commit 5af5b85505bc859adb338fe5d6e4842e72cdf932 ]
    
    The ti,keep-vref-on property, defined as a boolean flag in the Device
    Tree schema, was incorrectly assigned a value (<1>) in the DTS file,
    causing a validation error: "size (4) error for type flag". Remove
    the value to match the schema and ensure compatibility with the driver
    using device_property_read_bool(). This fixes the dtbs_check error.
    
    Fixes: ed05637c30e6 ("ARM: dts: omap3-devkit8000: Add ADS7846 Touchscreen support")
    Signed-off-by: Jihed Chaibi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kevin Hilman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: codecs: wcd937x: make stub functions inline [+ + +]
Author: Srinivas Kandagatla <[email protected]>
Date:   Tue Sep 9 13:19:43 2025 +0100

    ASoC: codecs: wcd937x: make stub functions inline
    
    commit c4bb62eb594418a6bd05ff03bb9072ee1fef29c2 upstream.
    
    For some reason we ended up with stub functions that are not inline,
    this can result in build error if its included multiple places, as we will
    be redefining the same function
    
    Fixes: c99a515ff153 ("ASoC: codecs: wcd937x-sdw: add SoundWire driver")
    Cc: [email protected]
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: codecs: wcd937x: set the comp soundwire port correctly [+ + +]
Author: Srinivas Kandagatla <[email protected]>
Date:   Tue Sep 9 13:19:42 2025 +0100

    ASoC: codecs: wcd937x: set the comp soundwire port correctly
    
    commit 66a940b1bf48a7095162688332d725ba160154eb upstream.
    
    For some reason we endup with setting soundwire port for
    HPHL_COMP and HPHR_COMP as zero, this can potentially result
    in a memory corruption due to accessing and setting -1 th element of
    port_map array.
    
    Fixes: 82be8c62a38c ("ASoC: codecs: wcd937x: add basic controls")
    Cc: [email protected]
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Reviewed-by: Alexey Klimov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Sep 2 19:18:19 2025 +0200

    ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping
    
    [ Upstream commit b20eb0e8de383116f1e1470d74da2a3c83c4e345 ]
    
    When an invalid value is passed via quirk option, currently
    bytcht_es8316 driver just ignores and leaves as is, which may lead to
    unepxected results like OOB access.
    
    This patch adds the sanity check and corrects the input mapping to the
    certain default value if an invalid value is passed.
    
    Fixes: 249d2fc9e55c ("ASoC: Intel: bytcht_es8316: Set card long_name based on quirks")
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Sep 2 19:18:20 2025 +0200

    ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping
    
    [ Upstream commit fba404e4b4af4f4f747bb0e41e9fff7d03c7bcc0 ]
    
    When an invalid value is passed via quirk option, currently
    bytcr_rt5640 driver only shows an error message but leaves as is.
    This may lead to unepxected results like OOB access.
    
    This patch corrects the input mapping to the certain default value if
    an invalid value is passed.
    
    Fixes: 063422ca2a9d ("ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks")
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Sep 2 19:18:21 2025 +0200

    ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping
    
    [ Upstream commit 4336efb59ef364e691ef829a73d9dbd4d5ed7c7b ]
    
    When an invalid value is passed via quirk option, currently
    bytcr_rt5640 driver just ignores and leaves as is, which may lead to
    unepxected results like OOB access.
    
    This patch adds the sanity check and corrects the input mapping to the
    certain default value if an invalid value is passed.
    
    Fixes: 64484ccee7af ("ASoC: Intel: bytcr_rt5651: Set card long_name based on quirks")
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: hda-sdw-bpt: set persistent_buffer false [+ + +]
Author: Bard Liao <[email protected]>
Date:   Mon Sep 15 10:48:53 2025 +0800

    ASoC: Intel: hda-sdw-bpt: set persistent_buffer false
    
    [ Upstream commit 8b184c34806e5da4d4847fabd3faeff38b47e70a ]
    
    The persistent_buffer agreement is false when hda_cl_prepare() is
    called. We should use the same value when hda_cl_cleanup() is called.
    
    Fixes: 5d5cb86fb46ea ("ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA")
    Signed-off-by: Bard Liao <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: sof_sdw: Prevent jump to NULL add_sidecar callback [+ + +]
Author: Richard Fitzgerald <[email protected]>
Date:   Fri Sep 19 15:02:35 2025 +0100

    ASoC: Intel: sof_sdw: Prevent jump to NULL add_sidecar callback
    
    [ Upstream commit 87cab86925b7fa4c1c977bc191ac549a3b23f0ea ]
    
    In create_sdw_dailink() check that sof_end->codec_info->add_sidecar
    is not NULL before calling it.
    
    The original code assumed that if include_sidecar is true, the codec
    on that link has an add_sidecar callback. But there could be other
    codecs on the same link that do not have an add_sidecar callback.
    
    Fixes: da5244180281 ("ASoC: Intel: sof_sdw: Add callbacks to register sidecar devices")
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: qcom: sc8280xp: use sa8775p/ subdir for QCS9100 / QCS9075 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Sep 24 22:34:02 2025 +0300

    ASoC: qcom: sc8280xp: use sa8775p/ subdir for QCS9100 / QCS9075
    
    [ Upstream commit ba0c67d3c4b0ce5ec5e6de35e6433b22eecb1f6a ]
    
    All firmware for the Lemans platform aka QCS9100 aka QCS9075 is for
    historical reasons located in the qcom/sa8775p/ subdir inside
    linux-firmware. The only exceptions to this rule are audio topology
    files. While it's not too late, change the subdir to point to the
    sa8775p/ subdir, so that all firmware for that platform is present at
    the same location.
    
    Fixes: 5b5bf5922f4c ("ASoC: qcom: sc8280xp: Add sound card support for QCS9100 and QCS9075")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Srinivas Kandagatla <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines tear down [+ + +]
Author: Ranjani Sridharan <[email protected]>
Date:   Thu Oct 2 10:31:25 2025 +0300

    ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines tear down
    
    commit 59abe7bc7e7c70e9066b3e46874d1b7e6a13de14 upstream.
    
    In the case of static pipelines, freeing the widgets in the pipelines
    that were not suspended after freeing the scheduler widgets results in
    errors because the secondary cores are powered off when the scheduler
    widgets are freed. Fix this by tearing down the leftover pipelines before
    powering off the secondary cores.
    
    Cc: [email protected]
    Fixes: d7332c4a4f1a ("ASoC: SOF: ipc3-topology: Fix pipeline tear down logic")
    Signed-off-by: Ranjani Sridharan <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: SOF: ipc4-pcm: fix delay calculation when DSP resamples [+ + +]
Author: Kai Vehmanen <[email protected]>
Date:   Thu Oct 2 10:47:15 2025 +0300

    ASoC: SOF: ipc4-pcm: fix delay calculation when DSP resamples
    
    commit bcd1383516bb5a6f72b2d1e7f7ad42c4a14837d1 upstream.
    
    When the sampling rates going in (host) and out (dai) from the DSP
    are different, the IPC4 delay reporting does not work correctly.
    Add support for this case by scaling the all raw position values to
    a common timebase before calculating real-time delay for the PCM.
    
    Cc: [email protected]
    Fixes: 0ea06680dfcb ("ASoC: SOF: ipc4-pcm: Correct the delay calculation")
    Signed-off-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: SOF: ipc4-pcm: Fix incorrect comparison with number of tdm_slots [+ + +]
Author: Richard Fitzgerald <[email protected]>
Date:   Tue Aug 19 17:05:25 2025 +0100

    ASoC: SOF: ipc4-pcm: Fix incorrect comparison with number of tdm_slots
    
    [ Upstream commit 62a7b3bbb6b873fdcc85a37efbd0102d66c8a73e ]
    
    In ipc4_ssp_dai_config_pcm_params_match() when comparing params_channels()
    against hw_config->tdm_slots the comparison should be a <= not a ==.
    
    The number of TDM slots must be enough for the number of required channels.
    But it can be greater. There are various reason why a I2S/TDM link has more
    TDM slots than a particular audio stream needs.
    
    The original comparison would fail on systems that had more TDM slots.
    
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Fixes: 8a07944a77e9 ("ASoC: SOF: ipc4-pcm: Look for best matching hw_config for SSP")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: ipc4-pcm: fix start offset calculation for chain DMA [+ + +]
Author: Kai Vehmanen <[email protected]>
Date:   Thu Oct 2 10:47:16 2025 +0300

    ASoC: SOF: ipc4-pcm: fix start offset calculation for chain DMA
    
    commit bace10b59624e6bd8d68bc9304357f292f1b3dcf upstream.
    
    Assumption that chain DMA module starts the link DMA when 1ms of
    data is available from host is not correct. Instead the firmware
    chain DMA module fills the link DMA with initial buffer of zeroes
    and the host and link DMAs are started at the same time.
    
    This results in a small error in delay calculation. This can become a
    more severe problem if host DMA has delays that exceed 1ms. This results
    in negative delay to be calculated and bogus values reported to
    applications. This can confuse some applications like
    alsa_conformance_test.
    
    Fix the issue by correctly calculating the firmware chain DMA
    preamble size and initializing the start offset to this value.
    
    Cc: [email protected]
    Fixes: a1d203d390e0 ("ASoC: SOF: ipc4-pcm: Enable delay reporting for ChainDMA streams")
    Signed-off-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data() [+ + +]
Author: Ma Ke <[email protected]>
Date:   Tue Sep 23 14:52:12 2025 +0800

    ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()
    
    commit 4e65bda8273c938039403144730923e77916a3d7 upstream.
    
    wcd934x_codec_parse_data() contains a device reference count leak in
    of_slim_get_device() where device_find_child() increases the reference
    count of the device but this reference is not properly decreased in
    the success path. Add put_device() in wcd934x_codec_parse_data() and
    add devm_add_action_or_reset() in the probe function, which ensures
    that the reference count of the device is correctly managed.
    
    Memory leak in regmap_init_slimbus() as the allocated regmap is not
    released when the device is removed. Using devm_regmap_init_slimbus()
    instead of regmap_init_slimbus() to ensure automatic regmap cleanup on
    device removal.
    
    Calling path: of_slim_get_device() -> of_find_slim_device() ->
    device_find_child(). As comment of device_find_child() says, 'NOTE:
    you will need to drop the reference with put_device() after use.'.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec")
    Signed-off-by: Ma Ke <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
blk-mq-sched: add new parameter nr_requests in blk_mq_alloc_sched_tags() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:42 2025 +0800

    blk-mq-sched: add new parameter nr_requests in blk_mq_alloc_sched_tags()
    
    [ Upstream commit 6293e336f6d7d3f3415346ce34993b3398846166 ]
    
    This helper only support to allocate the default number of requests,
    add a new parameter to support specific number of requests.
    
    Prepare to fix potential deadlock in the case nr_requests grow.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
    Signed-off-by: Sasha Levin <[email protected]>

 
blk-mq: check invalid nr_requests in queue_requests_store() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:38 2025 +0800

    blk-mq: check invalid nr_requests in queue_requests_store()
    
    [ Upstream commit b46d4c447db76e36906ed59ebb9b3ef8f3383322 ]
    
    queue_requests_store() is the only caller of
    blk_mq_update_nr_requests(), and blk_mq_update_nr_requests() is the
    only caller of blk_mq_tag_update_depth(), however, they all have
    checkings for nr_requests input by user.
    
    Make code cleaner by moving all the checkings to the top function:
    
    1) nr_requests > reserved tags;
    2) if there is elevator, 4 <= nr_requests <= 2048;
    3) if elevator is none, 4 <= nr_requests <= tag_set->queue_depth;
    
    Meanwhile, case 2 is the only case tags can grow and -ENOMEM might be
    returned.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctx [+ + +]
Author: Li Nan <[email protected]>
Date:   Tue Aug 26 16:48:54 2025 +0800

    blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctx
    
    [ Upstream commit 4c7ef92f6d4d08a27d676e4c348f4e2922cab3ed ]
    
    In __blk_mq_update_nr_hw_queues() the return value of
    blk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctx
    fails, later changing the number of hw_queues or removing disk will
    trigger the following warning:
    
      kernfs: can not remove 'nr_tags', no directory
      WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160
      Call Trace:
       remove_files.isra.1+0x38/0xb0
       sysfs_remove_group+0x4d/0x100
       sysfs_remove_groups+0x31/0x60
       __kobject_del+0x23/0xf0
       kobject_del+0x17/0x40
       blk_mq_unregister_hctx+0x5d/0x80
       blk_mq_sysfs_unregister_hctxs+0x94/0xd0
       blk_mq_update_nr_hw_queues+0x124/0x760
       nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
       nullb_device_submit_queues_store+0x92/0x120 [null_blk]
    
    kobjct_del() was called unconditionally even if sysfs creation failed.
    Fix it by checkig the kobject creation statusbefore deleting it.
    
    Fixes: 477e19dedc9d ("blk-mq: adjust debugfs and sysfs register when updating nr_hw_queues")
    Signed-off-by: Li Nan <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: cleanup shared tags case in blk_mq_update_nr_requests() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:40 2025 +0800

    blk-mq: cleanup shared tags case in blk_mq_update_nr_requests()
    
    [ Upstream commit 7f2799c546dba9e12f9ff4d07936601e416c640d ]
    
    For shared tags case, all hctx->sched_tags/tags are the same, it doesn't
    make sense to call into blk_mq_tag_update_depth() multiple times for the
    same tags.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: convert to serialize updating nr_requests with update_nr_hwq_lock [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:39 2025 +0800

    blk-mq: convert to serialize updating nr_requests with update_nr_hwq_lock
    
    [ Upstream commit 626ff4f8ebcb7207f01e7810acb85812ccf06bd8 ]
    
    request_queue->nr_requests can be changed by:
    
    a) switch elevator by updating nr_hw_queues
    b) switch elevator by elevator sysfs attribute
    c) configue queue sysfs attribute nr_requests
    
    Current lock order is:
    
    1) update_nr_hwq_lock, case a,b
    2) freeze_queue
    3) elevator_lock, case a,b,c
    
    And update nr_requests is seriablized by elevator_lock() already,
    however, in the case c, we'll have to allocate new sched_tags if
    nr_requests grow, and do this with elevator_lock held and queue
    freezed has the risk of deadlock.
    
    Hence use update_nr_hwq_lock instead, make it possible to allocate
    memory if tags grow, meanwhile also prevent nr_requests to be changed
    concurrently.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: fix elevator depth_updated method [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Thu Aug 21 14:06:11 2025 +0800

    blk-mq: fix elevator depth_updated method
    
    [ Upstream commit 7d337eef4affc5e26e0570513168c69ddbc40f92 ]
    
    Current depth_updated has some problems:
    
    1) depth_updated() will be called for each hctx, while all elevators
    will update async_depth for the disk level, this is not related to hctx;
    2) In blk_mq_update_nr_requests(), if previous hctx update succeed and
    this hctx update failed, q->nr_requests will not be updated, while
    async_depth is already updated with new nr_reqeuests in previous
    depth_updated();
    3) All elevators are using q->nr_requests to calculate async_depth now,
    however, q->nr_requests is still the old value when depth_updated() is
    called from blk_mq_update_nr_requests();
    
    Those problems are first from error path, then mq-deadline, and recently
    for bfq and kyber, fix those problems by:
    
    - pass in request_queue instead of hctx;
    - move depth_updated() after q->nr_requests is updated in
      blk_mq_update_nr_requests();
    - add depth_updated() call inside init_sched() method to initialize
      async_depth;
    - remove init_hctx() method for mq-deadline and bfq that is useless now;
    
    Fixes: 77f1e0a52d26 ("bfq: update internal depth state when queue depth changes")
    Fixes: 39823b47bbd4 ("block/mq-deadline: Fix the tag reservation code")
    Fixes: 42e6c6ce03fd ("lib/sbitmap: convert shallow_depth from one word to the whole sbitmap")
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Li Nan <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: fix potential deadlock while nr_requests grown [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:43 2025 +0800

    blk-mq: fix potential deadlock while nr_requests grown
    
    [ Upstream commit b86433721f46d934940528f28d49c1dedb690df1 ]
    
    Allocate and free sched_tags while queue is freezed can deadlock[1],
    this is a long term problem, hence allocate memory before freezing
    queue and free memory after queue is unfreezed.
    
    [1] https://lore.kernel.org/all/[email protected]/
    Fixes: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through sysfs")
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: remove useless checkings in blk_mq_update_nr_requests() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:37 2025 +0800

    blk-mq: remove useless checkings in blk_mq_update_nr_requests()
    
    [ Upstream commit 8bd7195fea6d9662aa3b32498a3828bfd9b63185 ]
    
    1) queue_requests_store() is the only caller of
    blk_mq_update_nr_requests(), where queue is already freezed, no need to
    check mq_freeze_depth;
    2) q->tag_set must be set for request based device, and queue_is_mq() is
    already checked in blk_mq_queue_attr_visible(), no need to check
    q->tag_set.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
    Signed-off-by: Sasha Levin <[email protected]>

blk-mq: split bitmap grow and resize case in blk_mq_update_nr_requests() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 16:04:41 2025 +0800

    blk-mq: split bitmap grow and resize case in blk_mq_update_nr_requests()
    
    [ Upstream commit e63200404477456ec60c62dd8b3b1092aba2e211 ]
    
    No functional changes are intended, make code cleaner and prepare to fix
    the grow case in following patches.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Nilay Shroff <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
    Signed-off-by: Sasha Levin <[email protected]>

 
blk-throttle: fix access race during throttle policy activation [+ + +]
Author: Han Guangjiang <[email protected]>
Date:   Fri Sep 5 18:24:11 2025 +0800

    blk-throttle: fix access race during throttle policy activation
    
    [ Upstream commit bd9fd5be6bc0836820500f68fff144609fbd85a9 ]
    
    On repeated cold boots we occasionally hit a NULL pointer crash in
    blk_should_throtl() when throttling is consulted before the throttle
    policy is fully enabled for the queue. Checking only q->td != NULL is
    insufficient during early initialization, so blkg_to_pd() for the
    throttle policy can still return NULL and blkg_to_tg() becomes NULL,
    which later gets dereferenced.
    
     Unable to handle kernel NULL pointer dereference
     at virtual address 0000000000000156
     ...
     pc : submit_bio_noacct+0x14c/0x4c8
     lr : submit_bio_noacct+0x48/0x4c8
     sp : ffff800087f0b690
     x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0
     x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70
     x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
     x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff
     x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff
     x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c
     x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60
     x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002
     x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500
     x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a
     Call trace:
      submit_bio_noacct+0x14c/0x4c8
      verity_map+0x178/0x2c8
      __map_bio+0x228/0x250
      dm_submit_bio+0x1c4/0x678
      __submit_bio+0x170/0x230
      submit_bio_noacct_nocheck+0x16c/0x388
      submit_bio_noacct+0x16c/0x4c8
      submit_bio+0xb4/0x210
      f2fs_submit_read_bio+0x4c/0xf0
      f2fs_mpage_readpages+0x3b0/0x5f0
      f2fs_readahead+0x90/0xe8
    
    Tighten blk_throtl_activated() to also require that the throttle policy
    bit is set on the queue:
    
      return q->td != NULL &&
             test_bit(blkcg_policy_throtl.plid, q->blkcg_pols);
    
    This prevents blk_should_throtl() from accessing throttle group state
    until policy data has been attached to blkgs.
    
    Fixes: a3166c51702b ("blk-throttle: delay initialization until configuration")
    Co-developed-by: Liang Jie <[email protected]>
    Signed-off-by: Liang Jie <[email protected]>
    Signed-off-by: Han Guangjiang <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

blk-throttle: fix throtl_data leak during disk release [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 17 15:55:39 2025 +0800

    blk-throttle: fix throtl_data leak during disk release
    
    [ Upstream commit 336aec7b06be860477be80a4299263a2e9355789 ]
    
    Tightening the throttle activation check in blk_throtl_activated() to
    require both q->td presence and policy bit set introduced a memory leak
    during disk release:
    
    blkg_destroy_all() clears the policy bit first during queue deactivation,
    causing subsequent blk_throtl_exit() to skip throtl_data cleanup when
    blk_throtl_activated() fails policy check.
    
    Idealy we should avoid modifying blk_throtl_exit() activation check because
    it's intuitive that blk-throtl start from blk_throtl_init() and end in
    blk_throtl_exit(). However, call blk_throtl_exit() before
    blkg_destroy_all() will make a long term deadlock problem easier to
    trigger[1], hence fix this problem by checking if q->td is NULL from
    blk_throtl_exit(), and remove policy deactivation as well since it's
    useless.
    
    [1] https://lore.kernel.org/all/CAHj4cs9p9H5yx+ywsb3CMUdbqGPhM+8tuBvhW=9ADiCjAqza9w@mail.gmail.com/#t
    
    Fixes: bd9fd5be6bc0 ("blk-throttle: fix access race during throttle policy activation")
    Reported-by: Yi Zhang <[email protected]>
    Closes: https://lore.kernel.org/all/CAHj4cs-p-ZwBEKigBj7T6hQCOo-H68-kVwCrV6ZvRovrr9Z+HA@mail.gmail.com/
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block: cleanup bio_issue [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 14:30:41 2025 +0800

    block: cleanup bio_issue
    
    [ Upstream commit 1733e88874838ddebf7774440c285700865e6b08 ]
    
    Now that bio->bi_issue is only used by blk-iolatency to get bio issue
    time, replace bio_issue with u64 time directly and remove bio_issue to
    make code cleaner.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 1f963bdd6420 ("block: initialize bio issue time in blk_mq_submit_bio()")
    Signed-off-by: Sasha Levin <[email protected]>

block: factor out a helper bio_submit_split_bioset() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 14:30:46 2025 +0800

    block: factor out a helper bio_submit_split_bioset()
    
    [ Upstream commit e37b5596a19be9a150cb194ec32e78f295a3574b ]
    
    No functional changes are intended, some drivers like mdraid will split
    bio by internal processing, prepare to unify bio split codes.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b2f5974079d8 ("block: fix ordering of recursive split IO")
    Signed-off-by: Sasha Levin <[email protected]>

block: fix ordering of recursive split IO [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 14:30:55 2025 +0800

    block: fix ordering of recursive split IO
    
    [ Upstream commit b2f5974079d82a4761f002e80601064d4e39a81f ]
    
    Currently, split bio will be chained to original bio, and original bio
    will be resubmitted to the tail of current->bio_list, waiting for
    split bio to be issued. However, if split bio get split again, the IO
    order will be messed up. This problem, on the one hand, will cause
    performance degradation, especially for mdraid with large IO size; on
    the other hand, will cause write errors for zoned block devices[1].
    
    For example, in raid456 IO will first be split by max_sector from
    md_submit_bio(), and then later be split again by chunksize for internal
    handling:
    
    For example, assume max_sectors is 1M, and chunksize is 512k
    
    1) issue a 2M IO:
    
    bio issuing: 0+2M
    current->bio_list: NULL
    
    2) md_submit_bio() split by max_sector:
    
    bio issuing: 0+1M
    current->bio_list: 1M+1M
    
    3) chunk_aligned_read() split by chunksize:
    
    bio issuing: 0+512k
    current->bio_list: 1M+1M -> 512k+512k
    
    4) after first bio issued, __submit_bio_noacct() will contuine issuing
    next bio:
    
    bio issuing: 1M+1M
    current->bio_list: 512k+512k
    bio issued: 0+512k
    
    5) chunk_aligned_read() split by chunksize:
    
    bio issuing: 1M+512k
    current->bio_list: 512k+512k -> 1536k+512k
    bio issued: 0+512k
    
    6) no split afterwards, finally the issue order is:
    
    0+512k -> 1M+512k -> 512k+512k -> 1536k+512k
    
    This behaviour will cause large IO read on raid456 endup to be small
    discontinuous IO in underlying disks. Fix this problem by placing split
    bio to the head of current->bio_list.
    
    Test script: test on 8 disk raid5 with 64k chunksize
    dd if=/dev/md0 of=/dev/null bs=4480k iflag=direct
    
    Test results:
    Before this patch
    1) iostat results:
    Device            r/s     rMB/s   rrqm/s  %rrqm r_await rareq-sz  aqu-sz  %util
    md0           52430.00   3276.87     0.00   0.00    0.62    64.00   32.60  80.10
    sd*           4487.00    409.00  2054.00  31.40    0.82    93.34    3.68  71.20
    2) blktrace G stage:
      8,0    0   486445    11.357392936   843  G   R 14071424 + 128 [dd]
      8,0    0   486451    11.357466360   843  G   R 14071168 + 128 [dd]
      8,0    0   486454    11.357515868   843  G   R 14071296 + 128 [dd]
      8,0    0   486468    11.357968099   843  G   R 14072192 + 128 [dd]
      8,0    0   486474    11.358031320   843  G   R 14071936 + 128 [dd]
      8,0    0   486480    11.358096298   843  G   R 14071552 + 128 [dd]
      8,0    0   486490    11.358303858   843  G   R 14071808 + 128 [dd]
    3) io seek for sdx:
    Noted io seek is the result from blktrace D stage, statistic of:
    ABS((offset of next IO) - (offset + len of previous IO))
    
    Read|Write seek
    cnt 55175, zero cnt 25079
        >=(KB) .. <(KB)     : count       ratio |distribution                            |
             0 .. 1         : 25079       45.5% |########################################|
             1 .. 2         : 0            0.0% |                                        |
             2 .. 4         : 0            0.0% |                                        |
             4 .. 8         : 0            0.0% |                                        |
             8 .. 16        : 0            0.0% |                                        |
            16 .. 32        : 0            0.0% |                                        |
            32 .. 64        : 12540       22.7% |#####################                   |
            64 .. 128       : 2508         4.5% |#####                                   |
           128 .. 256       : 0            0.0% |                                        |
           256 .. 512       : 10032       18.2% |#################                       |
           512 .. 1024      : 5016         9.1% |#########                               |
    
    After this patch:
    1) iostat results:
    Device            r/s     rMB/s   rrqm/s  %rrqm r_await rareq-sz  aqu-sz  %util
    md0           87965.00   5271.88     0.00   0.00    0.16    61.37   14.03  90.60
    sd*           6020.00    658.44  5117.00  45.95    0.44   112.00    2.68  86.50
    2) blktrace G stage:
      8,0    0   206296     5.354894072   664  G   R 7156992 + 128 [dd]
      8,0    0   206305     5.355018179   664  G   R 7157248 + 128 [dd]
      8,0    0   206316     5.355204438   664  G   R 7157504 + 128 [dd]
      8,0    0   206319     5.355241048   664  G   R 7157760 + 128 [dd]
      8,0    0   206333     5.355500923   664  G   R 7158016 + 128 [dd]
      8,0    0   206344     5.355837806   664  G   R 7158272 + 128 [dd]
      8,0    0   206353     5.355960395   664  G   R 7158528 + 128 [dd]
      8,0    0   206357     5.356020772   664  G   R 7158784 + 128 [dd]
    3) io seek for sdx
    Read|Write seek
    cnt 28644, zero cnt 21483
        >=(KB) .. <(KB)     : count       ratio |distribution                            |
             0 .. 1         : 21483       75.0% |########################################|
             1 .. 2         : 0            0.0% |                                        |
             2 .. 4         : 0            0.0% |                                        |
             4 .. 8         : 0            0.0% |                                        |
             8 .. 16        : 0            0.0% |                                        |
            16 .. 32        : 0            0.0% |                                        |
            32 .. 64        : 7161        25.0% |##############                          |
    
    BTW, this looks like a long term problem from day one, and large
    sequential IO read is pretty common case like video playing.
    
    And even with this patch, in this test case IO is merged to at most 128k
    is due to block layer plug limit BLK_PLUG_FLUSH_SIZE, increase such
    limit can get even better performance. However, we'll figure out how to do
    this properly later.
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Fixes: d89d87965dcb ("When stacked block devices are in-use (e.g. md or dm), the recursive calls")
    Reported-by: Tie Ren <[email protected]>
    Closes: https://lore.kernel.org/all/7dro5o7u5t64d6bgiansesjavxcuvkq5p2pok7dtwkav7b7ape@3isfr44b6352/
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: fix stacking of atomic writes when atomics are not supported [+ + +]
Author: John Garry <[email protected]>
Date:   Mon Sep 15 10:34:59 2025 +0000

    block: fix stacking of atomic writes when atomics are not supported
    
    [ Upstream commit f2d8c5a2f79c28569edf4948b611052253b5e99a ]
    
    Atomic writes support may not always be possible when stacking devices
    which support atomic writes. Such as case is a different atomic write
    boundary between stacked devices (which is not supported).
    
    In the case that atomic writes cannot supported, the top device queue HW
    limits are set to 0.
    
    However, in blk_stack_atomic_writes_limits(), we detect that we are
    stacking the first bottom device by checking the top device
    atomic_write_hw_max value == 0. This get confused with the case of atomic
    writes not supported, above.
    
    Make the distinction between stacking the first bottom device and no
    atomics supported by initializing stacked device atomic_write_hw_max =
    UINT_MAX and checking that for stacking the first bottom device.
    
    Fixes: d7f36dc446e8 ("block: Support atomic writes limits for stacked devices")
    Signed-off-by: John Garry <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: initialize bio issue time in blk_mq_submit_bio() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 14:30:42 2025 +0800

    block: initialize bio issue time in blk_mq_submit_bio()
    
    [ Upstream commit 1f963bdd6420b6080bcfd0ee84a75c96f35545a6 ]
    
    bio->issue_time_ns is only used by blk-iolatency, which can only be
    enabled for rq-based disk, hence it's not necessary to initialize
    the time for bio-based disk.
    
    Meanwhile, if bio is split by blk_crypto_fallback_split_bio_if_needed(),
    the issue time is not initialized for new split bio, this can be fixed
    as well.
    
    Noted the next patch will optimize better that bio issue time will
    only be used when blk-iolatency is really enabled by the disk.
    
    Fixes: 488f6682c832 ("block: blk-crypto-fallback for Inline Encryption")
    Signed-off-by: Yu Kuai <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: skip unnecessary checks for split bio [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Sep 10 14:30:54 2025 +0800

    block: skip unnecessary checks for split bio
    
    [ Upstream commit 0b64682e78f7a53ea863e368b1aa66f05767858d ]
    
    Lots of checks are already done while submitting this bio the first
    time, and there is no need to check them again when this bio is
    resubmitted after split.
    
    Hence open code should_fail_bio() and blk_throtl_bio() that are still
    necessary from submit_bio_split_bioset().
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: b2f5974079d8 ("block: fix ordering of recursive split IO")
    Signed-off-by: Sasha Levin <[email protected]>

block: update validation of atomic writes boundary for stacked devices [+ + +]
Author: John Garry <[email protected]>
Date:   Mon Sep 15 10:34:58 2025 +0000

    block: update validation of atomic writes boundary for stacked devices
    
    [ Upstream commit bfd4037296bd7e1f95394a2e3daf8e3c1796c3b3 ]
    
    In commit 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked
    atomic write limits"), it was missed to use a chunk sectors limit check
    in blk_stack_atomic_writes_boundary_head(), so update that function to
    do the proper check.
    
    Fixes: 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked atomic write limits")
    Signed-off-by: John Garry <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: use int to store blk_stack_limits() return value [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Tue Sep 2 21:09:30 2025 +0800

    block: use int to store blk_stack_limits() return value
    
    [ Upstream commit b0b4518c992eb5f316c6e40ff186cbb7a5009518 ]
    
    Change the 'ret' variable in blk_stack_limits() from unsigned int to int,
    as it needs to store negative value -1.
    
    Storing the negative error codes in unsigned type, or performing equality
    comparisons (e.g., ret == -1), doesn't cause an issue at runtime [1] but
    can be confusing.  Additionally, assigning negative error codes to unsigned
    type may trigger a GCC warning when the -Wsign-conversion flag is enabled.
    
    No effect on runtime.
    
    Link: https://lore.kernel.org/all/x3wogjf6vgpkisdhg3abzrx7v7zktmdnfmqeih5kosszmagqfs@oh3qxrgzkikf/ #1
    Signed-off-by: Qianfeng Rong <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Fixes: fe0b393f2c0a ("block: Correct handling of bottom device misaligment")
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: btintel_pcie: Refactor Device Coredump [+ + +]
Author: Kiran K <[email protected]>
Date:   Wed Aug 6 12:18:49 2025 +0530

    Bluetooth: btintel_pcie: Refactor Device Coredump
    
    [ Upstream commit 58fddb364dd5c4e9bf223a2113a42538d9c040de ]
    
    As device coredumps are not HCI traces, maintain the device coredump at
    the driver level and eliminate the dependency on hdev_devcd*()
    
    Signed-off-by: Kiran K <[email protected]>
    Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Sep 19 12:30:05 2025 -0400

    Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements
    
    [ Upstream commit 03ddb4ac251463ec5b7b069395d9ab89163dd56c ]
    
    When creating an advertisement for BIG the address shall not be
    non-resolvable since in case of acting as BASS/Broadcast Assistant the
    address must be the same as the connection in order to use the PAST
    method and even when PAST/BASS are not in the picture a Periodic
    Advertisement can still be synchronized thus the same argument as to
    connectable advertisements still stand.
    
    Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: don't leak skb in ISO_CONT RX [+ + +]
Author: Pauli Virtanen <[email protected]>
Date:   Mon Sep 22 21:11:22 2025 +0300

    Bluetooth: ISO: don't leak skb in ISO_CONT RX
    
    [ Upstream commit 5bf863f4c5da055c1eb08887ae4f26d99dbc4aac ]
    
    For ISO_CONT RX, the data from skb is copied to conn->rx_skb, but the
    skb is leaked.
    
    Free skb after copying its data.
    
    Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
    Signed-off-by: Pauli Virtanen <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: Fix possible UAF on iso_conn_free [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Sep 22 16:27:51 2025 -0400

    Bluetooth: ISO: Fix possible UAF on iso_conn_free
    
    [ Upstream commit 9950f095d6c875dbe0c9ebfcf972ec88fdf26fc8 ]
    
    This attempt to fix similar issue to sco_conn_free where if the
    conn->sk is not set to NULL may lead to UAF on iso_conn_free.
    
    Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: free rx_skb if not consumed [+ + +]
Author: Pauli Virtanen <[email protected]>
Date:   Mon Sep 22 21:11:21 2025 +0300

    Bluetooth: ISO: free rx_skb if not consumed
    
    [ Upstream commit 6ba85da5804efffe15c89b03742ea868f20b4172 ]
    
    If iso_conn is freed when RX is incomplete, free any leftover skb piece.
    
    Fixes: dc26097bdb86 ("Bluetooth: ISO: Use kref to track lifetime of iso_conn")
    Signed-off-by: Pauli Virtanen <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: MGMT: Fix not exposing debug UUID on MGMT_OP_READ_EXP_FEATURES_INFO [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Aug 20 08:50:12 2025 -0400

    Bluetooth: MGMT: Fix not exposing debug UUID on MGMT_OP_READ_EXP_FEATURES_INFO
    
    [ Upstream commit 79e562a52adea4afa0601a15964498fae66c823c ]
    
    The debug UUID was only getting set if MGMT_OP_READ_EXP_FEATURES_INFO
    was not called with a specific index which breaks the likes of
    bluetoothd since it only invokes MGMT_OP_READ_EXP_FEATURES_INFO when an
    adapter is plugged, so instead of depending hdev not to be set just
    enable the UUID on any index like it was done with iso_sock_uuid.
    
    Fixes: e625e50ceee1 ("Bluetooth: Introduce debug feature when dynamic debug is disabled")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bonding: fix xfrm offload feature setup on active-backup mode [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Thu Sep 25 02:33:03 2025 +0000

    bonding: fix xfrm offload feature setup on active-backup mode
    
    [ Upstream commit 5b66169f6be4847008c0aea50885ff0632151479 ]
    
    The active-backup bonding mode supports XFRM ESP offload. However, when
    a bond is added using command like `ip link add bond0 type bond mode 1
    miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
    disabled. This occurs because, in bond_newlink(), we change bond link
    first and register bond device later. So the XFRM feature update in
    bond_option_mode_set() is not called as the bond device is not yet
    registered, leading to the offload feature not being set successfully.
    
    To resolve this issue, we can modify the code order in bond_newlink() to
    ensure that the bond device is registered first before changing the bond
    link parameters. This change will allow the XFRM ESP offload feature to be
    correctly enabled.
    
    Fixes: 007ab5345545 ("bonding: fix feature flag setting at init time")
    Signed-off-by: Hangbin Liu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, arm64: Call bpf_jit_binary_pack_finalize() in bpf_jit_free() [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Tue Sep 16 23:26:53 2025 +0000

    bpf, arm64: Call bpf_jit_binary_pack_finalize() in bpf_jit_free()
    
    [ Upstream commit 6ff4a0fa3e1b2b9756254b477fb2f0fbe04ff378 ]
    
    The current implementation seems incorrect and does NOT match the
    comment above, use bpf_jit_binary_pack_finalize() instead.
    
    Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management")
    Acked-by: Puranjay Mohan <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Acked-by: Puranjay Mohan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf/selftests: Fix test_tcpnotify_user [+ + +]
Author: Matt Bobrowski <[email protected]>
Date:   Fri Aug 15 12:12:14 2025 +0000

    bpf/selftests: Fix test_tcpnotify_user
    
    [ Upstream commit c80d79720647ed77ebc0198abd5a0807efdaff0b ]
    
    Based on a bisect, it appears that commit 7ee988770326 ("timers:
    Implement the hierarchical pull model") has somehow inadvertently
    broken BPF selftest test_tcpnotify_user. The error that is being
    generated by this test is as follows:
    
            FAILED: Wrong stats Expected 10 calls, got 8
    
    It looks like the change allows timer functions to be run on CPUs
    different from the one they are armed on. The test had pinned itself
    to CPU 0, and in the past the retransmit attempts also occurred on CPU
    0. The test had set the max_entries attribute for
    BPF_MAP_TYPE_PERF_EVENT_ARRAY to 2 and was calling
    bpf_perf_event_output() with BPF_F_CURRENT_CPU, so the entry was
    likely to be in range. With the change to allow timers to run on other
    CPUs, the current CPU tasked with performing the retransmit might be
    bumped and in turn fall out of range, as the event will be filtered
    out via __bpf_perf_event_output() using:
    
        if (unlikely(index >= array->map.max_entries))
                return -E2BIG;
    
    A possible change would be to explicitly set the max_entries attribute
    for perf_event_map in test_tcpnotify_kern.c to a value that's at least
    as large as the number of CPUs. As it turns out however, if the field
    is left unset, then the libbpf will determine the number of CPUs available
    on the underlying system and update the max_entries attribute accordingly
    in map_set_def_max_entries().
    
    A further problem with the test is that it has a thread that continues
    running up until the program exits. The main thread cleans up some
    LIBBPF data structures, while the other thread continues to use them,
    which inevitably will trigger a SIGSEGV. This can be dealt with by
    telling the thread to run for as long as necessary and doing a
    pthread_join on it before exiting the program.
    
    Finally, I don't think binding the process to CPU 0 is meaningful for
    this test any more, so get rid of that.
    
    Fixes: 435f90a338ae ("selftests/bpf: add a test case for sock_ops perf-event notification")
    Signed-off-by: Matt Bobrowski <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Acked-by: Stanislav Fomichev <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: dont report verifier bug for missing bpf_scc_visit on speculative path [+ + +]
Author: Eduard Zingerman <[email protected]>
Date:   Tue Sep 16 14:22:50 2025 -0700

    bpf: dont report verifier bug for missing bpf_scc_visit on speculative path
    
    [ Upstream commit a3c73d629ea1373af3c0c954d41fd1af555492e3 ]
    
    Syzbot generated a program that triggers a verifier_bug() call in
    maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a
    state with insn_idx in some SCC, there should be an instance of struct
    bpf_scc_visit allocated for that SCC. Turns out the assumption does
    not hold for speculative execution paths. See example in the next
    patch.
    
    maybe_scc_exit() is called from update_branch_counts() for states that
    reach branch count of zero, meaning that path exploration for a
    particular path is finished. Path exploration can finish in one of
    three ways:
    a. Verification error is found. In this case, update_branch_counts()
       is called only for non-speculative paths.
    b. Top level BPF_EXIT is reached. Such instructions are never a part of
       an SCC, so compute_scc_callchain() in maybe_scc_exit() will return
       false, and maybe_scc_exit() will return early.
    c. A checkpoint is reached and matched. Checkpoints are created by
       is_state_visited(), which calls maybe_enter_scc(), which allocates
       bpf_scc_visit instances for checkpoints within SCCs.
    
    Hence, for non-speculative symbolic execution paths, the assumption
    still holds: if maybe_scc_exit() is called for a state within an SCC,
    bpf_scc_visit instance must exist.
    
    This patch removes the verifier_bug() call for speculative paths.
    
    Fixes: c9e31900b54c ("bpf: propagate read/precision marks over state graph backedges")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Signed-off-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Enforce expected_attach_type for tailcall compatibility [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Sep 26 19:12:00 2025 +0200

    bpf: Enforce expected_attach_type for tailcall compatibility
    
    [ Upstream commit 4540aed51b12bc13364149bf95f6ecef013197c0 ]
    
    Yinhao et al. recently reported:
    
      Our fuzzer tool discovered an uninitialized pointer issue in the
      bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem.
      This leads to a NULL pointer dereference when a BPF program attempts to
      deference the txq member of struct xdp_buff object.
    
    The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the
    entry point for bpf_prog_test_run_xdp() and its expected_attach_type can
    neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot
    of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP
    to pass xdp_is_valid_access() validation. The program returns struct xdp_md's
    egress_ifindex, and the latter is only allowed to be accessed under mentioned
    expected_attach_type. progB is then inserted into the tailcall which progA
    calls.
    
    The underlying issue goes beyond XDP though. Another example are programs
    of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well
    as sock_addr_func_proto() have different logic depending on the programs'
    expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME
    should not be allowed doing a tailcall into a program which calls bpf_bind()
    out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.
    
    In short, specifying expected_attach_type allows to open up additional
    functionality or restrictions beyond what the basic bpf_prog_type enables.
    The use of tailcalls must not violate these constraints. Fix it by enforcing
    expected_attach_type in __bpf_prog_map_compatible().
    
    Note that we only enforce this for tailcall maps, but not for BPF devmaps or
    cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and
    cpu_map_bpf_prog_run*() which set up a new environment / context and therefore
    these situations are not prone to this issue.
    
    Fixes: 5e43f899b03a ("bpf: Check attach type at prog load time")
    Reported-by: Yinhao Hu <[email protected]>
    Reported-by: Kaiyan Mei <[email protected]>
    Reviewed-by: Dongliang Mu <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Explicitly check accesses to bpf_sock_addr [+ + +]
Author: Paul Chaignon <[email protected]>
Date:   Wed Sep 17 10:08:00 2025 +0200

    bpf: Explicitly check accesses to bpf_sock_addr
    
    [ Upstream commit 6fabca2fc94d33cdf7ec102058983b086293395f ]
    
    Syzkaller found a kernel warning on the following sock_addr program:
    
        0: r0 = 0
        1: r2 = *(u32 *)(r1 +60)
        2: exit
    
    which triggers:
    
        verifier bug: error during ctx access conversion (0)
    
    This is happening because offset 60 in bpf_sock_addr corresponds to an
    implicit padding of 4 bytes, right after msg_src_ip4. Access to this
    padding isn't rejected in sock_addr_is_valid_access and it thus later
    fails to convert the access.
    
    This patch fixes it by explicitly checking the various fields of
    bpf_sock_addr in sock_addr_is_valid_access.
    
    I checked the other ctx structures and is_valid_access functions and
    didn't find any other similar cases. Other cases of (properly handled)
    padding are covered in new tests in a subsequent patch.
    
    Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg")
    Reported-by: [email protected]
    Signed-off-by: Paul Chaignon <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Closes: https://syzkaller.appspot.com/bug?extid=136ca59d411f92e821b7
    Link: https://lore.kernel.org/bpf/b58609d9490649e76e584b0361da0abd3c2c1779.1758094761.git.paul.chaignon@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Mark kfuncs as __noclone [+ + +]
Author: Andrea Righi <[email protected]>
Date:   Wed Sep 24 10:14:26 2025 +0200

    bpf: Mark kfuncs as __noclone
    
    [ Upstream commit d4680a11e14c7baf683cb8453d91d71d2e0b9d3e ]
    
    Some distributions (e.g., CachyOS) support building the kernel with -O3,
    but doing so may break kfuncs, resulting in their symbols not being
    properly exported.
    
    In fact, with gcc -O3, some kfuncs may be optimized away despite being
    annotated as noinline. This happens because gcc can still clone the
    function during IPA optimizations, e.g., by duplicating or inlining it
    into callers, and then dropping the standalone symbol. This breaks BTF
    ID resolution since resolve_btfids relies on the presence of a global
    symbol for each kfunc.
    
    Currently, this is not an issue for upstream, because we don't allow
    building the kernel with -O3, but it may be safer to address it anyway,
    to prevent potential issues in the future if compilers become more
    aggressive with optimizations.
    
    Therefore, add __noclone to __bpf_kfunc to ensure kfuncs are never
    cloned and remain distinct, globally visible symbols, regardless of
    the optimization level.
    
    Fixes: 57e7c169cd6af ("bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs")
    Acked-by: David Vernet <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrea Righi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Reject negative offsets for ALU ops [+ + +]
Author: Yazhou Tang <[email protected]>
Date:   Tue Sep 30 23:04:33 2025 +0800

    bpf: Reject negative offsets for ALU ops
    
    [ Upstream commit 55c0ced59fe17dee34e9dfd5f7be63cbab207758 ]
    
    When verifying BPF programs, the check_alu_op() function validates
    instructions with ALU operations. The 'offset' field in these
    instructions is a signed 16-bit integer.
    
    The existing check 'insn->off > 1' was intended to ensure the offset is
    either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is
    signed, this check incorrectly accepts all negative values (e.g., -1).
    
    This commit tightens the validation by changing the condition to
    '(insn->off != 0 && insn->off != 1)'. This ensures that any value
    other than the explicitly permitted 0 and 1 is rejected, hardening the
    verifier against malformed BPF programs.
    
    Co-developed-by: Shenghao Yuan <[email protected]>
    Signed-off-by: Shenghao Yuan <[email protected]>
    Co-developed-by: Tianci Cao <[email protected]>
    Signed-off-by: Tianci Cao <[email protected]>
    Signed-off-by: Yazhou Tang <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Fixes: ec0e2da95f72 ("bpf: Support new signed div/mod instructions.")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Remove migrate_disable in kprobe_multi_link_prog_run [+ + +]
Author: Tao Chen <[email protected]>
Date:   Thu Aug 14 20:14:29 2025 +0800

    bpf: Remove migrate_disable in kprobe_multi_link_prog_run
    
    [ Upstream commit abdaf49be5424db74e19d167c10d7dad79a0efc2 ]
    
    Graph tracer framework ensures we won't migrate, kprobe_multi_link_prog_run
    called all the way from graph tracer, which disables preemption in
    function_graph_enter_regs, as Jiri and Yonghong suggested, there is no
    need to use migrate_disable. As a result, some overhead may will be reduced.
    And add cant_sleep check for __this_cpu_inc_return.
    
    Fixes: 0dcac2725406 ("bpf: Add multi kprobe link")
    Signed-off-by: Tao Chen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Remove preempt_disable in bpf_try_get_buffers [+ + +]
Author: Tao Chen <[email protected]>
Date:   Tue Aug 19 20:56:38 2025 +0800

    bpf: Remove preempt_disable in bpf_try_get_buffers
    
    [ Upstream commit 4223bf833c8495e40ae2886acbc0ecbe88fa6306 ]
    
    Now BPF program will run with migration disabled, so it is safe
    to access this_cpu_inc_return(bpf_bprintf_nest_level).
    
    Fixes: d9c9e4db186a ("bpf: Factorize bpf_trace_printk and bpf_seq_printf")
    Signed-off-by: Tao Chen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer [+ + +]
Author: Brahmajit Das <[email protected]>
Date:   Thu Oct 2 00:47:38 2025 +0530

    bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer
    
    [ Upstream commit 34904582b502a86fdb4d7984b12cacd2faabbe0d ]
    
    In check_alu_op(), the verifier currently calls check_reg_arg() and
    adjust_scalar_min_max_vals() unconditionally for BPF_NEG operations.
    However, if the destination register holds a pointer, these scalar
    adjustments are unnecessary and potentially incorrect.
    
    This patch adds a check to skip the adjustment logic when the destination
    register contains a pointer.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=d36d5ae81e1b0a53ef58
    Fixes: aced132599b3 ("bpf: Add range tracking for BPF_NEG")
    Suggested-by: KaFai Wan <[email protected]>
    Suggested-by: Eduard Zingerman <[email protected]>
    Signed-off-by: Brahmajit Das <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Tidy verifier bug message [+ + +]
Author: Paul Chaignon <[email protected]>
Date:   Mon Aug 11 20:58:20 2025 +0200

    bpf: Tidy verifier bug message
    
    [ Upstream commit c93c59baa5ab57e94b874000cec56e26611b7a23 ]
    
    Yonghong noticed that error messages for potential verifier bugs often
    have a '(1)' at the end. This is happening because verifier_bug_if(cond,
    env, fmt, args...) prints "(" #cond ")\n" as part of the message and
    verifier_bug() is defined as:
    
      #define verifier_bug(env, fmt, args...) verifier_bug_if(1, env, fmt, ##args)
    
    Hence, verifier_bug() always ends up displaying '(1)'. This small patch
    fixes it by having verifier_bug_if conditionally call verifier_bug
    instead of the other way around.
    
    Fixes: 1cb0f56d9618 ("bpf: WARN_ONCE on verifier bugs")
    Reported-by: Yonghong Song <[email protected]>
    Signed-off-by: Paul Chaignon <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Tested-by: Eduard Zingerman <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: fix symbolic link reading when bs > ps [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Mon Sep 15 14:29:42 2025 +0930

    btrfs: fix symbolic link reading when bs > ps
    
    [ Upstream commit 67378b754608a3524d125bfa5744508a49fe48be ]
    
    [BUG DURING BS > PS TEST]
    When running the following script on a btrfs whose block size is larger
    than page size, e.g. 8K block size and 4K page size, it will trigger a
    kernel BUG:
    
      # mkfs.btrfs -s 8k $dev
      # mount $dev $mnt
      # mkdir $mnt/dir
      # ln -s dir $mnt/link
      # ls $mnt/link
    
    The call trace looks like this:
    
      BTRFS warning (device dm-2): support for block size 8192 with page size 4096 is experimental, some features may be missing
      BTRFS info (device dm-2): checking UUID tree
      BTRFS info (device dm-2): enabling ssd optimizations
      BTRFS info (device dm-2): enabling free space tree
      ------------[ cut here ]------------
      kernel BUG at /home/adam/linux/include/linux/highmem.h:275!
      Oops: invalid opcode: 0000 [#1] SMP
      CPU: 8 UID: 0 PID: 667 Comm: ls Tainted: G           OE       6.17.0-rc4-custom+ #283 PREEMPT(full)
      Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
      RIP: 0010:zero_user_segments.constprop.0+0xdc/0xe0 [btrfs]
      Call Trace:
       <TASK>
       btrfs_get_extent.cold+0x85/0x101 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f]
       btrfs_do_readpage+0x244/0x750 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f]
       btrfs_read_folio+0x9c/0x100 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f]
       filemap_read_folio+0x37/0xe0
       do_read_cache_folio+0x94/0x3e0
       __page_get_link.isra.0+0x20/0x90
       page_get_link+0x16/0x40
       step_into+0x69b/0x830
       path_lookupat+0xa7/0x170
       filename_lookup+0xf7/0x200
       ? set_ptes.isra.0+0x36/0x70
       vfs_statx+0x7a/0x160
       do_statx+0x63/0xa0
       __x64_sys_statx+0x90/0xe0
       do_syscall_64+0x82/0xae0
       entry_SYSCALL_64_after_hwframe+0x4b/0x53
       </TASK>
    
    Please note bs > ps support is still under development and the
    enablement patch is not even in btrfs development branch.
    
    [CAUSE]
    Btrfs reuses its data folio read path to handle symbolic links, as the
    symbolic link target is stored as an inline data extent.
    
    But for newly created inodes, btrfs only set the minimal order if the
    target inode is a regular file.
    
    Thus for above newly created symbolic link, it doesn't properly respect
    the minimal folio order, and triggered the above crash.
    
    [FIX]
    Call btrfs_set_inode_mapping_order() unconditionally inside
    btrfs_create_new_inode().
    
    For symbolic links this will fix the crash as now the folio will meet
    the minimal order.
    
    For regular files this brings no change.
    
    For directory/bdev/char and all the other types of inodes, they won't
    go through the data read path, thus no effect either.
    
    Fixes: cc38d178ff33 ("btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTAL")
    Signed-off-by: Qu Wenruo <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: return any hit error from extent_writepage_io() [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Thu Sep 18 08:40:45 2025 +0930

    btrfs: return any hit error from extent_writepage_io()
    
    [ Upstream commit 2d83ed6c6c4607b42ee7927e92a9d2fa31d6f30b ]
    
    Since the support of bs < ps support, extent_writepage_io() will submit
    multiple blocks inside the folio.
    
    But if we hit error submitting one sector, but the next sector can still
    be submitted successfully, the function extent_writepage_io() will still
    return 0.
    
    This will make btrfs to silently ignore the error without setting error
    flag for the filemap.
    
    Fix it by recording the first error hit, and always return that value.
    
    Fixes: 8bf334beb349 ("btrfs: fix double accounting race when extent_writepage_io() failed")
    Reviewed-by: Daniel Vacek <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: fsl-mc: Check return value of platform_get_resource() [+ + +]
Author: Salah Triki <[email protected]>
Date:   Mon Aug 25 10:34:35 2025 +0100

    bus: fsl-mc: Check return value of platform_get_resource()
    
    commit 25f526507b8ccc6ac3a43bc094d09b1f9b0b90ae upstream.
    
    platform_get_resource() returns NULL in case of failure, so check its
    return value and propagate the error in order to prevent NULL pointer
    dereference.
    
    Fixes: 6305166c8771 ("bus: fsl-mc: Add ACPI support for fsl-mc")
    Cc: [email protected]
    Signed-off-by: Salah Triki <[email protected]>
    Acked-by: Ioana Ciornei <[email protected]>
    Link: https://lore.kernel.org/r/aKwuK6TRr5XNYQ8u@pc
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cdx: don't select CONFIG_GENERIC_MSI_IRQ [+ + +]
Author: Nipun Gupta <[email protected]>
Date:   Tue Aug 26 10:08:51 2025 +0530

    cdx: don't select CONFIG_GENERIC_MSI_IRQ
    
    [ Upstream commit ab1d8dda32e9507ca3bfb6b43661aeaa27f7bd82 ]
    
    x86 does not use CONFIG_GENERIC_MSI_IRQ, and trying to enable it anyway
    results in a build failure:
    
    In file included from include/linux/ssb/ssb.h:10,
                     from drivers/ssb/pcihost_wrapper.c:18:
    include/linux/gpio/driver.h:41:33: error: field 'msiinfo' has incomplete type
       41 |         msi_alloc_info_t        msiinfo;
          |                                 ^~~~~~~
    In file included from include/linux/kvm_host.h:19,
                     from arch/x86/events/intel/core.c:17:
    include/linux/msi.h:528:33: error: field 'alloc_info' has incomplete type
      528 |         msi_alloc_info_t        alloc_info;
    
    Change the driver to actually build without this symbol and remove the
    incorrect 'select' statements.
    
    Fixes: e8b18c11731d ("cdx: Fix missing GENERIC_MSI_IRQ on compile test")
    Reviewed-by: Robin Murphy <[email protected]>
    Reviewed-by: Nikhil Agarwal <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Nipun Gupta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clocksource/drivers/tegra186: Avoid 64-bit division [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 20 13:19:35 2025 +0200

    clocksource/drivers/tegra186: Avoid 64-bit division
    
    [ Upstream commit 409f8fe03e08f92bf5be96cedbcd7a3e8fb2eeaf ]
    
    The newly added function causes a build failure on 32-bit targets with
    older compiler version such as gcc-10:
    
    arm-linux-gnueabi-ld: drivers/clocksource/timer-tegra186.o: in function `tegra186_wdt_get_timeleft':
    timer-tegra186.c:(.text+0x3c2): undefined reference to `__aeabi_uldivmod'
    
    The calculation can trivially be changed to avoid the division entirely,
    as USEC_PER_SEC is a multiple of 5. Change both such calculation for
    consistency, even though gcc apparently managed to optimize the other one
    properly already.
    
    [dlezcano : Fixed conflict with [email protected] ]
    
    Fixes: 28c842c8b0f5 ("clocksource/drivers/timer-tegra186: Add WDIOC_GETTIMELEFT support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
clocksource/drivers/timer-tegra186: Avoid 64-bit divide operation [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Sat Jun 14 10:55:55 2025 -0700

    clocksource/drivers/timer-tegra186: Avoid 64-bit divide operation
    
    [ Upstream commit 916aa36042db8ee230543ffe0d192f900e8b8c9f ]
    
    Building the driver on xtensa fails with
    
    tensa-linux-ld: drivers/clocksource/timer-tegra186.o:
            in function `tegra186_timer_remove':
    timer-tegra186.c:(.text+0x350):
            undefined reference to `__udivdi3'
    
    Avoid the problem by rearranging the offending code to avoid the 64-bit
    divide operation.
    
    Fixes: 28c842c8b0f5 ("clocksource/drivers/timer-tegra186: Add WDIOC_GETTIMELEFT support")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Jon Hunter <[email protected]>
    Cc: Pohsun Su <[email protected]>
    Cc: Robert Lin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight-etm4x: Conditionally access register TRCEXTINSELR [+ + +]
Author: Yuanfang Zhang <[email protected]>
Date:   Tue Aug 12 01:24:45 2025 -0700

    coresight-etm4x: Conditionally access register TRCEXTINSELR
    
    [ Upstream commit dcdc42f5dcf9b9197c51246c62966e2d54a033d8 ]
    
    The TRCEXTINSELR is only implemented if TRCIDR5.NUMEXTINSEL > 0.
    To avoid invalid accesses, introduce a check on numextinsel
    (derived from TRCIDR5[11:9]) before reading or writing to this register.
    
    Fixes: f5bd523690d2 ("coresight: etm4x: Convert all register accesses")
    Signed-off-by: Yuanfang Zhang <[email protected]>
    Reviewed-by: James Clark <[email protected]>
    Reviewed-by: Mike Leach <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: Appropriately disable programming clocks [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Jul 31 13:23:40 2025 +0100

    coresight: Appropriately disable programming clocks
    
    [ Upstream commit 1abc1b212effe920f4729353880c8e03f1d76b4b ]
    
    Some CoreSight components have programming clocks (pclk) and are enabled
    using clk_get() and clk_prepare_enable().  However, in many cases, these
    clocks are not disabled when modules exit and only released by clk_put().
    
    To fix the issue, this commit refactors programming clock by replacing
    clk_get() and clk_prepare_enable() with devm_clk_get_optional_enabled()
    for enabling APB clock. If the "apb_pclk" clock is not found, a NULL
    pointer is returned, and the function proceeds to attempt enabling the
    "apb" clock.
    
    Since ACPI platforms rely on firmware to manage clocks, returning a NULL
    pointer in this case leaves clock management to the firmware rather than
    the driver. This effectively avoids a clock imbalance issue during
    module removal - where the clock could be disabled twice: once during
    the ACPI runtime suspend and again during the devm resource release.
    
    Callers are updated to reuse the returned error value.
    
    With the change, programming clocks are managed as resources in driver
    model layer, allowing clock cleanup to be handled automatically.  As a
    result, manual cleanup operations are no longer needed and are removed
    from the Coresight drivers.
    
    Fixes: 73d779a03a76 ("coresight: etm4x: Change etm4_platform_driver driver for MMIO devices")
    Reviewed-by: Yeoreum Yun <[email protected]>
    Tested-by: James Clark <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: Appropriately disable trace bus clocks [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Jul 31 13:23:41 2025 +0100

    coresight: Appropriately disable trace bus clocks
    
    [ Upstream commit a8f2d480f19d912f15dbac7038cd578d6b8b4d74 ]
    
    Some CoreSight components have trace bus clocks 'atclk' and are enabled
    using clk_prepare_enable().  These clocks are not disabled when modules
    exit.
    
    As atclk is optional, use devm_clk_get_optional_enabled() to manage it.
    The benefit is the driver model layer can automatically disable and
    release clocks.
    
    Check the returned value with IS_ERR() to detect errors but leave the
    NULL pointer case if the clock is not found.  And remove the error
    handling codes which are no longer needed.
    
    Fixes: d1839e687773 ("coresight: etm: retrieve and handle atclk")
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Tested-by: James Clark <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: Avoid enable programming clock duplicately [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Jul 31 13:23:42 2025 +0100

    coresight: Avoid enable programming clock duplicately
    
    [ Upstream commit d091c6312561821f216ced63a7ad17c946b6d335 ]
    
    The programming clock is enabled by AMBA bus driver before a dynamic
    probe. As a result, a CoreSight driver may redundantly enable the same
    clock.
    
    To avoid this, add a check for device type and skip enabling the
    programming clock for AMBA devices. The returned NULL pointer will be
    tolerated by the drivers.
    
    Fixes: 73d779a03a76 ("coresight: etm4x: Change etm4_platform_driver driver for MMIO devices")
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Tested-by: James Clark <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: catu: Support atclk [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Jul 31 13:23:38 2025 +0100

    coresight: catu: Support atclk
    
    [ Upstream commit 5483624effea2e893dc0df6248253a6a2a085451 ]
    
    The atclk is an optional clock for the CoreSight CATU, but the driver
    misses to initialize it.
    
    This change enables atclk in probe of the CATU driver, and dynamically
    control the clock during suspend and resume.
    
    The checks for driver data and clocks in suspend and resume are not
    needed, remove them.  Add error handling in the resume function.
    
    Fixes: fcacb5c154ba ("coresight: Introduce support for Coresight Address Translation Unit")
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Tested-by: James Clark <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: etm4x: Support atclk [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Jul 31 13:23:39 2025 +0100

    coresight: etm4x: Support atclk
    
    [ Upstream commit 40c0cdc9cbbebae9f43bef1cab9ce152318d0cce ]
    
    The atclk is an optional clock for the CoreSight ETMv4, but the driver
    misses to initialize it.
    
    This change enables atclk in probe of the ETMv4 driver, and dynamically
    control the clock during suspend and resume.
    
    No need to check the driver data and clock pointer in the runtime
    suspend and resume, so remove checks.  And add error handling in the
    resume function.
    
    Add a minor fix to the comment format when adding the atclk field.
    
    Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver")
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Tested-by: James Clark <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: Fix incorrect handling for return value of devm_kzalloc [+ + +]
Author: Lin Yujun <[email protected]>
Date:   Mon Sep 8 20:20:22 2025 +0800

    coresight: Fix incorrect handling for return value of devm_kzalloc
    
    [ Upstream commit 70714eb7243eaf333d23501d4c7bdd9daf011c01 ]
    
    The return value of devm_kzalloc could be an null pointer,
    use "!desc.pdata" to fix incorrect handling return value
    of devm_kzalloc.
    
    Fixes: 4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE")
    Signed-off-by: Lin Yujun <[email protected]>
    Reviewed-by: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: fix indentation error in cscfg_remove_owned_csdev_configs() [+ + +]
Author: Yeoreum Yun <[email protected]>
Date:   Wed Jun 11 11:30:25 2025 +0100

    coresight: fix indentation error in cscfg_remove_owned_csdev_configs()
    
    [ Upstream commit 21dd3f8bc24b6adc57f09fff5430b0039dd00492 ]
    
    Fix wrong indentation in cscfg_remove_owned_csdev_configs()
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 53b9e2659719 ("coresight: holding cscfg_csdev_lock while removing cscfg from csdev")
    Signed-off-by: Yeoreum Yun <[email protected]>
    Reviewed-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: Fix missing include for FIELD_GET [+ + +]
Author: James Clark <[email protected]>
Date:   Mon Jul 7 10:55:27 2025 +0100

    coresight: Fix missing include for FIELD_GET
    
    [ Upstream commit 08d24e076d0fb9f90522ef69bf6cdae06e0919de ]
    
    Include the header for FIELD_GET which is only sometimes transitively
    included on some configs and kernel releases.
    
    Reported-by: Linux Kernel Functional Testing <[email protected]>
    Closes: https://lists.linaro.org/archives/list/[email protected]/thread/6GKMK52PPRJVEYMEUHJP6BXF4CJAXOFL/
    Fixes: a4e65842e114 ("coresight: Only check bottom two claim bits")
    Signed-off-by: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/20250707-james-coresight-bitfield-include-v1-1-aa0f4220ecfd@linaro.org
    Signed-off-by: Sasha Levin <[email protected]>

coresight: Only register perf symlink for sinks with alloc_buffer [+ + +]
Author: Yuanfang Zhang <[email protected]>
Date:   Mon Jun 30 18:26:19 2025 +0800

    coresight: Only register perf symlink for sinks with alloc_buffer
    
    [ Upstream commit 12d9a9dd9d8a4f1968073e7f34515896d1e22b78 ]
    
    Ensure that etm_perf_add_symlink_sink() is only called for devices
    that implement the alloc_buffer operation. This prevents invalid
    symlink creation for dummy sinks that do not implement alloc_buffer.
    
    Without this check, perf may attempt to use a dummy sink that lacks
    alloc_buffer operationsu to initialise perf's ring buffer, leading
    to runtime failures.
    
    Fixes: 9d3ba0b6c0569 ("Coresight: Add coresight dummy driver")
    Signed-off-by: Yuanfang Zhang <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: tmc: Support atclk [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Jul 31 13:23:37 2025 +0100

    coresight: tmc: Support atclk
    
    [ Upstream commit 8a79026926b329d4ab0c6d0921373a80ec8aab6e ]
    
    The atclk is an optional clock for the CoreSight TMC, but the driver
    misses to initialize it.  In most cases, TMC shares the atclk clock with
    other CoreSight components.  Since these components enable the clock
    before the TMC device is initialized, the TMC continues properly,
    which is why we don’t observe any lockup issues.
    
    This change enables atclk in probe of the TMC driver.  Given the clock
    is optional, it is possible to return NULL if the clock does not exist.
    IS_ERR() is tolerant for this case.
    
    Dynamically disable and enable atclk during suspend and resume.  The
    clock pointers will never be error values if the driver has successfully
    probed, and the case of a NULL pointer case will be handled by the clock
    core layer.  The driver data is always valid after probe. Therefore,
    remove the related checks.  Also in the resume flow adds error handling.
    
    Fixes: bc4bf7fe98da ("coresight-tmc: add CoreSight TMC driver")
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Tested-by: James Clark <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: tpda: fix the logic to setup the element size [+ + +]
Author: Jie Gan <[email protected]>
Date:   Sat Sep 6 07:53:04 2025 +0800

    coresight: tpda: fix the logic to setup the element size
    
    [ Upstream commit 43e0a92c04de7c822f6104abc73caa4a857b4a02 ]
    
    Some TPDM devices support both CMB and DSB datasets, requiring
    the system to enable the port with both corresponding element sizes.
    
    Currently, the logic treats tpdm_read_element_size as successful if
    the CMB element size is retrieved correctly, regardless of whether
    the DSB element size is obtained. This behavior causes issues
    when parsing data from TPDM devices that depend on both element sizes.
    
    To address this, the function should explicitly fail if the DSB
    element size cannot be read correctly.
    
    Fixes: e6d7f5252f73 ("coresight-tpda: Add support to configure CMB element")
    Reviewed-by: James Clark <[email protected]>
    Signed-off-by: Jie Gan <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/20250906-fix_element_size_issue-v2-1-dbb0ac2541a9@oss.qualcomm.com
    Signed-off-by: Sasha Levin <[email protected]>

coresight: trbe: Add ISB after TRBLIMITR write [+ + +]
Author: James Clark <[email protected]>
Date:   Mon Jun 9 11:19:05 2025 +0100

    coresight: trbe: Add ISB after TRBLIMITR write
    
    [ Upstream commit 52c0164b2526bce7013fca193e076f6d9eec9c95 ]
    
    DEN0154 states that hardware will be allowed to ignore writes to TRB*
    registers while the trace buffer is enabled. Add an ISB to ensure that
    it's disabled before clearing the other registers.
    
    This is purely defensive because it's expected that arm_trbe_disable()
    would be called before teardown which has the required ISB.
    
    Fixes: a2b579c41fe9 ("coresight: trbe: Remove redundant disable call")
    Signed-off-by: James Clark <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: trbe: Prevent overflow in PERF_IDX2OFF() [+ + +]
Author: Leo Yan <[email protected]>
Date:   Wed Sep 17 18:41:38 2025 +0100

    coresight: trbe: Prevent overflow in PERF_IDX2OFF()
    
    [ Upstream commit 105f56877f2d5f82d71e20b45eb7be7c24c3d908 ]
    
    Cast nr_pages to unsigned long to avoid overflow when handling large
    AUX buffer sizes (>= 2 GiB).
    
    Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

coresight: trbe: Return NULL pointer for allocation failures [+ + +]
Author: Leo Yan <[email protected]>
Date:   Thu Sep 4 15:13:52 2025 +0100

    coresight: trbe: Return NULL pointer for allocation failures
    
    [ Upstream commit 8a55c161f7f9c1aa1c70611b39830d51c83ef36d ]
    
    When the TRBE driver fails to allocate a buffer, it currently returns
    the error code "-ENOMEM". However, the caller etm_setup_aux() only
    checks for a NULL pointer, so it misses the error. As a result, the
    driver continues and eventually causes a kernel panic.
    
    Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on
    allocation failures. This allows that the callers can properly handle
    the failure.
    
    Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
    Reported-by: Tamas Zsoldos <[email protected]>
    Signed-off-by: Leo Yan <[email protected]>
    Reviewed-by: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/20250904-cs_etm_auxsetup_fix_error_handling-v2-1-a502d0bafb95@arm.com
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus() [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Mon Aug 18 08:50:48 2025 -0700

    cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus()
    
    [ Upstream commit cd5d4621ba846dad9b2e6b0c2d1518d083fcfa13 ]
    
    Broadcom STB platforms were early adopters (2017) of the SCMI framework and as
    a result, not all deployed systems have a Device Tree entry where SCMI
    protocol 0x13 (PERFORMANCE) is declared as a clock provider, nor are the
    CPU Device Tree node(s) referencing protocol 0x13 as their clock
    provider. This was clarified in commit e11c480b6df1 ("dt-bindings:
    firmware: arm,scmi: Extend bindings for protocol@13") in 2023.
    
    For those platforms, we allow the checks done by scmi_dev_used_by_cpus()
    to continue, and in the event of not having done an early return, we key
    off the documented compatible string and give them a pass to continue to
    use scmi-cpufreq.
    
    Fixes: 6c9bb8692272 ("cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs")
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Sudeep Holla <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpuidle: qcom-spm: fix device and OF node leaks at probe [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Sep 8 17:22:12 2025 +0200

    cpuidle: qcom-spm: fix device and OF node leaks at probe
    
    [ Upstream commit cdc06f912670c8c199d5fa9e78b64b7ed8e871d0 ]
    
    Make sure to drop the reference to the saw device taken by
    of_find_device_by_node() after retrieving its driver data during
    probe().
    
    Also drop the reference to the CPU node sooner to avoid leaking it in
    case there is no saw node or device.
    
    Fixes: 60f3692b5f0b ("cpuidle: qcom_spm: Detach state machine from main SPM handling")
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpuset: fix failure to enable isolated partition when containing isolcpus [+ + +]
Author: Chen Ridong <[email protected]>
Date:   Fri Sep 19 01:12:26 2025 +0000

    cpuset: fix failure to enable isolated partition when containing isolcpus
    
    [ Upstream commit 216217ebee16afc4d79c3e86a736d87175c18e68 ]
    
    The 'isolcpus' parameter specified at boot time can be assigned to an
    isolated partition. While it is valid put the 'isolcpus' in an isolated
    partition, attempting to change a member cpuset to an isolated partition
    will fail if the cpuset contains any 'isolcpus'.
    
    For example, the system boots with 'isolcpus=9', and the following
    configuration works correctly:
    
      # cd /sys/fs/cgroup/
      # mkdir test
      # echo 1 > test/cpuset.cpus
      # echo isolated > test/cpuset.cpus.partition
      # cat test/cpuset.cpus.partition
      isolated
      # echo 9 > test/cpuset.cpus
      # cat test/cpuset.cpus.partition
      isolated
      # cat test/cpuset.cpus
      9
    
    However, the following steps to convert a member cpuset to an isolated
    partition will fail:
    
      # cd /sys/fs/cgroup/
      # mkdir test
      # echo 9 > test/cpuset.cpus
      # echo isolated > test/cpuset.cpus.partition
      # cat test/cpuset.cpus.partition
      isolated invalid (partition config conflicts with housekeeping setup)
    
    The issue occurs because the new partition state (new_prs) is used for
    validation against housekeeping constraints before it has been properly
    updated. To resolve this, move the assignment of new_prs before the
    housekeeping validation check when enabling a root partition.
    
    Fixes: 4a74e418881f ("cgroup/cpuset: Check partition conflict with housekeeping setup")
    Signed-off-by: Chen Ridong <[email protected]>
    Reviewed-by: Waiman Long <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cramfs: fix incorrect physical page address calculation [+ + +]
Author: Alistair Popple <[email protected]>
Date:   Tue Sep 23 10:53:33 2025 +1000

    cramfs: fix incorrect physical page address calculation
    
    [ Upstream commit 20a8e0454d833d80d0c0cae304841a50a2a126bd ]
    
    Commit 21aa65bf82a7 ("mm: remove callers of pfn_t functionality")
    incorrectly replaced the pfn with the physical address when calling
    vmf_insert_mixed().  Instead the phys_to_pfn_t() call should have been
    replaced with PHYS_PFN().
    
    Found by inspection after a similar issue was noted in fuse virtio_fs.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 21aa65bf82a7 ("mm: remove callers of pfn_t functionality")
    Signed-off-by: Alistair Popple <[email protected]>
    Reviewed-by: Dev Jain <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Cc: Haiyue Wang <[email protected]>
    Cc: Nicolas Pitre <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: comp - Use same definition of context alloc and free ops [+ + +]
Author: Dan Moulding <[email protected]>
Date:   Mon Sep 8 10:12:43 2025 -0600

    crypto: comp - Use same definition of context alloc and free ops
    
    [ Upstream commit f75f66683ded09f7135aef2e763c245a07c8271a ]
    
    In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation
    code into acomp"), the crypto_acomp_streams struct was made to rely on
    having the alloc_ctx and free_ctx operations defined in the same order
    as the scomp_alg struct. But in that same commit, the alloc_ctx and
    free_ctx members of scomp_alg may be randomized by structure layout
    randomization, since they are contained in a pure ops structure
    (containing only function pointers). If the pointers within scomp_alg
    are randomized, but those in crypto_acomp_streams are not, then
    the order may no longer match. This fixes the problem by removing the
    union from scomp_alg so that both crypto_acomp_streams and scomp_alg
    will share the same definition of alloc_ctx and free_ctx, ensuring
    they will always have the same layout.
    
    Signed-off-by: Dan Moulding <[email protected]>
    Suggested-by: Herbert Xu <[email protected]>
    Fixes: 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp")
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon - check the sva module status while enabling or disabling address prefetch [+ + +]
Author: Weili Qian <[email protected]>
Date:   Thu Aug 21 09:38:06 2025 +0800

    crypto: hisilicon - check the sva module status while enabling or disabling address prefetch
    
    [ Upstream commit 1f9128f121a872f27251be60ccccfd98c136d72e ]
    
    After enabling address prefetch, check the sva module status. If all
    previous prefetch requests from the sva module are not completed, then
    disable the address prefetch to ensure normal execution of new task
    operations. After disabling address prefetch, check if all requests
    from the sva module have been completed.
    
    Fixes: a5c164b195a8 ("crypto: hisilicon/qm - support address prefetching")
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon - re-enable address prefetch after device resuming [+ + +]
Author: Chenghai Huang <[email protected]>
Date:   Thu Aug 21 09:38:05 2025 +0800

    crypto: hisilicon - re-enable address prefetch after device resuming
    
    [ Upstream commit 0dcd21443d9308ed88909d35aa0490c3fc680a47 ]
    
    When the device resumes from a suspended state, it will revert to its
    initial state and requires re-enabling. Currently, the address prefetch
    function is not re-enabled after device resuming. Move the address prefetch
    enable to the initialization process. In this way, the address prefetch
    can be enabled when the device resumes by calling the initialization
    process.
    
    Fixes: 607c191b371d ("crypto: hisilicon - support runtime PM for accelerator device")
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - check whether the input function and PF are on the same device [+ + +]
Author: Zhushuai Yin <[email protected]>
Date:   Thu Aug 21 09:38:07 2025 +0800

    crypto: hisilicon/qm - check whether the input function and PF are on the same device
    
    [ Upstream commit 6a2c9164b52e6bc134127fd543461fdef95cc8ec ]
    
    Function rate limiting is set through physical function driver.
    Users configure by providing function information and rate limit values.
    Before configuration, it is necessary to check whether the
    provided function and PF belong to the same device.
    
    Fixes: 22d7a6c39cab ("crypto: hisilicon/qm - add pci bdf number check")
    Signed-off-by: Zhushuai Yin <[email protected]>
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - request reserved interrupt for virtual function [+ + +]
Author: Weili Qian <[email protected]>
Date:   Thu Aug 21 09:38:08 2025 +0800

    crypto: hisilicon/qm - request reserved interrupt for virtual function
    
    [ Upstream commit 9228facb308157ac0bdd264b873187896f7a9c7a ]
    
    The device interrupt vector 3 is an error interrupt for
    physical function and a reserved interrupt for virtual function.
    However, the driver has not registered the reserved interrupt for
    virtual function. When allocating interrupts, the number of interrupts
    is allocated based on powers of two, which includes this interrupt.
    When the system enables GICv4 and the virtual function passthrough
    to the virtual machine, releasing the interrupt in the driver
    triggers a warning.
    
    The WARNING report is:
    WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4
    
    Therefore, register a reserved interrupt for VF and set the
    IRQF_NO_AUTOEN flag to avoid that warning.
    
    Fixes: 3536cc55cada ("crypto: hisilicon/qm - support get device irq information from hardware registers")
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs [+ + +]
Author: Chenghai Huang <[email protected]>
Date:   Sat Sep 13 18:57:54 2025 +0800

    crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs
    
    [ Upstream commit f0cafb02de883b3b413d34eb079c9680782a9cc1 ]
    
    When the initialization of qm->debug.acc_diff_reg fails,
    the probe process does not exit. However, after qm->debug.qm_diff_regs is
    freed, it is not set to NULL. This can lead to a double free when the
    remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs
    should be set to NULL after it is freed.
    
    Fixes: 8be091338971 ("crypto: hisilicon/debugfs - Fix debugfs uninit process issue")
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/zip - remove unnecessary validation for high-performance mode configurations [+ + +]
Author: Chenghai Huang <[email protected]>
Date:   Thu Aug 21 09:38:04 2025 +0800

    crypto: hisilicon/zip - remove unnecessary validation for high-performance mode configurations
    
    [ Upstream commit d4e081510471e79171c4e0a11f6cb608e49bc082 ]
    
    When configuring the high-performance mode register, there is no
    need to verify whether the register has been successfully
    enabled, as there is no possibility of a write failure for this
    register.
    
    Fixes: a9864bae1806 ("crypto: hisilicon/zip - add zip comp high perf mode configuration")
    Signed-off-by: Chenghai Huang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: keembay - Add missing check after sg_nents_for_len() [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jul 28 14:03:30 2025 +0200

    crypto: keembay - Add missing check after sg_nents_for_len()
    
    [ Upstream commit 4e53be21dd0315c00eaf40cc8f8c0facd4d9a6b2 ]
    
    sg_nents_for_len() returns an int which is negative in case of error.
    
    Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver")
    Signed-off-by: Thomas Fourier <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: octeontx2 - Call strscpy() with correct size argument [+ + +]
Author: Thorsten Blum <[email protected]>
Date:   Mon Aug 11 11:24:57 2025 +0200

    crypto: octeontx2 - Call strscpy() with correct size argument
    
    [ Upstream commit 361fa7f813e7056cecdb24f3582ab0ad4a088e4e ]
    
    In otx2_cpt_dl_custom_egrp_create(), strscpy() is called with the length
    of the source string rather than the size of the destination buffer.
    
    This is fine as long as the destination buffer is larger than the source
    string, but we should still use the destination buffer size instead to
    call strscpy() as intended. And since 'tmp_buf' is a fixed-size buffer,
    we can safely omit the size argument and let strscpy() infer it using
    sizeof().
    
    Fixes: d9d7749773e8 ("crypto: octeontx2 - add apis for custom engine groups")
    Signed-off-by: Thorsten Blum <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm vdo: return error on corrupted metadata in start_restoring_volume functions [+ + +]
Author: Ivan Abramov <[email protected]>
Date:   Tue Sep 9 23:22:38 2025 +0300

    dm vdo: return error on corrupted metadata in start_restoring_volume functions
    
    [ Upstream commit 9ddf6d3fcbe0b96e318da364cf7e6b59cd4cb5a2 ]
    
    The return values of VDO_ASSERT calls that validate metadata are not acted
    upon.
    
    Return UDS_CORRUPT_DATA in case of an error.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: a4eb7e255517 ("dm vdo: implement the volume index")
    Signed-off-by: Ivan Abramov <[email protected]>
    Reviewed-by: Matthew Sakai <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm: fix NULL pointer dereference in __dm_suspend() [+ + +]
Author: Zheng Qixing <[email protected]>
Date:   Tue Aug 26 15:42:04 2025 +0800

    dm: fix NULL pointer dereference in __dm_suspend()
    
    commit 8d33a030c566e1f105cd5bf27f37940b6367f3be upstream.
    
    There is a race condition between dm device suspend and table load that
    can lead to null pointer dereference. The issue occurs when suspend is
    invoked before table load completes:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000054
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
    RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50
    Call Trace:
      <TASK>
      blk_mq_quiesce_queue+0x2c/0x50
      dm_stop_queue+0xd/0x20
      __dm_suspend+0x130/0x330
      dm_suspend+0x11a/0x180
      dev_suspend+0x27e/0x560
      ctl_ioctl+0x4cf/0x850
      dm_ctl_ioctl+0xd/0x20
      vfs_ioctl+0x1d/0x50
      __se_sys_ioctl+0x9b/0xc0
      __x64_sys_ioctl+0x19/0x30
      x64_sys_call+0x2c4a/0x4620
      do_syscall_64+0x9e/0x1b0
    
    The issue can be triggered as below:
    
    T1                                              T2
    dm_suspend                                      table_load
    __dm_suspend                                    dm_setup_md_queue
                                                    dm_mq_init_request_queue
                                                    blk_mq_init_allocated_queue
                                                    => q->mq_ops = set->ops; (1)
    dm_stop_queue / dm_wait_for_completion
    => q->tag_set NULL pointer!     (2)
                                                    => q->tag_set = set; (3)
    
    Fix this by checking if a valid table (map) exists before performing
    request-based suspend and waiting for target I/O. When map is NULL,
    skip these table-dependent suspend steps.
    
    Even when map is NULL, no I/O can reach any target because there is
    no table loaded; I/O submitted in this state will fail early in the
    DM layer. Skipping the table-dependent suspend logic in this case
    is safe and avoids NULL pointer dereferences.
    
    Fixes: c4576aed8d85 ("dm: fix request-based dm's use of dm_wait_for_completion")
    Cc: [email protected]
    Signed-off-by: Zheng Qixing <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dm: fix queue start/stop imbalance under suspend/load/resume races [+ + +]
Author: Zheng Qixing <[email protected]>
Date:   Tue Aug 26 15:42:03 2025 +0800

    dm: fix queue start/stop imbalance under suspend/load/resume races
    
    commit 7f597c2cdb9d3263a6fce07c4fc0a9eaa8e8fc43 upstream.
    
    When suspend and load run concurrently, before q->mq_ops is set in
    blk_mq_init_allocated_queue(), __dm_suspend() skip dm_stop_queue(). As a
    result, the queue's quiesce depth is not incremented.
    
    Later, once table load has finished and __dm_resume() runs, which triggers
    q->quiesce_depth ==0 warning in blk_mq_unquiesce_queue():
    Call Trace:
     <TASK>
     dm_start_queue+0x16/0x20 [dm_mod]
     __dm_resume+0xac/0xb0 [dm_mod]
     dm_resume+0x12d/0x150 [dm_mod]
     do_resume+0x2c2/0x420 [dm_mod]
     dev_suspend+0x30/0x130 [dm_mod]
     ctl_ioctl+0x402/0x570 [dm_mod]
     dm_ctl_ioctl+0x23/0x30 [dm_mod]
    
    Fix this by explicitly tracking whether the request queue was
    stopped in __dm_suspend() via a new DMF_QUEUE_STOPPED flag.
    Only call dm_start_queue() in __dm_resume() if the queue was
    actually stopped.
    
    Fixes: e70feb8b3e68 ("blk-mq: support concurrent queue quiesce/unquiesce")
    Cc: [email protected]
    Signed-off-by: Zheng Qixing <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dmaengine: Fix dma_async_tx_descriptor->tx_submit documentation [+ + +]
Author: Nathan Lynch <[email protected]>
Date:   Tue Aug 26 11:07:38 2025 -0500

    dmaengine: Fix dma_async_tx_descriptor->tx_submit documentation
    
    [ Upstream commit 7ea95d55e63176899eb96f7aaa34a5646f501b2c ]
    
    Commit 790fb9956eea ("linux/dmaengine.h: fix a few kernel-doc
    warnings") inserted new documentation for @desc_free in the middle of
    @tx_submit's description.
    
    Put @tx_submit's description back together, matching the indentation
    style of the rest of the documentation for dma_async_tx_descriptor.
    
    Fixes: 790fb9956eea ("linux/dmaengine.h: fix a few kernel-doc warnings")
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Nathan Lynch <[email protected]>
    Link: https://lore.kernel.org/r/20250826-dma_async_tx_desc-tx_submit-doc-fix-v1-1-18a4b51697db@amd.com
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
docs: iio: ad3552r: Fix malformed code-block directive [+ + +]
Author: Jorge Marques <[email protected]>
Date:   Mon Aug 18 16:44:23 2025 +0200

    docs: iio: ad3552r: Fix malformed code-block directive
    
    [ Upstream commit 788c57f4766bd5802af9918ea350053a91488c60 ]
    
    Missing required double dot and line break.
    
    Fixes: ede84c455659 ("docs: iio: add documentation for ad3552r driver")
    Signed-off-by: Jorge Marques <[email protected]>
    Reviewed-by: David Lechner <[email protected]>
    Link: https://patch.msgid.link/20250818-docs-ad3552r-code-block-fix-v1-1-4430cbc26676@analog.com
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Documentation: trace: historgram-design: Separate sched_waking histogram section heading and the following diagram [+ + +]
Author: Bagas Sanjaya <[email protected]>
Date:   Tue Sep 16 12:42:01 2025 +0700

    Documentation: trace: historgram-design: Separate sched_waking histogram section heading and the following diagram
    
    [ Upstream commit 8c716e87ea33519920811338100d6d8a7fb32456 ]
    
    Section heading for sched_waking histogram is shown as normal paragraph
    instead due to codeblock marker for the following diagram being in the
    same line as the section underline. Separate them.
    
    Fixes: daceabf1b494 ("tracing/doc: Fix ascii-art in histogram-design.rst")
    Reviewed-by: Tom Zanussi <[email protected]>
    Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Bagas Sanjaya <[email protected]>
    Acked-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Jonathan Corbet <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/base/node: fix double free in register_one_node() [+ + +]
Author: Donet Tom <[email protected]>
Date:   Thu Sep 18 11:11:44 2025 +0530

    drivers/base/node: fix double free in register_one_node()
    
    [ Upstream commit 0efdedfa537eb534c251a5b4794caaf72cc55869 ]
    
    When device_register() fails in register_node(), it calls
    put_device(&node->dev).  This triggers node_device_release(), which calls
    kfree(to_node(dev)), thereby freeing the entire node structure.
    
    As a result, when register_node() returns an error, the node memory has
    already been freed.  Calling kfree(node) again in register_one_node()
    leads to a double free.
    
    This patch removes the redundant kfree(node) from register_one_node() to
    prevent the double free.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 786eb990cfb7 ("drivers/base/node: handle error properly in register_one_node()")
    Signed-off-by: Donet Tom <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Acked-by: Oscar Salvador <[email protected]>
    Cc: Alison Schofield <[email protected]>
    Cc: Chris Mason <[email protected]>
    Cc: Danilo Krummrich <[email protected]>
    Cc: Dave Jiang <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Hiroyouki Kamezawa <[email protected]>
    Cc: Joanthan Cameron <[email protected]>
    Cc: "Ritesh Harjani (IBM)" <[email protected]>
    Cc: Yury Norov (NVIDIA) <[email protected]>
    Cc: Zi Yan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers/base/node: handle error properly in register_one_node() [+ + +]
Author: Donet Tom <[email protected]>
Date:   Fri Aug 22 14:18:45 2025 +0530

    drivers/base/node: handle error properly in register_one_node()
    
    [ Upstream commit 786eb990cfb78aab94eb74fb32a030e14723a620 ]
    
    If register_node() returns an error, it is not handled correctly.
    The function will proceed further and try to register CPUs under the
    node, which is not correct.
    
    So, in this patch, if register_node() returns an error, we return
    immediately from the function.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 76b67ed9dce6 ("[PATCH] node hotplug: register cpu: remove node struct")
    Signed-off-by: Donet Tom <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Cc: Alison Schofield <[email protected]>
    Cc: Danilo Krummrich <[email protected]>
    Cc: Dave Jiang <[email protected]>
    Cc: Donet Tom <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Hiroyouki Kamezawa <[email protected]>
    Cc: Joanthan Cameron <[email protected]>
    Cc: Oscar Salvador <[email protected]>
    Cc: "Ritesh Harjani (IBM)" <[email protected]>
    Cc: Yury Norov (NVIDIA) <[email protected]>
    Cc: Zi Yan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Wed Aug 13 12:14:01 2025 +0530

    drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions
    
    [ Upstream commit bf4e4b97d0fdc66f04fc19d807e24dd8421b8f11 ]
    
    The function dc_stream_set_cursor_attributes() currently dereferences
    the `stream` pointer and nested members `stream->ctx->dc->current_state`
    without checking for NULL.
    
    All callers of these functions, such as in
    `dcn30_apply_idle_power_optimizations()` and
    `amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks
    before calling these functions.
    
    Fixes below:
    drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes()
    error: we previously assumed 'stream' could be null (see line 334)
    
    drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c
        327 bool dc_stream_program_cursor_attributes(
        328         struct dc_stream_state *stream,
        329         const struct dc_cursor_attributes *attributes)
        330 {
        331         struct dc  *dc;
        332         bool reset_idle_optimizations = false;
        333
        334         dc = stream ? stream->ctx->dc : NULL;
                         ^^^^^^
    The old code assumed stream could be NULL.
    
        335
    --> 336         if (dc_stream_set_cursor_attributes(stream, attributes)) {
                                                        ^^^^^^
    The refactor added an unchecked dereference.
    
    drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c
       313  bool dc_stream_set_cursor_attributes(
       314          struct dc_stream_state *stream,
       315          const struct dc_cursor_attributes *attributes)
       316  {
       317          bool result = false;
       318
       319          if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) {
                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here.
    This function used to check for if stream as NULL and return false at
    the start. Probably we should add that back.
    
    Fixes: 4465dd0e41e8 ("drm/amd/display: Refactor SubVP cursor limiting logic")
    Reported-by: Dan Carpenter <[email protected]>
    Cc: Alex Hung <[email protected]>
    Cc: Alvin Lee <[email protected]>
    Cc: Ray Wu <[email protected]>
    Cc: Dillon Varone <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: ChiaHsuan Chung <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Daniel Wheeler <[email protected]>
    Cc: Tom Chung <[email protected]>
    Cc: Wenjing Liu <[email protected]>
    Cc: Jun Lei <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Dillon Varone <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Reduce Stack Usage by moving 'audio_output' into 'stream_res' v4 [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Thu Jul 24 13:02:18 2025 +0530

    drm/amd/display: Reduce Stack Usage by moving 'audio_output' into 'stream_res' v4
    
    [ Upstream commit 1cf1205ef2685cf43db3785706b017d1e54e0bec ]
    
    The function `dp_retrain_link_dp_test` currently allocates a large
    audio_output array on the stack, causing the stack frame size to exceed
    the compiler limit (1080 bytes > 1024 bytes).
    
    This change prevents stack overflow issues:
    amdgpu/../display/dc/link/accessories/link_dp_cts.c:65:13: warning: stack frame size (1080) exceeds limit (1024) in 'dp_retrain_link_dp_test' [-Wframe-larger-than]
    static void dp_retrain_link_dp_test(struct dc_link *link,
    
    v2: Move audio-related data like `audio_output` is kept "per pipe" to
        manage the audio for that specific display pipeline/display output path
        (stream). (Wenjing)
    
    v3: Update in all the places where `build_audio_output` is currently
        called with a separate audio_output variable on the stack & wherever
        `audio_output` is passed to other functions
        `dce110_apply_single_controller_ctx_to_hw()` &
        `dce110_setup_audio_dto()` (like `az_configure`, `wall_dto_setup`)
        replace with usage of `pipe_ctx->stream_res.audio_output`
        to centralize audio data per pipe.
    
    v4: Remove empty lines before `build_audio_output`. (Alex)
    
    Fixes: 9c6669c2e21a ("drm/amd/display: Fix Link Override Sequencing When Switching Between DIO/HPO")
    Cc: Wayne Lin <[email protected]>
    Cc: George Shen <[email protected]>
    Cc: Michael Strauss <[email protected]>
    Cc: Alvin Lee <[email protected]>
    Cc: Ray Wu <[email protected]>
    Cc: Wenjing Liu <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Tom Chung <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Alex Hung <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Wenjing Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Remove redundant semicolons [+ + +]
Author: Liao Yuanhong <[email protected]>
Date:   Tue Aug 12 15:50:14 2025 +0800

    drm/amd/display: Remove redundant semicolons
    
    [ Upstream commit 90b810dd859c0df9db2290da1ac5842e5f031267 ]
    
    Remove unnecessary semicolons.
    
    Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321")
    Signed-off-by: Liao Yuanhong <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm: Adjust si_upload_smc_data register programming (v3) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:07 2025 +0200

    drm/amd/pm: Adjust si_upload_smc_data register programming (v3)
    
    [ Upstream commit ce025130127437dc884c84c254170e27b2ce9309 ]
    
    Based on some comments in dm_pp_display_configuration
    above the crtc_index and line_time fields, these values
    are programmed to the SMC to work around an SMC hang
    when it switches MCLK.
    
    According to Alex, the Windows driver programs them to:
    mclk_change_block_cp_min = 200 / line_time
    mclk_change_block_cp_max = 100 / line_time
    Let's use the same for the sake of consistency.
    
    Previously we used the watermark values, but it seemed buggy
    as the code was mixing up low/high and A/B watermarks, and
    was not saving a low watermark value on DCE 6, so
    mclk_change_block_cp_max would be always zero previously.
    
    Split this change off from the previous si_upload_smc_data
    to make it easier to bisect, in case it causes any issues.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/pm: Disable MCLK switching with non-DC at 120 Hz+ (v2) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:09 2025 +0200

    drm/amd/pm: Disable MCLK switching with non-DC at 120 Hz+ (v2)
    
    [ Upstream commit ed3803533c7bf7df88bc3fc9f70bd317e1228ea8 ]
    
    According to pp_pm_compute_clocks the non-DC display code
    has "issues with mclk switching with refresh rates over 120 hz".
    The workaround is to disable MCLK switching in this case.
    
    Do the same for legacy DPM.
    
    Fixes: 6ddbd37f1074 ("drm/amd/pm: optimize the amdgpu_pm_compute_clocks() implementations")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/pm: Disable SCLK switching on Oland with high pixel clocks (v3) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:10 2025 +0200

    drm/amd/pm: Disable SCLK switching on Oland with high pixel clocks (v3)
    
    [ Upstream commit 7009e3af0474aca5f64262b3c72fb6e23b232f9b ]
    
    Port of commit 227545b9a08c ("drm/radeon/dpm: Disable sclk
    switching on Oland when two 4K 60Hz monitors are connected")
    
    This is an ad-hoc DPM fix, necessary because we don't have
    proper bandwidth calculation for DCE 6.
    
    We define "high pixelclock" for SI as higher than necessary
    for 4K 30Hz. For example, 4K 60Hz and 1080p 144Hz fall into
    this category.
    
    When two high pixel clock displays are connected to Oland,
    additionally disable shader clock switching, which results in
    a higher voltage, thereby addressing some visible flickering.
    
    v2:
    Add more comments.
    v3:
    Split into two commits for easier review.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/pm: Disable ULV even if unsupported (v3) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:04 2025 +0200

    drm/amd/pm: Disable ULV even if unsupported (v3)
    
    [ Upstream commit 3a0c3a4035f995e1f993dfaf4d63dc19e9b4bc1c ]
    
    Always send PPSMC_MSG_DisableULV to the SMC, even if ULV mode
    is unsupported, to make sure it is properly turned off.
    
    v3:
    Simplify si_disable_ulv further.
    Always check the return value of amdgpu_si_send_msg_to_smc.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/pm: Fix si_upload_smc_data (v3) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:06 2025 +0200

    drm/amd/pm: Fix si_upload_smc_data (v3)
    
    [ Upstream commit a43b2cec04b02743338aa78f837ee0bdf066a6d5 ]
    
    The si_upload_smc_data function uses si_write_smc_soft_register
    to set some register values in the SMC, and expects the result
    to be PPSMC_Result_OK which is 1.
    
    The PPSMC_Result_OK / PPSMC_Result_Failed values are used for
    checking the result of a command sent to the SMC.
    However, the si_write_smc_soft_register actually doesn't send
    any commands to the SMC and returns zero on success,
    so this check was incorrect.
    
    Fix that by not checking the return value, just like other
    calls to si_write_smc_soft_register.
    
    v3:
    Additionally, when no display is plugged in, there is no need
    to restrict MCLK switching, so program the registers to zero.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:08 2025 +0200

    drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)
    
    [ Upstream commit 9003a0746864f39a0ef72bd45f8e1ad85d930d67 ]
    
    Some parts of the code base expect that MCLK switching is turned
    off when the vblank time is set to zero.
    
    According to pp_pm_compute_clocks the non-DC code has issues
    with MCLK switching with refresh rates over 120 Hz.
    
    v3:
    Add code comment to explain this better.
    Add an if statement instead of changing the switch_limit.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/vcn: Add regdump helper functions [+ + +]
Author: Sathishkumar S <[email protected]>
Date:   Thu Jul 17 11:30:52 2025 +0530

    drm/amdgpu/vcn: Add regdump helper functions
    
    [ Upstream commit de55cbff5ce93c316b0113535752e43079761f2c ]
    
    Add generic helper functions for vcn devcoredump support
    which can be re-used for all vcn versions.
    
    Signed-off-by: Sathishkumar S <[email protected]>
    Acked-by: Leo Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 9c0442286f84 ("drm/amdgpu: Check vcn state before profile switch")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu/vcn: Fix double-free of vcn dump buffer [+ + +]
Author: Lijo Lazar <[email protected]>
Date:   Tue Aug 5 17:40:09 2025 +0530

    drm/amdgpu/vcn: Fix double-free of vcn dump buffer
    
    commit 1a0e57eb96c3fca338665ffd7d9b59f351e5fea7 upstream.
    
    The buffer is already freed as part of amdgpu_vcn_reg_dump_fini(). The
    issue is introduced by below patch series.
    
    Fixes: de55cbff5ce9 ("drm/amdgpu/vcn: Add regdump helper functions")
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Sathishkumar S <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu/vcn: Hold pg_lock before vcn power off [+ + +]
Author: Sathishkumar S <[email protected]>
Date:   Tue Aug 5 21:35:10 2025 +0530

    drm/amdgpu/vcn: Hold pg_lock before vcn power off
    
    [ Upstream commit 111821e4b5a3105c42c7c99f4abd4d8af9f64248 ]
    
    Acquire vcn_pg_lock before changes to vcn power state
    and release it after power off in idle work handler.
    
    Signed-off-by: Sathishkumar S <[email protected]>
    Reviewed-by: Leo Liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 9c0442286f84 ("drm/amdgpu: Check vcn state before profile switch")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: Check vcn state before profile switch [+ + +]
Author: Lijo Lazar <[email protected]>
Date:   Thu Aug 14 13:52:50 2025 +0530

    drm/amdgpu: Check vcn state before profile switch
    
    [ Upstream commit 9c0442286f84a5036958b3d8eb00bf0bb070dbd1 ]
    
    The patch uses power state of VCN instances for requesting video
    profile.
    
    In idle worker of a vcn instance, when there is no outstanding
    submisssion or fence, the instance is put to power gated state. When
    all instances are powered off that means video profile is no longer
    required. A request is made to turn off video profile.
    
    A job submission starts with begin_use of ring, and at that time
    vcn instance state is changed to power on. Subsequently a check is
    made for active video profile, and if not active, a request is made.
    
    Fixes: 3b669df92c85 ("drm/amdgpu/vcn: adjust workload profile handling")
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Sathishkumar S <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Fix allocating extra dwords for rings (v2) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Tue Sep 9 16:49:35 2025 +0200

    drm/amdgpu: Fix allocating extra dwords for rings (v2)
    
    [ Upstream commit ae5c2bee1680436d9bf8bfaca7416496adff0ee0 ]
    
    Rename extra_dw to extra_bytes and document what it's for.
    
    The value is already used as if it were bytes in vcn_v4_0.c
    and in amdgpu_ring_init. Just adjust the dword count in
    jpeg_v1_0.c so that it becomes a byte count.
    
    v2:
    Rename extra_dw to extra_bytes as discussed during review.
    
    Fixes: c8c1a1d2ef04 ("drm/amdgpu: define and add extra dword for jpeg ring")
    Signed-off-by: Timur Kristóf <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Fix jpeg v4.0.3 poison irq call trace on sriov guest [+ + +]
Author: Xiang Liu <[email protected]>
Date:   Thu Jul 31 14:28:26 2025 +0800

    drm/amdgpu: Fix jpeg v4.0.3 poison irq call trace on sriov guest
    
    [ Upstream commit d3d73bdb02e8cc4a1b2b721a42908504cd18ebf9 ]
    
    Sriov guest side doesn't init ras feature hence the poison irq shouldn't
    be put during hw fini.
    
    [25209.467154] Call Trace:
    [25209.467156]  <TASK>
    [25209.467158]  ? srso_alias_return_thunk+0x5/0x7f
    [25209.467162]  ? show_trace_log_lvl+0x28e/0x2ea
    [25209.467166]  ? show_trace_log_lvl+0x28e/0x2ea
    [25209.467171]  ? jpeg_v4_0_3_hw_fini+0x6f/0x90 [amdgpu]
    [25209.467300]  ? show_regs.part.0+0x23/0x29
    [25209.467303]  ? show_regs.cold+0x8/0xd
    [25209.467304]  ? amdgpu_irq_put+0x9e/0xc0 [amdgpu]
    [25209.467403]  ? __warn+0x8c/0x100
    [25209.467407]  ? amdgpu_irq_put+0x9e/0xc0 [amdgpu]
    [25209.467503]  ? report_bug+0xa4/0xd0
    [25209.467508]  ? handle_bug+0x39/0x90
    [25209.467511]  ? exc_invalid_op+0x19/0x70
    [25209.467513]  ? asm_exc_invalid_op+0x1b/0x20
    [25209.467518]  ? amdgpu_irq_put+0x9e/0xc0 [amdgpu]
    [25209.467613]  ? amdgpu_irq_put+0x5f/0xc0 [amdgpu]
    [25209.467709]  jpeg_v4_0_3_hw_fini+0x6f/0x90 [amdgpu]
    [25209.467805]  amdgpu_ip_block_hw_fini+0x34/0x61 [amdgpu]
    [25209.467971]  amdgpu_device_fini_hw+0x3b3/0x467 [amdgpu]
    
    Fixes: 1b2231de4163 ("drm/amdgpu: Register aqua vanjaram jpeg poison irq")
    Signed-off-by: Xiang Liu <[email protected]>
    Reviewed-by: Stanley.Yang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: fix link error for !PM_SLEEP [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Mon Jul 14 10:16:25 2025 +0200

    drm/amdgpu: fix link error for !PM_SLEEP
    
    [ Upstream commit 4d22db6d070ed3934f02ed15391283f6feb258ad ]
    
    When power management is not enabled in the kernel build, the newly
    added hibernation changes cause a link failure:
    
    arm-linux-gnueabi-ld: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o: in function `amdgpu_pmops_thaw':
    amdgpu_drv.c:(.text+0x1514): undefined reference to `pm_hibernate_is_recovering'
    
    Make the power management code in this driver conditional on
    CONFIG_PM and CONFIG_PM_SLEEP
    
    Fixes: 530694f54dd5 ("drm/amdgpu: do not resume device in thaw for normal hibernation")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Fix vcn v4.0.3 poison irq call trace on sriov guest [+ + +]
Author: Xiang Liu <[email protected]>
Date:   Thu Jul 31 14:54:50 2025 +0800

    drm/amdgpu: Fix vcn v4.0.3 poison irq call trace on sriov guest
    
    [ Upstream commit 58364f01db4a155356f92cce1474761d7a0eda3d ]
    
    Sriov guest side doesn't init ras feature hence the poison irq shouldn't
    be put during hw fini.
    
    [25209.468816] Call Trace:
    [25209.468817]  <TASK>
    [25209.468818]  ? srso_alias_return_thunk+0x5/0x7f
    [25209.468820]  ? show_trace_log_lvl+0x28e/0x2ea
    [25209.468822]  ? show_trace_log_lvl+0x28e/0x2ea
    [25209.468825]  ? vcn_v4_0_3_hw_fini+0xaf/0xe0 [amdgpu]
    [25209.468936]  ? show_regs.part.0+0x23/0x29
    [25209.468939]  ? show_regs.cold+0x8/0xd
    [25209.468940]  ? amdgpu_irq_put+0x9e/0xc0 [amdgpu]
    [25209.469038]  ? __warn+0x8c/0x100
    [25209.469040]  ? amdgpu_irq_put+0x9e/0xc0 [amdgpu]
    [25209.469135]  ? report_bug+0xa4/0xd0
    [25209.469138]  ? handle_bug+0x39/0x90
    [25209.469140]  ? exc_invalid_op+0x19/0x70
    [25209.469142]  ? asm_exc_invalid_op+0x1b/0x20
    [25209.469146]  ? amdgpu_irq_put+0x9e/0xc0 [amdgpu]
    [25209.469241]  vcn_v4_0_3_hw_fini+0xaf/0xe0 [amdgpu]
    [25209.469343]  amdgpu_ip_block_hw_fini+0x34/0x61 [amdgpu]
    [25209.469511]  amdgpu_device_fini_hw+0x3b3/0x467 [amdgpu]
    
    Fixes: 4c4a89149608 ("drm/amdgpu: Register aqua vanjaram vcn poison irq")
    Signed-off-by: Xiang Liu <[email protected]>
    Reviewed-by: Stanley.Yang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Power up UVD 3 for FW validation (v2) [+ + +]
Author: Timur Kristóf <[email protected]>
Date:   Thu Aug 28 17:11:03 2025 +0200

    drm/amdgpu: Power up UVD 3 for FW validation (v2)
    
    [ Upstream commit c661219cd7be75bb5599b525f16a455a058eb516 ]
    
    Unlike later versions, UVD 3 has firmware validation.
    For this to work, the UVD should be powered up correctly.
    
    When DPM is enabled and the display clock is off,
    the SMU may choose a power state which doesn't power
    the UVD, which can result in failure to initialize UVD.
    
    v2:
    Add code comments to explain about the UVD power state
    and how UVD clock is turned on/off.
    
    Fixes: b38f3e80ecec ("drm amdgpu: SI UVD v3_1 (v2)")
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Timur Kristóf <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdkfd: Fix error code sign for EINVAL in svm_ioctl() [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Thu Sep 4 20:36:46 2025 +0800

    drm/amdkfd: Fix error code sign for EINVAL in svm_ioctl()
    
    [ Upstream commit cbda64f3f58027f68211dda8ea94d52d7e493995 ]
    
    Use negative error code -EINVAL instead of positive EINVAL in the default
    case of svm_ioctl() to conform to Linux kernel error code conventions.
    
    Fixes: 42de677f7999 ("drm/amdkfd: register svm range")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/bridge: cdns-dsi: Fix the _atomic_check() [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Wed Jul 23 13:05:07 2025 +0300

    drm/bridge: cdns-dsi: Fix the _atomic_check()
    
    [ Upstream commit 04864af849d9ae0dd020798f5b3632d9cf26fa03 ]
    
    Use the "adjusted_mode" for the dsi configuration check, as that is the
    more appropriate display_mode for validation, and later bridge enable.
    
    Also, fix the mode_valid_check parameter from false to true, as the dsi
    configuration check is taking place during the check-phase, and the
    crtc_* mode values are not expected to be populated yet.
    
    Fixes: a53d987756ea ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()")
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Tested-by: Jayesh Choudhary <[email protected]>
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: it6505: select REGMAP_I2C [+ + +]
Author: Chia-I Wu <[email protected]>
Date:   Tue Jun 10 16:58:25 2025 -0700

    drm/bridge: it6505: select REGMAP_I2C
    
    [ Upstream commit 21b137f651cf9d981e22d2c60a2a8105f50a6361 ]
    
    Fix
    
      aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_i2c_probe':
      ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c'
    
    Signed-off-by: Chia-I Wu <[email protected]>
    Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
    Reviewed-by: Chen-Yu Tsai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/display: bridge-connector: correct CEC bridge pointers in drm_bridge_connector_init [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Jul 19 13:58:13 2025 +0300

    drm/display: bridge-connector: correct CEC bridge pointers in drm_bridge_connector_init
    
    [ Upstream commit 92e34a5241ddf4b084df20e6953275d16f156aa8 ]
    
    The bridge used in drm_bridge_connector_init() for CEC init does not
    correctly point to the required HDMI CEC bridge, which can lead to
    errors during CEC initialization.
    
    Fixes: 65a2575a68e4 ("drm/display: bridge-connector: hook in CEC notifier support")
    Fixes: a74288c8ded7 ("drm/display: bridge-connector: handle CEC adapters")
    Reported-by: Luca Ceresoli <[email protected]>
    Closes: http://lore.kernel.org/r/20250718164156.194702d9@booty/
    Reviewed-by: Luca Ceresoli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/dp: drm_edp_backlight_set_level: do not always send 3-byte commands [+ + +]
Author: Val Packett <[email protected]>
Date:   Sun Jul 6 17:42:24 2025 -0300

    drm/dp: drm_edp_backlight_set_level: do not always send 3-byte commands
    
    [ Upstream commit 4aa8961b1b9c7498550b41168a91cf1558133dd3 ]
    
    At least some panels using the LSB register are not happy with the
    unconditional increase of the command buffer to 3 bytes.
    
    With the BOE NE14QDM in my Dell Latitude 7455, the recent patches for
    luminance based brightness have introduced a regression: the brightness
    range stopped being contiguous and became nonsensical (it probably was
    interpreting the last 2 bytes of the buffer and not the first 2).
    
    Change from using a fixed sizeof() to a length variable that's only
    set to 3 when luminance is used. Let's leave the default as 2 even for
    the single-byte version, since that's how it worked before.
    
    Fixes: f2db78e37fe7 ("drm/dp: Modify drm_edp_backlight_set_level")
    Signed-off-by: Val Packett <[email protected]>
    Tested-by: Abel Vesa <[email protected]>
    Reviewed-by: Suraj Kandpal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dpu: fix incorrect type for ret [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Tue Aug 26 17:20:45 2025 +0800

    drm/msm/dpu: fix incorrect type for ret
    
    [ Upstream commit 88ec0e01a880e3326794e149efae39e3aa4dbbec ]
    
    Change 'ret' from unsigned long to int, as storing negative error codes
    in an unsigned long makes it never equal to -ETIMEDOUT, causing logical
    errors.
    
    Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/671100/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/mdp4: stop supporting no-IOMMU configuration [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Sep 3 13:51:49 2025 +0300

    drm/msm/mdp4: stop supporting no-IOMMU configuration
    
    [ Upstream commit cc64568b522b64fb8f8c607da9eb4e2d9f72d0cf ]
    
    With the switch to GPUVM the msm driver no longer supports the no-IOMMU
    configurations (even without the actual GPU). Return an error in case we
    face the lack of the IOMMU for an MDP4 device.
    
    Fixes: 111fdd2198e6 ("drm/msm: drm_gpuvm conversion")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/672557/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm: Do not validate SSPP when it is not ready [+ + +]
Author: Jun Nie <[email protected]>
Date:   Tue Aug 19 09:30:55 2025 +0800

    drm/msm: Do not validate SSPP when it is not ready
    
    [ Upstream commit 6fc616723bb5fd4289d7422fa013da062b44ae55 ]
    
    Current code will validate current plane and previous plane to
    confirm they can share a SSPP with multi-rect mode. The SSPP
    is already allocated for previous plane, while current plane
    is not associated with any SSPP yet. Null pointer is referenced
    when validating the SSPP of current plane. Skip SSPP validation
    for current plane.
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
    Mem abort info:
      ESR = 0x0000000096000004
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x04: level 0 translation fault
    Data abort info:
      ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=0000000888ac3000
    [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
    Internal error: Oops: 0000000096000004 [#1]  SMP
    Modules linked in:
    CPU: 4 UID: 0 PID: 1891 Comm: modetest Tainted: G S                  6.15.0-rc2-g3ee3f6e1202e #335 PREEMPT
    Tainted: [S]=CPU_OUT_OF_SPEC
    Hardware name: SM8650 EV1 rev1 4slam 2et (DT)
    pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
    pc : dpu_plane_is_multirect_capable+0x68/0x90
    lr : dpu_assign_plane_resources+0x288/0x410
    sp : ffff800093dcb770
    x29: ffff800093dcb770 x28: 0000000000002000 x27: ffff000817c6c000
    x26: ffff000806b46368 x25: ffff0008013f6080 x24: ffff00080cbf4800
    x23: ffff000810842680 x22: ffff0008013f1080 x21: ffff00080cc86080
    x20: ffff000806b463b0 x19: ffff00080cbf5a00 x18: 00000000ffffffff
    x17: 707a5f657a696c61 x16: 0000000000000003 x15: 0000000000002200
    x14: 00000000ffffffff x13: 00aaaaaa00aaaaaa x12: 0000000000000000
    x11: ffff000817c6e2b8 x10: 0000000000000000 x9 : ffff80008106a950
    x8 : ffff00080cbf48f4 x7 : 0000000000000000 x6 : 0000000000000000
    x5 : 0000000000000000 x4 : 0000000000000438 x3 : 0000000000000438
    x2 : ffff800082e245e0 x1 : 0000000000000008 x0 : 0000000000000000
    Call trace:
     dpu_plane_is_multirect_capable+0x68/0x90 (P)
     dpu_crtc_atomic_check+0x5bc/0x650
     drm_atomic_helper_check_planes+0x13c/0x220
     drm_atomic_helper_check+0x58/0xb8
     msm_atomic_check+0xd8/0xf0
     drm_atomic_check_only+0x4a8/0x968
     drm_atomic_commit+0x50/0xd8
     drm_atomic_helper_update_plane+0x140/0x188
     __setplane_atomic+0xfc/0x148
     drm_mode_setplane+0x164/0x378
     drm_ioctl_kernel+0xc0/0x140
     drm_ioctl+0x20c/0x500
     __arm64_sys_ioctl+0xbc/0xf8
     invoke_syscall+0x50/0x120
     el0_svc_common.constprop.0+0x48/0xf8
     do_el0_svc+0x28/0x40
     el0_svc+0x30/0xd0
     el0t_64_sync_handler+0x144/0x168
     el0t_64_sync+0x198/0x1a0
    Code: b9402021 370fffc1 f9401441 3707ff81 (f94010a1)
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 3ed12a3664b36 ("drm/msm/dpu: allow sharing SSPP between planes")
    Signed-off-by: Jun Nie <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/669224/
    Link: https://lore.kernel.org/r/20250819-v6-16-rc2-quad-pipe-upstream-v15-1-2c7a85089db8@linaro.org
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm: Fix bootup splat with separate_gpu_drm modparam [+ + +]
Author: Akhil P Oommen <[email protected]>
Date:   Tue Sep 2 17:20:00 2025 +0530

    drm/msm: Fix bootup splat with separate_gpu_drm modparam
    
    [ Upstream commit f028bcafb6dfb4c2bb656cbff9e6a66222d3d3d7 ]
    
    The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses
    drm_gem_obj.gpuva.list, which is not initialized when the drm driver
    does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms
    drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam
    is set:
    
    [    9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0
    [    9.523160] Mem abort info:
    [    9.523161]   ESR = 0x0000000096000006
    [    9.523163]   EC = 0x25: DABT (current EL), IL = 32 bits
    [    9.523165]   SET = 0, FnV = 0
    [    9.523166]   EA = 0, S1PTW = 0
    [    9.523167]   FSC = 0x06: level 2 translation fault
    [    9.523169] Data abort info:
    [    9.523170]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
    [    9.523171]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [    9.523172]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [    9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000
    [    9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000
    [    9.523184] Internal error: Oops: 0000000096000006 [#1]  SMP
    [    9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT
    [    9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024
    [    9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    [    9.592973] pc : lookup_vma+0x28/0xe0 [msm]
    [    9.592996] lr : get_vma_locked+0x2c/0x128 [msm]
    [    9.763632] sp : ffff800082dab460
    [    9.763666] Call trace:
    [    9.763668]  lookup_vma+0x28/0xe0 [msm] (P)
    [    9.763688]  get_vma_locked+0x2c/0x128 [msm]
    [    9.763706]  msm_gem_get_and_pin_iova_range+0x68/0x11c [msm]
    [    9.763723]  msm_gem_get_and_pin_iova+0x18/0x24 [msm]
    [    9.763740]  msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm]
    [    9.763760]  __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper]
    [    9.763771]  drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper]
    [    9.763779]  drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib]
    [    9.763782]  drm_client_register+0x58/0x9c [drm]
    [    9.763806]  drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib]
    [    9.763809]  drm_client_setup+0xb4/0xd8 [drm_client_lib]
    [    9.763811]  msm_drm_kms_post_init+0x2c/0x3c [msm]
    [    9.763830]  msm_drm_init+0x1a8/0x22c [msm]
    [    9.763848]  msm_drm_bind+0x30/0x3c [msm]
    [    9.919273]  try_to_bring_up_aggregate_device+0x168/0x1d4
    [    9.919283]  __component_add+0xa4/0x170
    [    9.919286]  component_add+0x14/0x20
    [    9.919288]  msm_dp_display_probe_tail+0x4c/0xac [msm]
    [    9.919315]  msm_dp_auxbus_done_probe+0x14/0x20 [msm]
    [    9.919335]  dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus]
    [    9.919341]  really_probe+0xbc/0x298
    [    9.919345]  __driver_probe_device+0x78/0x12c
    [    9.919348]  driver_probe_device+0x40/0x160
    [    9.919350]  __driver_attach+0x94/0x19c
    [    9.919353]  bus_for_each_dev+0x74/0xd4
    [    9.919355]  driver_attach+0x24/0x30
    [    9.919358]  bus_add_driver+0xe4/0x208
    [    9.919360]  driver_register+0x60/0x128
    [    9.919363]  __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus]
    [    9.919365]  atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20]
    [    9.919370]  do_one_initcall+0x6c/0x1b0
    [    9.919374]  do_init_module+0x58/0x234
    [    9.919377]  load_module+0x19cc/0x1bd4
    [    9.919380]  init_module_from_file+0x84/0xc4
    [    9.919382]  __arm64_sys_finit_module+0x1b8/0x2cc
    [    9.919384]  invoke_syscall+0x48/0x110
    [    9.919389]  el0_svc_common.constprop.0+0xc8/0xe8
    [    9.919393]  do_el0_svc+0x20/0x2c
    [    9.919396]  el0_svc+0x34/0xf0
    [    9.919401]  el0t_64_sync_handler+0xa0/0xe4
    [    9.919403]  el0t_64_sync+0x198/0x19c
    [    9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44)
    [    9.919410] ---[ end trace 0000000000000000 ]---
    
    Fixes: 217ed15bd399 ("drm/msm: enable separate binding of GPU and display devices")
    Signed-off-by: Akhil P Oommen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/672257/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm: Fix missing VM_BIND offset/range validation [+ + +]
Author: Rob Clark <[email protected]>
Date:   Wed Aug 20 17:04:26 2025 -0700

    drm/msm: Fix missing VM_BIND offset/range validation
    
    [ Upstream commit 3a3bef68a6c15d079646a964ebc4dc8bb0aedb06 ]
    
    We need to reject the MAP op if offset+range is larger than the BO size.
    
    Reported-by: Connor Abbott <[email protected]>
    Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl")
    Signed-off-by: Rob Clark <[email protected]>
    Tested-by: Connor Abbott <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/669781/
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm: Fix obj leak in VM_BIND error path [+ + +]
Author: Rob Clark <[email protected]>
Date:   Wed Aug 20 17:04:25 2025 -0700

    drm/msm: Fix obj leak in VM_BIND error path
    
    [ Upstream commit 278f8904434aa96055e793936b5977c010549e28 ]
    
    If we fail a handle-lookup part way thru, we need to drop the already
    obtained obj references.
    
    Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl")
    Signed-off-by: Rob Clark <[email protected]>
    Tested-by: Connor Abbott <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/669784/
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm: stop supporting no-IOMMU configuration [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Sep 3 13:51:50 2025 +0300

    drm/msm: stop supporting no-IOMMU configuration
    
    [ Upstream commit c94fc6d35685587aa0cb9a8d7d7062c73ab04d89 ]
    
    With the switch to GPUVM the msm driver no longer supports the no-IOMMU
    configurations (even without the actual GPU). Return an error in case we
    face the lack of the IOMMU.
    
    Fixes: 111fdd2198e6 ("drm/msm: drm_gpuvm conversion")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/672559/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel-edp: Add 50ms disable delay for four panels [+ + +]
Author: Langyan Ye <[email protected]>
Date:   Wed Jul 23 15:25:13 2025 +0800

    drm/panel-edp: Add 50ms disable delay for four panels
    
    [ Upstream commit 1511d3c4d2bb30f784924a877f3cef518bb73077 ]
    
    Add 50ms disable delay for NV116WHM-N49, NV122WUM-N41, and MNC207QS1-1
    to satisfy T9+T10 timing. Add 50ms disable delay for MNE007JA1-2
    as well, since MNE007JA1-2 copies the timing of MNC207QS1-1.
    
    Specifically, it should be noted that the MNE007JA1-2 panel was added
    by someone who did not have the panel documentation, so they simply
    copied the timing from the MNC207QS1-1 panel. Adding an extra 50 ms
    of delay should be safe.
    
    Fixes: 0547692ac146 ("drm/panel-edp: Add several generic edp panels")
    Fixes: 50625eab3972 ("drm/edp-panel: Add panel used by T14s Gen6 Snapdragon")
    Signed-off-by: Langyan Ye <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20250723072513.2880369-1-yelangyan@huaqin.corp-partner.google.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel-edp: Add disable to 100ms for MNB601LS1-4 [+ + +]
Author: Langyan Ye <[email protected]>
Date:   Mon Jul 21 14:16:27 2025 +0800

    drm/panel-edp: Add disable to 100ms for MNB601LS1-4
    
    [ Upstream commit 9b3700b15cb581d748c3d46e7eb30ffced1642e8 ]
    
    For the MNB601LS1-4 panel, the T9+T10 timing does not meet the
    requirements of the specification, so disable is set to 100ms.
    
    Fixes: 9d8e91439fc3 ("drm/panel-edp: Add CSW MNB601LS1-4")
    Signed-off-by: Langyan Ye <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20250721061627.3816612-1-yelangyan@huaqin.corp-partner.google.com
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel: Allow powering on panel follower after panel is enabled [+ + +]
Author: Pin-yen Lin <[email protected]>
Date:   Mon Aug 18 19:49:33 2025 +0800

    drm/panel: Allow powering on panel follower after panel is enabled
    
    [ Upstream commit 2eb22214c132374e11e681c44d7879c91f67f614 ]
    
    Some touch controllers have to be powered on after the panel's backlight
    is enabled. To support these controllers, introduce .panel_enabled() and
    .panel_disabling() to panel_follower_funcs and use them to power on the
    device after the panel and its backlight are enabled.
    
    Signed-off-by: Pin-yen Lin <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: cbdd16b818ee ("HID: i2c-hid: Make elan touch controllers power on after panel is enabled")
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: novatek-nt35560: Fix invalid return value [+ + +]
Author: Brigham Campbell <[email protected]>
Date:   Wed Jul 30 21:23:41 2025 -0600

    drm/panel: novatek-nt35560: Fix invalid return value
    
    [ Upstream commit 125459e19ec654924e472f3ff5aeea40358dbebf ]
    
    Fix bug in nt35560_set_brightness() which causes the function to
    erroneously report an error. mipi_dsi_dcs_write() returns either a
    negative value when an error occurred or a positive number of bytes
    written when no error occurred. The buggy code reports an error under
    either condition.
    
    Fixes: 8152c2bfd780 ("drm/panel: Add driver for Sony ACX424AKP panel")
    Reviewed-by: Douglas Anderson <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Brigham Campbell <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/r600_cs: clean up of dead code in r600_cs [+ + +]
Author: Brahmajit Das <[email protected]>
Date:   Mon Aug 11 14:51:25 2025 +0530

    drm/radeon/r600_cs: clean up of dead code in r600_cs
    
    [ Upstream commit 260dcf5b06d519bcf27a5dfdb5c626821a55c170 ]
    
    GCC 16 enables -Werror=unused-but-set-variable= which results in build
    error with the following message.
    
    drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_texture_size’:
    drivers/gpu/drm/radeon/r600_cs.c:1411:29: error: variable ‘level’ set but not used [-Werror=unused-but-set-variable=]
     1411 |         unsigned offset, i, level;
          |                             ^~~~~
    cc1: all warnings being treated as errors
    make[6]: *** [scripts/Makefile.build:287: drivers/gpu/drm/radeon/r600_cs.o] Error 1
    
    level although is set, but in never used in the function
    r600_texture_size. Thus resulting in dead code and this error getting
    triggered.
    
    Fixes: 60b212f8ddcd ("drm/radeon: overhaul texture checking. (v3)")
    Acked-by: Christian König <[email protected]>
    Signed-off-by: Brahmajit Das <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/sched: Fix a race in DRM_GPU_SCHED_STAT_NO_HANG test [+ + +]
Author: Tvrtko Ursulin <[email protected]>
Date:   Wed Jul 16 09:48:17 2025 +0100

    drm/sched: Fix a race in DRM_GPU_SCHED_STAT_NO_HANG test
    
    [ Upstream commit 2650bc4007c15e05f995f472b4fc89e793162bc4 ]
    
    The "skip reset" test waits for the timeout handler to run for the
    duration of 2 * MOCK_TIMEOUT, and because the mock scheduler opted to
    remove the "skip reset" flag once it fires, this gives opportunity for the
    timeout handler to run twice. Second time the job will be removed from the
    mock scheduler job list and the drm_mock_sched_advance() call in the test
    will fail.
    
    Fix it by making the "don't reset" flag persist for the lifetime of the
    job and add a new flag to verify that the code path had executed as
    expected.
    
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Fixes: 1472e7549f84 ("drm/sched: Add new test for DRM_GPU_SCHED_STAT_NO_HANG")
    Cc: Maíra Canal <[email protected]>
    Cc: Philipp Stanner <[email protected]>
    Reviewed-by: Maíra Canal <[email protected]>
    Signed-off-by: Philipp Stanner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vmwgfx: fix missing assignment to ts [+ + +]
Author: Colin Ian King <[email protected]>
Date:   Mon Jun 23 23:35:26 2025 +0100

    drm/vmwgfx: fix missing assignment to ts
    
    [ Upstream commit 33f8f321e7aa7715ce19560801ee5223ba8b9a7d ]
    
    The assignment to ts is missing on the call to ktime_to_timespec64.
    Fix this by adding the missing assignment.
    
    Fixes: db6a94b26354 ("drm/vmwgfx: Implement dma_fence_ops properly")
    Signed-off-by: Colin Ian King <[email protected]>
    Reviewed-by: Ian Forbes <[email protected]>
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm: re-allow no-op changes on non-primary planes in async flips [+ + +]
Author: Xaver Hugl <[email protected]>
Date:   Fri Aug 22 17:28:49 2025 +0200

    drm: re-allow no-op changes on non-primary planes in async flips
    
    [ Upstream commit b065bd213caf6d35b57c5089d6507d7e8598a586 ]
    
    Commit fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to
    async flip") unintentionally disallowed no-op changes on non-primary
    planes that the driver doesn't allow async flips on. This broke async
    flips for compositors that disable the cursor plane in every async
    atomic commit. To fix that, change drm_atomic_set_property to again
    only run atomic_async_check if the plane would actually be changed by
    the atomic commit.
    
    Fixes: fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
    Signed-off-by: Xaver Hugl <[email protected]>
    Reviewed-by: André Almeida <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [andrealmeid: fix checkpatch warning]
    Signed-off-by: André Almeida <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: vendor-prefixes: Add undocumented vendor prefixes [+ + +]
Author: Rob Herring (Arm) <[email protected]>
Date:   Thu Aug 21 17:21:33 2025 -0500

    dt-bindings: vendor-prefixes: Add undocumented vendor prefixes
    
    [ Upstream commit 4ed46073274a5b23baf0b992c459762e28faf549 ]
    
    Add various vendor prefixes which are in use in compatible strings
    already. These were found by modifying vendor-prefixes.yaml into a
    schema to check compatible strings.
    
    The added prefixes doesn't include various duplicate prefixes in use
    such as "lge".
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rob Herring (Arm) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dts: arm: amlogic: fix pwm node for c3 [+ + +]
Author: Xianwei Zhao <[email protected]>
Date:   Thu Jul 17 17:29:54 2025 +0800

    dts: arm: amlogic: fix pwm node for c3
    
    [ Upstream commit f8c9fabf2f3d87773613734a8479d0ef9b662b11 ]
    
    Fix reg address for c3 pwm node.
    
    Fixes: be90cd4bd422 ("arm64: dts: amlogic: Add Amlogic C3 PWM")
    Signed-off-by: Xianwei Zhao <[email protected]>
    Reviewed-by: Martin Blumenstingl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller [+ + +]
Author: Qiuxu Zhuo <[email protected]>
Date:   Wed Aug 6 14:57:07 2025 +0800

    EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller
    
    [ Upstream commit 2e6fe1bbefd9c059c3787d1c620fe67343a94dff ]
    
    When loading the i10nm_edac driver on some Intel Granite Rapids servers,
    a call trace may appear as follows:
    
      UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16
      shift exponent -66 is negative
      ...
      __ubsan_handle_shift_out_of_bounds+0x1e3/0x390
      skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]
      i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]
      skx_register_mci+0x159/0x220 [skx_edac_common]
      i10nm_init+0xcb0/0x1ff0 [i10nm_edac]
      ...
    
    This occurs because some BIOS may disable a memory controller if there
    aren't any memory DIMMs populated on this memory controller. The DIMMMTR
    register of this disabled memory controller contains the invalid value
    ~0, resulting in the call trace above.
    
    Fix this call trace by skipping DIMM enumeration on a disabled memory
    controller.
    
    Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support")
    Reported-by: Jose Jesus Ambriz Meza <[email protected]>
    Reported-by: Chia-Lin Kao (AceLan) <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Qiuxu Zhuo <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Tested-by: Chia-Lin Kao (AceLan) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
efi: Explain OVMF acronym in OVMF_DEBUG_LOG help text [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 12 15:54:29 2025 +0200

    efi: Explain OVMF acronym in OVMF_DEBUG_LOG help text
    
    [ Upstream commit 05e75ac35ee9e38f96bbfebf1830ec2cace2e7f8 ]
    
    People not very intimate with EFI may not know the meaning of the OVMF
    acronym.  Write it in full, to help users with making good decisions
    when configuring their kernels.
    
    Fixes: f393a761763c5427 ("efi: add ovmf debug log driver")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Richard Lyu <[email protected]>
    Acked-by: Gerd Hoffmann <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
erofs: avoid reading more for fragment maps [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Tue Sep 16 16:48:51 2025 +0800

    erofs: avoid reading more for fragment maps
    
    [ Upstream commit 334c0e493c2aa3e843a80bb9f3862bb50360cb36 ]
    
    Since all real encoded extents (directly handled by the decompression
    subsystem) have a sane, limited maximum decoded length
    (Z_EROFS_PCLUSTER_MAX_DSIZE), and the read-more policy is only applied
    if needed.
    
    However, it makes no sense to read more for non-encoded maps, such as
    fragment extents, since such extents can be huge (up to i_size) and
    there is no benefit to reading more at this layer.
    
    For normal images, it does not really matter, but for crafted images
    generated by syzbot, excessively large fragment extents can cause
    read-more to run for an overly long time.
    
    Reported-and-tested-by: [email protected]
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: b44686c8391b ("erofs: fix large fragment handling")
    Fixes: b15b2e307c3a ("erofs: support on-disk compressed fragments data")
    Reviewed-by: Hongbo Li <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: fix checks for orphan inodes [+ + +]
Author: Jan Kara <[email protected]>
Date:   Thu Sep 25 14:30:39 2025 +0200

    ext4: fix checks for orphan inodes
    
    commit acf943e9768ec9d9be80982ca0ebc4bfd6b7631e upstream.
    
    When orphan file feature is enabled, inode can be tracked as orphan
    either in the standard orphan list or in the orphan file. The first can
    be tested by checking ei->i_orphan list head, the second is recorded by
    EXT4_STATE_ORPHAN_FILE inode state flag. There are several places where
    we want to check whether inode is tracked as orphan and only some of
    them properly check for both possibilities. Luckily the consequences are
    mostly minor, the worst that can happen is that we track an inode as
    orphan although we don't need to and e2fsck then complains (resulting in
    occasional ext4/307 xfstest failures). Fix the problem by introducing a
    helper for checking whether an inode is tracked as orphan and use it in
    appropriate places.
    
    Fixes: 4a79a98c7b19 ("ext4: Improve scalability of ext4 orphan file handling")
    Cc: [email protected]
    Signed-off-by: Jan Kara <[email protected]>
    Reviewed-by: Zhang Yi <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix potential null deref in ext4_mb_init() [+ + +]
Author: Baokun Li <[email protected]>
Date:   Mon Aug 25 11:38:30 2025 +0800

    ext4: fix potential null deref in ext4_mb_init()
    
    commit 3c3fac6bc0a9c00dbe65d8dc0d3a282afe4d3188 upstream.
    
    In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called
    when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo
    slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()
    lacks null pointer checking, this leads to a null pointer dereference.
    
    ==================================================================
    EXT4-fs: no memory for groupinfo slab cache
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    PGD 0 P4D 0
    Oops: Oops: 0002 [#1] SMP PTI
    CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)
    RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40
    Call Trace:
     <TASK>
     xa_destroy+0x61/0x130
     ext4_mb_init+0x483/0x540
     __ext4_fill_super+0x116d/0x17b0
     ext4_fill_super+0xd3/0x280
     get_tree_bdev_flags+0x132/0x1d0
     vfs_get_tree+0x29/0xd0
     do_new_mount+0x197/0x300
     __x64_sys_mount+0x116/0x150
     do_syscall_64+0x50/0x1c0
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    ==================================================================
    
    Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()
    to prevent this issue. The same fix is also applied to
    ext4_mb_largest_free_orders_destroy().
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=1713b1aa266195b916c2
    Cc: [email protected]
    Fixes: f7eaacbb4e54 ("ext4: convert free groups order lists to xarrays")
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Zhang Yi <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
f2fs: fix condition in __allow_reserved_blocks() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Jul 31 14:03:38 2025 +0800

    f2fs: fix condition in __allow_reserved_blocks()
    
    [ Upstream commit e75ce117905d2830976a289e718470f3230fa30a ]
    
    If reserve_root mount option is not assigned, __allow_reserved_blocks()
    will return false, it's not correct, fix it.
    
    Fixes: 7e65be49ed94 ("f2fs: add reserved blocks for root user")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to allow removing qf_name [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Aug 18 10:09:39 2025 +0800

    f2fs: fix to allow removing qf_name
    
    [ Upstream commit ff11d8701b77e303593fd86cf9ef74ef3ac4048e ]
    
    The mount behavior changed after commit d18535132523 ("f2fs: separate the
    options parsing and options checking"), let's fix it.
    
    [Scripts]
    mkfs.f2fs -f /dev/vdb
    mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs
    quotacheck -uc /mnt/f2fs
    umount /mnt/f2fs
    mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs
    mount|grep f2fs
    mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs
    mount|grep f2fs
    dmesg
    
    [Before commit]
    mount#1: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,...
    mount#2: ...,quota,jqfmt=vfsold,...
    kmsg: no output
    
    [After commit]
    mount#1: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,...
    mount#2: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,...
    kmsg: "user quota file already specified"
    
    [After patch]
    mount#1: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,...
    mount#2: ...,quota,jqfmt=vfsold,...
    kmsg: "remove qf_name aquota.user"
    
    Fixes: d18535132523 ("f2fs: separate the options parsing and options checking")
    Cc: Hongbo Li <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Reviewed-by: Hongbo Li <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid migrating empty section [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Sep 1 10:04:15 2025 +0800

    f2fs: fix to avoid migrating empty section
    
    [ Upstream commit d625a2b08c089397d3a03bff13fa8645e4ec7a01 ]
    
    It reports a bug from device w/ zufs:
    
    F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT
    F2FS-fs (dm-64): Stopped filesystem due to reason: 4
    
    Thread A                                Thread B
    - f2fs_expand_inode_data
     - f2fs_allocate_pinning_section
      - f2fs_gc_range
       - do_garbage_collect w/ segno #x
                                            - writepage
                                             - f2fs_allocate_data_block
                                              - new_curseg
                                               - allocate segno #x
    
    The root cause is: fallocate on pinning file may race w/ block allocation
    as above, result in do_garbage_collect() from fallocate() may migrate
    segment which is just allocated by a log, the log will update segment type
    in its in-memory structure, however GC will get segment type from on-disk
    SSA block, once segment type changes by log, we can detect such
    inconsistency, then shutdown filesystem.
    
    In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE),
    however segno #173822 was just allocated as data type segment, so in-memory
    SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA).
    
    Change as below to fix this issue:
    - check whether current section is empty before gc
    - add sanity checks on do_garbage_collect() to avoid any race case, result
    in migrating segment used by log.
    - btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA".
    
    Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Aug 18 10:09:38 2025 +0800

    f2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency()
    
    [ Upstream commit 930a9a6ee8e7ffa20af4bffbfc2bbd21d83bf81c ]
    
    syzbot reported a f2fs bug as below:
    
    Oops: gen[  107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G        W           6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)}
    RIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284
    Call Trace:
     <TASK>
     f2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline]
     f2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436
     __f2fs_remount fs/f2fs/super.c:2653 [inline]
     f2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297
     reconfigure_super+0x224/0x890 fs/super.c:1077
     do_remount fs/namespace.c:3314 [inline]
     path_mount+0xd18/0xfe0 fs/namespace.c:4112
     do_mount fs/namespace.c:4133 [inline]
     __do_sys_mount fs/namespace.c:4344 [inline]
     __se_sys_mount+0x317/0x410 fs/namespace.c:4321
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    The direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref
    issue in strcmp().
    
    The bug can be reproduced w/ below scripts:
    mkfs.f2fs -f /dev/vdb
    mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs
    quotacheck -uc /mnt/f2fs/
    umount /mnt/f2fs
    mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs
    mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs
    umount /mnt/f2fs
    
    So, before old_qname and new_qname comparison, we need to check whether
    they are all valid pointers, fix it.
    
    Reported-by: [email protected]
    Fixes: d18535132523 ("f2fs: separate the options parsing and options checking")
    Closes: https://lore.kernel.org/linux-f2fs-devel/[email protected]
    Cc: Hongbo Li <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Reviewed-by: Hongbo Li <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid overflow while left shift operation [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Aug 5 14:29:10 2025 +0800

    f2fs: fix to avoid overflow while left shift operation
    
    [ Upstream commit 0fe1c6bec54ea68ed8c987b3890f2296364e77bb ]
    
    Should cast type of folio->index from pgoff_t to loff_t to avoid overflow
    while left shift operation.
    
    Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to clear unusable_cap for checkpoint=enable [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Aug 7 09:48:35 2025 +0800

    f2fs: fix to clear unusable_cap for checkpoint=enable
    
    [ Upstream commit 2e8f4c2b2bb12fc3d40762f1bb778e95c6ddbc93 ]
    
    mount -t f2fs -o checkpoint=disable:10% /dev/vdb /mnt/f2fs/
    mount -t f2fs -o remount,checkpoint=enable /dev/vdb /mnt/f2fs/
    
    kernel log:
    F2FS-fs (vdb): Adjust unusable cap for checkpoint=disable = 204440 / 10%
    
    If we has assigned checkpoint=enable mount option, unusable_cap{,_perc}
    parameters of checkpoint=disable should be reset, then calculation and
    log print could be avoid in adjust_unusable_cap_perc().
    
    Fixes: 1ae18f71cb52 ("f2fs: fix checkpoint=disable:%u%%")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to mitigate overhead of f2fs_zero_post_eof_page() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Sep 16 10:47:09 2025 +0800

    f2fs: fix to mitigate overhead of f2fs_zero_post_eof_page()
    
    [ Upstream commit c2f7c32b254006ad48f8e4efb2e7e7bf71739f17 ]
    
    f2fs_zero_post_eof_page() may cuase more overhead due to invalidate_lock
    and page lookup, change as below to mitigate its overhead:
    - check new_size before grabbing invalidate_lock
    - lookup and invalidate pages only in range of [old_size, new_size]
    
    Fixes: ba8dac350faf ("f2fs: fix to zero post-eof page")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to truncate first page in error path of f2fs_truncate() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Sep 10 16:40:24 2025 +0800

    f2fs: fix to truncate first page in error path of f2fs_truncate()
    
    [ Upstream commit 9251a9e6e871cb03c4714a18efa8f5d4a8818450 ]
    
    syzbot reports a bug as below:
    
    loop0: detected capacity change from 0 to 40427
    F2FS-fs (loop0): Wrong SSA boundary, start(3584) end(4096) blocks(3072)
    F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
    F2FS-fs (loop0): invalid crc value
    F2FS-fs (loop0): f2fs_convert_inline_folio: corrupted inline inode ino=3, i_addr[0]:0x1601, run fsck to fix.
    ------------[ cut here ]------------
    kernel BUG at fs/inode.c:753!
    RIP: 0010:clear_inode+0x169/0x190 fs/inode.c:753
    Call Trace:
     <TASK>
     evict+0x504/0x9c0 fs/inode.c:810
     f2fs_fill_super+0x5612/0x6fa0 fs/f2fs/super.c:5047
     get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692
     vfs_get_tree+0x8f/0x2b0 fs/super.c:1815
     do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808
     do_mount fs/namespace.c:4136 [inline]
     __do_sys_mount fs/namespace.c:4347 [inline]
     __se_sys_mount+0x317/0x410 fs/namespace.c:4324
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    During f2fs_evict_inode(), clear_inode() detects that we missed to truncate
    all page cache before destorying inode, that is because in below path, we
    will create page #0 in cache, but missed to drop it in error path, let's fix
    it.
    
    - evict
     - f2fs_evict_inode
      - f2fs_truncate
       - f2fs_convert_inline_inode
        - f2fs_grab_cache_folio
        : create page #0 in cache
        - f2fs_convert_inline_folio
        : sanity check failed, return -EFSCORRUPTED
      - clear_inode detects that inode->i_data.nrpages is not zero
    
    Fixes: 92dffd01790a ("f2fs: convert inline_data when i_size becomes large")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/linux-f2fs-devel/[email protected]
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to update map->m_next_extent correctly in f2fs_map_blocks() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Sep 12 16:12:50 2025 +0800

    f2fs: fix to update map->m_next_extent correctly in f2fs_map_blocks()
    
    [ Upstream commit 869833f54e8306326b85ca3ed08979b7ad412a4a ]
    
    Script to reproduce:
    mkfs.f2fs -O extra_attr,compression /dev/vdb -f
    mount /dev/vdb /mnt/f2fs -o mode=lfs,noextent_cache
    cd /mnt/f2fs
    f2fs_io write 1 0 1024 rand dsync testfile
    xfs_io testfile -c "fsync"
    f2fs_io write 1 0 512 rand dsync testfile
    xfs_io testfile -c "fsync"
    cd /
    umount /mnt/f2fs
    mount /dev/vdb /mnt/f2fs
    f2fs_io precache_extents /mnt/f2fs/testfile
    umount /mnt/f2fs
    
    Tracepoint output:
    f2fs_update_read_extent_tree_range: dev = (253,16), ino = 4, pgofs = 0, len = 512, blkaddr = 1055744, c_len = 0
    f2fs_update_read_extent_tree_range: dev = (253,16), ino = 4, pgofs = 513, len = 351, blkaddr = 17921, c_len = 0
    f2fs_update_read_extent_tree_range: dev = (253,16), ino = 4, pgofs = 864, len = 160, blkaddr = 18272, c_len = 0
    
    During precache_extents, there is off-by-one issue, we should update
    map->m_next_extent to pgofs rather than pgofs + 1, if last blkaddr is
    valid and not contiguous to previous extent.
    
    Fixes: c4020b2da4c9 ("f2fs: support F2FS_IOC_PRECACHE_EXTENTS")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to zero data after EOF for compressed file correctly [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Aug 6 14:11:06 2025 +0800

    f2fs: fix to zero data after EOF for compressed file correctly
    
    [ Upstream commit 0b2cd5092139f499544c77b5107a74e5fdb3a386 ]
    
    generic/091 may fail, then it bisects to the bad commit ba8dac350faf
    ("f2fs: fix to zero post-eof page").
    
    What will cause generic/091 to fail is something like below Testcase #1:
    1. write 16k as compressed blocks
    2. truncate to 12k
    3. truncate to 20k
    4. verify data in range of [12k, 16k], however data is not zero as
    expected
    
    Script of Testcase #1
    mkfs.f2fs -f -O extra_attr,compression /dev/vdb
    mount -t f2fs -o compress_extension=* /dev/vdb /mnt/f2fs
    dd if=/dev/zero of=/mnt/f2fs/file bs=12k count=1
    dd if=/dev/random of=/mnt/f2fs/file bs=4k count=1 seek=3 conv=notrunc
    sync
    truncate -s $((12*1024)) /mnt/f2fs/file
    truncate -s $((20*1024)) /mnt/f2fs/file
    dd if=/mnt/f2fs/file of=/mnt/f2fs/data bs=4k count=1 skip=3
    od /mnt/f2fs/data
    umount /mnt/f2fs
    
    Analisys:
    in step 2), we will redirty all data pages from #0 to #3 in compressed
    cluster, and zero page #3,
    in step 3), f2fs_setattr() will call f2fs_zero_post_eof_page() to drop
    all page cache post eof, includeing dirtied page #3,
    in step 4) when we read data from page #3, it will decompressed cluster
    and extra random data to page #3, finally, we hit the non-zeroed data
    post eof.
    
    However, the commit ba8dac350faf ("f2fs: fix to zero post-eof page") just
    let the issue be reproduced easily, w/o the commit, it can reproduce this
    bug w/ below Testcase #2:
    1. write 16k as compressed blocks
    2. truncate to 8k
    3. truncate to 12k
    4. truncate to 20k
    5. verify data in range of [12k, 16k], however data is not zero as
    expected
    
    Script of Testcase #2
    mkfs.f2fs -f -O extra_attr,compression /dev/vdb
    mount -t f2fs -o compress_extension=* /dev/vdb /mnt/f2fs
    dd if=/dev/zero of=/mnt/f2fs/file bs=12k count=1
    dd if=/dev/random of=/mnt/f2fs/file bs=4k count=1 seek=3 conv=notrunc
    sync
    truncate -s $((8*1024)) /mnt/f2fs/file
    truncate -s $((12*1024)) /mnt/f2fs/file
    truncate -s $((20*1024)) /mnt/f2fs/file
    echo 3 > /proc/sys/vm/drop_caches
    dd if=/mnt/f2fs/file of=/mnt/f2fs/data bs=4k count=1 skip=3
    od /mnt/f2fs/data
    umount /mnt/f2fs
    
    Anlysis:
    in step 2), we will redirty all data pages from #0 to #3 in compressed
    cluster, and zero page #2 and #3,
    in step 3), we will truncate page #3 in page cache,
    in step 4), expand file size,
    in step 5), hit random data post eof w/ the same reason in Testcase #1.
    
    Root Cause:
    In f2fs_truncate_partial_cluster(), after we truncate partial data block
    on compressed cluster, all pages in cluster including the one post eof
    will be dirtied, after another tuncation, dirty page post eof will be
    dropped, however on-disk compressed cluster is still valid, it may
    include non-zero data post eof, result in exposing previous non-zero data
    post eof while reading.
    
    Fix:
    In f2fs_truncate_partial_cluster(), let change as below to fix:
    - call filemap_write_and_wait_range() to flush dirty page
    - call truncate_pagecache() to drop pages or zero partial page post eof
    - call f2fs_do_truncate_blocks() to truncate non-compress cluster to
      last valid block
    
    Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode")
    Reported-by: Jan Prusakowski <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix UAF issue in f2fs_merge_page_bio() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Sun Sep 28 18:24:22 2025 +0800

    f2fs: fix UAF issue in f2fs_merge_page_bio()
    
    [ Upstream commit edf7e9040fc52c922db947f9c6c36f07377c52ea ]
    
    As JY reported in bugzilla [1],
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98
    lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4
    CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P    B   W  OE      6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5
    Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    Workqueue: writeback wb_workfn (flush-254:49)
    Call trace:
     f2fs_is_cp_guaranteed+0x70/0x98
     f2fs_inplace_write_data+0x174/0x2f4
     f2fs_do_write_data_page+0x214/0x81c
     f2fs_write_single_data_page+0x28c/0x764
     f2fs_write_data_pages+0x78c/0xce4
     do_writepages+0xe8/0x2fc
     __writeback_single_inode+0x4c/0x4b4
     writeback_sb_inodes+0x314/0x540
     __writeback_inodes_wb+0xa4/0xf4
     wb_writeback+0x160/0x448
     wb_workfn+0x2f0/0x5dc
     process_scheduled_works+0x1c8/0x458
     worker_thread+0x334/0x3f0
     kthread+0x118/0x1ac
     ret_from_fork+0x10/0x20
    
    [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575
    
    The panic was caused by UAF issue w/ below race condition:
    
    kworker
    - writepages
     - f2fs_write_cache_pages
      - f2fs_write_single_data_page
       - f2fs_do_write_data_page
        - f2fs_inplace_write_data
         - f2fs_merge_page_bio
          - add_inu_page
          : cache page #1 into bio & cache bio in
            io->bio_list
      - f2fs_write_single_data_page
       - f2fs_do_write_data_page
        - f2fs_inplace_write_data
         - f2fs_merge_page_bio
          - add_inu_page
          : cache page #2 into bio which is linked
            in io->bio_list
                                                    write
                                                    - f2fs_write_begin
                                                    : write page #1
                                                     - f2fs_folio_wait_writeback
                                                      - f2fs_submit_merged_ipu_write
                                                       - f2fs_submit_write_bio
                                                       : submit bio which inclues page #1 and #2
    
                                                    software IRQ
                                                    - f2fs_write_end_io
                                                     - fscrypt_free_bounce_page
                                                     : freed bounced page which belongs to page #2
          - inc_page_count( , WB_DATA_TYPE(data_folio), false)
          : data_folio points to fio->encrypted_page
            the bounced page can be freed before
            accessing it in f2fs_is_cp_guarantee()
    
    It can reproduce w/ below testcase:
    Run below script in shell #1:
    for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \
    -c "pwrite 0 32k" -c "fdatasync"
    
    Run below script in shell #2:
    for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \
    -c "pwrite 0 32k" -c "fdatasync"
    
    So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after
    commit page into internal ipu cache.
    
    Fixes: 0b20fcec8651 ("f2fs: cache global IPU bio")
    Reported-by: JY <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix zero-sized extent for precache extents [+ + +]
Author: wangzijie <[email protected]>
Date:   Wed Sep 17 10:36:21 2025 +0800

    f2fs: fix zero-sized extent for precache extents
    
    [ Upstream commit 8175c864391753b210f3dcfae1aeed686a226ebb ]
    
    Script to reproduce:
    f2fs_io write 1 0 1881 rand dsync testfile
    f2fs_io fallocate 0 7708672 4096 testfile
    f2fs_io write 1 1881 1 rand buffered testfile
    fsync testfile
    umount
    mount
    f2fs_io precache_extents testfile
    
    When the data layout is something like this:
    dnode1:                     dnode2:
    [0]      A                  [0]    NEW_ADDR
    [1]      A+1                [1]    0x0
    ...
    [1016]   A+1016
    [1017]   B (B!=A+1017)      [1017] 0x0
    
    During precache_extents, we map the last block(valid blkaddr) in dnode1:
    map->m_flags |= F2FS_MAP_MAPPED;
    map->m_pblk = blkaddr(valid blkaddr);
    map->m_len = 1;
    then we goto next_dnode, meet the first block in dnode2(hole), goto sync_out:
    map->m_flags & F2FS_MAP_MAPPED == true, and we make zero-sized extent:
    
    map->m_len = 1
    ofs = start_pgofs - map->m_lblk = 1882 - 1881 = 1
    ei.fofs = start_pgofs = 1882
    ei.len = map->m_len - ofs = 1 - 1 = 0
    
    Rebased on patch[1], this patch can cover these cases to avoid zero-sized extent:
    A,B,C is valid blkaddr
    case1:
    dnode1:                     dnode2:
    [0]      A                  [0]    NEW_ADDR
    [1]      A+1                [1]    0x0
    ...                         ....
    [1016]   A+1016
    [1017]   B (B!=A+1017)      [1017] 0x0
    
    case2:
    dnode1:                     dnode2:
    [0]      A                  [0]    C (C!=B+1)
    [1]      A+1                [1]    C+1
    ...                         ....
    [1016]   A+1016
    [1017]   B (B!=A+1017)      [1017] 0x0
    
    case3:
    dnode1:                     dnode2:
    [0]      A                  [0]    C (C!=B+2)
    [1]      A+1                [1]    C+1
    ...                         ....
    [1015]   A+1015
    [1016]   B (B!=A+1016)
    [1017]   B+1                [1017] 0x0
    
    [1] https://lore.kernel.org/linux-f2fs-devel/[email protected]/
    
    Fixes: c4020b2da4c9 ("f2fs: support F2FS_IOC_PRECACHE_EXTENTS")
    Signed-off-by: wangzijie <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fanotify: Validate the return value of mnt_ns_from_dentry() before dereferencing [+ + +]
Author: Anderson Nascimento <[email protected]>
Date:   Thu Sep 4 16:09:13 2025 +0200

    fanotify: Validate the return value of mnt_ns_from_dentry() before dereferencing
    
    [ Upstream commit 62e59ffe8787b5550ccff70c30b6f6be6a3ac3dd ]
    
    The function do_fanotify_mark() does not validate if
    mnt_ns_from_dentry() returns NULL before dereferencing mntns->user_ns.
    This causes a NULL pointer dereference in do_fanotify_mark() if the
    path is not a mount namespace object.
    
    Fix this by checking mnt_ns_from_dentry()'s return value before
    dereferencing it.
    
    Before the patch
    
    $ gcc fanotify_nullptr.c -o fanotify_nullptr
    $ mkdir A
    $ ./fanotify_nullptr
    Fanotify fd: 3
    fanotify_mark: Operation not permitted
    $ unshare -Urm
    Fanotify fd: 3
    Killed
    
    int main(void){
        int ffd;
        ffd = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_MNT, 0);
        if(ffd < 0){
            perror("fanotify_init");
            exit(EXIT_FAILURE);
        }
    
        printf("Fanotify fd: %d\n",ffd);
    
        if(fanotify_mark(ffd, FAN_MARK_ADD | FAN_MARK_MNTNS,
    FAN_MNT_ATTACH, AT_FDCWD, "A") < 0){
            perror("fanotify_mark");
            exit(EXIT_FAILURE);
        }
    
    return 0;
    }
    
    After the patch
    
    $ gcc fanotify_nullptr.c -o fanotify_nullptr
    $ mkdir A
    $ ./fanotify_nullptr
    Fanotify fd: 3
    fanotify_mark: Operation not permitted
    $ unshare -Urm
    Fanotify fd: 3
    fanotify_mark: Invalid argument
    
    [   25.694973] BUG: kernel NULL pointer dereference, address: 0000000000000038
    [   25.695006] #PF: supervisor read access in kernel mode
    [   25.695012] #PF: error_code(0x0000) - not-present page
    [   25.695017] PGD 109a30067 P4D 109a30067 PUD 142b46067 PMD 0
    [   25.695025] Oops: Oops: 0000 [#1] SMP NOPTI
    [   25.695032] CPU: 4 UID: 1000 PID: 1478 Comm: fanotify_nullpt Not
    tainted 6.17.0-rc4 #1 PREEMPT(lazy)
    [   25.695040] Hardware name: VMware, Inc. VMware Virtual
    Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
    [   25.695049] RIP: 0010:do_fanotify_mark+0x817/0x950
    [   25.695066] Code: 04 00 00 e9 45 fd ff ff 48 8b 7c 24 48 4c 89 54
    24 18 4c 89 5c 24 10 4c 89 0c 24 e8 b3 11 fc ff 4c 8b 54 24 18 4c 8b
    5c 24 10 <48> 8b 78 38 4c 8b 0c 24 49 89 c4 e9 13 fd ff ff 8b 4c 24 28
    85 c9
    [   25.695081] RSP: 0018:ffffd31c469e3c08 EFLAGS: 00010203
    [   25.695104] RAX: 0000000000000000 RBX: 0000000001000000 RCX: ffff8eb48aebd220
    [   25.695110] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8eb4835e8180
    [   25.695115] RBP: 0000000000000111 R08: 0000000000000000 R09: 0000000000000000
    [   25.695142] R10: ffff8eb48a7d56c0 R11: ffff8eb482bede00 R12: 00000000004012a7
    [   25.695148] R13: 0000000000000110 R14: 0000000000000001 R15: ffff8eb48a7d56c0
    [   25.695154] FS:  00007f8733bda740(0000) GS:ffff8eb61ce5f000(0000)
    knlGS:0000000000000000
    [   25.695162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   25.695170] CR2: 0000000000000038 CR3: 0000000136994006 CR4: 00000000003706f0
    [   25.695201] Call Trace:
    [   25.695209]  <TASK>
    [   25.695215]  __x64_sys_fanotify_mark+0x1f/0x30
    [   25.695222]  do_syscall_64+0x82/0x2c0
    ...
    
    Fixes: 58f5fbeb367f ("fanotify: support watching filesystems and mounts inside userns")
    Link: https://patch.msgid.link/CAPhRvkw4ONypNsJrCnxbKnJbYmLHTDEKFC4C_num_5sVBVa8jg@mail.gmail.com
    Signed-off-by: Anderson Nascimento <[email protected]>
    Reviewed-by: Christian Brauner <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: simplefb: Fix use after free in simplefb_detach_genpds() [+ + +]
Author: Janne Grunau <[email protected]>
Date:   Mon Sep 15 08:36:41 2025 +0200

    fbdev: simplefb: Fix use after free in simplefb_detach_genpds()
    
    commit da1bb9135213744e7ec398826c8f2e843de4fb94 upstream.
    
    The pm_domain cleanup can not be devres managed as it uses struct
    simplefb_par which is allocated within struct fb_info by
    framebuffer_alloc(). This allocation is explicitly freed by
    unregister_framebuffer() in simplefb_remove().
    Devres managed cleanup runs after the device remove call and thus can no
    longer access struct simplefb_par.
    Call simplefb_detach_genpds() explicitly from simplefb_destroy() like
    the cleanup functions for clocks and regulators.
    
    Fixes an use after free on M2 Mac mini during
    aperture_remove_conflicting_devices() using the downstream asahi kernel
    with Debian's kernel config. For unknown reasons this started to
    consistently dereference an invalid pointer in v6.16.3 based kernels.
    
    [    6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220
    [    6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227
    [    6.750697]
    [    6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S                  6.16.3-asahi+ #16 PREEMPTLAZY
    [    6.752186] Tainted: [S]=CPU_OUT_OF_SPEC
    [    6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)
    [    6.752189] Call trace:
    [    6.752190]  show_stack+0x34/0x98 (C)
    [    6.752194]  dump_stack_lvl+0x60/0x80
    [    6.752197]  print_report+0x17c/0x4d8
    [    6.752201]  kasan_report+0xb4/0x100
    [    6.752206]  __asan_report_load4_noabort+0x20/0x30
    [    6.752209]  simplefb_detach_genpds+0x58/0x220
    [    6.752213]  devm_action_release+0x50/0x98
    [    6.752216]  release_nodes+0xd0/0x2c8
    [    6.752219]  devres_release_all+0xfc/0x178
    [    6.752221]  device_unbind_cleanup+0x28/0x168
    [    6.752224]  device_release_driver_internal+0x34c/0x470
    [    6.752228]  device_release_driver+0x20/0x38
    [    6.752231]  bus_remove_device+0x1b0/0x380
    [    6.752234]  device_del+0x314/0x820
    [    6.752238]  platform_device_del+0x3c/0x1e8
    [    6.752242]  platform_device_unregister+0x20/0x50
    [    6.752246]  aperture_detach_platform_device+0x1c/0x30
    [    6.752250]  aperture_detach_devices+0x16c/0x290
    [    6.752253]  aperture_remove_conflicting_devices+0x34/0x50
    ...
    [    6.752343]
    [    6.967409] Allocated by task 62:
    [    6.970724]  kasan_save_stack+0x3c/0x70
    [    6.974560]  kasan_save_track+0x20/0x40
    [    6.978397]  kasan_save_alloc_info+0x40/0x58
    [    6.982670]  __kasan_kmalloc+0xd4/0xd8
    [    6.986420]  __kmalloc_noprof+0x194/0x540
    [    6.990432]  framebuffer_alloc+0xc8/0x130
    [    6.994444]  simplefb_probe+0x258/0x2378
    ...
    [    7.054356]
    [    7.055838] Freed by task 227:
    [    7.058891]  kasan_save_stack+0x3c/0x70
    [    7.062727]  kasan_save_track+0x20/0x40
    [    7.066565]  kasan_save_free_info+0x4c/0x80
    [    7.070751]  __kasan_slab_free+0x6c/0xa0
    [    7.074675]  kfree+0x10c/0x380
    [    7.077727]  framebuffer_release+0x5c/0x90
    [    7.081826]  simplefb_destroy+0x1b4/0x2c0
    [    7.085837]  put_fb_info+0x98/0x100
    [    7.089326]  unregister_framebuffer+0x178/0x320
    [    7.093861]  simplefb_remove+0x3c/0x60
    [    7.097611]  platform_remove+0x60/0x98
    [    7.101361]  device_remove+0xb8/0x160
    [    7.105024]  device_release_driver_internal+0x2fc/0x470
    [    7.110256]  device_release_driver+0x20/0x38
    [    7.114529]  bus_remove_device+0x1b0/0x380
    [    7.118628]  device_del+0x314/0x820
    [    7.122116]  platform_device_del+0x3c/0x1e8
    [    7.126302]  platform_device_unregister+0x20/0x50
    [    7.131012]  aperture_detach_platform_device+0x1c/0x30
    [    7.136157]  aperture_detach_devices+0x16c/0x290
    [    7.140779]  aperture_remove_conflicting_devices+0x34/0x50
    ...
    
    Reported-by: Daniel Huhardeaux <[email protected]>
    Cc: [email protected]
    Fixes: 92a511a568e44 ("fbdev/simplefb: Add support for generic power-domains")
    Signed-off-by: Janne Grunau <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
filelock: add FL_RECLAIM to show_fl_flags() macro [+ + +]
Author: Jeff Layton <[email protected]>
Date:   Wed Sep 3 11:23:33 2025 -0400

    filelock: add FL_RECLAIM to show_fl_flags() macro
    
    [ Upstream commit c593b9d6c446510684da400833f9d632651942f0 ]
    
    Show the FL_RECLAIM flag symbolically in tracepoints.
    
    Fixes: bb0a55bb7148 ("nfs: don't allow reexport reclaims")
    Signed-off-by: Jeff Layton <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: arm_scmi: Mark VirtIO ready before registering scmi_virtio_driver [+ + +]
Author: Junnan Wu <[email protected]>
Date:   Tue Aug 12 15:53:43 2025 +0800

    firmware: arm_scmi: Mark VirtIO ready before registering scmi_virtio_driver
    
    [ Upstream commit e8faa8a466f61f4ae07069ed6b0872f602f1cba9 ]
    
    After commit 20bda12a0ea0 (“firmware: arm_scmi: Make VirtIO transport a
    standalone driver”), the VirtIO transport probes independently. During
    scmi_virtio_probe, scmi_probe() is called, which intune invokes
    scmi_protocol_acquire() that sends a message over the virtqueue and
    waits for a reply.
    
    Previously, DRIVER_OK was only set after scmi_vio_probe, in the core
    virtio via virtio_dev_probe(). According to the Virtio spec (3.1 Device
    Initialization):
      |  The driver MUST NOT send any buffer available notifications to the
      |  device before setting DRIVER_OK.
    
    Some type-1 hypervisors block available-buffer notifications until the
    driver is marked OK. In such cases, scmi_vio_probe stalls in
    scmi_wait_for_reply(), and the probe never completes.
    
    Resolve this by setting DRIVER_OK immediately after the device-specific
    setup, so scmi_probe() can safely send notifications.
    
    Note after splitting the transports into modules, the probe sequence
    changed a bit. We can no longer rely on virtio_device_ready() being
    called by the core in virtio_dev_probe(), because scmi_vio_probe()
    doesn’t complete until the core SCMI stack runs scmi_probe(), which
    immediately issues the initial BASE protocol exchanges.
    
    Fixes: 20bda12a0ea0 ("firmware: arm_scmi: Make VirtIO transport a standalone driver")
    Signed-off-by: Junnan Wu <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Sudeep Holla <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

firmware: firmware: meson-sm: fix compile-test default [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Fri Jul 25 09:54:29 2025 +0200

    firmware: firmware: meson-sm: fix compile-test default
    
    [ Upstream commit 0454346d1c5f7fccb3ef6e3103985de8ab3469f3 ]
    
    Enabling compile testing should not enable every individual driver (we
    have "allyesconfig" for that).
    
    Fixes: 4a434abc40d2 ("firmware: meson-sm: enable build as module")
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Martin Blumenstingl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Fix CC_HAS_ASM_GOTO_OUTPUT on non-x86 architectures [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Sep 29 08:54:12 2025 -0700

    Fix CC_HAS_ASM_GOTO_OUTPUT on non-x86 architectures
    
    [ Upstream commit fde0ab43b9a30d08817adc5402b69fec83a61cb8 ]
    
    There's a silly problem with the CC_HAS_ASM_GOTO_OUTPUT test: even with
    a working compiler it will fail on some architectures simply because it
    uses the mnemonic "jmp" for testing the inline asm.
    
    And as reported by Geert, not all architectures use that mnemonic, so
    the test fails spuriously on such platforms (including arm and riscv,
    but also several other architectures).
    
    This issue avoided any obvious test failures because the build still
    works thanks to falling back on the old non-asm-goto code, which just
    generates worse code.
    
    Just use an empty asm statement instead.
    
    Reported-and-tested-by: Geert Uytterhoeven <[email protected]>
    Suggested-by: Peter Zijlstra <[email protected]>
    Fixes: e2ffa15b9baa ("kbuild: Disable CC_HAS_ASM_GOTO_OUTPUT on clang < 17")
    Cc: Nathan Chancellor <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist [+ + +]
Author: Moon Hee Lee <[email protected]>
Date:   Tue Jul 22 10:40:16 2025 -0700

    fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist
    
    [ Upstream commit 0dc7117da8f92dd5fe077d712a756eccbe377d40 ]
    
    Index allocation requires at least one bit in the $BITMAP attribute to
    track usage of index entries. If the bitmap is empty while index blocks
    are already present, this reflects on-disk corruption.
    
    syzbot triggered this condition using a malformed NTFS image. During a
    rename() operation involving a long filename (which spans multiple
    index entries), the empty bitmap allowed the name to be added without
    valid tracking. Subsequent deletion of the original entry failed with
    -ENOENT, due to unexpected index state.
    
    Reject such cases by verifying that the bitmap is not empty when index
    blocks exist.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=b0373017f711c06ada64
    Fixes: d99208b91933 ("fs/ntfs3: cancle set bad inode after removing name fails")
    Tested-by: [email protected]
    Signed-off-by: Moon Hee Lee <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs: ntfs3: Fix integer overflow in run_unpack() [+ + +]
Author: Vitaly Grigoryev <[email protected]>
Date:   Mon Aug 25 13:08:55 2025 +0300

    fs: ntfs3: Fix integer overflow in run_unpack()
    
    [ Upstream commit 736fc7bf5f68f6b74a0925b7e072c571838657d2 ]
    
    The MFT record relative to the file being opened contains its runlist,
    an array containing information about the file's location on the physical
    disk. Analysis of all Call Stack paths showed that the values of the
    runlist array, from which LCNs are calculated, are not validated before
    run_unpack function.
    
    The run_unpack function decodes the compressed runlist data format
    from MFT attributes (for example, $DATA), converting them into a runs_tree
    structure, which describes the mapping of virtual clusters (VCN) to
    logical clusters (LCN). The NTFS3 subsystem also has a shortcut for
    deleting files from MFT records - in this case, the RUN_DEALLOCATE
    command is sent to the run_unpack input, and the function logic
    provides that all data transferred to the runlist about file or
    directory is deleted without creating a runs_tree structure.
    
    Substituting the runlist in the $DATA attribute of the MFT record for an
    arbitrary file can lead either to access to arbitrary data on the disk
    bypassing access checks to them (since the inode access check
    occurs above) or to destruction of arbitrary data on the disk.
    
    Add overflow check for addition operation.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation")
    Signed-off-by: Vitaly Grigoryev <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs: udf: fix OOB read in lengthAllocDescs handling [+ + +]
Author: Larshin Sergey <[email protected]>
Date:   Mon Sep 22 16:13:58 2025 +0300

    fs: udf: fix OOB read in lengthAllocDescs handling
    
    commit 3bd5e45c2ce30e239d596becd5db720f7eb83c99 upstream.
    
    When parsing Allocation Extent Descriptor, lengthAllocDescs comes from
    on-disk data and must be validated against the block size. Crafted or
    corrupted images may set lengthAllocDescs so that the total descriptor
    length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,
    leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and
    trigger a KASAN use-after-free read.
    
    BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
    Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309
    
    CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0x169/0x550 mm/kasan/report.c:488
     kasan_report+0x143/0x180 mm/kasan/report.c:601
     crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
     udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261
     udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179
     extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46
     udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106
     udf_release_file+0xc1/0x120 fs/udf/file.c:185
     __fput+0x23f/0x880 fs/file_table.c:431
     task_work_run+0x24f/0x310 kernel/task_work.c:239
     exit_task_work include/linux/task_work.h:43 [inline]
     do_exit+0xa2f/0x28e0 kernel/exit.c:939
     do_group_exit+0x207/0x2c0 kernel/exit.c:1088
     __do_sys_exit_group kernel/exit.c:1099 [inline]
     __se_sys_exit_group kernel/exit.c:1097 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
     x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
     </TASK>
    
    Validate the computed total length against epos->bh->b_size.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=8743fca924afed42f93e
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: [email protected]
    Signed-off-by: Larshin Sergey <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fuse: remove unneeded offset assignment when filling write pages [+ + +]
Author: Joanne Koong <[email protected]>
Date:   Tue May 20 13:16:54 2025 -0700

    fuse: remove unneeded offset assignment when filling write pages
    
    [ Upstream commit 6fd26f50857698c6f07a9e6b149247925fadb8fd ]
    
    With the change in aee03ea7ff98 ("fuse: support large folios for
    writethrough writes"), this old line for setting ap->descs[0].offset is
    now obsolete and unneeded. This should have been removed as part of
    aee03ea7ff98.
    
    Signed-off-by: Joanne Koong <[email protected]>
    Fixes: aee03ea7ff98 ("fuse: support large folios for writethrough writes")
    Signed-off-by: Miklos Szeredi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fwctl/mlx5: Fix memory alloc/free in mlx5ctl_fw_rpc() [+ + +]
Author: Akhilesh Patil <[email protected]>
Date:   Sat Aug 16 11:49:54 2025 +0530

    fwctl/mlx5: Fix memory alloc/free in mlx5ctl_fw_rpc()
    
    [ Upstream commit 7f059e47326746ceebe2a984bd6124459df3b458 ]
    
    Use kvfree() to free memory allocated by kvzalloc() instead of kfree().
    Avoid potential memory management issue considering kvzalloc() can
    internally choose to use either kmalloc() or vmalloc() based on memory
    request and current system memory state. Hence, use more appropriate
    kvfree() which automatically determines correct free method to avoid
    potential hard to debug memory issues.  Fix this issue discovered by
    running spatch static analysis tool using coccinelle script -
    scripts/coccinelle/api/kfree_mismatch.cocci
    
    Fixes: 52929c2142041 ("fwctl/mlx5: Support for communicating with mlx5 fw")
    Link: https://patch.msgid.link/r/[email protected]
    Signed-off-by: Akhilesh Patil <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Alison Schofield <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
genirq/test: Depend on SPARSE_IRQ [+ + +]
Author: Brian Norris <[email protected]>
Date:   Fri Aug 22 11:59:05 2025 -0700

    genirq/test: Depend on SPARSE_IRQ
    
    [ Upstream commit 0c888bc86d672e551ce5c58b891c8b44f8967643 ]
    
    Some architectures have a static interrupt layout, with a limited number of
    interrupts. Without SPARSE_IRQ, the test may not be able to allocate any
    fake interrupts, and the test will fail. (This occurs on ARCH=m68k, for
    example.)
    
    Additionally, managed-affinity is only supported with CONFIG_SPARSE_IRQ=y,
    so irq_shutdown_depth_test() and irq_cpuhotplug_test() would fail without
    it.
    
    Add a 'SPARSE_IRQ' dependency to avoid these problems.
    
    Many architectures 'select SPARSE_IRQ', so this is easy to miss.
    
    Notably, this also excludes ARCH=um from running any of these tests, even
    though some of them might work.
    
    Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
    Reported-by: Guenter Roeck <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

genirq/test: Drop CONFIG_GENERIC_IRQ_MIGRATION assumptions [+ + +]
Author: Brian Norris <[email protected]>
Date:   Fri Aug 22 11:59:06 2025 -0700

    genirq/test: Drop CONFIG_GENERIC_IRQ_MIGRATION assumptions
    
    [ Upstream commit add03fdb9d52411cabb3872fb7692df6f4c67586 ]
    
    Not all platforms use the generic IRQ migration code, even if they select
    GENERIC_IRQ_MIGRATION. (See, for example, powerpc / pseries_cpu_disable().)
    
    If such platforms don't perform managed shutdown the same way, the interrupt
    may not actually shut down, and these tests fail:
    
    [    4.357022][  T101]     # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:211
    [    4.357022][  T101]     Expected irqd_is_activated(data) to be false, but is true
    [    4.358128][  T101]     # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:212
    [    4.358128][  T101]     Expected irqd_is_started(data) to be false, but is true
    [    4.375558][  T101]     # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:216
    [    4.375558][  T101]     Expected irqd_is_activated(data) to be false, but is true
    [    4.376088][  T101]     # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:217
    [    4.376088][  T101]     Expected irqd_is_started(data) to be false, but is true
    [    4.377851][    T1]     # irq_cpuhotplug_test: pass:0 fail:1 skip:0 total:1
    [    4.377901][    T1]     not ok 4 irq_cpuhotplug_test
    [    4.378073][    T1] # irq_test_cases: pass:3 fail:1 skip:0 total:4
    
    Rather than test that PowerPC performs migration the same way as the
    unterrupt core, just drop the state checks. The point of the test was to
    ensure that the code kept |depth| balanced, which still can be tested for.
    
    Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
    Reported-by: Guenter Roeck <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

genirq/test: Ensure CPU 1 is online for hotplug test [+ + +]
Author: Brian Norris <[email protected]>
Date:   Fri Aug 22 11:59:07 2025 -0700

    genirq/test: Ensure CPU 1 is online for hotplug test
    
    [ Upstream commit 8ad25ebfa70e86860559b306bbc923c7db4fcac6 ]
    
    It's possible to run these tests on platforms that think they have a
    hotpluggable CPU1, but for whatever reason, CPU1 is not online and can't be
    brought online:
    
        # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:210
        Expected remove_cpu(1) == 0, but
            remove_cpu(1) == 1 (0x1)
    CPU1: failed to boot: -38
        # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:214
        Expected add_cpu(1) == 0, but
            add_cpu(1) == -38 (0xffffffffffffffda)
    
    Check that CPU1 is actually online before trying to run the test.
    
    Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
    Reported-by: Guenter Roeck <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

genirq/test: Fix depth tests on architectures with NOREQUEST by default. [+ + +]
Author: David Gow <[email protected]>
Date:   Sat Aug 16 17:45:28 2025 +0800

    genirq/test: Fix depth tests on architectures with NOREQUEST by default.
    
    [ Upstream commit c9163915a93d40e32c4e4aeb942c0adcb190d72e ]
    
    The new irq KUnit tests fail on some architectures (notably PowerPC and
    32-bit ARM), as the request_irq() call fails due to the ARCH_IRQ_INIT_FLAGS
    containing IRQ_NOREQUEST, yielding the following errors:
    
    [10:17:45]     # irq_free_disabled_test: EXPECTATION FAILED at kernel/irq/irq_test.c:88
    [10:17:45]     Expected ret == 0, but
    [10:17:45]         ret == -22 (0xffffffffffffffea)
    [10:17:45]     # irq_free_disabled_test: EXPECTATION FAILED at kernel/irq/irq_test.c:90
    [10:17:45]     Expected desc->depth == 0, but
    [10:17:45]         desc->depth == 1 (0x1)
    [10:17:45]     # irq_free_disabled_test: EXPECTATION FAILED at kernel/irq/irq_test.c:93
    [10:17:45]     Expected desc->depth == 1, but
    [10:17:45]         desc->depth == 2 (0x2)
    
    By clearing IRQ_NOREQUEST from the interrupt descriptor, these tests now
    pass on ARM and PowerPC.
    
    Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
    Signed-off-by: David Gow <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Brian Norris <[email protected]>
    Reviewed-by: Brian Norris <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

genirq/test: Select IRQ_DOMAIN [+ + +]
Author: Brian Norris <[email protected]>
Date:   Fri Aug 22 11:59:02 2025 -0700

    genirq/test: Select IRQ_DOMAIN
    
    [ Upstream commit f8a44f9babd054ff19e20a30cab661d716ad5459 ]
    
    These tests use irq_domain_alloc_descs() and so require CONFIG_IRQ_DOMAIN.
    
    Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts")
    Reported-by: Guenter Roeck <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
genirq: Add irq_chip_(startup/shutdown)_parent() [+ + +]
Author: Inochi Amaoto <[email protected]>
Date:   Thu Aug 14 07:28:31 2025 +0800

    genirq: Add irq_chip_(startup/shutdown)_parent()
    
    [ Upstream commit 7a721a2fee2bce01af26699a87739db8ca8ea3c8 ]
    
    As the MSI controller on SG2044 uses PLIC as the underlying interrupt
    controller, it needs to call irq_enable() and irq_disable() to
    startup/shutdown interrupts. Otherwise, the MSI interrupt can not be
    startup correctly and will not respond any incoming interrupt.
    
    Introduce irq_chip_startup_parent() and irq_chip_shutdown_parent() to allow
    the interrupt controller to call the irq_startup()/irq_shutdown() callbacks
    of the parent interrupt chip.
    
    In case the irq_startup()/irq_shutdown() callbacks are not implemented for
    the parent interrupt chip, this will fallback to irq_chip_enable_parent()
    or irq_chip_disable_parent().
    
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Inochi Amaoto <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Chen Wang <[email protected]> # Pioneerbox
    Reviewed-by: Chen Wang <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Stable-dep-of: 9d8c41816bac ("irqchip/sg2042-msi: Fix broken affinity setting")
    Signed-off-by: Sasha Levin <[email protected]>

 
gfs2: Add proper lockspace locking [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Mon Jul 7 14:31:41 2025 +0200

    gfs2: Add proper lockspace locking
    
    [ Upstream commit 6ab26555c9ffef96c56ca16356e55ac5ab61ec93 ]
    
    GFS2 has been calling functions like dlm_lock() even after the lockspace
    that these functions operate on has been released with
    dlm_release_lockspace().  It has always assumed that those functions
    would return -EINVAL in that case, but that was never guaranteed, and it
    certainly is no longer the case since commit 4db41bf4f04f ("dlm: remove
    ls_local_handle from struct dlm_ls").
    
    To fix that, add proper lockspace locking.
    
    Fixes: 3e11e5304150 ("GFS2: ignore unlock failures after withdraw")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: do_xmote cleanup [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Tue Jul 8 19:13:32 2025 +0200

    gfs2: do_xmote cleanup
    
    [ Upstream commit 2309a01351e56446f43c89e200d643647d47e739 ]
    
    Check for asynchronous completion and clear the GLF_PENDING_REPLY flag
    earlier in do_xmote().  This will make future changes more readable.
    
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Stable-dep-of: 6ab26555c9ff ("gfs2: Add proper lockspace locking")
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Fix GLF_INVALIDATE_IN_PROGRESS flag clearing in do_xmote [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Sat Aug 2 23:57:24 2025 +0200

    gfs2: Fix GLF_INVALIDATE_IN_PROGRESS flag clearing in do_xmote
    
    [ Upstream commit 061df28b82af6b22fb5fa529a8f2ef00474ee004 ]
    
    Commit 865cc3e9cc0b ("gfs2: fix a deadlock on withdraw-during-mount")
    added a statement to do_xmote() to clear the GLF_INVALIDATE_IN_PROGRESS
    flag a second time after it has already been cleared.  Fix that.
    
    Fixes: 865cc3e9cc0b ("gfs2: fix a deadlock on withdraw-during-mount")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Fix LM_FLAG_TRY* logic in add_to_queue [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Fri Aug 8 22:31:59 2025 +0200

    gfs2: Fix LM_FLAG_TRY* logic in add_to_queue
    
    [ Upstream commit 0c23e24164d83086e75581b0cf930f4e161636d6 ]
    
    The logic in add_to_queue() for determining whether a LM_FLAG_TRY or
    LM_FLAG_TRY_1CB holder should be queued does not make any sense: we are
    interested in wether or not the new operation will block behind an
    existing or future holder in the queue, but the current code checks for
    ongoing locking or ->go_inval() operations, which has little to do with
    that.
    
    Replace that code with something more sensible, remove the incorrect
    add_to_queue() function annotations, remove the similarly misguided
    do_error(gl, 0) call in do_xmote(), and add a missing comment to the
    same call in do_promote().
    
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS")
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Further sanitize lock_dlm.c [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Thu Aug 7 10:21:33 2025 +0200

    gfs2: Further sanitize lock_dlm.c
    
    [ Upstream commit fd70ab7155c4b92a9747d42c02791a0793ab9c66 ]
    
    The gl_req field and GLF_BLOCKING flag are only relevant to gdlm_lock(),
    its callback gdlm_ast(), and their helpers, so set and clear them inside
    lock_dlm.c.
    
    Also, the LM_FLAG_ANY flag is relevant to gdlm_lock(), but do_xmote()
    doesn't pass that flag down to gdlm_lock() as it should.  Fix that by
    passing down all the flags.
    
    In addition, document the effect of the LM_FLAG_ANY flag on locks held
    in EX mode locally.
    
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS")
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Fri Aug 8 23:26:12 2025 +0200

    gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS
    
    [ Upstream commit bddb53b776fb7ce81dfba7c24884d9f2c0c68e50 ]
    
    Get rid of the GLF_INVALIDATE_IN_PROGRESS flag: it was originally used
    to indicate to add_to_queue() that the ->go_sync() and ->go_invalid()
    operations were in progress, but as we have established in commit "gfs2:
    Fix LM_FLAG_TRY* logic in add_to_queue", add_to_queue() has no need to
    know.
    
    Commit d99724c3c36a describes a race in which GLF_INVALIDATE_IN_PROGRESS
    is used to serialize two processes which are both in do_xmote() at the
    same time.  That analysis is wrong: the serialization happens via the
    GLF_LOCK flag, which ensures that at most one glock operation can be
    active at any time.
    
    Fixes: d99724c3c36a ("gfs2: Close timing window with GLF_INVALIDATE_IN_PROGRESS")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Remove duplicate check in do_xmote [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Fri Aug 8 23:18:45 2025 +0200

    gfs2: Remove duplicate check in do_xmote
    
    [ Upstream commit 9b54770b68ae793a3a8d378be4cda2bb7be6c8cc ]
    
    In do_xmote(), remove the duplicate check for the ->go_sync and
    ->go_inval glock operations.  They are either both defined, or none of
    them are.
    
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS")
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Remove space before newline [+ + +]
Author: Colin Ian King <[email protected]>
Date:   Tue Jul 29 12:36:38 2025 +0100

    gfs2: Remove space before newline
    
    [ Upstream commit aa94ad9ab230d08741e6630a20fd1296b52c1009 ]
    
    There is an extraneous space before a newline in a fs_err message.
    Remove it
    
    Signed-off-by: Colin Ian King <[email protected]>
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Reviewed-by: Andrew Price <[email protected]>
    Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS")
    Signed-off-by: Sasha Levin <[email protected]>

 
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() [+ + +]
Author: Kang Chen <[email protected]>
Date:   Tue Sep 9 11:13:16 2025 +0800

    hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
    
    [ Upstream commit bea3e1d4467bcf292c8e54f080353d556d355e26 ]
    
    BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
    Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290
    
    CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0xca/0x5f0 mm/kasan/report.c:482
     kasan_report+0xca/0x100 mm/kasan/report.c:595
     hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
     hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738
     vfs_listxattr+0xbe/0x140 fs/xattr.c:493
     listxattr+0xee/0x190 fs/xattr.c:924
     filename_listxattr fs/xattr.c:958 [inline]
     path_listxattrat+0x143/0x360 fs/xattr.c:988
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fe0e9fae16d
    Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 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 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3
    RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000
    RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000
     </TASK>
    
    Allocated by task 14290:
     kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
     kasan_save_track+0x14/0x30 mm/kasan/common.c:68
     poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
     __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __do_kmalloc_node mm/slub.c:4333 [inline]
     __kmalloc_noprof+0x219/0x540 mm/slub.c:4345
     kmalloc_noprof include/linux/slab.h:909 [inline]
     hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
     hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697
     vfs_listxattr+0xbe/0x140 fs/xattr.c:493
     listxattr+0xee/0x190 fs/xattr.c:924
     filename_listxattr fs/xattr.c:958 [inline]
     path_listxattrat+0x143/0x360 fs/xattr.c:988
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    When hfsplus_uni2asc is called from hfsplus_listxattr,
    it actually passes in a struct hfsplus_attr_unistr*.
    The size of the corresponding structure is different from that of hfsplus_unistr,
    so the previous fix (94458781aee6) is insufficient.
    The pointer on the unicode buffer is still going beyond the allocated memory.
    
    This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and
    hfsplus_uni2asc_str to process two unicode buffers,
    struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.
    When ustrlen value is bigger than the allocated memory size,
    the ustrlen value is limited to an safe size.
    
    Fixes: 94458781aee6 ("hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()")
    Signed-off-by: Kang Chen <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: hidraw: tighten ioctl command parsing [+ + +]
Author: Benjamin Tissoires <[email protected]>
Date:   Fri Sep 12 18:58:51 2025 +0200

    HID: hidraw: tighten ioctl command parsing
    
    [ Upstream commit 75d5546f60b36900051d75ee623fceccbeb6750c ]
    
    The handling for variable-length ioctl commands in hidraw_ioctl() is
    rather complex and the check for the data direction is incomplete.
    
    Simplify this code by factoring out the various ioctls grouped by dir
    and size, and using a switch() statement with the size masked out, to
    ensure the rest of the command is correctly matched.
    
    Fixes: 9188e79ec3fd ("HID: add phys and name ioctls to hidraw")
    Reported-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: i2c-hid: Fix test in i2c_hid_core_register_panel_follower() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Aug 27 15:57:31 2025 +0300

    HID: i2c-hid: Fix test in i2c_hid_core_register_panel_follower()
    
    [ Upstream commit 5c76c794bf29399394ebacaa5af8436b8bed0d46 ]
    
    Bitwise AND was intended instead of OR.  With the current code the
    condition is always true.
    
    Fixes: cbdd16b818ee ("HID: i2c-hid: Make elan touch controllers power on after panel is enabled")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Reviewed-by: Pin-yen Lin <[email protected]>
    Acked-by: Jiri Kosina <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

HID: i2c-hid: Make elan touch controllers power on after panel is enabled [+ + +]
Author: Pin-yen Lin <[email protected]>
Date:   Mon Aug 18 19:49:34 2025 +0800

    HID: i2c-hid: Make elan touch controllers power on after panel is enabled
    
    [ Upstream commit cbdd16b818eef876dd2de9d503fe7397a0666cbe ]
    
    Introduce a new HID quirk to indicate that this device has to be enabled
    after the panel's backlight is enabled, and update the driver data for
    the elan devices to enable this quirk. This cannot be a I2C HID quirk
    because the kernel needs to acknowledge this before powering up the
    device and read the VID/PID. When this quirk is enabled, register
    .panel_enabled()/.panel_disabling() instead for the panel follower.
    
    Also rename the *panel_prepare* functions into *panel_follower* because
    they could be called in other situations now.
    
    Fixes: bd3cba00dcc63 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens")
    Fixes: d06651bebf99e ("HID: i2c-hid: elan: Add elan-ekth6a12nay timing")
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Pin-yen Lin <[email protected]>
    Acked-by: Jiri Kosina <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

HID: steelseries: Fix STEELSERIES_SRWS1 handling in steelseries_remove() [+ + +]
Author: Jiri Kosina <[email protected]>
Date:   Fri Sep 12 16:27:35 2025 +0200

    HID: steelseries: Fix STEELSERIES_SRWS1 handling in steelseries_remove()
    
    [ Upstream commit 2910913ef87dd9b9ce39e844c7295e1896b3b039 ]
    
    srws1_remove label can be only reached only if LEDS subsystem is enabled. To
    avoid putting horryfing ifdef second time around the label, just perform
    the cleanup and exit immediately directly.
    
    Fixes: a84eeacbf9325 ("HID: steelseries: refactor probe() and remove()")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: steelseries: refactor probe() and remove() [+ + +]
Author: Jeongjun Park <[email protected]>
Date:   Thu Jul 17 20:26:43 2025 +0900

    HID: steelseries: refactor probe() and remove()
    
    [ Upstream commit a84eeacbf9325fd7f604b80f246aaba157730cd5 ]
    
    steelseries_srws1_probe() still does not use devm_kzalloc() and
    devm_led_classdev_register(), so there is a lot of code to safely manage
    heap, which reduces readability and may cause memory leaks due to minor
    patch mistakes in the future.
    
    Therefore, it should be changed to use devm_kzalloc() and
    devm_led_classdev_register() to easily and safely manage heap.
    
    Also, the current steelseries driver mainly checks sd->quriks to determine
    which product a specific HID device is, which is not the correct way.
    
    remove(), unlike probe(), does not receive struct hid_device_id as an
    argument, so it must check hdev unconditionally to know which product
    it is.
    
    However, since struct steelseries_device and struct steelseries_srws1_data
    have different structures, if SRWS1 is removed in remove(), converts
    hdev->dev, which is initialized to struct steelseries_srws1_data,
    to struct steelseries_device and uses it. This causes various
    memory-related bugs as completely unexpected values exist in member
    variables of the structure.
    
    Therefore, in order to modify probe() and remove() to work properly,
    Arctis 1, 9 should be added to HID_USB_DEVICE and some functions should be
    modified to check hdev->product when determining HID device product.
    
    Fixes: a0c76896c3fb ("HID: steelseries: Add support for Arctis 1 XBox")
    Signed-off-by: Jeongjun Park <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hisi_acc_vfio_pci: Fix reference leak in hisi_acc_vfio_debug_init [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Mon Sep 1 16:18:08 2025 +0800

    hisi_acc_vfio_pci: Fix reference leak in hisi_acc_vfio_debug_init
    
    commit eaba58355ecd124b4a8c91df7335970ad9fe2624 upstream.
    
    The debugfs_lookup() function returns a dentry with an increased reference
    count that must be released by calling dput().
    
    Fixes: b398f91779b8 ("hisi_acc_vfio_pci: register debugfs for hisilicon migration driver")
    Cc: [email protected]
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Longfang Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwmon: (asus-ec-sensors) Narrow lock for X870E-CREATOR WIFI [+ + +]
Author: Eugene Shalygin <[email protected]>
Date:   Tue Aug 5 22:31:48 2025 +0200

    hwmon: (asus-ec-sensors) Narrow lock for X870E-CREATOR WIFI
    
    [ Upstream commit 3aa72cf03924d04c8d20f8b319df8f73550dd26c ]
    
    Use mutex from the SIO device rather than the global lock.
    
    Signed-off-by: Eugene Shalygin <[email protected]>
    
    Fixes: 3e538b52157b ("hwmon: (asus-ec-sensors) add ProArt X870E-CREATOR WIFI")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (mlxreg-fan) Separate methods of fan setting coming from different subsystems [+ + +]
Author: Vadim Pasternak <[email protected]>
Date:   Mon Jan 13 10:48:58 2025 +0200

    hwmon: (mlxreg-fan) Separate methods of fan setting coming from different subsystems
    
    [ Upstream commit c02e4644f8ac9c501077ef5ac53ae7fc51472d49 ]
    
    Distinct between fan speed setting request coming for hwmon and
    thermal subsystems.
    
    There are fields 'last_hwmon_state' and 'last_thermal_state' in the
    structure 'mlxreg_fan_pwm', which respectively store the cooling state
    set by the 'hwmon' and 'thermal' subsystem.
    The purpose is to make arbitration of fan speed setting. For example, if
    fan speed required to be not lower than some limit, such setting is to
    be performed through 'hwmon' subsystem, thus 'thermal' subsystem will
    not set fan below this limit.
    
    Currently, the 'last_thermal_state' is also be updated by 'hwmon' causing
    cooling state to never be set to a lower value.
    
    Eliminate update of 'last_thermal_state', when request is coming from
    'hwmon' subsystem.
    
    Fixes: da74944d3a46 ("hwmon: (mlxreg-fan) Use pwm attribute for setting fan speed low limit")
    Signed-off-by: Vadim Pasternak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwrng: ks-sa - fix division by zero in ks_sa_rng_init [+ + +]
Author: Nishanth Menon <[email protected]>
Date:   Fri Sep 19 08:20:02 2025 -0500

    hwrng: ks-sa - fix division by zero in ks_sa_rng_init
    
    [ Upstream commit 612b1dfeb414dfa780a6316014ceddf9a74ff5c0 ]
    
    Fix division by zero in ks_sa_rng_init caused by missing clock
    pointer initialization. The clk_get_rate() call is performed on
    an uninitialized clk pointer, resulting in division by zero when
    calculating delay values.
    
    Add clock initialization code before using the clock.
    
    Fixes: 6d01d8511dce ("hwrng: ks-sa - Add minimum sleep time before ready-polling")
    Signed-off-by: Nishanth Menon <[email protected]>
    
     drivers/char/hw_random/ks-sa-rng.c | 7 +++++++
     1 file changed, 7 insertions(+)
    Reviewed-by: Alexander Sverdlin <[email protected]>
    
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwrng: nomadik - add ARM_AMBA dependency [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Jul 29 17:28:00 2025 +0200

    hwrng: nomadik - add ARM_AMBA dependency
    
    [ Upstream commit efaa2d815a0e4d1c06750e587100f6f7f4ee5497 ]
    
    Compile-testing this driver is only possible when the AMBA bus driver is
    available in the kernel:
    
    x86_64-linux-ld: drivers/char/hw_random/nomadik-rng.o: in function `nmk_rng_remove':
    nomadik-rng.c:(.text+0x67): undefined reference to `amba_release_regions'
    x86_64-linux-ld: drivers/char/hw_random/nomadik-rng.o: in function `nmk_rng_probe':
    nomadik-rng.c:(.text+0xee): undefined reference to `amba_request_regions'
    x86_64-linux-ld: nomadik-rng.c:(.text+0x18d): undefined reference to `amba_release_regions'
    
    The was previously implied by the 'depends on ARCH_NOMADIK', but needs to be
    specified for the COMPILE_TEST case.
    
    Fixes: d5e93b3374e4 ("hwrng: Kconfig - Add helper dependency on COMPILE_TEST")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c: designware: Add disabling clocks when probe fails [+ + +]
Author: Kunihiko Hayashi <[email protected]>
Date:   Thu Jul 24 13:22:11 2025 +0900

    i2c: designware: Add disabling clocks when probe fails
    
    [ Upstream commit c149841b069ccc6e480b00e11f35a57b5d88c7bb ]
    
    After an error occurs during probing state, dw_i2c_plat_pm_cleanup() is
    called. However, this function doesn't disable clocks and the clock-enable
    count keeps increasing. Should disable these clocks explicitly.
    
    Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM")
    Co-developed-by: Kohei Ito <[email protected]>
    Signed-off-by: Kohei Ito <[email protected]>
    Signed-off-by: Kunihiko Hayashi <[email protected]>
    Acked-by: Jarkko Nikula <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: designware: Fix clock issue when PM is disabled [+ + +]
Author: Kunihiko Hayashi <[email protected]>
Date:   Thu Jul 24 13:22:10 2025 +0900

    i2c: designware: Fix clock issue when PM is disabled
    
    [ Upstream commit 70e633bedeeb4a7290d3b1dd9d49cc2bae25a46f ]
    
    When the driver is removed, the clocks are first enabled by
    calling pm_runtime_get_sync(), and then disabled with
    pm_runtime_put_sync().
    
    If CONFIG_PM=y, clocks for this controller are disabled when it's in
    the idle state. So the clocks are properly disabled when the driver
    exits.
    
    Othewise, the clocks are always enabled and the PM functions have
    no effect. Therefore, the driver exits without disabling the clocks.
    
        # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count
        18
        # echo 1214a000.i2c > /sys/bus/platform/drivers/i2c_designware/bind
        # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count
        20
        # echo 1214a000.i2c > /sys/bus/platform/drivers/i2c_designware/unbind
        # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count
        20
    
    To ensure that the clocks can be disabled correctly even without
    CONFIG_PM=y, should add the following fixes:
    
    - Replace with pm_runtime_put_noidle(), which only decrements the runtime
      PM usage count.
    - Call i2c_dw_prepare_clk(false) to explicitly disable the clocks.
    
    Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM")
    Co-developed-by: Kohei Ito <[email protected]>
    Signed-off-by: Kohei Ito <[email protected]>
    Signed-off-by: Kunihiko Hayashi <[email protected]>
    Tested-by: Jarkko Nikula <[email protected]>
    Acked-by: Jarkko Nikula <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD [+ + +]
Author: Leilk.Liu <[email protected]>
Date:   Sat Sep 6 16:24:06 2025 +0800

    i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD
    
    [ Upstream commit b492183652808e0f389272bf63dc836241b287ff ]
    
    The old IC does not support the I2C_MASTER_WRRD (write-then-read)
    function, but the current code’s handling of i2c->auto_restart may
    potentially lead to entering the I2C_MASTER_WRRD software flow,
    resulting in unexpected bugs.
    
    Instead of repurposing the auto_restart flag, add a separate flag
    to signal I2C_MASTER_WRRD operations.
    
    Also fix handling of msgs. If the operation (i2c->op) is
    I2C_MASTER_WRRD, then the msgs pointer is incremented by 2.
    For all other operations, msgs is simply incremented by 1.
    
    Fixes: b2ed11e224a2 ("I2C: mediatek: Add driver for MediaTek MT8173 I2C controller")
    Signed-off-by: Leilk.Liu <[email protected]>
    Suggested-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: spacemit: check SDA instead of SCL after bus reset [+ + +]
Author: Troy Mitchell <[email protected]>
Date:   Thu Sep 25 10:02:28 2025 +0800

    i2c: spacemit: check SDA instead of SCL after bus reset
    
    [ Upstream commit db7720ef50e0103be70a3887bc66e9c909933ad9 ]
    
    After calling spacemit_i2c_conditionally_reset_bus(),
    the controller should ensure that the SDA line is release
    before proceeding.
    
    Previously, the driver checked the SCL line instead,
    which does not guarantee that the bus is truly idle.
    
    This patch changes the check to verify SDA. This ensures
    proper bus recovery and avoids potential communication errors
    after a conditional reset.
    
    Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
    Reviewed-by: Aurelien Jarno <[email protected]>
    Signed-off-by: Troy Mitchell <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: spacemit: disable SDA glitch fix to avoid restart delay [+ + +]
Author: Troy Mitchell <[email protected]>
Date:   Thu Sep 25 10:02:27 2025 +0800

    i2c: spacemit: disable SDA glitch fix to avoid restart delay
    
    [ Upstream commit 11f40684ccd84e792eced110f0a5d3d6adbdf90d ]
    
    The K1 I2C controller has an SDA glitch fix that introduces a small
    delay on restart signals. While this feature can suppress glitches
    on SDA when SCL = 0, it also delays the restart signal, which may
    cause unexpected behavior in some transfers.
    
    The glitch itself does not affect normal I2C operation, because
    the I2C specification allows SDA to change while SCL is low.
    
    To ensure correct transmission for every message, we disable the
    SDA glitch fix by setting the RCR.SDA_GLITCH_NOFIX bit during
    initialization.
    
    This guarantees that restarts are issued promptly without
    unintended delays.
    
    Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
    Reviewed-by: Aurelien Jarno <[email protected]>
    Signed-off-by: Troy Mitchell <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: spacemit: ensure bus release check runs when wait_bus_idle() fails [+ + +]
Author: Troy Mitchell <[email protected]>
Date:   Thu Sep 25 10:02:25 2025 +0800

    i2c: spacemit: ensure bus release check runs when wait_bus_idle() fails
    
    [ Upstream commit 41d6f90ef5dc2841bdd09817c63a3d6188473b9b ]
    
    spacemit_i2c_wait_bus_idle() only returns 0 on success or a negative
    error code on failure.
    
    Since 'ret' can never be positive, the final 'else' branch was
    unreachable, and spacemit_i2c_check_bus_release() was never called.
    
    This commit guarantees we attempt to release the bus whenever waiting for
    an idle bus fails.
    
    Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
    Reviewed-by: Aurelien Jarno <[email protected]>
    Signed-off-by: Troy Mitchell <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: spacemit: ensure SDA is released after bus reset [+ + +]
Author: Troy Mitchell <[email protected]>
Date:   Thu Sep 25 10:02:29 2025 +0800

    i2c: spacemit: ensure SDA is released after bus reset
    
    [ Upstream commit 0de61943244dec418d396633a587adca1c350b55 ]
    
    After performing a conditional bus reset, the controller must ensure
    that the SDA line is actually released.
    
    Previously, the reset routine only performed a single check,
    which could leave the bus in a locked state in some situations.
    
    This patch introduces a loop that toggles the reset cycle and issues
    a reset request up to SPACEMIT_BUS_RESET_CLK_CNT_MAX times, checking
    SDA after each attempt. If SDA is released before the maximum count,
    the function returns early. Otherwise, a warning is emitted.
    
    This change improves bus recovery reliability.
    
    Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
    Signed-off-by: Troy Mitchell <[email protected]>
    Reviewed-by: Aurelien Jarno <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: spacemit: remove stop function to avoid bus error [+ + +]
Author: Troy Mitchell <[email protected]>
Date:   Thu Sep 25 10:02:26 2025 +0800

    i2c: spacemit: remove stop function to avoid bus error
    
    [ Upstream commit 445522fe7aad6131b2747ae8c76f77266054cd84 ]
    
    Previously, STOP handling was split into two separate steps:
      1) clear TB/STOP/START/ACK bits
      2) issue STOP by calling spacemit_i2c_stop()
    
    This left a small window where the control register was updated
    twice, which can confuse the controller. While this race has not
    been observed with interrupt-driven transfers, it reliably causes
    bus errors in PIO mode.
    
    Inline the STOP sequence into the IRQ handler and ensure that
    control register bits are updated atomically in a single writel().
    
    Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
    Signed-off-by: Troy Mitchell <[email protected]>
    Reviewed-by: Aurelien Jarno <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i3c: fix big-endian FIFO transfers [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Sep 24 22:18:33 2025 +0200

    i3c: fix big-endian FIFO transfers
    
    [ Upstream commit d6ddd9beb1a5c32acb9b80f5c2cd8b17f41371d1 ]
    
    Short MMIO transfers that are not a multiple of four bytes in size need
    a special case for the final bytes, however the existing implementation
    is not endian-safe and introduces an incorrect byteswap on big-endian
    kernels.
    
    This usually does not cause problems because most systems are
    little-endian and most transfers are multiple of four bytes long, but
    still needs to be fixed to avoid the extra byteswap.
    
    Change the special case for both i3c_writel_fifo() and i3c_readl_fifo()
    to use non-byteswapping writesl() and readsl() with a single element
    instead of the byteswapping writel()/readl() that are meant for individual
    MMIO registers. As data is copied between a FIFO and a memory buffer,
    the writesl()/readsl() loops are typically based on __raw_readl()/
    __raw_writel(), resulting in the order of bytes in the FIFO to match
    the order in the buffer, regardless of the CPU endianess.
    
    The earlier versions in the dw-i3c and i3c-master-cdns had a correct
    implementation, but the generic version that was recently added broke it.
    
    Fixes: 733b439375b4 ("i3c: master: Add inline i3c_readl_fifo() and i3c_writel_fifo()")
    Cc: Manikanta Guntupalli <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Jorge Marques <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i3c: master: svc: Recycle unused IBI slot [+ + +]
Author: Stanley Chu <[email protected]>
Date:   Fri Aug 29 09:23:09 2025 +0800

    i3c: master: svc: Recycle unused IBI slot
    
    [ Upstream commit 3448a934ba6f803911ac084d05a2ffce507ea6c6 ]
    
    In svc_i3c_master_handle_ibi(), an IBI slot is fetched from the pool
    to store the IBI payload. However, when an error condition is encountered,
    the function returns without recycling the IBI slot, resulting in an IBI
    slot leak.
    
    Fixes: c85e209b799f ("i3c: master: svc: fix ibi may not return mandatory data byte")
    Signed-off-by: Stanley Chu <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i3c: master: svc: Use manual response for IBI events [+ + +]
Author: Stanley Chu <[email protected]>
Date:   Fri Aug 29 09:23:08 2025 +0800

    i3c: master: svc: Use manual response for IBI events
    
    [ Upstream commit a7869b0a2540fd122eccec00ae7d4243166b0a60 ]
    
    Driver wants to nack the IBI request when the target is not in the
    known address list. In below code, svc_i3c_master_nack_ibi() will
    cause undefined behavior when using AUTOIBI with auto response rule,
    because hw always auto ack the IBI request.
    
        switch (ibitype) {
        case SVC_I3C_MSTATUS_IBITYPE_IBI:
                dev = svc_i3c_master_dev_from_addr(master, ibiaddr);
                if (!dev || !is_events_enabled(master, SVC_I3C_EVENT_IBI))
                        svc_i3c_master_nack_ibi(master);
                ...
                break;
    
    AutoIBI has another issue that the controller doesn't quit AutoIBI state
    after IBIWON polling timeout when there is a SDA glitch(high->low->high).
    1. SDA high->low: raising an interrupt to execute IBI ISR
    2. SDA low->high
    3. Driver writes an AutoIBI request
    4. AutoIBI process does not start because SDA is not low
    5. IBIWON polling times out
    6. Controller reamins in AutoIBI state and doesn't accept EmitStop request
    
    Emitting broadcast address with IBIRESP_MANUAL avoids both issues.
    
    Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver")
    Signed-off-by: Stanley Chu <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
IB/sa: Fix sa_local_svc_timeout_ms read race [+ + +]
Author: Vlad Dumitrescu <[email protected]>
Date:   Tue Sep 16 19:31:12 2025 +0300

    IB/sa: Fix sa_local_svc_timeout_ms read race
    
    [ Upstream commit 1428cd764cd708d53a072a2f208d87014bfe05bc ]
    
    When computing the delta, the sa_local_svc_timeout_ms is read without
    ib_nl_request_lock held. Though unlikely in practice, this can cause
    a race condition if multiple local service threads are managing the
    timeout.
    
    Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink")
    Signed-off-by: Vlad Dumitrescu <[email protected]>
    Reviewed-by: Mark Zhang <[email protected]>
    Signed-off-by: Edward Srouji <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
idpf: fix mismatched free function for dma_alloc_coherent [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Thu Sep 25 11:02:10 2025 -0700

    idpf: fix mismatched free function for dma_alloc_coherent
    
    [ Upstream commit b9bd25f47eb79c9eb275e3d9ac3983dc88577dd4 ]
    
    The mailbox receive path allocates coherent DMA memory with
    dma_alloc_coherent(), but frees it with dmam_free_coherent().
    This is incorrect since dmam_free_coherent() is only valid for
    buffers allocated with dmam_alloc_coherent().
    
    Fix the mismatch by using dma_free_coherent() instead of
    dmam_free_coherent
    
    Fixes: e54232da1238 ("idpf: refactor idpf_recv_mb_msg")
    Signed-off-by: Alok Tiwari <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Reviewed-by: Madhu Chittim <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

idpf: fix Rx descriptor ready check barrier in splitq [+ + +]
Author: Alexander Lobakin <[email protected]>
Date:   Tue Aug 26 17:54:56 2025 +0200

    idpf: fix Rx descriptor ready check barrier in splitq
    
    [ Upstream commit c20edbacc0295fd36f5f634b3421647ce3e08fd7 ]
    
    No idea what the current barrier position was meant for. At that point,
    nothing is read from the descriptor, only the pointer to the actual one
    is fetched.
    The correct barrier usage here is after the generation check, so that
    only the first qword is read if the descriptor is not yet ready and we
    need to stop polling. Debatable on coherent DMA as the Rx descriptor
    size is <= cacheline size, but anyway, the current barrier position
    only makes the codegen worse.
    
    Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
    Reviewed-by: Maciej Fijalkowski <[email protected]>
    Signed-off-by: Alexander Lobakin <[email protected]>
    Tested-by: Ramu R <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: consumers: Fix handling of negative channel scale in iio_convert_raw_to_processed() [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sun Aug 31 12:48:20 2025 +0200

    iio: consumers: Fix handling of negative channel scale in iio_convert_raw_to_processed()
    
    [ Upstream commit 0f85406bf830eb8747dd555ab53c9d97ee4af293 ]
    
    There is an issue with the handling of negative channel scales
    in iio_convert_raw_to_processed_unlocked() when the channel-scale
    is of the IIO_VAL_INT_PLUS_[MICRO|NANO] type:
    
    Things work for channel-scale values > -1.0 and < 0.0 because of
    the use of signed values in:
    
            *processed += div_s64(raw64 * (s64)scale_val2 * scale, 1000000LL);
    
    Things will break however for scale values < -1.0. Lets for example say
    that raw = 2, (caller-provided)scale = 10 and (channel)scale_val = -1.5.
    
    The result should then be 2 * 10 * -1.5 = -30.
    
    channel-scale = -1.5 means scale_val = -1 and scale_val2 = 500000,
    now lets see what gets stored in processed:
    
    1. *processed = raw64 * scale_val * scale;
    2. *processed += raw64 * scale_val2 * scale / 1000000LL;
    
    1. Sets processed to 2 * -1 * 10 = -20
    2. Adds 2 * 500000 * 10 / 1000000 = 10 to processed
    
    And the end result is processed = -20 + 10 = -10, which is not correct.
    
    Fix this by always using the abs value of both scale_val and scale_val2
    and if either is negative multiply the end-result by -1.
    
    Note there seems to be an unwritten rule about negative
    IIO_VAL_INT_PLUS_[MICRO|NANO] values that:
    
    i.   values > -1.0 and < 0.0 are written as val=0 val2=-xxx
    ii.  values <= -1.0 are written as val=-xxx val2=xxx
    
    But iio_format_value() will also correctly display a third option:
    
    iii. values <= -1.0 written as val=-xxx val2=-xxx
    
    Since iio_format_value() uses abs(val) when val2 < 0.
    
    This fix also makes iio_convert_raw_to_processed() properly handle
    channel-scales using this third option.
    
    Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value")
    Cc: Matteo Martelli <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: consumers: Fix offset handling in iio_convert_raw_to_processed() [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sun Aug 31 12:48:21 2025 +0200

    iio: consumers: Fix offset handling in iio_convert_raw_to_processed()
    
    [ Upstream commit 33f5c69c4daff39c010b3ea6da8ebab285f4277b ]
    
    Fix iio_convert_raw_to_processed() offset handling for channels without
    a scale attribute.
    
    The offset has been applied to the raw64 value not to the original raw
    value. Use the raw64 value so that the offset is taken into account.
    
    Fixes: 14b457fdde38 ("iio: inkern: apply consumer scale when no channel scale is available")
    Cc: Liam Beguin <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
inet: ping: check sock_net() in ping_get_port() and ping_lookup() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Aug 29 15:30:51 2025 +0000

    inet: ping: check sock_net() in ping_get_port() and ping_lookup()
    
    [ Upstream commit 59f26d86b2a16f1406f3b42025062b6d1fba5dd5 ]
    
    We need to check socket netns before considering them in ping_get_port().
    Otherwise, one malicious netns could 'consume' all ports.
    
    Add corresponding check in ping_lookup().
    
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Reviewed-by: Yue Haibing <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
init: INITRAMFS_PRESERVE_MTIME should depend on BLK_DEV_INITRD [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Sep 15 09:11:05 2025 +0200

    init: INITRAMFS_PRESERVE_MTIME should depend on BLK_DEV_INITRD
    
    [ Upstream commit 74792608606a525a0e0df7e8d48acd8000561389 ]
    
    INITRAMFS_PRESERVE_MTIME is only used in init/initramfs.c and
    init/initramfs_test.c.  Hence add a dependency on BLK_DEV_INITRD, to
    prevent asking the user about this feature when configuring a kernel
    without initramfs support.
    
    Fixes: 1274aea127b2e8c9 ("initramfs: add INITRAMFS_PRESERVE_MTIME Kconfig option")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Martin Wilck <[email protected]>
    Reviewed-by: David Disseldorp <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: atmel_mxt_ts - allow reset GPIO to sleep [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Sun Oct 5 04:33:10 2025 +0200

    Input: atmel_mxt_ts - allow reset GPIO to sleep
    
    commit c7866ee0a9ddd9789faadf58cdac6abd7aabf045 upstream.
    
    The reset GPIO is not toggled in any critical section where it couldn't
    sleep, allow the reset GPIO to sleep. This allows the driver to operate
    reset GPIOs connected to I2C GPIO expanders.
    
    Signed-off-by: Marek Vasut <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak [+ + +]
Author: Zhen Ni <[email protected]>
Date:   Sun Sep 28 14:37:37 2025 +0800

    Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
    
    commit d3366a04770eea807f2826cbdb96934dd8c9bf79 upstream.
    
    Struct ff_effect_compat is embedded twice inside
    uinput_ff_upload_compat, contains internal padding. In particular, there
    is a hole after struct ff_replay to satisfy alignment requirements for
    the following union member. Without clearing the structure,
    copy_to_user() may leak stack data to userspace.
    
    Initialize ff_up_compat to zero before filling valid fields.
    
    Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput")
    Cc: [email protected]
    Signed-off-by: Zhen Ni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/waitid: always prune wait queue entry in io_waitid_wait() [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Tue Oct 7 07:46:00 2025 -0600

    io_uring/waitid: always prune wait queue entry in io_waitid_wait()
    
    commit 2f8229d53d984c6a05b71ac9e9583d4354e3b91f upstream.
    
    For a successful return, always remove our entry from the wait queue
    entry list. Previously this was skipped if a cancelation was in
    progress, but this can race with another invocation of the wait queue
    entry callback.
    
    Cc: [email protected]
    Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support")
    Reported-by: [email protected]
    Tested-by: [email protected]
    Link: https://lore.kernel.org/io-uring/[email protected]/
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/zcrx: fix overshooting recv limit [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Wed Oct 8 13:38:06 2025 +0100

    io_uring/zcrx: fix overshooting recv limit
    
    commit 09cfd3c52ea76f43b3cb15e570aeddf633d65e80 upstream.
    
    It's reported that sometimes a zcrx request can receive more than was
    requested. It's caused by io_zcrx_recv_skb() adjusting desc->count for
    all received buffers including frag lists, but then doing recursive
    calls to process frag list skbs, which leads to desc->count double
    accounting and underflow.
    
    Reported-and-tested-by: Matthias Jasny <[email protected]>
    Fixes: 6699ec9a23f85 ("io_uring/zcrx: add a read limit to recvzc requests")
    Cc: [email protected]
    Signed-off-by: Pavel Begunkov <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iommu/selftest: prevent use of uninitialized variable [+ + +]
Author: Alessandro Zanni <[email protected]>
Date:   Wed Sep 24 19:16:28 2025 +0200

    iommu/selftest: prevent use of uninitialized variable
    
    [ Upstream commit 1d235d8494259b588bc3b7d29bc73ce34bf885bc ]
    
    Fix to avoid the usage of the `res` variable uninitialized in the
    following macro expansions.
    
    It solves the following warning:
    In function ‘iommufd_viommu_vdevice_alloc’,
      inlined from ‘wrapper_iommufd_viommu_vdevice_alloc’ at iommufd.c:2889:1:
    ../kselftest_harness.h:760:12: warning: ‘ret’ may be used uninitialized [-Wmaybe-uninitialized]
      760 |   if (!(__exp _t __seen)) { \
          |      ^
    ../kselftest_harness.h:513:9: note: in expansion of macro ‘__EXPECT’
      513 |   __EXPECT(expected, #expected, seen, #seen, ==, 1)
          |   ^~~~~~~~
    iommufd_utils.h:1057:9: note: in expansion of macro ‘ASSERT_EQ’
     1057 |   ASSERT_EQ(0, _test_cmd_trigger_vevents(self->fd, dev_id, nvevents))
          |   ^~~~~~~~~
    iommufd.c:2924:17: note: in expansion of macro ‘test_cmd_trigger_vevents’
     2924 |   test_cmd_trigger_vevents(dev_id, 3);
          |   ^~~~~~~~~~~~~~~~~~~~~~~~
    
    The issue can be reproduced, building the tests, with the command: make -C
    tools/testing/selftests TARGETS=iommu
    
    Link: https://patch.msgid.link/r/[email protected]
    Fixes: 97717a1f283f ("iommufd/selftest: Add IOMMU_VEVENTQ_ALLOC test coverage")
    Signed-off-by: Alessandro Zanni <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/vt-d: debugfs: Fix legacy mode page table dump logic [+ + +]
Author: Vineeth Pillai (Google) <[email protected]>
Date:   Thu Sep 18 13:01:59 2025 +0800

    iommu/vt-d: debugfs: Fix legacy mode page table dump logic
    
    [ Upstream commit fbe6070c73badca726e4ff7877320e6c62339917 ]
    
    In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR
    maybe uninitialized or zero in that case and may cause oops like:
    
     Oops: general protection fault, probably for non-canonical address
           0xf00087d3f000f000: 0000 [#1] SMP NOPTI
     CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014
     RIP: 0010:pgtable_walk_level+0x98/0x150
     RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206
     RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e
     RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000
     RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002
     R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000
     R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98
     FS:  0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0
     PKRU: 55555554
     Call Trace:
      <TASK>
      pgtable_walk_level+0x88/0x150
      domain_translation_struct_show.isra.0+0x2d9/0x300
      dev_domain_translation_struct_show+0x20/0x40
      seq_read_iter+0x12d/0x490
    ...
    
    Avoid walking the page table if TT is not 00b or 01b.
    
    Fixes: 2b437e804566 ("iommu/vt-d: debugfs: Support dumping a specified page table")
    Signed-off-by: Vineeth Pillai (Google) <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lu Baolu <[email protected]>
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iommu/vt-d: Disallow dirty tracking if incoherent page walk [+ + +]
Author: Lu Baolu <[email protected]>
Date:   Fri Sep 26 10:41:30 2025 +0800

    iommu/vt-d: Disallow dirty tracking if incoherent page walk
    
    [ Upstream commit 57f55048e564dedd8a4546d018e29d6bbfff0a7e ]
    
    Dirty page tracking relies on the IOMMU atomically updating the dirty bit
    in the paging-structure entry. For this operation to succeed, the paging-
    structure memory must be coherent between the IOMMU and the CPU. In
    another word, if the iommu page walk is incoherent, dirty page tracking
    doesn't work.
    
    The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:
    
    "Remapping hardware encountering the need to atomically update A/EA/D bits
     in a paging-structure entry that is not snooped will result in a non-
     recoverable fault."
    
    To prevent an IOMMU from being incorrectly configured for dirty page
    tracking when it is operating in an incoherent mode, mark SSADS as
    supported only when both ecap_slads and ecap_smpwc are supported.
    
    Fixes: f35f22cc760e ("iommu/vt-d: Access/Dirty bit support for SS domains")
    Signed-off-by: Lu Baolu <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommufd: Register iommufd mock devices with fwspec [+ + +]
Author: Guixin Liu <[email protected]>
Date:   Thu Sep 25 13:47:30 2025 +0800

    iommufd: Register iommufd mock devices with fwspec
    
    [ Upstream commit 2a918911ed3d0841923525ed0fe707762ee78844 ]
    
    Since the bus ops were retired the iommu subsystem changed to using fwspec
    to match the iommu driver to the iommu device. If a device has a NULL
    fwspec then it is matched to the first iommu driver with a NULL fwspec,
    effectively disabling support for systems with more than one non-fwspec
    iommu driver.
    
    Thus, if the iommufd selfest are run in an x86 system that registers a
    non-fwspec iommu driver they fail to bind their mock devices to the mock
    iommu driver.
    
    Fix this by allocating a software fwnode for mock iommu driver's
    iommu_device, and set it to the device which mock iommu driver created.
    
    This is done by adding a new helper iommu_mock_device_add() which abuses
    the internals of the fwspec system to establish a fwspec before the device
    is added and is careful not to leak it. A matching dummy fwspec is
    automatically added to the mock iommu driver.
    
    Test by "make -C toosl/testing/selftests TARGETS=iommu run_tests":
    PASSED: 229 / 229 tests passed.
    
    In addition, this issue is also can be found on amd platform, and
    also tested on a amd machine.
    
    Link: https://patch.msgid.link/r/[email protected]
    Fixes: 17de3f5fdd35 ("iommu: Retire bus ops")
    Signed-off-by: Guixin Liu <[email protected]>
    Reviewed-by: Lu Baolu <[email protected]>
    Tested-by: Qinyun Tan <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv4: start using dst_dev_rcu() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:23 2025 +0000

    ipv4: start using dst_dev_rcu()
    
    [ Upstream commit 6ad8de3cefdb6ffa6708b21c567df0dbf82c43a8 ]
    
    Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.
    
    Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),
    ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: mcast: Add ip6_mc_find_idev() helper [+ + +]
Author: Yue Haibing <[email protected]>
Date:   Fri Aug 22 14:40:51 2025 +0800

    ipv6: mcast: Add ip6_mc_find_idev() helper
    
    [ Upstream commit 60c481d4caa569001c708d4e9622d19650b6bedc ]
    
    Extract the same code logic from __ipv6_sock_mc_join() and
    ip6_mc_find_dev(), also add new helper ip6_mc_find_idev() to
    reduce redundancy and enhance readability.
    
    No functional changes intended.
    
    Signed-off-by: Yue Haibing <[email protected]>
    Reviewed-by: Dawid Osuchowski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: b775ecf1655c ("ipv6: start using dst_dev_rcu()")
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: snmp: do not track per idev ICMP6_MIB_RATELIMITHOST [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 5 16:58:07 2025 +0000

    ipv6: snmp: do not track per idev ICMP6_MIB_RATELIMITHOST
    
    [ Upstream commit 2fab94bcf313480336b0a41eb45a24ffd5087490 ]
    
    Blamed commit added a critical false sharing on a single
    atomic_long_t under DOS, like receiving UDP packets
    to closed ports.
    
    Per netns ICMP6_MIB_RATELIMITHOST tracking uses per-cpu
    storage and is enough, we do not need per-device and slow tracking.
    
    Fixes: d0941130c9351 ("icmp: Add counters for rate limits")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Jamie Bainbridge <[email protected]>
    Cc: Abhishek Rawal <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: snmp: do not use SNMP_MIB_SENTINEL anymore [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 5 16:58:06 2025 +0000

    ipv6: snmp: do not use SNMP_MIB_SENTINEL anymore
    
    [ Upstream commit ceac1fb2290d230eb83aff3761058c559440de13 ]
    
    Use ARRAY_SIZE(), so that we know the limit at compile time.
    
    Following patch needs this preliminary change.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 2fab94bcf313 ("ipv6: snmp: do not track per idev ICMP6_MIB_RATELIMITHOST")
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: start using dst_dev_rcu() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:17 2025 +0000

    ipv6: start using dst_dev_rcu()
    
    [ Upstream commit b775ecf1655cedbc465fd6699ab18a2bc4e7a352 ]
    
    Refactor icmpv6_xrlim_allow() and ip6_dst_hoplimit()
    so that we acquire rcu_read_lock() a bit longer
    to be able to use dst_dev_rcu() instead of dst_dev().
    
    __ip6_rt_update_pmtu() and rt6_do_redirect can directly
    use dst_dev_rcu() in sections already holding rcu_read_lock().
    
    Small changes to use dst_dev_net_rcu() in
    ip6_default_advmss(), ipv6_sock_ac_join(),
    ip6_mc_find_dev() and ndisc_send_skb().
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: use RCU in ip6_output() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:19 2025 +0000

    ipv6: use RCU in ip6_output()
    
    [ Upstream commit 11709573cc4e48dc34c80fc7ab9ce5b159e29695 ]
    
    Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent
    possible UAF.
    
    We can remove rcu_read_lock()/rcu_read_unlock() pairs
    from ip6_finish_output2().
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: use RCU in ip6_xmit() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:18 2025 +0000

    ipv6: use RCU in ip6_xmit()
    
    [ Upstream commit 9085e56501d93af9f2d7bd16f7fcfacdde47b99c ]
    
    Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent
    possible UAF.
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipvs: Defer ip_vs_ftp unregister during netns cleanup [+ + +]
Author: Slavin Liu <[email protected]>
Date:   Fri Sep 12 01:57:59 2025 +0800

    ipvs: Defer ip_vs_ftp unregister during netns cleanup
    
    [ Upstream commit 134121bfd99a06d44ef5ba15a9beb075297c0821 ]
    
    On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp
    before connections with valid cp->app pointers are flushed, leading to a
    use-after-free.
    
    Fix this by introducing a global `exiting_module` flag, set to true in
    ip_vs_ftp_exit() before unregistering the pernet subsystem. In
    __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
    cleanup (when exiting_module is false) and defer it to
    __ip_vs_cleanup_batch(), which unregisters all apps after all connections
    are flushed. If called during module exit, unregister ip_vs_ftp
    immediately.
    
    Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.")
    Suggested-by: Julian Anastasov <[email protected]>
    Signed-off-by: Slavin Liu <[email protected]>
    Signed-off-by: Julian Anastasov <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipvs: Use READ_ONCE/WRITE_ONCE for ipvs->enable [+ + +]
Author: Zhang Tengfei <[email protected]>
Date:   Mon Sep 1 21:46:54 2025 +0800

    ipvs: Use READ_ONCE/WRITE_ONCE for ipvs->enable
    
    [ Upstream commit 944b6b216c0387ac3050cd8b773819ae360bfb1c ]
    
    KCSAN reported a data-race on the `ipvs->enable` flag, which is
    written in the control path and read concurrently from many other
    contexts.
    
    Following a suggestion by Julian, this patch fixes the race by
    converting all accesses to use `WRITE_ONCE()/READ_ONCE()`.
    This lightweight approach ensures atomic access and acts as a
    compiler barrier, preventing unsafe optimizations where the flag
    is checked in loops (e.g., in ip_vs_est.c).
    
    Additionally, the `enable` checks in the fast-path hooks
    (`ip_vs_in_hook`, `ip_vs_out_hook`, `ip_vs_forward_icmp`) are
    removed. These are unnecessary since commit 857ca89711de
    ("ipvs: register hooks only with services"). The `enable=0`
    condition they check for can only occur in two rare and non-fatal
    scenarios: 1) after hooks are registered but before the flag is set,
    and 2) after hooks are unregistered on cleanup_net. In the worst
    case, a single packet might be mishandled (e.g., dropped), which
    does not lead to a system crash or data corruption. Adding a check
    in the performance-critical fast-path to handle this harmless
    condition is not a worthwhile trade-off.
    
    Fixes: 857ca89711de ("ipvs: register hooks only with services")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=1651b5234028c294c339
    Suggested-by: Julian Anastasov <[email protected]>
    Link: https://lore.kernel.org/lvs-devel/[email protected]/
    Signed-off-by: Zhang Tengfei <[email protected]>
    Acked-by: Julian Anastasov <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/gic-v5: Fix error handling in gicv5_its_irq_domain_alloc() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Sep 8 10:27:45 2025 +0200

    irqchip/gic-v5: Fix error handling in gicv5_its_irq_domain_alloc()
    
    [ Upstream commit a186120c780e21e4cfd186a925e34f718e30de88 ]
    
    Code in gicv5_its_irq_domain_alloc() has two issues:
    
     - it checks the wrong return value/variable when calling gicv5_alloc_lpi()
    
     - The cleanup code does not take previous loop iterations into account
    
    Fix both issues at once by adding the right gicv5_alloc_lpi() variable
    check and by reworking the function cleanup code to take into account
    current and previous iterations.
    
    [ lpieralisi: Reworded commit message ]
    
    Fixes: 57d72196dfc8 ("irqchip/gic-v5: Add GICv5 ITS support")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Lorenzo Pieralisi <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Zenghui Yu <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

irqchip/gic-v5: Fix loop in gicv5_its_create_itt_two_level() cleanup path [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Sep 8 10:27:44 2025 +0200

    irqchip/gic-v5: Fix loop in gicv5_its_create_itt_two_level() cleanup path
    
    [ Upstream commit bfcd1fdaae92faa8cae880eb4c3aaaa60c54bf0d ]
    
    The "i" variable in gicv5_its_create_itt_two_level() needs to be signed
    otherwise it can cause a forever loop in the function's cleanup path.
    
    [ lpieralisi: Reworded commit message ]
    
    Fixes: 57d72196dfc8 ("irqchip/gic-v5: Add GICv5 ITS support")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Lorenzo Pieralisi <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Zenghui Yu <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/sg2042-msi: Fix broken affinity setting [+ + +]
Author: Inochi Amaoto <[email protected]>
Date:   Thu Aug 14 07:28:33 2025 +0800

    irqchip/sg2042-msi: Fix broken affinity setting
    
    [ Upstream commit 9d8c41816bac518b4824f83b346ae30a1be83f68 ]
    
    When using NVME on SG2044, the NVME drvier always complains about "I/O tag
    XXX (XXX) QID XX timeout, completion polled", which is caused by the broken
    affinity setting mechanism of the sg2042-msi driver.
    
    The PLIC driver can only the set the affinity when enabled, but the
    sg2042-msi driver invokes the affinity setter in disabled state, which
    causes the change to be lost.
    
    Cure this by implementing the irq_startup()/shutdown() callbacks, which
    allow to startup (enabled) the underlying PLIC first.
    
    Fixes: e96b93a97c90 ("irqchip/sg2042-msi: Add the Sophgo SG2044 MSI interrupt controller")
    Reported-by: Han Gao <[email protected]>
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Inochi Amaoto <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Chen Wang <[email protected]> # Pioneerbox
    Reviewed-by: Chen Wang <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
kbuild: Add missing $(objtree) prefix to powerpc crtsavres.o artifact [+ + +]
Author: Kienan Stewart <[email protected]>
Date:   Tue Feb 18 15:26:39 2025 -0500

    kbuild: Add missing $(objtree) prefix to powerpc crtsavres.o artifact
    
    [ Upstream commit 46104a7d3ccd2acfe508e661393add0615c27a22 ]
    
    In the upstream commit 214c0eea43b2ea66bcd6467ea57e47ce8874191b
    ("kbuild: add $(objtree)/ prefix to some in-kernel build artifacts")
    artifacts required for building out-of-tree kernel modules had
    $(objtree) prepended to them to prepare for building in other
    directories.
    
    When building external modules for powerpc,
    arch/powerpc/lib/crtsavres.o is required for certain
    configurations. This artifact is missing the prepended $(objtree).
    
    Fixes: 13b25489b6f8 ("kbuild: change working directory to external module directory with M=")
    Acked-by: Masahiro Yamada <[email protected]>
    Reviewed-by: Nicolas Schier <[email protected]>
    Tested-by: Nicolas Schier <[email protected]>
    Signed-off-by: Kienan Stewart <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
KEYS: X.509: Fix Basic Constraints CA flag parsing [+ + +]
Author: Fan Wu <[email protected]>
Date:   Mon Sep 15 21:15:50 2025 +0000

    KEYS: X.509: Fix Basic Constraints CA flag parsing
    
    [ Upstream commit 5851afffe2ab323a53e184ba5a35fddf268f096b ]
    
    Fix the X.509 Basic Constraints CA flag parsing to correctly handle
    the ASN.1 DER encoded structure. The parser was incorrectly treating
    the length field as the boolean value.
    
    Per RFC 5280 section 4.1, X.509 certificates must use ASN.1 DER encoding.
    According to ITU-T X.690, a DER-encoded BOOLEAN is represented as:
    
    Tag (0x01), Length (0x01), Value (0x00 for FALSE, 0xFF for TRUE)
    
    The basicConstraints extension with CA:TRUE is encoded as:
    
      SEQUENCE (0x30) | Length | BOOLEAN (0x01) | Length (0x01) | Value (0xFF)
                                 ^-- v[2]         ^-- v[3]        ^-- v[4]
    
    The parser was checking v[3] (the length field, always 0x01) instead
    of v[4] (the actual boolean value, 0xFF for TRUE in DER encoding).
    
    Also handle the case where the extension is an empty SEQUENCE (30 00),
    which is valid for CA:FALSE when the default value is omitted as
    required by DER encoding rules (X.690 section 11.5).
    
    Per ITU-T X.690-0207:
    - Section 11.5: Default values must be omitted in DER
    - Section 11.1: DER requires TRUE to be encoded as 0xFF
    
    Link: https://datatracker.ietf.org/doc/html/rfc5280
    Link: https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
    Fixes: 30eae2b037af ("KEYS: X.509: Parse Basic Constraints for CA")
    Signed-off-by: Fan Wu <[email protected]>
    Reviewed-by: Lukas Wunner <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kselftest/arm64/gcs: Correctly check return value when disabling GCS [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Thu Aug 21 17:13:02 2025 +0200

    kselftest/arm64/gcs: Correctly check return value when disabling GCS
    
    [ Upstream commit 740cdafd0d998903c1faeee921028a8a78698be5 ]
    
    The return value was not assigned to 'ret', so the check afterwards
    does not do anything.
    
    Fixes: 3d37d4307e0f ("kselftest/arm64: Add very basic GCS test program")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Mark Brown <[email protected]>
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ksmbd: add max ip connections parameter [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Wed Oct 1 09:25:35 2025 +0900

    ksmbd: add max ip connections parameter
    
    commit d8b6dc9256762293048bf122fc11c4e612d0ef5d upstream.
    
    This parameter set the maximum number of connections per ip address.
    The default is 8.
    
    Cc: [email protected]
    Fixes: c0d41112f1a5 ("ksmbd: extend the connection limiting mechanism to support IPv6")
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: fix error code overwriting in smb2_get_info_filesystem() [+ + +]
Author: Matvey Kovalev <[email protected]>
Date:   Thu Sep 25 15:12:34 2025 +0300

    ksmbd: fix error code overwriting in smb2_get_info_filesystem()
    
    commit 88daf2f448aad05a2e6df738d66fe8b0cf85cee0 upstream.
    
    If client doesn't negotiate with SMB3.1.1 POSIX Extensions,
    then proper error code won't be returned due to overwriting.
    
    Return error immediately.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: e2f34481b24db ("cifsd: add server-side procedures for SMB3")
    Cc: [email protected]
    Signed-off-by: Matvey Kovalev <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: Fix race condition in RPC handle list access [+ + +]
Author: Yunseong Kim <[email protected]>
Date:   Mon Sep 15 22:44:09 2025 +0000

    ksmbd: Fix race condition in RPC handle list access
    
    commit 305853cce379407090a73b38c5de5ba748893aee upstream.
    
    The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd
    session. Access to this list is intended to be protected by
    'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was
    flawed, leading to potential race conditions.
    
    In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock
    before calling xa_store() and xa_erase(). Since these operations modify
    the XArray structure, a write lock is required to ensure exclusive access
    and prevent data corruption from concurrent modifications.
    
    Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load()
    without holding any lock at all. This could lead to reading inconsistent
    data or a potential use-after-free if an entry is concurrently removed and
    the pointer is dereferenced.
    
    Fix these issues by:
    1. Using down_write() and up_write() in ksmbd_session_rpc_open()
       to ensure exclusive access during XArray modification, and ensuring
       the lock is correctly released on error paths.
    2. Adding down_read() and up_read() in ksmbd_session_rpc_method()
       to safely protect the lookup.
    
    Fixes: a1f46c99d9ea ("ksmbd: fix use-after-free in ksmbd_session_rpc_open")
    Fixes: b685757c7b08 ("ksmbd: Implements sess->rpc_handle_list as xarray")
    Cc: [email protected]
    Signed-off-by: Yunseong Kim <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Tue Aug 5 12:05:09 2025 -0700

    KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid
    
    commit 0910dd7c9ad45a2605c45fd2bf3d1bcac087687c upstream.
    
    Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP
    isn't valid, e.g. because KVM is running with nrips=false.  SVM must
    decode and emulate to skip the instruction if the CPU doesn't provide the
    next RIP, and getting the instruction bytes to decode requires reading
    guest memory.  Reading guest memory through the emulator can fault, i.e.
    can sleep, which is disallowed since the fastpath handlers run with IRQs
    disabled.
    
     BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106
     in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu
     preempt_count: 1, expected: 0
     INFO: lockdep is turned off.
     irq event stamp: 30580
     hardirqs last  enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm]
     hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0
     softirqs last  enabled at (30570): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210
     softirqs last disabled at (30568): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210
     CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G     U              6.16.0-smp--e6c618b51cfe-sleep #782 NONE
     Tainted: [U]=USER
     Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025
     Call Trace:
      <TASK>
      dump_stack_lvl+0x7d/0xb0
      __might_resched+0x271/0x290
      __might_fault+0x28/0x80
      kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]
      kvm_fetch_guest_virt+0x92/0xc0 [kvm]
      __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]
      x86_decode_insn+0xd1/0x1010 [kvm]
      x86_emulate_instruction+0x105/0x810 [kvm]
      __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]
      handle_fastpath_invd+0xc4/0x1a0 [kvm]
      vcpu_run+0x11a1/0x1db0 [kvm]
      kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]
      kvm_vcpu_ioctl+0x578/0x6a0 [kvm]
      __se_sys_ioctl+0x6d/0xb0
      do_syscall_64+0x8a/0x2c0
      entry_SYSCALL_64_after_hwframe+0x4b/0x53
     RIP: 0033:0x7f479d57a94b
      </TASK>
    
    Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:
    Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with
    different justification (KVM now grabs SRCU when skipping the instruction
    for other reasons).
    
    Fixes: b439eb8ab578 ("Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
leds: flash: leds-qcom-flash: Update torch current clamp setting [+ + +]
Author: Fenglin Wu <[email protected]>
Date:   Tue Jul 29 12:51:22 2025 +0800

    leds: flash: leds-qcom-flash: Update torch current clamp setting
    
    [ Upstream commit 5974e8f6c3e47ab097c3dd8ece7324d1f88fe739 ]
    
    There is a register to clamp the flash current per LED channel when
    safety timer is disabled. It needs to be updated according to the
    maximum torch LED current setting to ensure the torch current won't
    be clamped unexpectedly.
    
    Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
    Signed-off-by: Fenglin Wu <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

leds: leds-lp55xx: Use correct address for memory programming [+ + +]
Author: Andrei Lalaev <[email protected]>
Date:   Wed Aug 20 10:47:12 2025 +0200

    leds: leds-lp55xx: Use correct address for memory programming
    
    [ Upstream commit d6058316d16ee0d1861c0550051b2492efb54b79 ]
    
    Memory programming doesn't work for devices without page support.
    For example, LP5562 has 3 engines but doesn't support pages,
    the start address is changed depending on engine number.
    According to datasheet [1], the PROG MEM register addresses for each
    engine are as follows:
    
      Engine 1: 0x10
      Engine 2: 0x30
      Engine 3: 0x50
    
    However, the current implementation incorrectly calculates the address
    of PROG MEM register using the engine index starting from 1:
    
      prog_mem_base = 0x10
      LP55xx_BYTES_PER_PAGE = 0x20
    
      Engine 1: 0x10 + 0x20 * 1 = 0x30
      Engine 2: 0x10 + 0x20 * 2 = 0x50
      Engine 3: 0x10 + 0x20 * 3 = 0x70
    
    This results in writing to the wrong engine memory, causing pattern
    programming to fail.
    
    To correct it, the engine index should be decreased:
      Engine 1: 0x10 + 0x20 * 0 = 0x10
      Engine 2: 0x10 + 0x20 * 1 = 0x30
      Engine 3: 0x10 + 0x20 * 2 = 0x50
    
    1 - https://www.ti.com/lit/ds/symlink/lp5562.pdf
    
    Fixes: 31379a57cf2f ("leds: leds-lp55xx: Generalize update_program_memory function")
    Signed-off-by: Andrei Lalaev <[email protected]>
    Link: https://lore.kernel.org/r/20250820-lp5562-prog-mem-address-v1-1-8569647fa71d@anton-paar.com
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

leds: max77705: Function return instead of variable assignment [+ + +]
Author: Len Bao <[email protected]>
Date:   Sun Jul 27 07:56:45 2025 +0000

    leds: max77705: Function return instead of variable assignment
    
    [ Upstream commit 6e3779e3c6f9dcc9267bf98bef70773a0b13dcbb ]
    
    Coverity noticed that assigning value -EINVAL to 'ret' in the if
    statement is useless because 'ret' is overwritten a few lines later.
    However, after inspect the code, this warning reveals that we need to
    return -EINVAL instead of the variable assignment. So, fix it.
    
    Coverity-id: 1646104
    Fixes: aebb5fc9a0d8 ("leds: max77705: Add LEDs support")
    Signed-off-by: Len Bao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
libbpf: Export bpf_object__prepare symbol [+ + +]
Author: Mykyta Yatsenko <[email protected]>
Date:   Tue Aug 19 22:51:19 2025 +0100

    libbpf: Export bpf_object__prepare symbol
    
    [ Upstream commit 2693227c1150d58bf82ef45a394a554373be5286 ]
    
    Add missing LIBBPF_API macro for bpf_object__prepare function to enable
    its export. libbpf.map had bpf_object__prepare already listed.
    
    Fixes: 1315c28ed809 ("libbpf: Split bpf object load into prepare/load")
    Signed-off-by: Mykyta Yatsenko <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Fix error when st-prefix_ops and ops from differ btf [+ + +]
Author: D. Wythe <[email protected]>
Date:   Fri Sep 26 15:17:51 2025 +0800

    libbpf: Fix error when st-prefix_ops and ops from differ btf
    
    [ Upstream commit 0cc114dc358cf8da2ca23a366e761e89a46ca277 ]
    
    When a module registers a struct_ops, the struct_ops type and its
    corresponding map_value type ("bpf_struct_ops_") may reside in different
    btf objects, here are four possible case:
    
    +--------+---------------+-------------+---------------------------------+
    |        |bpf_struct_ops_| xxx_ops     |                                 |
    +--------+---------------+-------------+---------------------------------+
    | case 0 | btf_vmlinux   | btf_vmlinux | be used and reg only in vmlinux |
    +--------+---------------+-------------+---------------------------------+
    | case 1 | btf_vmlinux   | mod_btf     | INVALID                         |
    +--------+---------------+-------------+---------------------------------+
    | case 2 | mod_btf       | btf_vmlinux | reg in mod but be used both in  |
    |        |               |             | vmlinux and mod.                |
    +--------+---------------+-------------+---------------------------------+
    | case 3 | mod_btf       | mod_btf     | be used and reg only in mod     |
    +--------+---------------+-------------+---------------------------------+
    
    Currently we figure out the mod_btf by searching with the struct_ops type,
    which makes it impossible to figure out the mod_btf when the struct_ops
    type is in btf_vmlinux while it's corresponding map_value type is in
    mod_btf (case 2).
    
    The fix is to use the corresponding map_value type ("bpf_struct_ops_")
    as the lookup anchor instead of the struct_ops type to figure out the
    `btf` and `mod_btf` via find_ksym_btf_id(), and then we can locate
    the kern_type_id via btf__find_by_name_kind() with the `btf` we just
    obtained from find_ksym_btf_id().
    
    With this change the lookup obtains the correct btf and mod_btf for case 2,
    preserves correct behavior for other valid cases, and still fails as
    expected for the invalid scenario (case 1).
    
    Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support")
    Signed-off-by: D. Wythe <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Acked-by: Martin KaFai Lau <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Fix reuse of DEVMAP [+ + +]
Author: Yureka Lilian <[email protected]>
Date:   Thu Aug 14 20:01:12 2025 +0200

    libbpf: Fix reuse of DEVMAP
    
    [ Upstream commit 6c6b4146deb12d20f42490d5013f2043df942161 ]
    
    Previously, re-using pinned DEVMAP maps would always fail, because
    get_map_info on a DEVMAP always returns flags with BPF_F_RDONLY_PROG set,
    but BPF_F_RDONLY_PROG being set on a map during creation is invalid.
    
    Thus, ignore the BPF_F_RDONLY_PROG flag in the flags returned from
    get_map_info when checking for compatibility with an existing DEVMAP.
    
    The same problem is handled in a third-party ebpf library:
    - https://github.com/cilium/ebpf/issues/925
    - https://github.com/cilium/ebpf/pull/930
    
    Fixes: 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF")
    Signed-off-by: Yureka Lilian <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.17.3 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Oct 15 12:04:23 2025 +0200

    Linux 6.17.3
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Takeshi Ogasawara <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Pascal Ernster <[email protected]>
    Tested-by: Dileep Malepu <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
LoongArch: Automatically disable kaslr if boot from kexec_file [+ + +]
Author: Youling Tang <[email protected]>
Date:   Thu Oct 2 22:39:08 2025 +0800

    LoongArch: Automatically disable kaslr if boot from kexec_file
    
    commit c8168b4faf1d62cbb320a3e518ad31cdd567cb05 upstream.
    
    Automatically disable kaslr when the kernel loads from kexec_file.
    
    kexec_file loads the secondary kernel image to a non-linked address,
    inherently providing KASLR-like randomization.
    
    However, on LoongArch where System RAM may be non-contiguous, enabling
    KASLR for the second kernel may relocate it to an invalid memory region
    and cause a boot failure. Thus, we disable KASLR when "kexec_file" is
    detected in the command line.
    
    To ensure compatibility with older kernels loaded via kexec_file, this
    patch should be backported to stable branches.
    
    Cc: [email protected]
    Signed-off-by: Youling Tang <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Don't align trampoline size [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: Don't align trampoline size
    
    commit a04731cbee6e981afa4263289a0c0059c8b2e7b9 upstream.
    
    Currently, arch_alloc_bpf_trampoline() use bpf_prog_pack_alloc() which
    will pack multiple trampolines into a huge page. So, no need to assume
    the trampoline size is page aligned.
    
    Cc: [email protected]
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Fix uninitialized symbol 'retval_off' [+ + +]
Author: Huacai Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: Fix uninitialized symbol 'retval_off'
    
    commit 7b6c2d172d023d344527d3cb4516d0d6b29f4919 upstream.
    
    In __arch_prepare_bpf_trampoline(), retval_off is meaningful only when
    save_ret is not 0, so the current logic is correct. But it may cause a
    build warning:
    
    arch/loongarch/net/bpf_jit.c:1547 __arch_prepare_bpf_trampoline() error: uninitialized symbol 'retval_off'.
    
    So initialize retval_off unconditionally to fix it.
    
    Cc: [email protected]
    Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
    Closes: https://lore.kernel.org/r/[email protected]/
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Make error handling robust in arch_prepare_bpf_trampoline() [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:53 2025 +0800

    LoongArch: BPF: Make error handling robust in arch_prepare_bpf_trampoline()
    
    commit de2c0b7788648850b68b75f7cc8698b2749dd31e upstream.
    
    Bail out instead of trying to perform a bpf_arch_text_copy() if
    __arch_prepare_bpf_trampoline() failed.
    
    Cc: [email protected]
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Make trampoline size stable [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: Make trampoline size stable
    
    commit ea645cfd3d5f74a2bd40a60003f113b3c467975d upstream.
    
    When attach fentry/fexit BPF programs, __arch_prepare_bpf_trampoline()
    is called twice with different `struct bpf_tramp_image *im`:
    
        bpf_trampoline_update()
            -> arch_bpf_trampoline_size()
                -> __arch_prepare_bpf_trampoline()
            -> arch_prepare_bpf_trampoline()
                -> __arch_prepare_bpf_trampoline()
    
    Use move_imm() will emit unstable instruction sequences, so let's use
    move_addr() instead to prevent subtle bugs.
    
    (I observed this while debugging other issues with printk.)
    
    Cc: [email protected]
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: No support of struct argument in trampoline programs [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: No support of struct argument in trampoline programs
    
    commit e82406c7cbdd368c5459b8a45e118811d2ba0794 upstream.
    
    The current implementation does not support struct argument. This causes
    a oops when running bpf selftest:
    
      $ ./test_progs -a tracing_struct
      Oops[#1]:
      CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938
      rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
      rcu:     1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801
      rcu:     (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)
      Sending NMI from CPU 0 to CPUs 1:
      rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2
      rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
      rcu: RCU grace-period kthread stack dump:
      task:rcu_preempt     state:I stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000800
      Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680
              9000000085d88000 0000000000000000 0000000000000040 9000000087159350
              9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005
              00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004
              9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e
              00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350
              900000008715bf98 0000000000000005 9000000087036000 900000008704a000
              9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0
              00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000
              9000000007002150 00000000ffff355b 9000000084615480 0000000007000002
              ...
      Call Trace:
      [<9000000085c2a868>] __schedule+0x410/0x1520
      [<9000000085c2b9ac>] schedule+0x34/0x190
      [<9000000085c33d38>] schedule_timeout+0x98/0x140
      [<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868
      [<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0
      [<900000008454e8a4>] kthread+0x144/0x238
      [<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8
      [<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88
    
      rcu: Stack dump where RCU GP kthread last ran:
      Sending NMI from CPU 0 to CPUs 2:
      NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4
    
    Reject it for now.
    
    Cc: [email protected]
    Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support")
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: No text_poke() for kernel text [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: No text_poke() for kernel text
    
    commit 3d770bd11b943066db11dba7be0b6f0d81cb5d50 upstream.
    
    The current implementation of bpf_arch_text_poke() requires 5 nops
    at patch site which is not applicable for kernel/module functions.
    Because LoongArch reserves ONLY 2 nops at the function entry. With
    CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y, this can be done by ftrace
    instead.
    
    See the following commit for details:
      * commit b91e014f078e ("bpf: Make BPF trampoline use register_ftrace_direct() API")
      * commit 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support")
    
    Cc: [email protected]
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Remove duplicated bpf_flush_icache() [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: Remove duplicated bpf_flush_icache()
    
    commit b0f50dc09bf008b2e581d5e6ad570d325725881c upstream.
    
    The bpf_flush_icache() is called by bpf_arch_text_copy() already. So
    remove it. This has been done in arm64 and riscv.
    
    Cc: [email protected]
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Remove duplicated flags check [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:52 2025 +0800

    LoongArch: BPF: Remove duplicated flags check
    
    commit 909d3e3f51b1bc00f33a484ce0d41b42fed01965 upstream.
    
    The check for (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY) is
    duplicated in __arch_prepare_bpf_trampoline(). Remove it.
    
    While at it, make sure stack_size and nargs are initialized once.
    
    Cc: [email protected]
    Tested-by: Vincent Li <[email protected]>
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: BPF: Sign-extend struct ops return values properly [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Thu Oct 2 22:39:53 2025 +0800

    LoongArch: BPF: Sign-extend struct ops return values properly
    
    commit 8b51b11b3d81c1ed48a52f87da9256d737b723a0 upstream.
    
    The ns_bpf_qdisc selftest triggers a kernel panic:
    
      Oops[#1]:
      CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4
      CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G           OE       6.16.0+ #3 PREEMPT(full)
      Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
      Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
      pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600
      a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008
      a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000
      t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001
      t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d
      t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800
      s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880
      s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000
         ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8
        ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8
       CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
       PRMD: 00000004 (PPLV0 +PIE -PWE)
       EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
       ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
      ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
       BADV: 0000000000741d58
       PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
      Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
      Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)
      Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8
              90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000
              900000010597c400 900000008694a000 0000000000000000 9000000105b59000
              90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c
              9000000086936000 0000000100094d4c fffffff400676208 0000000000000000
              9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000
              9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000
              9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840
              0000000000000000 9000000086be6c40 0000000000000000 0000000000000000
              0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4
              ...
      Call Trace:
      [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8
      [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0
      [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950
      [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448
      [<9000000085370b24>] ip6_xmit+0x304/0x858
      [<90000000853c4438>] inet6_csk_xmit+0x100/0x170
      [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0
      [<90000000852b47fc>] tcp_connect+0xbcc/0x1168
      [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0
      [<90000000852e7738>] __inet_stream_connect+0x170/0x480
      [<90000000852e7a98>] inet_stream_connect+0x50/0x88
      [<90000000850f2814>] __sys_connect+0xe4/0x110
      [<90000000850f2858>] sys_connect+0x18/0x28
      [<9000000085520c94>] do_syscall+0x94/0x1a0
      [<9000000083df1fb8>] handle_syscall+0xb8/0x158
    
      Code: 4001ad80  2400873f  2400832d <240073cc> 001137ff  001133ff  6407b41f  001503cc  0280041d
    
      ---[ end trace 0000000000000000 ]---
    
    The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer
    is treated as a 32bit value and sign extend to 64bit in epilogue. This
    behavior is right for most bpf prog types but wrong for struct ops which
    requires LoongArch ABI.
    
    So let's sign extend struct ops return values according to the LoongArch
    ABI ([1]) and return value spec in function model.
    
    [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
    
    Cc: [email protected]
    Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline")
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lsm: CONFIG_LSM can depend on CONFIG_SECURITY [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sun Aug 24 15:28:00 2025 -0700

    lsm: CONFIG_LSM can depend on CONFIG_SECURITY
    
    [ Upstream commit 54d94c422fed9575b74167333c1757847a4e6899 ]
    
    When CONFIG_SECURITY is not set, CONFIG_LSM (builtin_lsm_order) does
    not need to be visible and settable since builtin_lsm_order is defined in
    security.o, which is only built when CONFIG_SECURITY=y.
    
    So make CONFIG_LSM depend on CONFIG_SECURITY.
    
    Fixes: 13e735c0e953 ("LSM: Introduce CONFIG_LSM")
    Signed-off-by: Randy Dunlap <[email protected]>
    [PM: subj tweak]
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: i2c: vd55g1: Fix duster register address [+ + +]
Author: Benjamin Mugnier <[email protected]>
Date:   Mon Aug 18 15:50:58 2025 +0200

    media: i2c: vd55g1: Fix duster register address
    
    [ Upstream commit ba4b8886c22a3e8c3f41c6dd373b177d7d41bcf8 ]
    
    The duster register needs to be disabled on test patterns. While the
    code is correctly doing so, the register address contained a typo, thus
    not disabling the duster correctly. Fix the typo.
    
    Fixes: e56616d7b23c ("media: i2c: Add driver for ST VD55G1 camera sensor")
    
    Signed-off-by: Benjamin Mugnier <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rj54n1cb0c: Fix memleak in rj54n1_probe() [+ + +]
Author: Zhang Shurong <[email protected]>
Date:   Tue Jun 24 16:27:24 2025 +0800

    media: rj54n1cb0c: Fix memleak in rj54n1_probe()
    
    [ Upstream commit fda55673ecdabf25f5ecc61b5ab17239257ac252 ]
    
    rj54n1_probe() won't clean all the allocated resources in fail
    path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to
    prevent memleak.
    
    Fixes: f187352dcd45 ("media: i2c: Copy rj54n1cb0c soc_camera sensor driver")
    Signed-off-by: Zhang Shurong <[email protected]>
    Reviewed-by: Jacopo Mondi <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: st-delta: avoid excessive stack usage [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Jun 10 11:31:56 2025 +0200

    media: st-delta: avoid excessive stack usage
    
    [ Upstream commit 5954ad7d1af92cb6244c5f31216e43af55febbb7 ]
    
    Building with a reduced stack warning limit shows that delta_mjpeg_decode()
    copies a giant structure to the stack each time but only uses three of
    its members:
    
    drivers/media/platform/st/sti/delta/delta-mjpeg-dec.c: In function 'delta_mjpeg_decode':
    drivers/media/platform/st/sti/delta/delta-mjpeg-dec.c:427:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
    
    Open-code the passing of the structure members that are actually used here.
    
    Fixes: 433ff5b4a29b ("[media] st-delta: add mjpeg support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: staging/ipu7: cleanup the MMU correctly in IPU7 driver release [+ + +]
Author: Bingbu Cao <[email protected]>
Date:   Fri Aug 15 17:20:37 2025 +0800

    media: staging/ipu7: cleanup the MMU correctly in IPU7 driver release
    
    [ Upstream commit 01a80b6649e69e4889b8521de022d3ee4bc5cb6f ]
    
    IPU7 ISYS and PSYS auxiliary devices are released after
    ipu7_bus_del_devices(), so driver can not reference the MMU devices
    from ISYS and PSYS auxiliary devices, so move the MMUs cleanup before
    releasing the auxiliary devices.
    
    Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
    Signed-off-by: Bingbu Cao <[email protected]>
    [Sakari Ailus: Drop extra newline.]
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: staging/ipu7: convert to use pci_alloc_irq_vectors() API [+ + +]
Author: Bingbu Cao <[email protected]>
Date:   Fri Aug 15 17:20:35 2025 +0800

    media: staging/ipu7: convert to use pci_alloc_irq_vectors() API
    
    [ Upstream commit 283f7638c26c0f36e4ef5e147884e241b24fbebd ]
    
    pci_enable_msi() is a deprecated API, thus switch to use modern
    pci_alloc_irq_vectors().
    
    Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
    Signed-off-by: Bingbu Cao <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: staging/ipu7: Don't set name for IPU7 PCI device [+ + +]
Author: Bingbu Cao <[email protected]>
Date:   Fri Aug 15 17:20:36 2025 +0800

    media: staging/ipu7: Don't set name for IPU7 PCI device
    
    [ Upstream commit 8abb489f9aa181882ece7c24712ad39cbb9dab81 ]
    
    Driver better not dev_set_name() to change the PCI device
    name, so remove it.
    
    Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
    Signed-off-by: Bingbu Cao <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: zoran: Remove zoran_fh structure [+ + +]
Author: Jacopo Mondi <[email protected]>
Date:   Sun Aug 10 04:30:15 2025 +0300

    media: zoran: Remove zoran_fh structure
    
    [ Upstream commit dc322d13cf417552b59e313e809a6da40b8b36ef ]
    
    The zoran_fh structure is a wrapper around v4l2_fh. Its usage has been
    mostly removed by commit 83f89a8bcbc3 ("media: zoran: convert to vb2"),
    but the structure stayed by mistake. It is now used in a single
    location, assigned from a void pointer and then recast to a void
    pointer, without being every accessed. Drop it.
    
    Fixes: 83f89a8bcbc3 ("media: zoran: convert to vb2")
    Signed-off-by: Jacopo Mondi <[email protected]>
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Mon Aug 4 15:32:40 2025 +0200

    mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag
    
    commit 64e0d839c589f4f2ecd2e3e5bdb5cee6ba6bade9 upstream.
    
    Testing has shown that reading multiple registers at once (for 10-bit
    ADC values) does not work. Set the use_single_read regmap_config flag
    to make regmap split these for us.
    
    This should fix temperature opregion accesses done by
    drivers/acpi/pmic/intel_pmic_chtdc_ti.c and is also necessary for
    the upcoming drivers for the ADC and battery MFD cells.
    
    Fixes: 6bac0606fdba ("mfd: Add support for Cherry Trail Dollar Cove TI PMIC")
    Cc: [email protected]
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mfd: max77705: max77705_charger: move active discharge setting to mfd parent [+ + +]
Author: Dzmitry Sankouski <[email protected]>
Date:   Thu Sep 18 20:06:46 2025 +0300

    mfd: max77705: max77705_charger: move active discharge setting to mfd parent
    
    [ Upstream commit c24928ac69be2390cdf456d126b464af079c57ef ]
    
    Active discharge setting is a part of MFD top level i2c device, hence
    cannot be controlled by charger. Writing to MAX77705_PMIC_REG_MAINCTRL1
    register from charger driver is a mistake.
    
    Move active discharge setting to MFD parent driver.
    
    Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705")
    Signed-off-by: Dzmitry Sankouski <[email protected]>
    Acked-by: Lee Jones <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: max77705: Setup the core driver as an interrupt controller [+ + +]
Author: Dzmitry Sankouski <[email protected]>
Date:   Tue Sep 9 21:23:07 2025 +0300

    mfd: max77705: Setup the core driver as an interrupt controller
    
    [ Upstream commit 605c9820e44de2da7d67acf66484136561da63a2 ]
    
    Current implementation describes only MFD's own topsys interrupts.
    However, max77705 has a register which indicates interrupt source, i.e.
    it acts as an interrupt controller. There's 4 interrupt sources in
    max77705: topsys, charger, fuelgauge, usb type-c manager.
    
    Setup max77705 MFD parent as an interrupt controller. Delete topsys
    interrupts because currently unused.
    
    Remove shared interrupt flag, because we're are an interrupt controller
    now, and subdevices should request interrupts from us.
    
    Fixes: c8d50f029748 ("mfd: Add new driver for MAX77705 PMIC")
    
    Signed-off-by: Dzmitry Sankouski <[email protected]>
    Link: https://lore.kernel.org/r/20250909-max77705-fix_interrupt_handling-v3-1-233c5a1a20b5@gmail.com
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: rz-mtu3: Fix MTU5 NFCR register offset [+ + +]
Author: Cosmin Tanislav <[email protected]>
Date:   Wed Sep 10 20:59:06 2025 +0300

    mfd: rz-mtu3: Fix MTU5 NFCR register offset
    
    commit da32b0e82c523b76265ba1ad25d7ea74f0ece402 upstream.
    
    The NFCR register for MTU5 is at 0x1a95 offset according to Datasheet
    Page 725, Table 16.4. The address of all registers is offset by 0x1200,
    making the proper address of MTU5 NFCR register be 0x895.
    
    Cc: [email protected]
    Fixes: 654c293e1687 ("mfd: Add Renesas RZ/G2L MTU3a core driver")
    Signed-off-by: Cosmin Tanislav <[email protected]>
    Reviewed-by: Biju Das <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data() [+ + +]
Author: Bartosz Golaszewski <[email protected]>
Date:   Mon Aug 11 15:36:16 2025 +0200

    mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data()
    
    commit 1efbee6852f1ff698a9981bd731308dd027189fb upstream.
    
    Commit 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
    removed the return value check from the call to gpiochip_add_data() (or
    rather gpiochip_add() back then and later converted to devres) with no
    explanation. This function however can still fail, so check the return
    value and bail-out if it does.
    
    Cc: [email protected]
    Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
misc: fastrpc: Fix fastrpc_map_lookup operation [+ + +]
Author: Ling Xu <[email protected]>
Date:   Fri Sep 12 14:12:34 2025 +0100

    misc: fastrpc: Fix fastrpc_map_lookup operation
    
    commit 9031626ade38b092b72638dfe0c6ffce8d8acd43 upstream.
    
    Fastrpc driver creates maps for user allocated fd buffers. Before
    creating a new map, the map list is checked for any already existing
    maps using map fd. Checking with just map fd is not sufficient as the
    user can pass offsetted buffer with less size when the map is created
    and then a larger size the next time which could result in memory
    issues. Check for dma_buf object also when looking up for the map.
    
    Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
    Cc: [email protected]
    Co-developed-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ling Xu <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

misc: fastrpc: fix possible map leak in fastrpc_put_args [+ + +]
Author: Ling Xu <[email protected]>
Date:   Fri Sep 12 14:12:35 2025 +0100

    misc: fastrpc: fix possible map leak in fastrpc_put_args
    
    commit da1ba64176e0138f2bfa96f9e43e8c3640d01e1e upstream.
    
    copy_to_user() failure would cause an early return without cleaning up
    the fdlist, which has been updated by the DSP. This could lead to map
    leak. Fix this by redirecting to a cleanup path on failure, ensuring
    that all mapped buffers are properly released before returning.
    
    Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
    Cc: [email protected]
    Co-developed-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ling Xu <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

misc: fastrpc: Save actual DMA size in fastrpc_map structure [+ + +]
Author: Ling Xu <[email protected]>
Date:   Fri Sep 12 14:12:33 2025 +0100

    misc: fastrpc: Save actual DMA size in fastrpc_map structure
    
    commit 8b5b456222fd604079b5cf2af1f25ad690f54a25 upstream.
    
    For user passed fd buffer, map is created using DMA calls. The
    map related information is stored in fastrpc_map structure. The
    actual DMA size is not stored in the structure. Store the actual
    size of buffer and check it against the user passed size.
    
    Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
    Cc: [email protected]
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Co-developed-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ling Xu <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

misc: fastrpc: Skip reference for DMA handles [+ + +]
Author: Ling Xu <[email protected]>
Date:   Fri Sep 12 14:12:36 2025 +0100

    misc: fastrpc: Skip reference for DMA handles
    
    commit 10df039834f84a297c72ec962c0f9b7c8c5ca31a upstream.
    
    If multiple dma handles are passed with same fd over a remote call
    the kernel driver takes a reference and expects that put for the
    map will be called as many times to free the map. But DSP only
    updates the fd one time in the fd list when the DSP refcount
    goes to zero and hence kernel make put call only once for the
    fd. This can cause SMMU fault issue as the same fd can be used
    in future for some other call.
    
    Fixes: 35a82b87135d ("misc: fastrpc: Add dma handle implementation")
    Cc: [email protected]
    Co-developed-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ekansh Gupta <[email protected]>
    Signed-off-by: Ling Xu <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

misc: genwqe: Fix incorrect cmd field being reported in error [+ + +]
Author: Colin Ian King <[email protected]>
Date:   Tue Sep 2 12:37:12 2025 +0100

    misc: genwqe: Fix incorrect cmd field being reported in error
    
    [ Upstream commit 6b26053819dccc664120e07c56f107fb6f72f3fa ]
    
    There is a dev_err message that is reporting the value of
    cmd->asiv_length when it should be reporting cmd->asv_length
    instead. Fix this.
    
    Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
    Signed-off-by: Colin Ian King <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

misc: pci_endpoint_test: Fix array underflow in pci_endpoint_test_ioctl() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Aug 1 20:03:35 2025 +0300

    misc: pci_endpoint_test: Fix array underflow in pci_endpoint_test_ioctl()
    
    [ Upstream commit 1ad82f9db13d85667366044acdfb02009d576c5a ]
    
    Commit eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case")
    added NO_BAR (-1) to the pci_barno enum which, in practical terms,
    changes the enum from an unsigned int to a signed int.  If the user
    passes a negative number in pci_endpoint_test_ioctl() then it results in
    an array underflow in pci_endpoint_test_bar().
    
    Fixes: eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/aIzzZ4vc6ZrmM9rI@suswa
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/ksm: fix flag-dropping behavior in ksm_madvise [+ + +]
Author: Jakub Acs <[email protected]>
Date:   Wed Oct 1 09:03:52 2025 +0000

    mm/ksm: fix flag-dropping behavior in ksm_madvise
    
    commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 upstream.
    
    syzkaller discovered the following crash: (kernel BUG)
    
    [   44.607039] ------------[ cut here ]------------
    [   44.607422] kernel BUG at mm/userfaultfd.c:2067!
    [   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
    [   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)
    [   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    [   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
    
    <snip other registers, drop unreliable trace>
    
    [   44.617726] Call Trace:
    [   44.617926]  <TASK>
    [   44.619284]  userfaultfd_release+0xef/0x1b0
    [   44.620976]  __fput+0x3f9/0xb60
    [   44.621240]  fput_close_sync+0x110/0x210
    [   44.622222]  __x64_sys_close+0x8f/0x120
    [   44.622530]  do_syscall_64+0x5b/0x2f0
    [   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [   44.623244] RIP: 0033:0x7f365bb3f227
    
    Kernel panics because it detects UFFD inconsistency during
    userfaultfd_release_all().  Specifically, a VMA which has a valid pointer
    to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
    
    The inconsistency is caused in ksm_madvise(): when user calls madvise()
    with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,
    it accidentally clears all flags stored in the upper 32 bits of
    vma->vm_flags.
    
    Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and
    int are 32-bit wide.  This setup causes the following mishap during the &=
    ~VM_MERGEABLE assignment.
    
    VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000.
    After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then
    promoted to unsigned long before the & operation.  This promotion fills
    upper 32 bits with leading 0s, as we're doing unsigned conversion (and
    even for a signed conversion, this wouldn't help as the leading bit is 0).
    & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff
    instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears
    the upper 32-bits of its value.
    
    Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the
    BIT() macro.
    
    Note: other VM_* flags are not affected: This only happens to the
    VM_MERGEABLE flag, as the other VM_* flags are all constants of type int
    and after ~ operation, they end up with leading 1 and are thus converted
    to unsigned long with leading 1s.
    
    Note 2:
    After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is
    no longer a kernel BUG, but a WARNING at the same place:
    
    [   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
    
    but the root-cause (flag-drop) remains the same.
    
    [[email protected]: rust bindgen wasn't able to handle BIT(), from Miguel]
      Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode")
    Signed-off-by: Jakub Acs <[email protected]>
    Signed-off-by: Miguel Ojeda <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Acked-by: SeongJae Park <[email protected]>
    Tested-by: Alice Ryhl <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Cc: Xu Xin <[email protected]>
    Cc: Chengming Zhou <[email protected]>
    Cc: Peter Xu <[email protected]>
    Cc: Axel Rasmussen <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/slub: Fix cmp_loc_by_count() to return 0 when counts are equal [+ + +]
Author: Kuan-Wei Chiu <[email protected]>
Date:   Tue Aug 26 14:23:14 2025 +0800

    mm/slub: Fix cmp_loc_by_count() to return 0 when counts are equal
    
    [ Upstream commit e1c4350327b39c9cad27b6c5779b3754384f26c8 ]
    
    The comparison function cmp_loc_by_count() used for sorting stack trace
    locations in debugfs currently returns -1 if a->count > b->count and 1
    otherwise. This breaks the antisymmetry property required by sort(),
    because when two counts are equal, both cmp(a, b) and cmp(b, a) return
    1.
    
    This can lead to undefined or incorrect ordering results. Fix it by
    updating the comparison logic to explicitly handle the case when counts
    are equal, and use cmp_int() to ensure the comparison function adheres
    to the required mathematical properties of antisymmetry.
    
    Fixes: 553c0369b3e1 ("mm/slub: sort debugfs output by frequency of stack traces")
    Reviewed-by: Joshua Hahn <[email protected]>
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Reviewed-by: Harry Yoo <[email protected]>
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm: hugetlb: avoid soft lockup when mprotect to large memory area [+ + +]
Author: Yang Shi <[email protected]>
Date:   Mon Sep 29 13:24:02 2025 -0700

    mm: hugetlb: avoid soft lockup when mprotect to large memory area
    
    commit f52ce0ea90c83a28904c7cc203a70e6434adfecb upstream.
    
    When calling mprotect() to a large hugetlb memory area in our customer's
    workload (~300GB hugetlb memory), soft lockup was observed:
    
    watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]
    
    CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7
    Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025
    pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : mte_clear_page_tags+0x14/0x24
    lr : mte_sync_tags+0x1c0/0x240
    sp : ffff80003150bb80
    x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000
    x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458
    x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000
    x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c
    x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
    x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000
    x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000
    
    Call trace:
      mte_clear_page_tags+0x14/0x24
      set_huge_pte_at+0x25c/0x280
      hugetlb_change_protection+0x220/0x430
      change_protection+0x5c/0x8c
      mprotect_fixup+0x10c/0x294
      do_mprotect_pkey.constprop.0+0x2e0/0x3d4
      __arm64_sys_mprotect+0x24/0x44
      invoke_syscall+0x50/0x160
      el0_svc_common+0x48/0x144
      do_el0_svc+0x30/0xe0
      el0_svc+0x30/0xf0
      el0t_64_sync_handler+0xc4/0x148
      el0t_64_sync+0x1a4/0x1a8
    
    Soft lockup is not triggered with THP or base page because there is
    cond_resched() called for each PMD size.
    
    Although the soft lockup was triggered by MTE, it should be not MTE
    specific.  The other processing which takes long time in the loop may
    trigger soft lockup too.
    
    So add cond_resched() for hugetlb to avoid soft lockup.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 8f860591ffb2 ("[PATCH] Enable mprotect on huge pages")
    Signed-off-by: Yang Shi <[email protected]>
    Tested-by: Carl Worth <[email protected]>
    Reviewed-by: Christoph Lameter (Ampere) <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Acked-by: Oscar Salvador <[email protected]>
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Dev Jain <[email protected]>
    Cc: Muchun Song <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmc: core: Fix variable shadowing in mmc_route_rpmb_frames() [+ + +]
Author: Bean Huo <[email protected]>
Date:   Thu Sep 11 23:06:05 2025 +0200

    mmc: core: Fix variable shadowing in mmc_route_rpmb_frames()
    
    [ Upstream commit 072755cca7e743c28a273fcb69b0e826109473d7 ]
    
    Rename the inner 'frm' variable to 'resp_frm' in the write path of
    mmc_route_rpmb_frames() to avoid shadowing the outer 'frm' variable.
    
    The function declares 'frm' at function scope pointing to the request
    frame, but then redeclares another 'frm' variable inside the write
    block pointing to the response frame. This shadowing makes the code
    confusing and error-prone.
    
    Using 'resp_frm' for the response frame makes the distinction clear
    and improves code readability.
    
    Fixes: 7852028a35f0 ("mmc: block: register RPMB partition with the RPMB subsystem")
    Reviewed-by: Avri Altman <[email protected]>
    Reviewed-by: Jens Wiklander <[email protected]>
    Signed-off-by: Bean Huo <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: select REGMAP_MMIO with MMC_LOONGSON2 [+ + +]
Author: Mikko Rapeli <[email protected]>
Date:   Mon Sep 15 11:33:16 2025 +0300

    mmc: select REGMAP_MMIO with MMC_LOONGSON2
    
    [ Upstream commit 67da3f16e5f97a864a0beb4f9758d09e1890a76e ]
    
    COMPILE_TEST with MMC_LOONGSON2 failed to link due to
    undeclared dependency:
    
    ERROR: modpost: "__devm_regmap_init_mmio_clk"
    [drivers/mmc/host/loongson2-mmc.ko] undefined!
    
    Fixes: 2115772014bd ("mmc: loongson2: Add Loongson-2K SD/SDIO controller driver")
    
    Suggested-by: Arnd Bergmann <[email protected]>
    Suggested-by: Binbin Zhou <[email protected]>
    Signed-off-by: Mikko Rapeli <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mptcp: Call dst_release() in mptcp_active_enable(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:24 2025 +0000

    mptcp: Call dst_release() in mptcp_active_enable().
    
    [ Upstream commit 108a86c71c93ff28087994e6107bc99ebe336629 ]
    
    mptcp_active_enable() calls sk_dst_get(), which returns dst with its
    refcount bumped, but forgot dst_release().
    
    Let's add missing dst_release().
    
    Cc: [email protected]
    Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 893c49a78d9f ("mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable().")
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: Fix up subflow's memcg when CONFIG_SOCK_CGROUP_DATA=n. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri Aug 15 20:16:09 2025 +0000

    mptcp: Fix up subflow's memcg when CONFIG_SOCK_CGROUP_DATA=n.
    
    [ Upstream commit 68889dfd547bd8eabc5a98b58475d7b901cf5129 ]
    
    When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets
    sk->sk_memcg based on the current task.
    
    MPTCP subflow socket creation is triggered from userspace or
    an in-kernel worker.
    
    In the latter case, sk->sk_memcg is not what we want.  So, we fix
    it up from the parent socket's sk->sk_memcg in mptcp_attach_cgroup().
    
    Although the code is placed under #ifdef CONFIG_MEMCG, it is buried
    under #ifdef CONFIG_SOCK_CGROUP_DATA.
    
    The two configs are orthogonal.  If CONFIG_MEMCG is enabled without
    CONFIG_SOCK_CGROUP_DATA, the subflow's memory usage is not charged
    correctly.
    
    Let's move the code out of the wrong ifdef guard.
    
    Note that sk->sk_memcg is freed in sk_prot_free() and the parent
    sk holds the refcnt of memcg->css here, so we don't need to use
    css_tryget().
    
    Fixes: 3764b0c5651e3 ("mptcp: attach subflow socket to parent cgroup")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Acked-by: Matthieu Baerts (NGI0) <[email protected]>
    Acked-by: Shakeel Butt <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:25 2025 +0000

    mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable().
    
    [ Upstream commit 893c49a78d9f85e4b8081b908fb7c407d018106a ]
    
    mptcp_active_enable() is called from subflow_finish_connect(),
    which is icsk->icsk_af_ops->sk_rx_dst_set() and it's not always
    under RCU.
    
    Using sk_dst_get(sk)->dev could trigger UAF.
    
    Let's use __sk_dst_get() and dst_dev_rcu().
    
    Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: rawnand: atmel: Fix error handling path in atmel_nand_controller_add_nands [+ + +]
Author: Erick Karanja <[email protected]>
Date:   Mon Sep 22 14:07:27 2025 +0300

    mtd: rawnand: atmel: Fix error handling path in atmel_nand_controller_add_nands
    
    [ Upstream commit 8ed4728eb9f10b57c3eb02e0f6933a89ffcb8a91 ]
    
    In case of a jump to the  err label due to atmel_nand_create() or
    atmel_nand_controller_add_nand() failure, the reference to nand_np
    need to be released
    
    Use for_each_child_of_node_scoped() to fix the issue.
    
    Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
    
    Signed-off-by: Erick Karanja <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nbd: restrict sockets to TCP and UDP [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Sep 9 13:22:43 2025 +0000

    nbd: restrict sockets to TCP and UDP
    
    [ Upstream commit 9f7c02e031570e8291a63162c6c046dc15ff85b0 ]
    
    Recently, syzbot started to abuse NBD with all kinds of sockets.
    
    Commit cf1b2326b734 ("nbd: verify socket is supported during setup")
    made sure the socket supported a shutdown() method.
    
    Explicitely accept TCP and UNIX stream sockets.
    
    Fixes: cf1b2326b734 ("nbd: verify socket is supported during setup")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/CANn89iJ+76eE3A_8S_zTpSyW5hvPRn6V57458hCZGY5hbH_bFA@mail.gmail.com/T/#m081036e8747cd7e2626c1da5d78c8b9d1e55b154
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Mike Christie <[email protected]>
    Cc: Richard W.M. Jones <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Yu Kuai <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/9p: Fix buffer overflow in USB transport layer [+ + +]
Author: Dominique Martinet <[email protected]>
Date:   Sun Jun 22 22:39:56 2025 +0900

    net/9p: Fix buffer overflow in USB transport layer
    
    commit c04db81cd0288dfc68b7a0f7d09bd49b40bba451 upstream.
    
    A buffer overflow vulnerability exists in the USB 9pfs transport layer
    where inconsistent size validation between packet header parsing and
    actual data copying allows a malicious USB host to overflow heap buffers.
    
    The issue occurs because:
    - usb9pfs_rx_header() validates only the declared size in packet header
    - usb9pfs_rx_complete() uses req->actual (actual received bytes) for
    memcpy
    
    This allows an attacker to craft packets with small declared size
    (bypassing validation) but large actual payload (triggering overflow
    in memcpy).
    
    Add validation in usb9pfs_rx_complete() to ensure req->actual does not
    exceed the buffer capacity before copying data.
    
    Reported-by: Yuhao Jiang <[email protected]>
    Closes: https://lkml.kernel.org/r/[email protected]
    Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport")
    Cc: [email protected]
    Message-ID: <[email protected]>
    Signed-off-by: Dominique Martinet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/mlx5: fw reset, add reset timeout work [+ + +]
Author: Moshe Shemesh <[email protected]>
Date:   Mon Sep 29 00:02:09 2025 +0300

    net/mlx5: fw reset, add reset timeout work
    
    [ Upstream commit 5cfbe7ebfa42fd3c517a701dab5bd73524da9088 ]
    
    Add sync reset timeout to stop poll_sync_reset in case there was no
    reset done or abort event within timeout. Otherwise poll sync reset will
    just continue and in case of fw fatal error no health reporting will be
    done.
    
    Fixes: 38b9f903f22b ("net/mlx5: Handle sync reset request event")
    Signed-off-by: Moshe Shemesh <[email protected]>
    Reviewed-by: Shay Drori <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: pagealloc: Fix reclaim race during command interface teardown [+ + +]
Author: Shay Drory <[email protected]>
Date:   Mon Sep 29 00:02:08 2025 +0300

    net/mlx5: pagealloc: Fix reclaim race during command interface teardown
    
    [ Upstream commit 79a0e32b32ac4e4f9e4bb22be97f371c8c116c88 ]
    
    The reclaim_pages_cmd() function sends a command to the firmware to
    reclaim pages if the command interface is active.
    
    A race condition can occur if the command interface goes down (e.g., due
    to a PCI error) while the mlx5_cmd_do() call is in flight. In this
    case, mlx5_cmd_do() will return an error. The original code would
    propagate this error immediately, bypassing the software-based page
    reclamation logic that is supposed to run when the command interface is
    down.
    
    Fix this by checking whether mlx5_cmd_do() returns -ENXIO, which mark
    that command interface is down. If this is the case, fall through to
    the software reclamation path. If the command failed for any another
    reason, or finished successfully, return as before.
    
    Fixes: b898ce7bccf1 ("net/mlx5: cmdif, Avoid skipping reclaim pages if FW is not accessible")
    Signed-off-by: Shay Drory <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Stop polling for command response if interface goes down [+ + +]
Author: Moshe Shemesh <[email protected]>
Date:   Mon Sep 29 00:02:07 2025 +0300

    net/mlx5: Stop polling for command response if interface goes down
    
    [ Upstream commit b1f0349bd6d320c382df2e7f6fc2ac95c85f2b18 ]
    
    Stop polling on firmware response to command in polling mode if the
    command interface got down. This situation can occur, for example, if a
    firmware fatal error is detected during polling.
    
    This change halts the polling process when the command interface goes
    down, preventing unnecessary waits.
    
    Fixes: b898ce7bccf1 ("net/mlx5: cmdif, Avoid skipping reclaim pages if FW is not accessible")
    Signed-off-by: Moshe Shemesh <[email protected]>
    Reviewed-by: Shay Drori <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: dlink: handle copy_thresh allocation failure [+ + +]
Author: Yeounsu Moon <[email protected]>
Date:   Mon Sep 29 04:01:24 2025 +0900

    net: dlink: handle copy_thresh allocation failure
    
    [ Upstream commit 8169a6011c5fecc6cb1c3654c541c567d3318de8 ]
    
    The driver did not handle failure of `netdev_alloc_skb_ip_align()`.
    If the allocation failed, dereferencing `skb->protocol` could lead to
    a NULL pointer dereference.
    
    This patch tries to allocate `skb`. If the allocation fails, it falls
    back to the normal path.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Suggested-by: Jakub Kicinski <[email protected]>
    Tested-on: D-Link DGE-550T Rev-A3
    Signed-off-by: Yeounsu Moon <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dst: introduce dst->dev_rcu [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:16 2025 +0000

    net: dst: introduce dst->dev_rcu
    
    [ Upstream commit caedcc5b6df1b2e2b5f39079e3369c1d4d5c5f50 ]
    
    Followup of commit 88fe14253e18 ("net: dst: add four helpers
    to annotate data-races around dst->dev").
    
    We want to gradually add explicit RCU protection to dst->dev,
    including lockdep support.
    
    Add an union to alias dst->dev_rcu and dst->dev.
    
    Add dst_dev_net_rcu() helper.
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not configurable [+ + +]
Author: Kohei Enju <[email protected]>
Date:   Mon Sep 29 14:02:22 2025 +0900

    net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not configurable
    
    [ Upstream commit f017156aea60db8720e47591ed1e041993381ad2 ]
    
    In EC2 instances where the RSS hash key is not configurable, ethtool
    shows bogus RSS hash key since ena_get_rxfh_key_size() unconditionally
    returns ENA_HASH_KEY_SIZE.
    
    Commit 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not
    supported") added proper handling for devices that don't support RSS
    hash key configuration, but ena_get_rxfh_key_size() has been unchanged.
    
    When the RSS hash key is not configurable, return 0 instead of
    ENA_HASH_KEY_SIZE to clarify getting the value is not supported.
    
    Tested on m5 instance families.
    
    Without patch:
     # ethtool -x ens5 | grep -A 1 "RSS hash key"
     RSS hash key:
     00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
    
    With patch:
     # ethtool -x ens5 | grep -A 1 "RSS hash key"
     RSS hash key:
     Operation not supported
    
    Fixes: 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not supported")
    Signed-off-by: Kohei Enju <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: enetc: Fix probing error message typo for the ENETCv4 PF driver [+ + +]
Author: Claudiu Manoil <[email protected]>
Date:   Wed Sep 24 16:27:55 2025 +0800

    net: enetc: Fix probing error message typo for the ENETCv4 PF driver
    
    [ Upstream commit c35cf24a69b00b7f54f2f19838f2b82d54480b0f ]
    
    Blamed commit wrongly indicates VF error in case of PF probing error.
    
    Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF")
    Signed-off-by: Claudiu Manoil <[email protected]>
    Signed-off-by: Wei Fang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: enetc: initialize SW PIR and CIR based HW PIR and CIR values [+ + +]
Author: Wei Fang <[email protected]>
Date:   Fri Sep 26 09:39:53 2025 +0800

    net: enetc: initialize SW PIR and CIR based HW PIR and CIR values
    
    [ Upstream commit 2aff4420efc2910e905ee5b000e04e87422aebc4 ]
    
    Software can only initialize the PIR and CIR of the command BD ring after
    a FLR, and these two registers can only be set to 0. But the reset values
    of these two registers are 0, so software does not need to update them.
    If there is no a FLR and PIR and CIR are not 0, resetting them to 0 or
    other values by software will cause the command BD ring to work
    abnormally. This is because of an internal context in the ring prefetch
    logic that will retain the state from the first incarnation of the ring
    and continue prefetching from the stale location when the ring is
    reinitialized. The internal context can only be reset by the FLR.
    
    In addition, there is a logic error in the implementation, next_to_clean
    indicates the software CIR and next_to_use indicates the software PIR.
    But the current driver uses next_to_clean to set PIR and use next_to_use
    to set CIR. This does not cause a problem in actual use, because the
    current command BD ring is only initialized after FLR, and the initial
    values of next_to_use and next_to_clean are both 0.
    
    Therefore, this patch removes the initialization of PIR and CIR. Instead,
    next_to_use and next_to_clean are initialized by reading the values of
    PIR and CIR.
    
    Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP")
    Signed-off-by: Wei Fang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethtool: tsconfig: set command must provide a reply [+ + +]
Author: Vadim Fedorenko <[email protected]>
Date:   Mon Sep 22 16:19:24 2025 -0700

    net: ethtool: tsconfig: set command must provide a reply
    
    [ Upstream commit e8ab231782e92bc26e5eb605263525636a2f7ae7 ]
    
    Timestamping configuration through ethtool has inconsistent behavior of
    skipping the reply for set command if configuration was not changed. Fix
    it be providing reply in any case.
    
    Fixes: 6e9e2eed4f39d ("net: ethtool: Add support for tsconfig command to get/set hwtstamp config")
    Signed-off-by: Vadim Fedorenko <[email protected]>
    Reviewed-by: Kory Maincent <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: macb: move ring size computation to functions [+ + +]
Author: Théo Lebrun <[email protected]>
Date:   Tue Sep 23 18:00:25 2025 +0200

    net: macb: move ring size computation to functions
    
    [ Upstream commit 92d4256fafd8d0a14d3aaa10452ac771bf9b597c ]
    
    The tx/rx ring size calculation is somewhat complex and partially hidden
    behind a macro. Move that out of the {RX,TX}_RING_BYTES() macros and
    macb_{alloc,free}_consistent() functions into neat separate functions.
    
    In macb_free_consistent(), we drop the size variable and directly call
    the size helpers in the arguments list. In macb_alloc_consistent(), we
    keep the size variable that is used by netdev_dbg() calls.
    
    Acked-by: Nicolas Ferre <[email protected]>
    Signed-off-by: Théo Lebrun <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 78d901897b3c ("net: macb: single dma_alloc_coherent() for DMA descriptors")
    Signed-off-by: Sasha Levin <[email protected]>

net: macb: remove illusion about TBQPH/RBQPH being per-queue [+ + +]
Author: Théo Lebrun <[email protected]>
Date:   Tue Sep 23 18:00:24 2025 +0200

    net: macb: remove illusion about TBQPH/RBQPH being per-queue
    
    [ Upstream commit fca3dc859b200ca4dcdd2124beaf3bb2ab80b0f7 ]
    
    The MACB driver acts as if TBQPH/RBQPH are configurable on a per queue
    basis; this is a lie. A single register configures the upper 32 bits of
    each DMA descriptor buffers for all queues.
    
    Concrete actions:
    
     - Drop GEM_TBQPH/GEM_RBQPH macros which have a queue index argument.
       Only use MACB_TBQPH/MACB_RBQPH constants.
    
     - Drop struct macb_queue->TBQPH/RBQPH fields.
    
     - In macb_init_buffers(): do a single write to TBQPH and RBQPH for all
       queues instead of a write per queue.
    
     - In macb_tx_error_task(): drop the write to TBQPH.
    
     - In macb_alloc_consistent(): if allocations give different upper
       32-bits, fail. Previously, it would have lead to silent memory
       corruption as queues would have used the upper 32 bits of the alloc
       from queue 0 and their own low 32 bits.
    
     - In macb_suspend(): if we use the tie off descriptor for suspend, do
       the write once for all queues instead of once per queue.
    
    Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM")
    Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues")
    Reviewed-by: Sean Anderson <[email protected]>
    Acked-by: Nicolas Ferre <[email protected]>
    Signed-off-by: Théo Lebrun <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: macb: single dma_alloc_coherent() for DMA descriptors [+ + +]
Author: Théo Lebrun <[email protected]>
Date:   Tue Sep 23 18:00:26 2025 +0200

    net: macb: single dma_alloc_coherent() for DMA descriptors
    
    [ Upstream commit 78d901897b3cae06b38f54e48a2378cf9da21175 ]
    
    Move from 2*NUM_QUEUES dma_alloc_coherent() for DMA descriptor rings to
    2 calls overall.
    
    Issue is with how all queues share the same register for configuring the
    upper 32-bits of Tx/Rx descriptor rings. Taking Tx, notice how TBQPH
    does *not* depend on the queue index:
    
            #define GEM_TBQP(hw_q)          (0x0440 + ((hw_q) << 2))
            #define GEM_TBQPH(hw_q)         (0x04C8)
    
            queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma));
            #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
            if (bp->hw_dma_cap & HW_DMA_CAP_64B)
                    queue_writel(queue, TBQPH, upper_32_bits(queue->tx_ring_dma));
            #endif
    
    To maximise our chances of getting valid DMA addresses, we do a single
    dma_alloc_coherent() across queues. This improves the odds because
    alloc_pages() guarantees natural alignment. Other codepaths (IOMMU or
    dev/arch dma_map_ops) don't give high enough guarantees
    (even page-aligned isn't enough).
    
    Two consideration:
    
     - dma_alloc_coherent() gives us page alignment. Here we remove this
       constraint meaning each queue's ring won't be page-aligned anymore.
    
     - This can save some tiny amounts of memory. Fewer allocations means
       (1) less overhead (constant cost per alloc) and (2) less wasted bytes
       due to alignment constraints.
    
       Example for (2): 4 queues, default ring size (512), 64-bit DMA
       descriptors, 16K pages:
        - Before: 8 allocs of 8K, each rounded to 16K => 64K wasted.
        - After:  2 allocs of 32K => 0K wasted.
    
    Fixes: 02c958dd3446 ("net/macb: add TX multiqueue support for gem")
    Reviewed-by: Sean Anderson <[email protected]>
    Acked-by: Nicolas Ferre <[email protected]>
    Tested-by: Nicolas Ferre <[email protected]> # on sam9x75
    Signed-off-by: Théo Lebrun <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: nfc: nci: Add parameter validation for packet data [+ + +]
Author: Deepak Sharma <[email protected]>
Date:   Thu Sep 25 18:58:46 2025 +0530

    net: nfc: nci: Add parameter validation for packet data
    
    commit 9c328f54741bd5465ca1dc717c84c04242fac2e1 upstream.
    
    Syzbot reported an uninitialized value bug in nci_init_req, which was
    introduced by commit 5aca7966d2a7 ("Merge tag
    'perf-tools-fixes-for-v6.17-2025-09-16' of
    git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").
    
    This bug arises due to very limited and poor input validation
    that was done at nic_valid_size(). This validation only
    validates the skb->len (directly reflects size provided at the
    userspace interface) with the length provided in the buffer
    itself (interpreted as NCI_HEADER). This leads to the processing
    of memory content at the address assuming the correct layout
    per what opcode requires there. This leads to the accesses to
    buffer of `skb_buff->data` which is not assigned anything yet.
    
    Following the same silent drop of packets of invalid sizes at
    `nic_valid_size()`, add validation of the data in the respective
    handlers and return error values in case of failure. Release
    the skb if error values are returned from handlers in
    `nci_nft_packet` and effectively do a silent drop
    
    Possible TODO: because we silently drop the packets, the
    call to `nci_request` will be waiting for completion of request
    and will face timeouts. These timeouts can get excessively logged
    in the dmesg. A proper handling of them may require to export
    `nci_request_cancel` (or propagate error handling from the
    nft packets handlers).
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=740e04c2a93467a0f8c8
    Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
    Tested-by: [email protected]
    Cc: [email protected]
    Signed-off-by: Deepak Sharma <[email protected]>
    Reviewed-by: Vadim Fedorenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: phy: as21xxx: better handle PHY HW reset on soft-reboot [+ + +]
Author: Christian Marangi <[email protected]>
Date:   Sat Aug 23 15:44:29 2025 +0200

    net: phy: as21xxx: better handle PHY HW reset on soft-reboot
    
    [ Upstream commit b4d5cd20507b252c746fa6971d82ac96f3b3e5b7 ]
    
    On soft-reboot, with a reset GPIO defined for an Aeonsemi PHY, the
    special match_phy_device fails to correctly identify that the PHY
    needs to load the firmware again.
    
    This is caused by the fact that PHY ID is read BEFORE the PHY reset
    GPIO (if present) is asserted, so we can be in the scenario where the
    phydev have the previous PHY ID (with the PHY firmware loaded) but
    after reset the generic AS21xxx PHY is present in the PHY ID registers.
    
    To better handle this, skip reading the PHY ID register only for the PHY
    that are not AS21xxx (by matching for the Aeonsemi Vendor) and always
    read the PHY ID for the other case to handle both firmware already
    loaded or an HW reset.
    
    Fixes: 830877d89edc ("net: phy: Add support for Aeonsemi AS21xxx PHYs")
    Signed-off-by: Christian Marangi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: introduce phy_id_compare_vendor() PHY ID helper [+ + +]
Author: Christian Marangi <[email protected]>
Date:   Sat Aug 23 15:44:28 2025 +0200

    net: phy: introduce phy_id_compare_vendor() PHY ID helper
    
    [ Upstream commit 1abe21ef1adf0c5b6dbb5878c2fa4573df8d29fc ]
    
    Introduce phy_id_compare_vendor() PHY ID helper to compare a PHY ID with
    the PHY ID Vendor using the generic PHY ID Vendor mask.
    
    While at it also rework the PHY_ID_MATCH macro and move the mask to
    dedicated define so that PHY driver can make use of the mask if needed.
    
    Signed-off-by: Christian Marangi <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: b4d5cd20507b ("net: phy: as21xxx: better handle PHY HW reset on soft-reboot")
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock [+ + +]
Author: Oleksij Rempel <[email protected]>
Date:   Sun Oct 5 10:12:03 2025 +0200

    net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock
    
    commit 3d3c4cd5c62f24bb3cb4511b7a95df707635e00a upstream.
    
    Prevent USB runtime PM (autosuspend) for AX88772* in bind.
    
    usbnet enables runtime PM (autosuspend) by default, so disabling it via
    the usb_driver flag is ineffective. On AX88772B, autosuspend shows no
    measurable power saving with current driver (no link partner, admin
    up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering
    the PHY off on admin-down, not from USB autosuspend.
    
    The real hazard is that with runtime PM enabled, ndo_open() (under RTNL)
    may synchronously trigger autoresume (usb_autopm_get_interface()) into
    asix_resume() while the USB PM lock is held. Resume paths then invoke
    phylink/phylib and MDIO, which also expect RTNL, leading to possible
    deadlocks or PM lock vs MDIO wake issues.
    
    To avoid this, keep the device runtime-PM active by taking a usage
    reference in ax88772_bind() and dropping it in unbind(). A non-zero PM
    usage count blocks runtime suspend regardless of userspace policy
    (.../power/control - pm_runtime_allow/forbid), making this approach
    robust against sysfs overrides.
    
    Holding a runtime-PM usage ref does not affect system-wide suspend;
    system sleep/resume callbacks continue to run as before.
    
    Fixes: 4a2c7217cd5a ("net: usb: asix: ax88772: manage PHY PM from MAC")
    Reported-by: Hubert Wiśniewski <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Tested-by: Hubert Wiśniewski <[email protected]>
    Reported-by: Marek Szyprowski <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Cc: [email protected]
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast [+ + +]
Author: I Viswanath <[email protected]>
Date:   Wed Sep 24 19:13:50 2025 +0530

    net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast
    
    [ Upstream commit 958baf5eaee394e5fd976979b0791a875f14a179 ]
    
    syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.
    This is the sequence of events that leads to the warning:
    
    rtl8150_start_xmit() {
            netif_stop_queue();
            usb_submit_urb(dev->tx_urb);
    }
    
    rtl8150_set_multicast() {
            netif_stop_queue();
            netif_wake_queue();             <-- wakes up TX queue before URB is done
    }
    
    rtl8150_start_xmit() {
            netif_stop_queue();
            usb_submit_urb(dev->tx_urb);    <-- double submission
    }
    
    rtl8150_set_multicast being the ndo_set_rx_mode callback should not be
    calling netif_stop_queue and notif_start_queue as these handle
    TX queue synchronization.
    
    The net core function dev_set_rx_mode handles the synchronization
    for rtl8150_set_multicast making it safe to remove these locks.
    
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=78cae3f37c62ad092caa
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Tested-by: Michal Pecio <[email protected]>
    Signed-off-by: I Viswanath <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: use dst_dev_rcu() in sk_setup_caps() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:20 2025 +0000

    net: use dst_dev_rcu() in sk_setup_caps()
    
    [ Upstream commit 99a2ace61b211b0be861b07fbaa062fca4b58879 ]
    
    Use RCU to protect accesses to dst->dev from sk_setup_caps()
    and sk_dst_gso_max_size().
    
    Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),
    and ip_dst_mtu_maybe_forward().
    
    ip4_dst_hoplimit() can use dst_dev_net_rcu().
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: ipset: Remove unused htable_bits in macro ahash_region [+ + +]
Author: Zhen Ni <[email protected]>
Date:   Fri Aug 29 16:36:21 2025 +0800

    netfilter: ipset: Remove unused htable_bits in macro ahash_region
    
    [ Upstream commit ba941796d7cd1e81f51eed145dad1b47240ff420 ]
    
    Since the ahash_region() macro was redefined to calculate the region
    index solely from HTABLE_REGION_BITS, the htable_bits parameter became
    unused.
    
    Remove the unused htable_bits argument and its call sites, simplifying
    the code without changing semantics.
    
    Fixes: 8478a729c046 ("netfilter: ipset: fix region locking in hash types")
    Signed-off-by: Zhen Ni <[email protected]>
    Reviewed-by: Phil Sutter <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_conntrack: do not skip entries in /proc/net/nf_conntrack [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Sep 24 07:27:09 2025 +0000

    netfilter: nf_conntrack: do not skip entries in /proc/net/nf_conntrack
    
    [ Upstream commit c5ba345b2d358b07cc4f07253ba1ada73e77d586 ]
    
    ct_seq_show() has an opportunistic garbage collector :
    
    if (nf_ct_should_gc(ct)) {
        nf_ct_kill(ct);
        goto release;
    }
    
    So if one nf_conn is killed there, next time ct_get_next() runs,
    we skip the following item in the bucket, even if it should have
    been displayed if gc did not take place.
    
    We can decrement st->skip_elems to tell ct_get_next() one of the items
    was removed from the chain.
    
    Fixes: 58e207e4983d ("netfilter: evict stale entries when user reads /proc/net/nf_conntrack")
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nfnetlink: reset nlh pointer during batch replay [+ + +]
Author: Fernando Fernandez Mancera <[email protected]>
Date:   Fri Sep 19 14:40:43 2025 +0200

    netfilter: nfnetlink: reset nlh pointer during batch replay
    
    [ Upstream commit 09efbac953f6f076a07735f9ba885148d4796235 ]
    
    During a batch replay, the nlh pointer is not reset until the parsing of
    the commands. Since commit bf2ac490d28c ("netfilter: nfnetlink: Handle
    ACK flags for batch messages") that is problematic as the condition to
    add an ACK for batch begin will evaluate to true even if NLM_F_ACK
    wasn't used for batch begin message.
    
    If there is an error during the command processing, netlink is sending
    an ACK despite that. This misleads userspace tools which think that the
    return code was 0. Reset the nlh pointer to the original one when a
    replay is triggered.
    
    Fixes: bf2ac490d28c ("netfilter: nfnetlink: Handle ACK flags for batch messages")
    Signed-off-by: Fernando Fernandez Mancera <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfp: fix RSS hash key size when RSS is not supported [+ + +]
Author: Kohei Enju <[email protected]>
Date:   Mon Sep 29 14:42:15 2025 +0900

    nfp: fix RSS hash key size when RSS is not supported
    
    [ Upstream commit 8425161ac1204d2185e0a10f5ae652bae75d2451 ]
    
    The nfp_net_get_rxfh_key_size() function returns -EOPNOTSUPP when
    devices don't support RSS, and callers treat the negative value as a
    large positive value since the return type is u32.
    
    Return 0 when devices don't support RSS, aligning with the ethtool
    interface .get_rxfh_key_size() that requires returning 0 in such cases.
    
    Fixes: 9ff304bfaf58 ("nfp: add support for reporting CRC32 hash function")
    Signed-off-by: Kohei Enju <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs/localio: avoid issuing misaligned IO using O_DIRECT [+ + +]
Author: Mike Snitzer <[email protected]>
Date:   Fri Sep 19 10:36:26 2025 -0400

    nfs/localio: avoid issuing misaligned IO using O_DIRECT
    
    [ Upstream commit 25ba2b84c38f624151a3ba36e56d41c39b9223ad ]
    
    Add nfsd_file_dio_alignment and use it to avoid issuing misaligned IO
    using O_DIRECT. Any misaligned DIO falls back to using buffered IO.
    
    Because misaligned DIO is now handled safely, remove the nfs modparam
    'localio_O_DIRECT_semantics' that was added to require users opt-in to
    the requirement that all O_DIRECT be properly DIO-aligned.
    
    Also, introduce nfs_iov_iter_aligned_bvec() which is a variant of
    iov_iter_aligned_bvec() that also verifies the offset associated with
    an iov_iter is DIO-aligned.  NOTE: in a parallel effort,
    iov_iter_aligned_bvec() is being removed along with
    iov_iter_is_aligned().
    
    Lastly, add pr_info_ratelimited if underlying filesystem returns
    -EINVAL because it was made to try O_DIRECT for IO that is not
    DIO-aligned (shouldn't happen, so its best to be louder if it does).
    
    Fixes: 3feec68563d ("nfs/localio: add direct IO enablement with sync and async IO support")
    Signed-off-by: Mike Snitzer <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSD: filecache: add STATX_DIOALIGN and STATX_DIO_READ_ALIGN support [+ + +]
Author: Mike Snitzer <[email protected]>
Date:   Mon Sep 29 11:56:41 2025 -0400

    NFSD: filecache: add STATX_DIOALIGN and STATX_DIO_READ_ALIGN support
    
    [ Upstream commit d11f6cd1bb4a416b4515702d020a7480ac667f0f ]
    
    Use STATX_DIOALIGN and STATX_DIO_READ_ALIGN to get DIO alignment
    attributes from the underlying filesystem and store them in the
    associated nfsd_file. This is done when the nfsd_file is first
    opened for each regular file.
    
    Signed-off-by: Mike Snitzer <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: NeilBrown <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Acked-by: Chuck Lever <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Stable-dep-of: 25ba2b84c38f ("nfs/localio: avoid issuing misaligned IO using O_DIRECT")
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.1: fix backchannel max_resp_sz verification check [+ + +]
Author: Anthony Iliopoulos <[email protected]>
Date:   Wed Aug 13 11:00:46 2025 +0200

    NFSv4.1: fix backchannel max_resp_sz verification check
    
    [ Upstream commit 191512355e520dfc45c8bc3b56d4de59c3ade33e ]
    
    When the client max_resp_sz is larger than what the server encodes in
    its reply, the nfs4_verify_back_channel_attrs() check fails and this
    causes nfs4_proc_create_session() to fail, in cases where the client
    page size is larger than that of the server and the server does not want
    to negotiate upwards.
    
    While this is not a problem with the linux nfs server that will reflect
    the proposed value in its reply irrespective of the local page size,
    other nfs server implementations may insist on their own max_resp_sz
    value, which could be smaller.
    
    Fix this by accepting smaller max_resp_sz values from the server, as
    this does not violate the protocol. The server is allowed to decrease
    but not increase proposed the size, and as such values smaller than the
    client-proposed ones are valid.
    
    Fixes: 43c2e885be25 ("nfs4: fix channel attribute sanity-checks")
    Signed-off-by: Anthony Iliopoulos <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
null_blk: Fix the description of the cache_size module argument [+ + +]
Author: Genjian Zhang <[email protected]>
Date:   Fri Aug 15 17:07:32 2025 +0800

    null_blk: Fix the description of the cache_size module argument
    
    [ Upstream commit 7942b226e6b84df13b46b76c01d3b6e07a1b349e ]
    
    When executing modinfo null_blk, there is an error in the description
    of module parameter mbps, and the output information of cache_size is
    incomplete.The output of modinfo before and after applying this patch
    is as follows:
    
    Before:
    [...]
    parm:           cache_size:ulong
    [...]
    parm:           mbps:Cache size in MiB for memory-backed device.
                    Default: 0 (none) (uint)
    [...]
    
    After:
    [...]
    parm:           cache_size:Cache size in MiB for memory-backed device.
                    Default: 0 (none) (ulong)
    [...]
    parm:           mbps:Limit maximum bandwidth (in MiB/s).
                    Default: 0 (no limit) (uint)
    [...]
    
    Fixes: 058efe000b31 ("null_blk: add module parameters for 4 options")
    Signed-off-by: Genjian Zhang <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe() [+ + +]
Author: Guangshuo Li <[email protected]>
Date:   Thu Sep 25 14:44:48 2025 +0800

    nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe()
    
    commit a9e6aa994917ee602798bbb03180a194b37865bb upstream.
    
    devm_kcalloc() may fail. ndtest_probe() allocates three DMA address
    arrays (dcr_dma, label_dma, dimm_dma) and later unconditionally uses
    them in ndtest_nvdimm_init(), which can lead to a NULL pointer
    dereference under low-memory conditions.
    
    Check all three allocations and return -ENOMEM if any allocation fails,
    jumping to the common error path. Do not emit an extra error message
    since the allocator already warns on allocation failure.
    
    Fixes: 9399ab61ad82 ("ndtest: Add dimms to the two buses")
    Cc: [email protected]
    Signed-off-by: Guangshuo Li <[email protected]>
    Reviewed-by: Alison Schofield <[email protected]>
    Reviewed-by: Ira Weiny <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Ira Weiny <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvme-auth: update bi_directional flag [+ + +]
Author: Martin George <[email protected]>
Date:   Mon Sep 15 17:19:21 2025 +0530

    nvme-auth: update bi_directional flag
    
    [ Upstream commit 6ff1bd7846680dfdaafc68d7fcd0ab7e3bcbc4a0 ]
    
    While setting chap->s2 to zero as part of secure channel
    concatenation, the host missed out to disable the bi_directional
    flag to indicate that controller authentication is not requested.
    Fix the same.
    
    Fixes: e88a7595b57f ("nvme-tcp: request secure channel concatenation")
    Signed-off-by: Martin George <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme-tcp: send only permitted commands for secure concat [+ + +]
Author: Martin George <[email protected]>
Date:   Tue Sep 9 16:05:09 2025 +0530

    nvme-tcp: send only permitted commands for secure concat
    
    [ Upstream commit df4666a4908a6d883f628f93a3e6c80981332035 ]
    
    In addition to sending permitted commands such as connect/auth
    over the initial unencrypted admin connection as part of secure
    channel concatenation, the host also sends commands such as
    Property Get and Identify on the same. This is a spec violation
    leading to secure concat failures. Fix this by ensuring these
    additional commands are avoided on this connection.
    
    Fixes: 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure concatenation")
    Signed-off-by: Martin George <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet-fc: move lsop put work to nvmet_fc_ls_req_op [+ + +]
Author: Daniel Wagner <[email protected]>
Date:   Tue Sep 2 12:22:00 2025 +0200

    nvmet-fc: move lsop put work to nvmet_fc_ls_req_op
    
    [ Upstream commit db5a5406fb7e5337a074385c7a3e53c77f2c1bd3 ]
    
    It’s possible for more than one async command to be in flight from
    __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.
    
    In the current code, only one put work item is queued at a time, which
    results in a leaked reference.
    
    To fix this, move the work item to the nvmet_fc_ls_req_op struct, which
    already tracks all resources related to the command.
    
    Fixes: 710c69dbaccd ("nvmet-fc: avoid deadlock on delete association path")
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Daniel Wagner <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet-fcloop: call done callback even when remote port is gone [+ + +]
Author: Daniel Wagner <[email protected]>
Date:   Tue Sep 2 12:22:02 2025 +0200

    nvmet-fcloop: call done callback even when remote port is gone
    
    [ Upstream commit 10c165af35d225eb033f4edc7fcc699a8d2d533d ]
    
    When the target port is gone, it's not possible to access any of the
    request resources. The function should just silently drop the response.
    The comment is misleading in this regard.
    
    Though it's still necessary to call the driver via the ->done callback
    so the driver is able to release all resources.
    
    Reported-by: Yi Zhang <[email protected]>
    Closes: https://lore.kernel.org/all/CAHj4cs-OBA0WMt5f7R0dz+rR4HcEz19YLhnyGsj-MRV3jWDsPg@mail.gmail.com/
    Fixes: 84eedced1c5b ("nvmet-fcloop: drop response if targetport is gone")
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Daniel Wagner <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ocfs2: fix double free in user_cluster_connect() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Sep 23 14:26:07 2025 +0300

    ocfs2: fix double free in user_cluster_connect()
    
    [ Upstream commit 8f45f089337d924db24397f55697cda0e6960516 ]
    
    user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then
    the error handling frees "lc" a second time.  Set "lc" to NULL on this
    path to avoid a double free.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: c994c2ebdbbc ("ocfs2: use the new DLM operation callbacks while requesting new lockspace")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Reviewed-by: Goldwyn Rodrigues <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Jun Piao <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-pf: fix bitmap leak [+ + +]
Author: Bo Sun <[email protected]>
Date:   Tue Sep 30 14:12:36 2025 +0800

    octeontx2-pf: fix bitmap leak
    
    [ Upstream commit 92e9f4faffca70c82126e59552f6e8ff8f95cc65 ]
    
    The bitmap allocated with bitmap_zalloc() in otx2_probe() was not
    released in otx2_remove(). Unbinding and rebinding the driver therefore
    triggers a kmemleak warning:
    
        unreferenced object (size 8):
          backtrace:
            bitmap_zalloc
            otx2_probe
    
    Call bitmap_free() in the remove path to fix the leak.
    
    Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support")
    Signed-off-by: Bo Sun <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-vf: fix bitmap leak [+ + +]
Author: Bo Sun <[email protected]>
Date:   Tue Sep 30 14:12:35 2025 +0800

    octeontx2-vf: fix bitmap leak
    
    [ Upstream commit cd9ea7da41a449ff1950230a35990155457b9879 ]
    
    The bitmap allocated with bitmap_zalloc() in otx2vf_probe() was not
    released in otx2vf_remove(). Unbinding and rebinding the driver therefore
    triggers a kmemleak warning:
    
        unreferenced object (size 8):
          backtrace:
            bitmap_zalloc
            otx2vf_probe
    
    Call bitmap_free() in the remove path to fix the leak.
    
    Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support")
    Signed-off-by: Bo Sun <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
once: fix race by moving DO_ONCE to separate section [+ + +]
Author: Qi Xi <[email protected]>
Date:   Tue Sep 9 19:29:10 2025 +0800

    once: fix race by moving DO_ONCE to separate section
    
    [ Upstream commit edcc8a38b5ac1a3dbd05e113a38a25b937ebefe5 ]
    
    The commit c2c60ea37e5b ("once: use __section(".data.once")") moved
    DO_ONCE's ___done variable to .data.once section, which conflicts with
    DO_ONCE_LITE() that also uses the same section.
    
    This creates a race condition when clear_warn_once is used:
    
    Thread 1 (DO_ONCE)             Thread 2 (DO_ONCE)
    __do_once_start
        read ___done (false)
        acquire once_lock
    execute func
    __do_once_done
        write ___done (true)      __do_once_start
        release once_lock             // Thread 3 clear_warn_once reset ___done
                                      read ___done (false)
                                      acquire once_lock
                                  execute func
    schedule once_work            __do_once_done
    once_deferred: OK             write ___done (true)
    static_branch_disable         release once_lock
                                  schedule once_work
                                  once_deferred:
                                      BUG_ON(!static_key_enabled)
    
    DO_ONCE_LITE() in once_lite.h is used by WARN_ON_ONCE() and other warning
    macros. Keep its ___done flag in the .data..once section and allow resetting
    by clear_warn_once, as originally intended.
    
    In contrast, DO_ONCE() is used for functions like get_random_once() and
    relies on its ___done flag for internal synchronization. We should not reset
    DO_ONCE() by clear_warn_once.
    
    Fix it by isolating DO_ONCE's ___done into a separate .data..do_once section,
    shielding it from clear_warn_once.
    
    Fixes: c2c60ea37e5b ("once: use __section(".data.once")")
    Reported-by: Hulk Robot <[email protected]>
    Signed-off-by: Qi Xi <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/ACPI: Fix pci_acpi_preserve_config() memory leak [+ + +]
Author: Nirmoy Das <[email protected]>
Date:   Mon Aug 25 14:46:42 2025 -0700

    PCI/ACPI: Fix pci_acpi_preserve_config() memory leak
    
    [ Upstream commit fac679df7580979174c90303f004b09cdc6f086f ]
    
    pci_acpi_preserve_config() leaks memory by returning early without freeing
    the ACPI object on success. Fix that by always freeing the obj, which is
    not needed by the caller.
    
    Fixes: 9d7d5db8e78e ("PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge()")
    Signed-off-by: Nirmoy Das <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/AER: Avoid NULL pointer dereference in aer_ratelimit() [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Mon Sep 29 02:15:47 2025 -0700

    PCI/AER: Avoid NULL pointer dereference in aer_ratelimit()
    
    commit deb2f228388ff3a9d0623e3b59a053e9235c341d upstream.
    
    When platform firmware supplies error information to the OS, e.g., via the
    ACPI APEI GHES mechanism, it may identify an error source device that
    doesn't advertise an AER Capability and therefore dev->aer_info, which
    contains AER stats and ratelimiting data, is NULL.
    
    pci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but
    aer_ratelimit() did not, leading to NULL pointer dereferences like this one
    from the URL below:
    
      {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
      {1}[Hardware Error]: event severity: corrected
      {1}[Hardware Error]:   device_id: 0000:00:00.0
      {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2020
      {1}[Hardware Error]:   aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000
      BUG: kernel NULL pointer dereference, address: 0000000000000264
      RIP: 0010:___ratelimit+0xc/0x1b0
      pci_print_aer+0x141/0x360
      aer_recover_work_func+0xb5/0x130
    
    [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to
    be a Root Port but does not advertise an AER Capability.
    
    Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference.
    Note that this also prevents ratelimiting these events from GHES.
    
    Fixes: a57f2bfb4a5863 ("PCI/AER: Ratelimit correctable and non-fatal error logging")
    Link: https://lore.kernel.org/r/buduna6darbvwfg3aogl5kimyxkggu3n4romnmq6sozut6axeu@clnx7sfsy457/
    Signed-off-by: Breno Leitao <[email protected]>
    [bhelgaas: add crash details to commit log]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI/MSI: Add startup/shutdown for per device domains [+ + +]
Author: Inochi Amaoto <[email protected]>
Date:   Thu Aug 14 07:28:32 2025 +0800

    PCI/MSI: Add startup/shutdown for per device domains
    
    [ Upstream commit 54f45a30c0d0153d2be091ba2d683ab6db6d1d5b ]
    
    As the RISC-V PLIC cannot apply affinity settings without invoking
    irq_enable(), it will make the interrupt unavailble when used as an
    underlying interrupt chip for the MSI controller.
    
    Implement the irq_startup() and irq_shutdown() callbacks for the PCI MSI
    and MSI-X templates.
    
    For chips that specify MSI_FLAG_PCI_MSI_STARTUP_PARENT, the parent startup
    and shutdown functions are invoked. That allows the interrupt on the parent
    chip to be enabled if the interrupt has not been enabled during
    allocation. This is necessary for MSI controllers which use PLIC as
    underlying parent interrupt chip.
    
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Inochi Amaoto <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Chen Wang <[email protected]> # Pioneerbox
    Reviewed-by: Chen Wang <[email protected]>
    Acked-by: Bjorn Helgaas <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Stable-dep-of: 9d8c41816bac ("irqchip/sg2042-msi: Fix broken affinity setting")
    Signed-off-by: Sasha Levin <[email protected]>

PCI/MSI: Check MSI_FLAG_PCI_MSI_MASK_PARENT in cond_[startup|shutdown]_parent() [+ + +]
Author: Inochi Amaoto <[email protected]>
Date:   Thu Aug 28 07:09:42 2025 +0800

    PCI/MSI: Check MSI_FLAG_PCI_MSI_MASK_PARENT in cond_[startup|shutdown]_parent()
    
    [ Upstream commit 727e914bbfbbda9e6efa5cb1abe4e96a949d576f ]
    
    For MSI controllers which only support MSI_FLAG_PCI_MSI_MASK_PARENT, the
    newly added callback irq_startup() and irq_shutdown() for
    pci_msi[x]_template will not unmask or mask the interrupt when startup()
    resp.  shutdown() is invoked. This prevents the interrupt from being
    enabled resp. disabled.
    
    Invoke irq_[un]mask_parent() in cond_[startup|shutdown]_parent(), when the
    interrupt has the MSI_FLAG_PCI_MSI_MASK_PARENT flag set.
    
    Fixes: 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains")
    Reported-by: Linux Kernel Functional Testing <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Reported-by: Wei Fang <[email protected]>
    Signed-off-by: Inochi Amaoto <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Wei Fang <[email protected]>
    Tested-by: Chen Wang <[email protected]> # Pioneerbox/SG2042
    Acked-by: Bjorn Helgaas <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Closes: https://lore.kernel.org/regressions/aK4O7Hl8NCVEMznB@monster/
    Closes: https://lore.kernel.org/regressions/20250826220959.GA4119563@ax162/
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Aug 13 17:56:25 2025 +0200

    PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure
    
    [ Upstream commit ab81f2f79c683c94bac622aafafbe8232e547159 ]
    
    When devm_add_action_or_reset() fails, it calls the passed cleanup
    function.  Hence the caller must not repeat that cleanup.
    
    Replace the "goto err_regulator_free" by the actual freeing, as there
    will never be a need again for a second user of this label.
    
    Fixes: 75996c92f4de309f ("PCI/pwrctrl: Add pwrctrl driver for PCI slots")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Marek Vasut <[email protected]> # V4H Sparrow Hawk
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Marek Vasut <[email protected]>
    Acked-by: Bartosz Golaszewski <[email protected]>
    Link: https://patch.msgid.link/7b1386e6162e70e6d631c87f6323d2ab971bc1c5.1755100324.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: endpoint: pci-ep-msi: Fix NULL vs IS_ERR() check in pci_epf_write_msi_msg() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Aug 1 16:34:45 2025 +0300

    PCI: endpoint: pci-ep-msi: Fix NULL vs IS_ERR() check in pci_epf_write_msi_msg()
    
    [ Upstream commit 57a75fa9d56e310e883e4377205690e88c05781b ]
    
    The pci_epc_get() function returns error pointers. It never returns NULL.
    Update the check to match.
    
    Fixes: 1c3b002c6bf6 ("PCI: endpoint: Add RC-to-EP doorbell support using platform MSI controller")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release [+ + +]
Author: Shin'ichiro Kawasaki <[email protected]>
Date:   Tue Sep 16 11:57:56 2025 +0900

    PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release
    
    commit 85afa9ea122dd9d4a2ead104a951d318975dcd25 upstream.
    
    The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be
    NULL even after EPF initialization. Then it is prudent to check that
    they have non-NULL values before releasing the channels. Add the checks
    in pci_epf_test_clean_dma_chan().
    
    Without the checks, NULL pointer dereferences happen and they can lead
    to a kernel panic in some cases:
    
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
      Call trace:
       dma_release_channel+0x2c/0x120 (P)
       pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]
       pci_epc_deinit_notify+0x74/0xc0
       tegra_pcie_ep_pex_rst_irq+0x250/0x5d8
       irq_thread_fn+0x34/0xb8
       irq_thread+0x18c/0x2e8
       kthread+0x14c/0x210
       ret_from_fork+0x10/0x20
    
    Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities")
    Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data")
    Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
    [mani: trimmed the stack trace]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: Krzysztof Wilczyński <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: endpoint: pci-epf-test: Fix doorbell test support [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Mon Sep 8 18:19:42 2025 +0200

    PCI: endpoint: pci-epf-test: Fix doorbell test support
    
    [ Upstream commit f272210b28d050df56ec7dfaecb9fa3bebca6419 ]
    
    The doorbell feature temporarily overrides the inbound translation to point
    to the address stored in epf_test->db_bar.phys_addr, i.e., it calls
    set_bar() twice without ever calling clear_bar(), as calling clear_bar()
    would clear the BAR's PCI address assigned by the host.
    
    Thus, when disabling the doorbell, restore the inbound translation to point
    to the memory allocated for the BAR.
    
    Without this, running the PCI endpoint kselftest doorbell test case more
    than once would fail.
    
    Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support")
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: j721e: Fix incorrect error message in probe() [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Fri Sep 5 14:14:34 2025 -0700

    PCI: j721e: Fix incorrect error message in probe()
    
    [ Upstream commit cfcd6cab2f33c24a68517f9e3131480b4000c2be ]
    
    The probe() function prints "pm_runtime_get_sync failed" when
    j721e_pcie_ctrl_init() returns an error. This is misleading since
    the failure is not from pm_runtime, but from the controller init
    routine. Update the error message to correctly reflect the source.
    
    No functional changes.
    
    Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
    Signed-off-by: Alok Tiwari <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Siddharth Vadapalli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: qcom: Add equalization settings for 8.0 GT/s and 32.0 GT/s [+ + +]
Author: Ziyue Zhang <[email protected]>
Date:   Thu Sep 4 14:52:23 2025 +0800

    PCI: qcom: Add equalization settings for 8.0 GT/s and 32.0 GT/s
    
    [ Upstream commit 37bf0f4e39de9b53bc6f8d3702b021e2c6b5bae3 ]
    
    Add lane equalization setting for 8.0 GT/s and 32.0 GT/s to enhance link
    stability and avoid AER Correctable Errors reported on some platforms
    (eg. SA8775P).
    
    8.0 GT/s, 16.0 GT/s and 32.0 GT/s require the same equalization setting.
    This setting is programmed into a group of shadow registers, which can be
    switched to configure equalization for different speeds by writing 00b,
    01b and 10b to `RATE_SHADOW_SEL`.
    
    Hence, program equalization registers in a loop using link speed as index,
    so that equalization setting can be programmed for 8.0 GT/s, 16.0 GT/s
    and 32.0 GT/s.
    
    Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes")
    Co-developed-by: Qiang Yu <[email protected]>
    Signed-off-by: Qiang Yu <[email protected]>
    Signed-off-by: Ziyue Zhang <[email protected]>
    [mani: wrapped the warning to fit 100 columns, used post-increment for loop]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: qcom: Restrict port parsing only to PCIe bridge child nodes [+ + +]
Author: Krishna Chaitanya Chundru <[email protected]>
Date:   Tue Aug 26 16:32:55 2025 +0530

    PCI: qcom: Restrict port parsing only to PCIe bridge child nodes
    
    [ Upstream commit 45df22935bdc6bbddf87f38a57ae7257244cf3cf ]
    
    The qcom_pcie_parse_ports() function currently iterates over all available
    child nodes of the PCIe controller's device tree node. This includes
    unrelated nodes such as OPP (Operating Performance Points) nodes, which do
    not contain the expected 'reset' and 'phy' properties. As a result, parsing
    fails and the driver falls back to the legacy method of parsing the
    controller node directly. However, this fallback also fails when properties
    are shifted to the Root Port node, leading to probe failure.
    
    Fix this by restricting the parsing logic to only consider child nodes with
    device_type = "pci", which is the expected and required property for PCIe
    bridge nodes as per the pci-bus-common.yaml dtschema.
    
    Fixes: a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root Port binding")
    Signed-off-by: Krishna Chaitanya Chundru <[email protected]>
    [mani: reworded subject and description]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: rcar-gen4: Add missing 1ms delay after PWR reset assertion [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Fri Sep 19 15:45:58 2025 +0200

    PCI: rcar-gen4: Add missing 1ms delay after PWR reset assertion
    
    [ Upstream commit 8795b70581770657cd5ead3c965348f05242580f ]
    
    R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 585
    Figure 9.3.2 Software Reset flow (B) indicates that for peripherals in HSC
    domain, after reset has been asserted by writing a matching reset bit into
    register SRCR, it is mandatory to wait 1ms.
    
    Because it is the controller driver which can determine whether or not the
    controller is in HSC domain based on its compatible string, add the missing
    delay in the controller driver.
    
    This 1ms delay is documented on R-Car V4H and V4M; it is currently unclear
    whether S4 is affected as well. This patch does apply the extra delay on
    R-Car S4 as well.
    
    Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
    Suggested-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Marek Vasut <[email protected]>
    [mani: added the missing r-b tag from Krzysztof]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Krzysztof Wilczyński <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: rcar-gen4: Assure reset occurs before DBI access [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Wed Sep 24 02:55:45 2025 +0200

    PCI: rcar-gen4: Assure reset occurs before DBI access
    
    [ Upstream commit 0056d29f8c1b13d7e60d60cdb159767ac8f6a883 ]
    
    Assure the reset is latched and the core is ready for DBI access. On R-Car
    V4H, the PCIe reset is asynchronous and does not take effect immediately,
    but needs a short time to complete. In case DBI access happens in that
    short time, that access generates an SError. Make sure that condition can
    never happen, read back the state of the reset, which should turn the
    asynchronous reset into a synchronous one, and wait a little over 1ms to
    add additional safety margin.
    
    Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
    Signed-off-by: Marek Vasut <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: rcar-gen4: Fix inverted break condition in PHY initialization [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Tue Sep 16 01:58:40 2025 +0200

    PCI: rcar-gen4: Fix inverted break condition in PHY initialization
    
    [ Upstream commit 2bdf1d428f48e1077791bb7f88fd00262118256d ]
    
    R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 4581
    Figure 104.3b Initial Setting of PCIEC(example), third quarter of the
    figure indicates that register 0xf8 should be polled until bit 18 becomes
    set to 1.
    
    Register 0xf8, bit 18 is 0 immediately after write to PCIERSTCTRL1 and is
    set to 1 in less than 1 ms afterward. The current readl_poll_timeout()
    break condition is inverted and returns when register 0xf8, bit 18 is set
    to 0, which in most cases means immediately. In case
    CONFIG_DEBUG_LOCK_ALLOC=y, the timing changes just enough for the first
    readl_poll_timeout() poll to already read register 0xf8, bit 18 as 1 and
    afterward never read register 0xf8, bit 18 as 0, which leads to timeout
    and failure to start the PCIe controller.
    
    Fix this by inverting the poll condition to match the reference manual
    initialization sequence.
    
    Fixes: faf5a975ee3b ("PCI: rcar-gen4: Add support for R-Car V4H")
    Signed-off-by: Marek Vasut <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: rcar-host: Pass proper IRQ domain to generic_handle_domain_irq() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Sat Aug 9 17:44:47 2025 +0300

    PCI: rcar-host: Pass proper IRQ domain to generic_handle_domain_irq()
    
    [ Upstream commit d3fee10e40a938331e2aae34348691136db31304 ]
    
    Starting with commit dd26c1a23fd5 ("PCI: rcar-host: Switch to
    msi_create_parent_irq_domain()"), the MSI parent IRQ domain is NULL because
    the object of type struct irq_domain_info passed to:
    
    msi_create_parent_irq_domain() ->
      irq_domain_instantiate()() ->
        __irq_domain_instantiate()
    
    has no reference to the parent IRQ domain. Using msi->domain->parent as an
    argument for generic_handle_domain_irq() leads to below error:
    
            "Unable to handle kernel NULL pointer dereference at virtual address"
    
    This error was identified while switching the upcoming RZ/G3S PCIe host
    controller driver to msi_create_parent_irq_domain() (which was using a
    similar pattern to handle MSIs (see link section)), but it was not tested
    on hardware using the pcie-rcar-host controller driver due to lack of
    hardware.
    
    Fixes: dd26c1a23fd5 ("PCI: rcar-host: Switch to msi_create_parent_irq_domain()")
    Signed-off-by: Claudiu Beznea <[email protected]>
    [mani: reworded subject and description]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Nam Cao <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: tegra194: Fix duplicate PLL disable in pex_ep_event_pex_rst_assert() [+ + +]
Author: Nagarjuna Kristam <[email protected]>
Date:   Thu Sep 11 11:30:22 2025 +0200

    PCI: tegra194: Fix duplicate PLL disable in pex_ep_event_pex_rst_assert()
    
    [ Upstream commit 4f152338e384a3a47dd61909e1457539fa93f5a4 ]
    
    During PERST# assertion tegra_pcie_bpmp_set_pll_state() is currently
    called twice.
    
    pex_ep_event_pex_rst_assert() should do the opposite of
    pex_ep_event_pex_rst_deassert(), so it is obvious that the duplicate
    tegra_pcie_bpmp_set_pll_state() is a mistake, and that the duplicate
    tegra_pcie_bpmp_set_pll_state() call should instead be a call to
    tegra_pcie_bpmp_set_ctrl_state().
    
    With this, the uninitialization sequence also matches that of
    tegra_pcie_unconfig_controller().
    
    Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support")
    Signed-off-by: Nagarjuna Kristam <[email protected]>
    [cassel: improve commit log]
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [mani: added Fixes tag]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: tegra: Fix devm_kcalloc() argument order for port->phys allocation [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Tue Aug 19 08:04:08 2025 -0700

    PCI: tegra: Fix devm_kcalloc() argument order for port->phys allocation
    
    [ Upstream commit e1a8805e5d263453ad76a4f50ab3b1c18ea07560 ]
    
    Fix incorrect argument order in devm_kcalloc() when allocating port->phys.
    The original call used sizeof(phy) as the number of elements and
    port->lanes as the element size, which is reversed.  While this happens to
    produce the correct total allocation size with current pointer size and
    lane counts, the argument order is wrong.
    
    Fixes: 6fe7c187e026 ("PCI: tegra: Support per-lane PHYs")
    Signed-off-by: Alok Tiwari <[email protected]>
    [mani: added Fixes tag]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xgene-msi: Return negative -EINVAL in xgene_msi_handler_setup() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Aug 1 16:34:37 2025 +0300

    PCI: xgene-msi: Return negative -EINVAL in xgene_msi_handler_setup()
    
    [ Upstream commit b26fc701a25195134ff0327709a0421767c4c7b2 ]
    
    There is a typo so we accidentally return positive EINVAL instead of
    negative -EINVAL. Add the missing '-' character.
    
    Fixes: 6aceb36f17ab ("PCI: xgene-msi: Restructure handler setup/teardown")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Acked-by: Marc Zyngier <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/x86/intel: Fix IA32_PMC_x_CFG_B MSRs access error [+ + +]
Author: Dapeng Mi <[email protected]>
Date:   Wed Aug 20 10:30:27 2025 +0800

    perf/x86/intel: Fix IA32_PMC_x_CFG_B MSRs access error
    
    [ Upstream commit 43796f30507802d93ead2dc44fc9637f34671a89 ]
    
    When running perf_fuzzer on PTL, sometimes the below "unchecked MSR
     access error" is seen when accessing IA32_PMC_x_CFG_B MSRs.
    
    [   55.611268] unchecked MSR access error: WRMSR to 0x1986 (tried to write 0x0000000200000001) at rIP: 0xffffffffac564b28 (native_write_msr+0x8/0x30)
    [   55.611280] Call Trace:
    [   55.611282]  <TASK>
    [   55.611284]  ? intel_pmu_config_acr+0x87/0x160
    [   55.611289]  intel_pmu_enable_acr+0x6d/0x80
    [   55.611291]  intel_pmu_enable_event+0xce/0x460
    [   55.611293]  x86_pmu_start+0x78/0xb0
    [   55.611297]  x86_pmu_enable+0x218/0x3a0
    [   55.611300]  ? x86_pmu_enable+0x121/0x3a0
    [   55.611302]  perf_pmu_enable+0x40/0x50
    [   55.611307]  ctx_resched+0x19d/0x220
    [   55.611309]  __perf_install_in_context+0x284/0x2f0
    [   55.611311]  ? __pfx_remote_function+0x10/0x10
    [   55.611314]  remote_function+0x52/0x70
    [   55.611317]  ? __pfx_remote_function+0x10/0x10
    [   55.611319]  generic_exec_single+0x84/0x150
    [   55.611323]  smp_call_function_single+0xc5/0x1a0
    [   55.611326]  ? __pfx_remote_function+0x10/0x10
    [   55.611329]  perf_install_in_context+0xd1/0x1e0
    [   55.611331]  ? __pfx___perf_install_in_context+0x10/0x10
    [   55.611333]  __do_sys_perf_event_open+0xa76/0x1040
    [   55.611336]  __x64_sys_perf_event_open+0x26/0x30
    [   55.611337]  x64_sys_call+0x1d8e/0x20c0
    [   55.611339]  do_syscall_64+0x4f/0x120
    [   55.611343]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    On PTL, GP counter 0 and 1 doesn't support auto counter reload feature,
    thus it would trigger a #GP when trying to write 1 on bit 0 of CFG_B MSR
    which requires to enable auto counter reload on GP counter 0.
    
    The root cause of causing this issue is the check for auto counter
    reload (ACR) counter mask from user space is incorrect in
    intel_pmu_acr_late_setup() helper. It leads to an invalid ACR counter
    mask from user space could be set into hw.config1 and then written into
    CFG_B MSRs and trigger the MSR access warning.
    
    e.g., User may create a perf event with ACR counter mask (config2=0xcb),
    and there is only 1 event created, so "cpuc->n_events" is 1.
    
    The correct check condition should be "i + idx >= cpuc->n_events"
    instead of "i + idx > cpuc->n_events" (it looks a typo). Otherwise,
    the counter mask would traverse twice and an invalid "cpuc->assign[1]"
    bit (bit 0) is set into hw.config1 and cause MSR accessing error.
    
    Besides, also check if the ACR counter mask corresponding events are
    ACR events. If not, filter out these counter mask. If a event is not a
    ACR event, it could be scheduled to an HW counter which doesn't support
    ACR. It's invalid to add their counter index in ACR counter mask.
    
    Furthermore, remove the WARN_ON_ONCE() since it's easily triggered as
    user could set any invalid ACR counter mask and the warning message
    could mislead users.
    
    Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
    Signed-off-by: Dapeng Mi <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

perf/x86/intel: Use early_initcall() to hook bts_init() [+ + +]
Author: Dapeng Mi <[email protected]>
Date:   Wed Aug 20 10:30:26 2025 +0800

    perf/x86/intel: Use early_initcall() to hook bts_init()
    
    [ Upstream commit d9cf9c6884d21e01483c4e17479d27636ea4bb50 ]
    
    After the commit 'd971342d38bf ("perf/x86/intel: Decouple BTS
     initialization from PEBS initialization")' is introduced, x86_pmu.bts
    would initialized in bts_init() which is hooked by arch_initcall().
    
    Whereas init_hw_perf_events() is hooked by early_initcall(). Once the
    core PMU is initialized, nmi watchdog initialization is called
    immediately before bts_init() is called. It leads to the BTS buffer is
    not really initialized since bts_init() is not called and x86_pmu.bts is
    still false at that time. Worse, BTS buffer would never be initialized
    then unless all core PMU events are freed and reserve_ds_buffers()
    is called again.
    
    Thus aligning with init_hw_perf_events(), use early_initcall() to hook
    bts_init() to ensure x86_pmu.bts is initialized before nmi watchdog
    initialization.
    
    Fixes: d971342d38bf ("perf/x86/intel: Decouple BTS initialization from PEBS initialization")
    Signed-off-by: Dapeng Mi <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
perf: arm_spe: Prevent overflow in PERF_IDX2OFF() [+ + +]
Author: Leo Yan <[email protected]>
Date:   Wed Sep 17 18:41:39 2025 +0100

    perf: arm_spe: Prevent overflow in PERF_IDX2OFF()
    
    [ Upstream commit a29fea30dd93da16652930162b177941abd8c75e ]
    
    Cast nr_pages to unsigned long to avoid overflow when handling large
    AUX buffer sizes (>= 2 GiB).
    
    Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension")
    Signed-off-by: Leo Yan <[email protected]>
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
phy: rockchip: naneng-combphy: Enable U3 OTG port for RK3568 [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Wed Jul 23 07:23:22 2025 +0000

    phy: rockchip: naneng-combphy: Enable U3 OTG port for RK3568
    
    [ Upstream commit 7bb14b61b7d03db770b7e8871493f5b9b2be2b79 ]
    
    The boot firmware may disable the U3 port early during boot and leave it
    up to the controller or PHY driver to re-enable U3 when needed.
    
    The Rockchip USBDP PHY driver currently does this for RK3576 and RK3588,
    something the Rockchip Naneng Combo PHY driver never does for RK3568.
    This may result in USB 3.0 ports being limited to only using USB 2.0 or
    in special cases not working at all on RK3568.
    
    Write to PIPE_GRF USB3OTGx_CON1 reg to ensure the U3 port is enabled
    when a PHY with PHY_TYPE_USB3 mode is used.
    
    Fixes: 7160820d742a ("phy: rockchip: add naneng combo phy for RK3568")
    Signed-off-by: Jonas Karlman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pid: use ns_capable_noaudit() when determining net sysctl permissions [+ + +]
Author: Christian Göttsche <[email protected]>
Date:   Wed Sep 10 21:26:05 2025 +0200

    pid: use ns_capable_noaudit() when determining net sysctl permissions
    
    [ Upstream commit b9cb7e59ac4ae68940347ebfc41e0436d32d3c6e ]
    
    The capability check should not be audited since it is only being used
    to determine the inode permissions. A failed check does not indicate a
    violation of security policy but, when an LSM is enabled, a denial audit
    message was being generated.
    
    The denial audit message can either lead to the capability being
    unnecessarily allowed in a security policy, or being silenced potentially
    masking a legitimate capability check at a later point in time.
    
    Similar to commit d6169b0206db ("net: Use ns_capable_noaudit() when
    determining net sysctl permissions")
    
    Fixes: 7863dcc72d0f ("pid: allow pid_max to be set per pid namespace")
    CC: Christian Brauner <[email protected]>
    CC: [email protected]
    CC: [email protected]
    Signed-off-by: Christian Göttsche <[email protected]>
    Acked-by: Serge Hallyn <[email protected]>
    Reviewed-by: Paul Moore <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pinctrl: check the return value of pinmux_ops::get_function_name() [+ + +]
Author: Bartosz Golaszewski <[email protected]>
Date:   Tue Sep 2 13:59:10 2025 +0200

    pinctrl: check the return value of pinmux_ops::get_function_name()
    
    commit 4002ee98c022d671ecc1e4a84029e9ae7d8a5603 upstream.
    
    While the API contract in docs doesn't specify it explicitly, the
    generic implementation of the get_function_name() callback from struct
    pinmux_ops - pinmux_generic_get_function_name() - can fail and return
    NULL. This is already checked in pinmux_check_ops() so add a similar
    check in pinmux_func_name_to_selector() instead of passing the returned
    pointer right down to strcmp() where the NULL can get dereferenced. This
    is normal operation when adding new pinfunctions.
    
    Cc: [email protected]
    Tested-by: Neil Armstrong <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pinctrl: eswin: Fix regulator error check and Kconfig dependency [+ + +]
Author: Yulin Lu <[email protected]>
Date:   Wed Sep 3 17:19:15 2025 +0800

    pinctrl: eswin: Fix regulator error check and Kconfig dependency
    
    [ Upstream commit a6a2f50ab1721343ee2d5d2be888709aa886e3aa ]
    
    Smatch reported the following warning in eic7700_pinctrl_probe():
    
      drivers/pinctrl/pinctrl-eic7700.c:638 eic7700_pinctrl_probe()
      warn: passing zero to 'PTR_ERR'
    
    The root cause is that devm_regulator_get() may return NULL when
    CONFIG_REGULATOR is disabled. In such case, IS_ERR_OR_NULL() triggers
    PTR_ERR(NULL) which evaluates to 0, leading to passing a success code
    as an error.
    
    However, this driver cannot work without a regulator. To fix this:
    
     - Change the check from IS_ERR_OR_NULL() to IS_ERR()
     - Update Kconfig to explicitly select REGULATOR and
       REGULATOR_FIXED_VOLTAGE, ensuring that the regulator framework is
       always available.
    
    This resolves the Smatch warning and enforces the correct dependency.
    
    Suggested-by: Dan Carpenter <[email protected]>
    Fixes: 5b797bcc00ef ("pinctrl: eswin: Add EIC7700 pinctrl driver")
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/linux-gpio/[email protected]/
    Signed-off-by: Yulin Lu <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: meson-gxl: add missing i2c_d pinmux [+ + +]
Author: Da Xue <[email protected]>
Date:   Thu Aug 21 19:33:34 2025 -0400

    pinctrl: meson-gxl: add missing i2c_d pinmux
    
    [ Upstream commit d8c2a9edd181f0cc4a66eec954b3d8f6a1d954a7 ]
    
    Amlogic GXL has 4 I2C attached to gpio-periphs. I2C_D is on GPIOX_10/11.
    
    Add the relevant func 3 pinmux per the datasheet for S805X/S905X/S905D.
    
    Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions")
    Signed-off-by: Da Xue <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: renesas: rzg2l: Fix invalid unsigned return in rzg3s_oen_read() [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Wed Jul 9 17:08:13 2025 +0100

    pinctrl: renesas: rzg2l: Fix invalid unsigned return in rzg3s_oen_read()
    
    [ Upstream commit 8912b2862b9b74a0dc4e3ea1aacdec2f8abd7e1d ]
    
    rzg3s_oen_read() returns a u32 value, but previously propagated a negative
    error code from rzg3s_pin_to_oen_bit(), resulting in an unintended large
    positive value due to unsigned conversion. This caused incorrect
    output-enable reporting for certain pins.
    
    Without this patch, pins P1_0-P1_4 and P7_0-P7_4 are incorrectly reported
    as "output enabled" in the pinconf-pins debugfs file. With this fix, only
    P1_0-P1_1 and P7_0-P7_1 are shown as "output enabled", which matches the
    hardware manual.
    
    Fix this by returning 0 when the OEN bit lookup fails, treating the pin
    as output-disabled by default.
    
    Fixes: a9024a323af2 ("pinctrl: renesas: rzg2l: Clean up and refactor OEN read/write functions")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: renesas: Use int type to store negative error codes [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Sun Aug 31 16:49:58 2025 +0800

    pinctrl: renesas: Use int type to store negative error codes
    
    [ Upstream commit 9f062fc5b0ff44550088912ab89f9da40226a826 ]
    
    Change the 'ret' variable in sh_pfc_pinconf_group_set() from unsigned
    int to int, as it needs to store either negative error codes or zero
    returned by sh_pfc_pinconf_set().
    
    No effect on runtime.
    
    Signed-off-by: Qianfeng Rong <[email protected]>
    Fixes: d0593c363f04ccc4 ("pinctrl: sh-pfc: Propagate errors on group config")
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Thu Aug 7 18:58:23 2025 +0300

    PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()
    
    [ Upstream commit fc33bf0e097c6834646b98a7b3da0ae5b617f0f9 ]
    
    The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which
    would lead to a error pointer dereference.  Use IS_ERR_OR_NULL() to check
    that the pointer is valid.
    
    Fixes: e09bd5757b52 ("PM / devfreq: mtk-cci: Handle sram regulator probe deferral")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

PM / devfreq: rockchip-dfi: double count on RK3588 [+ + +]
Author: Nicolas Frattaroli <[email protected]>
Date:   Fri May 30 15:38:08 2025 +0200

    PM / devfreq: rockchip-dfi: double count on RK3588
    
    [ Upstream commit f89c7fb83ae95578e355bed1a7aeea5f3ca5a067 ]
    
    On RK3588 with LPDDR4X memory, the cycle count as returned by
    
      perf stat -a -e rockchip_ddr/cycles/ sleep 1
    
    consistently reads half as much as what the actual DDR frequency is at.
    For a LPDDR4X module running at 2112MHz, I get more like 1056059916
    cycles per second, which is almost bang-on half what it should be. No,
    I'm not mixing up megatransfers and megahertz.
    
    Consulting the downstream driver, this appears to be because the RK3588
    hardware specifically (and RK3528 as well, for future reference) needs a
    multiplier of 2 to get to the correct frequency with everything but
    LPDDR5.
    
    The RK3588's actual memory bandwidth measurements in MB/s are correct
    however, as confirmed with stress-ng --stream. This makes me think the
    access counters are not affected in the same way. This tracks with the
    vendor kernel not multiplying the access counts either.
    
    Solve this by adding a new member to the dfi struct, which each SoC can
    set to whatever they want, but defaults to 1 if left unset by the SoC
    init functions. The event_get_count op can then use this multiplier if
    the cycle count is requested.
    
    The cycle multiplier is not used in rockchip_dfi_get_event because the
    vendor driver doesn't use it there either, and we don't do other actual
    bandwidth unit conversion stuff in there anyway.
    
    Fixes: 481d97ba61e1 ("PM / devfreq: rockchip-dfi: add support for RK3588")
    Signed-off-by: Nicolas Frattaroli <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
PM: sleep: core: Clear power.must_resume in noirq suspend error path [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Tue Sep 2 15:55:45 2025 +0200

    PM: sleep: core: Clear power.must_resume in noirq suspend error path
    
    [ Upstream commit be82483d1b60baf6747884bd74cb7de484deaf76 ]
    
    If system suspend is aborted in the "noirq" phase (for instance, due to
    an error returned by one of the device callbacks), power.is_noirq_suspended
    will not be set for some devices and device_resume_noirq() will return
    early for them.  Consequently, noirq resume callbacks will not run for
    them at all because the noirq suspend callbacks have not run for them
    yet.
    
    If any of them has power.must_resume set and late suspend has been
    skipped for it (due to power.smart_suspend), early resume should be
    skipped for it either, or its state may become inconsistent (for
    instance, if the early resume assumes that it will always follow
    noirq resume).
    
    Make that happen by clearing power.must_resume in device_resume_noirq()
    for devices with power.is_noirq_suspended clear that have been left in
    suspend by device_suspend_late(), which will subsequently cause
    device_resume_early() to leave the device in suspend and avoid
    changing its state.
    
    Fixes: 0d4b54c6fee8 ("PM / core: Add LEAVE_SUSPENDED driver flag")
    Link: https://lore.kernel.org/linux-pm/[email protected]/
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Ulf Hansson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
power: supply: cw2015: Fix a alignment coding style issue [+ + +]
Author: Andy Yan <[email protected]>
Date:   Mon Aug 18 20:32:59 2025 +0800

    power: supply: cw2015: Fix a alignment coding style issue
    
    [ Upstream commit def5612170a8c6c4c6a3ea5bd6c3cfc8de6ba4b1 ]
    
    Fix the checkpatch warning:
    CHECK: Alignment should match open parenthesis
    
    Fixes: 0cb172a4918e ("power: supply: cw2015: Use device managed API to simplify the code")
    Signed-off-by: Andy Yan <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: max77705_charger: refactoring: rename charger to chg [+ + +]
Author: Dzmitry Sankouski <[email protected]>
Date:   Thu Sep 18 20:06:47 2025 +0300

    power: supply: max77705_charger: refactoring: rename charger to chg
    
    [ Upstream commit d84510db8c1414b67167cdc452103c1f429588cc ]
    
    Rename struct max77705_charger_data variable to chg for consistency.
    
    Signed-off-by: Dzmitry Sankouski <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Stable-dep-of: 12a1185a06e3 ("power: supply: max77705_charger: rework interrupts")
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: max77705_charger: rework interrupts [+ + +]
Author: Dzmitry Sankouski <[email protected]>
Date:   Thu Sep 18 20:06:51 2025 +0300

    power: supply: max77705_charger: rework interrupts
    
    [ Upstream commit 12a1185a06e3377af777e792ba7436862f8e528a ]
    
    Current implementation uses handle_post_irq to actually handle chgin
    irq. This is not how things are meant to work in regmap-irq.
    
    Remove handle_post_irq, and request a threaded interrupt for chgin.
    
    Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705")
    Signed-off-by: Dzmitry Sankouski <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: max77705_charger: use regfields for config registers [+ + +]
Author: Dzmitry Sankouski <[email protected]>
Date:   Thu Sep 18 20:06:48 2025 +0300

    power: supply: max77705_charger: use regfields for config registers
    
    [ Upstream commit ef1e734dbe257ce8bc42383b9977b5558f061288 ]
    
    Using regfields allows to cleanup masks and register offset definition,
    allowing to access register info by it's functional name.
    
    Signed-off-by: Dzmitry Sankouski <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Stable-dep-of: 12a1185a06e3 ("power: supply: max77705_charger: rework interrupts")
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/603: Really copy kernel PGD entries into all PGDIRs [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Thu Aug 21 08:30:18 2025 +0200

    powerpc/603: Really copy kernel PGD entries into all PGDIRs
    
    [ Upstream commit f2863371f017eb03c230addc253783fa4c7e90f5 ]
    
    Commit 82ef440f9a38 ("powerpc/603: Copy kernel PGD entries into all
    PGDIRs and preallocate execmem page tables") was supposed to extend
    to powerpc 603 the copy of kernel PGD entries into all PGDIRs
    implemented in a previous patch on the 8xx. But 603 is book3s/32 and
    uses a duplicate of pgd_alloc() defined in another header.
    
    So really do the copy at the correct place for the 603.
    
    Fixes: 82ef440f9a38 ("powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/752ab7514cae089a2dd7cc0f3d5e35849f76adb9.1755757797.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/8xx: Remove left-over instruction and comments in DataStoreTLBMiss handler [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Sat Aug 16 18:33:26 2025 +0200

    powerpc/8xx: Remove left-over instruction and comments in DataStoreTLBMiss handler
    
    [ Upstream commit d9e46de4bf5c5f987075afd5f240bb2a8a5d71ed ]
    
    Commit ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in
    DTLB misses") removed the test that needed the valeur in SPRN_EPN but
    failed to remove the read.
    
    Remove it.
    
    And remove related comments, including the very same comment
    in InstructionTLBMiss that should have been removed by
    commit 33c527522f39 ("powerpc/8xx: Inconditionally use task PGDIR in
    ITLB misses").
    
    Also update the comment about absence of a second level table which
    has been handled implicitely since commit 5ddb75cee5af ("powerpc/8xx:
    remove tests on PGDIR entry validity").
    
    Fixes: ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/5811c8d1d6187f280ad140d6c0ad6010e41eeaeb.1755361995.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/ftrace: ensure ftrace record ops are always set for NOPs [+ + +]
Author: Joe Lawrence <[email protected]>
Date:   Fri Sep 12 10:27:38 2025 -0400

    powerpc/ftrace: ensure ftrace record ops are always set for NOPs
    
    [ Upstream commit 5337609a314828aa2474ac359db615f475c4a4d2 ]
    
    When an ftrace call site is converted to a NOP, its corresponding
    dyn_ftrace record should have its ftrace_ops pointer set to
    ftrace_nop_ops.
    
    Correct the powerpc implementation to ensure the
    ftrace_rec_set_nop_ops() helper is called on all successful NOP
    initialization paths. This ensures all ftrace records are consistent
    before being handled by the ftrace core.
    
    Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
    Suggested-by: Naveen N Rao <[email protected]>
    Signed-off-by: Joe Lawrence <[email protected]>
    Acked-by: Naveen N Rao (AMD) <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc64/modules: correctly iterate over stubs in setup_ftrace_ool_stubs [+ + +]
Author: Joe Lawrence <[email protected]>
Date:   Fri Sep 12 10:27:39 2025 -0400

    powerpc64/modules: correctly iterate over stubs in setup_ftrace_ool_stubs
    
    [ Upstream commit f6b4df37ebfeb47e50e27780500d2d06b4d211bd ]
    
    CONFIG_PPC_FTRACE_OUT_OF_LINE introduced setup_ftrace_ool_stubs() to
    extend the ppc64le module .stubs section with an array of
    ftrace_ool_stub structures for each patchable function.
    
    Fix its ppc64_stub_entry stub reservation loop to properly write across
    all of the num_stubs used and not just the first entry.
    
    Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
    Signed-off-by: Joe Lawrence <[email protected]>
    Acked-by: Naveen N Rao (AMD) <[email protected]>
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
pps: fix warning in pps_register_cdev when register device fail [+ + +]
Author: Wang Liang <[email protected]>
Date:   Sat Aug 30 15:50:23 2025 +0800

    pps: fix warning in pps_register_cdev when register device fail
    
    [ Upstream commit b0531cdba5029f897da5156815e3bdafe1e9b88d ]
    
    Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error
    handling in __video_register_device()"), the release hook should be set
    before device_register(). Otherwise, when device_register() return error
    and put_device() try to callback the release function, the below warning
    may happen.
    
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567
      Modules linked in:
      CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE
      RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567
      Call Trace:
       <TASK>
       kobject_cleanup+0x136/0x410 lib/kobject.c:689
       kobject_release lib/kobject.c:720 [inline]
       kref_put include/linux/kref.h:65 [inline]
       kobject_put+0xe9/0x130 lib/kobject.c:737
       put_device+0x24/0x30 drivers/base/core.c:3797
       pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402
       pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108
       pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57
       tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432
       tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563
       tiocsetd drivers/tty/tty_io.c:2429 [inline]
       tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:598 [inline]
       __se_sys_ioctl fs/ioctl.c:584 [inline]
       __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
       </TASK>
    
    Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),
    pps_register_cdev() call device_create() to create pps->dev, which will
    init dev->release to device_create_release(). Now the comment is outdated,
    just remove it.
    
    Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed
    in pps_register_source() to avoid a double free in the failure case.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: c79a39dc8d06 ("pps: Fix a use-after-free")
    Signed-off-by: Wang Liang <[email protected]>
    Reviewed-By: Calvin Owens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ptp: Add a upper bound on max_vclocks [+ + +]
Author: I Viswanath <[email protected]>
Date:   Thu Sep 25 21:29:08 2025 +0530

    ptp: Add a upper bound on max_vclocks
    
    [ Upstream commit e9f35294e18da82162004a2f35976e7031aaf7f9 ]
    
    syzbot reported WARNING in max_vclocks_store.
    
    This occurs when the argument max is too large for kcalloc to handle.
    
    Extend the guard to guard against values that are too large for
    kcalloc
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=94d20db923b9f51be0df
    Tested-by: [email protected]
    Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion")
    Signed-off-by: I Viswanath <[email protected]>
    Acked-by: Richard Cochran <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pwm: loongson: Fix LOONGSON_PWM_FREQ_DEFAULT [+ + +]
Author: Xi Ruoyao <[email protected]>
Date:   Sat Aug 16 18:49:05 2025 +0800

    pwm: loongson: Fix LOONGSON_PWM_FREQ_DEFAULT
    
    commit 75604e9a5b60707722028947d6dc6bdacb42282e upstream.
    
    Per the 7A1000 and 7A2000 user manual, the clock frequency of their
    PWM controllers is 50 MHz, not 50 kHz.
    
    Fixes: 2b62c89448dd ("pwm: Add Loongson PWM controller support")
    Signed-off-by: Xi Ruoyao <[email protected]>
    Reviewed-by: Binbin Zhou <[email protected]>
    Reviewed-by: Huacai Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pwm: tiehrpwm: Don't drop runtime PM reference in .free() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Aug 11 18:00:59 2025 +0200

    pwm: tiehrpwm: Don't drop runtime PM reference in .free()
    
    [ Upstream commit 21a5e91fda50fc662ce1a12bd0aae9d103455b43 ]
    
    The pwm driver calls pm_runtime_get_sync() when the hardware becomes
    enabled and pm_runtime_put_sync() when it becomes disabled. The PWM's
    state is kept when a consumer goes away, so the call to
    pm_runtime_put_sync() in the .free() callback is unbalanced resulting in
    a non-functional device and a reference underlow for the second consumer.
    
    The easiest fix for that issue is to just not drop the runtime PM
    reference in .free(), so do that.
    
    Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/bbb089c4b5650cc1f7b25cf582d817543fd25384.1754927682.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: tiehrpwm: Fix corner case in clock divisor calculation [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Aug 11 18:01:02 2025 +0200

    pwm: tiehrpwm: Fix corner case in clock divisor calculation
    
    [ Upstream commit 00f83f0e07e44e2f1fb94b223e77ab7b18ee2d7d ]
    
    The function set_prescale_div() is responsible for calculating the clock
    divisor settings such that the input clock rate is divided down such that
    the required period length is at most 0x10000 clock ticks. If period_cycles
    is an integer multiple of 0x10000, the divisor period_cycles / 0x10000 is
    good enough. So round up in the calculation of the required divisor and
    compare it using >= instead of >.
    
    Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/85488616d7bfcd9c32717651d0be7e330e761b9c.1754927682.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculation [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Aug 11 18:01:01 2025 +0200

    pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculation
    
    [ Upstream commit bc7ce5bfc504eea9eac0eb0215017b9fcfc62c59 ]
    
    In Up-Count Mode the timer is reset to zero one tick after it reaches
    TBPRD, so the period length is (TBPRD + 1) * T_TBCLK. This matches both
    the documentation and measurements. So the value written to the TBPRD has
    to be one less than the calculated period_cycles value.
    
    A complication here is that for a 100% relative duty-cycle the value
    written to the CMPx register has to be TBPRD + 1 which might overflow if
    TBPRD is 0xffff. To handle that the calculation of the AQCTLx register
    has to be moved to ehrpwm_pwm_config() and the edge at CTR = CMPx has to
    be skipped.
    
    Additionally the AQCTL_PRD register field has to be 0 because that defines
    the hardware's action when the maximal counter value is reached, which is
    (as above) one clock tick before the period's end. The period start edge
    has to happen when the counter is reset and so is defined in the AQCTL_ZRO
    field.
    
    Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/dc818c69b7cf05109ecda9ee6b0043a22de757c1.1754927682.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: tiehrpwm: Make code comment in .free() more useful [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Aug 11 18:01:00 2025 +0200

    pwm: tiehrpwm: Make code comment in .free() more useful
    
    [ Upstream commit 878dbfc12cc52b17d79d205560c0fafcf5332b13 ]
    
    Instead of explaining trivia to everyone who can read C describe the
    higher-level effect of setting pc->period_cycles[pwm->hwpwm] to zero.
    
    Fixes: 01b2d4536f02 ("pwm: pwm-tiehrpwm: Fix conflicting channel period setting")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/4c38dd119a77d7017115318a3f2c50bde62a6f21.1754927682.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
raid6: riscv: Clean up unused header file inclusion [+ + +]
Author: Chunyan Zhang <[email protected]>
Date:   Fri Jul 18 15:27:07 2025 +0800

    raid6: riscv: Clean up unused header file inclusion
    
    [ Upstream commit f8a03516a530cc36bc9015c84ba7540ee3e8d7bd ]
    
    These two C files don't reference things defined in simd.h or types.h
    so remove these redundant #inclusions.
    
    Fixes: 6093faaf9593 ("raid6: Add RISC-V SIMD syndrome and recovery calculations")
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Signed-off-by: Chunyan Zhang <[email protected]>
    Reviewed-by: Nutty Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paul Walmsley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/cm: Rate limit destroy CM ID timeout error message [+ + +]
Author: Håkon Bugge <[email protected]>
Date:   Fri Sep 12 12:05:20 2025 +0200

    RDMA/cm: Rate limit destroy CM ID timeout error message
    
    [ Upstream commit 2bbe1255fcf19c5eb300efb6cb5ad98d66fdae2e ]
    
    When the destroy CM ID timeout kicks in, you typically get a storm of
    them which creates a log flooding. Hence, change pr_err() to
    pr_err_ratelimited() in cm_destroy_id_wait_timeout().
    
    Fixes: 96d9cbe2f2ff ("RDMA/cm: add timeout to cm_destroy_id wait")
    Signed-off-by: Håkon Bugge <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Zhu Yanjun <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/core: Resolve MAC of next-hop device without ARP support [+ + +]
Author: Parav Pandit <[email protected]>
Date:   Tue Sep 16 14:11:01 2025 +0300

    RDMA/core: Resolve MAC of next-hop device without ARP support
    
    [ Upstream commit 200651b9b8aadfbbec852f0e5d042d9abe75e2ab ]
    
    Currently, if the next-hop netdevice does not support ARP resolution,
    the destination MAC address is silently set to zero without reporting
    an error. This leads to incorrect behavior and may result in packet
    transmission failures.
    
    Fix this by deferring MAC resolution to the IP stack via neighbour
    lookup, allowing proper resolution or error reporting as appropriate.
    
    Fixes: 7025fcd36bd6 ("IB: address translation to map IP toIB addresses (GIDs)")
    Signed-off-by: Parav Pandit <[email protected]>
    Reviewed-by: Vlad Dumitrescu <[email protected]>
    Signed-off-by: Edward Srouji <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Better estimate max_qp_wr to reflect WQE count [+ + +]
Author: Or Har-Toov <[email protected]>
Date:   Wed Aug 13 15:39:56 2025 +0300

    RDMA/mlx5: Better estimate max_qp_wr to reflect WQE count
    
    [ Upstream commit 1a7c18c485bf17ef408d5ebb7f83e1f8ef329585 ]
    
    The mlx5 driver currently derives max_qp_wr directly from the
    log_max_qp_sz HCA capability:
    
        props->max_qp_wr = 1 << MLX5_CAP_GEN(mdev, log_max_qp_sz);
    
    However, this value represents the number of WQEs in units of Basic
    Blocks (see MLX5_SEND_WQE_BB), not actual number of WQEs.  Since the size
    of a WQE can vary depending on transport type and features (e.g., atomic
    operations, UMR, LSO), the actual number of WQEs can be significantly
    smaller than the WQEBB count suggests.
    
    This patch introduces a conservative estimation of the worst-case WQE size
    — considering largest segments possible with 1 SGE and no inline data or
    special features. It uses this to derive a more accurate max_qp_wr value.
    
    Fixes: 938fe83c8dcb ("net/mlx5_core: New device capabilities handling")
    Link: https://patch.msgid.link/r/7d992c9831c997ed5c33d30973406dc2dcaf5e89.1755088725.git.leon@kernel.org
    Reported-by: Chuck Lever <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Or Har-Toov <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Fix page size bitmap calculation for KSM mode [+ + +]
Author: Edward Srouji <[email protected]>
Date:   Sun Aug 24 17:48:39 2025 +0300

    RDMA/mlx5: Fix page size bitmap calculation for KSM mode
    
    [ Upstream commit 372fdb5c75b61f038f4abf596abdcf01acbdb7af ]
    
    When using KSM (Key Scatter-gather Memory) access mode, the HW requires
    the IOVA to be aligned to the selected page size.
    Without this alignment, the HW may not function correctly.
    
    Currently, mlx5_umem_mkc_find_best_pgsz() does not filter out page sizes
    that would result in misaligned IOVAs for KSM mode. This can lead to
    selecting page sizes that are incompatible with the given IOVA.
    
    Fix this by filtering the page size bitmap when in KSM mode, keeping
    only page sizes to which the IOVA is aligned to.
    
    Fixes: fcfb03597b7d ("RDMA/mlx5: Align mkc page size capability check to PRM")
    Signed-off-by: Edward Srouji <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Michael Guralnik <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Fix vport loopback forcing for MPV device [+ + +]
Author: Patrisious Haddad <[email protected]>
Date:   Wed Aug 13 15:41:19 2025 +0300

    RDMA/mlx5: Fix vport loopback forcing for MPV device
    
    [ Upstream commit 08aae7860450c89eebbc6fd4d38416e53c7a33d2 ]
    
    Previously loopback for MPV was supposed to be permanently enabled,
    however other driver flows were able to over-ride that configuration and
    disable it.
    
    Add force_lb parameter that indicates that loopback should always be
    enabled which prevents all other driver flows from disabling it.
    
    Fixes: a9a9e68954f2 ("RDMA/mlx5: Fix vport loopback for MPV device")
    Link: https://patch.msgid.link/r/cfc6b1f0f99f8100b087483cc14da6025317f901.1755088808.git.leon@kernel.org
    Signed-off-by: Patrisious Haddad <[email protected]>
    Reviewed-by: Mark Bloch <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/rxe: Fix race in do_task() when draining [+ + +]
Author: Gui-Dong Han <[email protected]>
Date:   Fri Sep 19 02:52:12 2025 +0000

    RDMA/rxe: Fix race in do_task() when draining
    
    [ Upstream commit 8ca7eada62fcfabf6ec1dc7468941e791c1d8729 ]
    
    When do_task() exhausts its iteration budget (!ret), it sets the state
    to TASK_STATE_IDLE to reschedule, without a secondary check on the
    current task->state. This can overwrite the TASK_STATE_DRAINING state
    set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().
    
    While state changes are protected by a spinlock, both rxe_cleanup_task()
    and rxe_disable_task() release the lock while waiting for the task to
    finish draining in the while(!is_done(task)) loop. The race occurs if
    do_task() hits its iteration limit and acquires the lock in this window.
    The cleanup logic may then proceed while the task incorrectly
    reschedules itself, leading to a potential use-after-free.
    
    This bug was introduced during the migration from tasklets to workqueues,
    where the special handling for the draining case was lost.
    
    Fix this by restoring the original pre-migration behavior. If the state is
    TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to
    force a new loop iteration. This allows the task to finish its work, so
    that a subsequent iteration can reach the switch statement and correctly
    transition the state to TASK_STATE_DRAINED, stopping the task as intended.
    
    Fixes: 9b4b7c1f9f54 ("RDMA/rxe: Add workqueue support for rxe tasks")
    Reviewed-by: Zhu Yanjun <[email protected]>
    Signed-off-by: Gui-Dong Han <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/siw: Always report immediate post SQ errors [+ + +]
Author: Bernard Metzler <[email protected]>
Date:   Tue Sep 23 16:45:36 2025 +0200

    RDMA/siw: Always report immediate post SQ errors
    
    [ Upstream commit fdd0fe94d68649322e391c5c27dd9f436b4e955e ]
    
    In siw_post_send(), any immediate error encountered during processing of
    the work request list must be reported to the caller, even if previous
    work requests in that list were just accepted and added to the send queue.
    
    Not reporting those errors confuses the caller, which would wait
    indefinitely for the failing and potentially subsequently aborted work
    requests completion.
    
    This fixes a case where immediate errors were overwritten by subsequent
    code in siw_post_send().
    
    Fixes: 303ae1cdfdf7 ("rdma/siw: application interface")
    Link: https://patch.msgid.link/r/[email protected]
    Suggested-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Bernard Metzler <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regmap: Remove superfluous check for !config in __regmap_init() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Aug 13 15:07:18 2025 +0200

    regmap: Remove superfluous check for !config in __regmap_init()
    
    [ Upstream commit 5c36b86d2bf68fbcad16169983ef7ee8c537db59 ]
    
    The first thing __regmap_init() do is check if config is non-NULL,
    so there is no need to check for this again later.
    
    Fixes: d77e745613680c54 ("regmap: Add bulk read/write callbacks into regmap_config")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://patch.msgid.link/a154d9db0f290dda96b48bd817eb743773e846e1.1755090330.git.geert+renesas@glider.be
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: scmi: Use int type to store negative error codes [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Fri Aug 29 18:14:11 2025 +0800

    regulator: scmi: Use int type to store negative error codes
    
    [ Upstream commit 9d35d068fb138160709e04e3ee97fe29a6f8615b ]
    
    Change the 'ret' variable from u32 to int to store negative error codes or
    zero returned by of_property_read_u32().
    
    Storing the negative error codes in unsigned type, doesn't cause an issue
    at runtime but it's ugly as pants. Additionally, assigning negative error
    codes to unsigned type may trigger a GCC warning when the -Wsign-conversion
    flag is enabled.
    
    No effect on runtime.
    
    Signed-off-by: Qianfeng Rong <[email protected]>
    Reviewed-by: Sudeep Holla <[email protected]>
    Fixes: 0fbeae70ee7c ("regulator: add SCMI driver")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable() [+ + +]
Author: Zhen Ni <[email protected]>
Date:   Tue Sep 23 19:21:09 2025 +0800

    remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()
    
    commit d41e075b077142bb9ae5df40b9ddf9fd7821a811 upstream.
    
    pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULL
    check, which could lead to a null pointer dereference. Move the pru
    assignment, ensuring we never dereference a NULL rproc pointer.
    
    Fixes: 102853400321 ("remoteproc: pru: Add pru_rproc_set_ctable() function")
    Cc: [email protected]
    Signed-off-by: Zhen Ni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

remoteproc: qcom: pas: Shutdown lite ADSP DTB on X1E [+ + +]
Author: Stephan Gerhold <[email protected]>
Date:   Wed Aug 20 18:02:35 2025 +0200

    remoteproc: qcom: pas: Shutdown lite ADSP DTB on X1E
    
    [ Upstream commit 142964960c7c35de5c5f7bdd61c32699de693630 ]
    
    The ADSP firmware on X1E has separate firmware binaries for the main
    firmware and the DTB. The same applies for the "lite" firmware loaded by
    the boot firmware.
    
    When preparing to load the new ADSP firmware we shutdown the lite_pas_id
    for the main firmware, but we don't shutdown the corresponding lite pas_id
    for the DTB. The fact that we're leaving it "running" forever becomes
    obvious if you try to reuse (or just access) the memory region used by the
    "lite" firmware: The &adsp_boot_mem is accessible, but accessing the
    &adsp_boot_dtb_mem results in a crash.
    
    We don't support reusing the memory regions currently, but nevertheless we
    should not keep part of the lite firmware running. Fix this by adding the
    lite_dtb_pas_id and shutting it down as well.
    
    We don't have a way to detect if the lite firmware is actually running yet,
    so ignore the return status of qcom_scm_pas_shutdown() for now. This was
    already the case before, the assignment to "ret" is not used anywhere.
    
    Fixes: 62210f7509e1 ("remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSP")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Stephan Gerhold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice [+ + +]
Author: Stephan Gerhold <[email protected]>
Date:   Wed Aug 20 18:02:33 2025 +0200

    remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice
    
    [ Upstream commit 110be46f5afe27b66caa2d12473a84cd397b1925 ]
    
    enable_irq() and disable_irq() are reference counted, so we must make sure
    that each enable_irq() is always paired with a single disable_irq(). If we
    call disable_irq() twice followed by just a single enable_irq(), the IRQ
    will remain disabled forever.
    
    For the error handling path in qcom_q6v5_wait_for_start(), disable_irq()
    will end up being called twice, because disable_irq() also happens in
    qcom_q6v5_unprepare() when rolling back the call to qcom_q6v5_prepare().
    
    Fix this by dropping disable_irq() in qcom_q6v5_wait_for_start(). Since
    qcom_q6v5_prepare() is the function that calls enable_irq(), it makes more
    sense to have the rollback handled always by qcom_q6v5_unprepare().
    
    Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Stephan Gerhold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

remoteproc: qcom_q6v5_mss: support loading MBN file on msm8974 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Jul 6 17:47:08 2025 +0300

    remoteproc: qcom_q6v5_mss: support loading MBN file on msm8974
    
    [ Upstream commit 581e3dea0ece4b59cf714c9dfe195a178d3ae13b ]
    
    On MSM8974 / APQ8074, MSM8226 and MSM8926 the MSS requires loading raw
    MBA image instead of the ELF file. Skip the ELF headers if mba.mbn was
    specified as the firmware image.
    
    Fixes: a5a4e02d083d ("remoteproc: qcom: Add support for parsing fw dt bindings")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Luca Weiss <[email protected]> # msm8974pro-fairphone-fp2
    Link: https://lore.kernel.org/r/[email protected]
    [bjorn: Unwrapped the long memcpy line, to taste]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations" [+ + +]
Author: Beleswar Padhi <[email protected]>
Date:   Mon Sep 8 19:58:14 2025 +0530

    Revert "arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations"
    
    [ Upstream commit 932424a925ce79cbed0a93d36c5f1b69a0128de1 ]
    
    This reverts commit 1a314099b7559690fe23cdf3300dfff6e830ecb1.
    
    The C6x carveouts are reversed intentionally. This is due to the
    requirement to keep the DMA memory region as non-cached, however the
    minimum granular cache region for C6x is 16MB. So, C66x_0 marks the
    entire C66x_1 16MB memory carveouts as non-cached, and uses the DMA
    memory region of C66x_1 as its own, and vice-versa.
    
    This was also called out in the original commit which introduced these
    reversed carveouts:
            "The minimum granularity on the Cache settings on C66x DSP
            cores is 16MB, so the DMA memory regions are chosen such that
            they are in separate 16MB regions for each DSP, while reserving
            a total of 16 MB for each DSP and not changing the overall DSP
            remoteproc carveouts."
    
    Fixes: 1a314099b755 ("arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations")
    Signed-off-by: Beleswar Padhi <[email protected]>
    Acked-by: Andrew Davis <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Revert "arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations" [+ + +]
Author: Beleswar Padhi <[email protected]>
Date:   Mon Sep 8 19:58:13 2025 +0530

    Revert "arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations"
    
    [ Upstream commit 79a1778c7819c8491cdbdc1f7e46d478cb84d5cf ]
    
    This reverts commit 9f3814a7c06b7c7296cf8c1622078ad71820454b.
    
    The C6x carveouts are reversed intentionally. This is due to the
    requirement to keep the DMA memory region as non-cached, however the
    minimum granular cache region for C6x is 16MB. So, C66x_0 marks the
    entire C66x_1 16MB memory carveouts as non-cached, and uses the DMA
    memory region of C66x_1 as its own, and vice-versa.
    
    This was also called out in the original commit which introduced these
    reversed carveouts:
            "The minimum granularity on the Cache settings on C66x DSP cores
            is 16MB, so the DMA memory regions are chosen such that they are
            in separate 16MB regions for each DSP, while reserving a total
            of 16 MB for each DSP and not changing the overall DSP
            remoteproc carveouts."
    
    Fixes: 9f3814a7c06b ("arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations")
    Signed-off-by: Beleswar Padhi <[email protected]>
    Acked-by: Andrew Davis <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "net/mlx5e: Update and set Xon/Xoff upon MTU set" [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Mon Sep 29 11:15:29 2025 -0700

    Revert "net/mlx5e: Update and set Xon/Xoff upon MTU set"
    
    [ Upstream commit 6f5dacf88a32b3fd8b52c8ea781bf188c42aaa95 ]
    
    This reverts commit ceddedc969f0532b7c62ca971ee50d519d2bc0cb.
    
    Commit in question breaks the mapping of PGs to pools for some SKUs.
    Specifically multi-host NICs seem to be shipped with a custom buffer
    configuration which maps the lossy PG to pool 4. But the bad commit
    overrides this with pool 0 which does not have sufficient buffer space
    reserved. Resulting in ~40% packet loss. The commit also breaks BMC /
    OOB connection completely (100% packet loss).
    
    Revert, similarly to commit 3fbfe251cc9f ("Revert "net/mlx5e: Update and
    set Xon/Xoff upon port speed set""). The breakage is exactly the same,
    the only difference is that quoted commit would break the NIC immediately
    on boot, and the currently reverted commit only when MTU is changed.
    
    Note: "good" kernels do not restore the configuration, so downgrade isn't
    enough to recover machines. A NIC power cycle seems to be necessary to
    return to a healthy state (or overriding the relevant registers using
    a custom patch).
    
    Fixes: ceddedc969f0 ("net/mlx5e: Update and set Xon/Xoff upon MTU set")
    Signed-off-by: Jakub Kicinski <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running" [+ + +]
Author: Michal Pecio <[email protected]>
Date:   Thu Sep 18 00:07:20 2025 +0300

    Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running"
    
    [ Upstream commit 08fa726e66039dfa80226dfa112931f60ad4c898 ]
    
    This reverts commit 28a76fcc4c85dd39633fb96edb643c91820133e3.
    
    No actual HW bugs are known where Endpoint Context shows Running state
    but Stop Endpoint fails repeatedly with Context State Error and leaves
    the endpoint state unchanged. Stop Endpoint retries on Running EPs have
    been performed since early 2021 with no such issues reported so far.
    
    Trying to handle this hypothetical case brings a more realistic danger:
    if Stop Endpoint fails on an endpoint which hasn't yet started after a
    doorbell ring and enough latency occurs before this completion event is
    handled, the driver may time out and begin removing cancelled TDs from
    a running endpoint, even though one more retry would stop it reliably.
    
    Such high latency is rare but not impossible, and removing TDs from a
    running endpoint can cause more damage than not giving back a cancelled
    URB (which wasn't happening anyway). So err on the side of caution and
    revert to the old policy of always retrying if the EP appears running.
    
    [Remove stable tag as we are dealing with theoretical cases -Mathias]
    
    Fixes: 28a76fcc4c85d ("usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running")
    Signed-off-by: Michal Pecio <[email protected]>
    Signed-off-by: Mathias Nyman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RISC-V: KVM: Write hgatp register with valid mode bits [+ + +]
Author: Fangyu Yu <[email protected]>
Date:   Thu Aug 21 10:25:40 2025 -0400

    RISC-V: KVM: Write hgatp register with valid mode bits
    
    [ Upstream commit 2b351e3d04be9e1533f26c3464f1e44a5beace30 ]
    
    According to the RISC-V Privileged Architecture Spec, when MODE=Bare
    is selected,software must write zero to the remaining fields of hgatp.
    
    We have detected the valid mode supported by the HW before, So using a
    valid mode to detect how many vmid bits are supported.
    
    Fixes: fd7bb4a251df ("RISC-V: KVM: Implement VMID allocator")
    Reviewed-by: Nutty Liu <[email protected]>
    Reviewed-by: Troy Mitchell <[email protected]>
    Reviewed-by: Guo Ren (Alibaba DAMO Academy) <[email protected]>
    Signed-off-by: Fangyu Yu <[email protected]>
    Signed-off-by: Guo Ren (Alibaba DAMO Academy) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Anup Patel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
riscv, bpf: Sign extend struct ops return values properly [+ + +]
Author: Hengqi Chen <[email protected]>
Date:   Mon Sep 8 01:24:48 2025 +0000

    riscv, bpf: Sign extend struct ops return values properly
    
    [ Upstream commit fd2e08128944a7679e753f920e9eda72057e427c ]
    
    The ns_bpf_qdisc selftest triggers a kernel panic:
    
        Unable to handle kernel paging request at virtual address ffffffffa38dbf58
        Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000
        [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000
        Oops [#1]
        Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)]
        CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G        W  OE       6.17.0-rc1-g2465bb83e0b4 #1 NONE
        Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
        Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024
        epc : __qdisc_run+0x82/0x6f0
         ra : __qdisc_run+0x6e/0x6f0
        epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550
         gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180
         t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0
         s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001
         a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000
         a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049
         s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000
         s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0
         s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000
         s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000
         t5 : 0000000000000000 t6 : ff60000093a6a8b6
        status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d
        [<ffffffff80bd5c7a>] __qdisc_run+0x82/0x6f0
        [<ffffffff80b6fe58>] __dev_queue_xmit+0x4c0/0x1128
        [<ffffffff80b80ae0>] neigh_resolve_output+0xd0/0x170
        [<ffffffff80d2daf6>] ip6_finish_output2+0x226/0x6c8
        [<ffffffff80d31254>] ip6_finish_output+0x10c/0x2a0
        [<ffffffff80d31446>] ip6_output+0x5e/0x178
        [<ffffffff80d2e232>] ip6_xmit+0x29a/0x608
        [<ffffffff80d6f4c6>] inet6_csk_xmit+0xe6/0x140
        [<ffffffff80c985e4>] __tcp_transmit_skb+0x45c/0xaa8
        [<ffffffff80c995fe>] tcp_connect+0x9ce/0xd10
        [<ffffffff80d66524>] tcp_v6_connect+0x4ac/0x5e8
        [<ffffffff80cc19b8>] __inet_stream_connect+0xd8/0x318
        [<ffffffff80cc1c36>] inet_stream_connect+0x3e/0x68
        [<ffffffff80b42b20>] __sys_connect_file+0x50/0x88
        [<ffffffff80b42bee>] __sys_connect+0x96/0xc8
        [<ffffffff80b42c40>] __riscv_sys_connect+0x20/0x30
        [<ffffffff80e5bcae>] do_trap_ecall_u+0x256/0x378
        [<ffffffff80e69af2>] handle_exception+0x14a/0x156
        Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709
        ---[ end trace 0000000000000000 ]---
    
    The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer
    is treated as a 32bit value and sign extend to 64bit in epilogue. This
    behavior is right for most bpf prog types but wrong for struct ops which
    requires RISC-V ABI.
    
    So let's sign extend struct ops return values according to the function
    model and RISC-V ABI([0]).
    
      [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf
    
    Fixes: 25ad10658dc1 ("riscv, bpf: Adapt bpf trampoline to optimized riscv ftrace framework")
    Signed-off-by: Hengqi Chen <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Tested-by: Pu Lehui <[email protected]>
    Reviewed-by: Pu Lehui <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
rpmsg: qcom_smd: Fix fallback to qcom,ipc parse [+ + +]
Author: Barnabás Czémán <[email protected]>
Date:   Fri Jul 25 22:02:58 2025 +0200

    rpmsg: qcom_smd: Fix fallback to qcom,ipc parse
    
    [ Upstream commit 09390ed9af37ed612dd0967ff2b0d639872b8776 ]
    
    mbox_request_channel() returning value was changed in case of error.
    It uses returning value of of_parse_phandle_with_args().
    It is returning with -ENOENT instead of -ENODEV when no mboxes property
    exists.
    
    Fixes: 24fdd5074b20 ("mailbox: use error ret code of of_parse_phandle_with_args()")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Stephan Gerhold <[email protected]>
    Tested-by: Stephan Gerhold <[email protected]> # msm8939
    Signed-off-by: Barnabás Czémán <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rust: cpumask: Mark CpumaskVar as transparent [+ + +]
Author: Baptiste Lepers <[email protected]>
Date:   Tue Aug 12 16:42:11 2025 +0200

    rust: cpumask: Mark CpumaskVar as transparent
    
    [ Upstream commit 23fca458f6ab18927e50c2134fb7b60297f18b4e ]
    
    Unsafe code in CpumaskVar's methods assumes that the type has the same
    layout as `bindings::cpumask_var_t`. This is not guaranteed by
    the default struct representation in Rust, but requires specifying the
    `transparent` representation.
    
    Fixes: 8961b8cb3099a ("rust: cpumask: Add initial abstractions")
    Signed-off-by: Baptiste Lepers <[email protected]>
    Reviewed-by: Alice Ryhl <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/bpf: Do not write tail call counter into helper and kfunc frames [+ + +]
Author: Ilya Leoshkevich <[email protected]>
Date:   Wed Aug 13 14:06:28 2025 +0200

    s390/bpf: Do not write tail call counter into helper and kfunc frames
    
    [ Upstream commit eada40e057fc1842358d9daca3abe5cacb21e8a1 ]
    
    Only BPF functions make use of the tail call counter; helpers and
    kfuncs ignore and most likely also clobber it. Writing it into these
    functions' frames is pointless and misleading, so do not do it.
    
    Fixes: dd691e847d28 ("s390/bpf: Implement bpf_jit_supports_subprog_tailcalls()")
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

s390/bpf: Write back tail call counter for BPF_PSEUDO_CALL [+ + +]
Author: Ilya Leoshkevich <[email protected]>
Date:   Wed Aug 13 14:06:29 2025 +0200

    s390/bpf: Write back tail call counter for BPF_PSEUDO_CALL
    
    [ Upstream commit c861a6b147137d10b5ff88a2c492ba376cd1b8b0 ]
    
    The tailcall_bpf2bpf_hierarchy_1 test hangs on s390. Its call graph is
    as follows:
    
      entry()
        subprog_tail()
          bpf_tail_call_static(0) -> entry + tail_call_start
        subprog_tail()
          bpf_tail_call_static(0) -> entry + tail_call_start
    
    entry() copies its tail call counter to the subprog_tail()'s frame,
    which then increments it. However, the incremented result is discarded,
    leading to an astronomically large number of tail calls.
    
    Fix by writing the incremented counter back to the entry()'s frame.
    
    Fixes: dd691e847d28 ("s390/bpf: Implement bpf_jit_supports_subprog_tailcalls()")
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

s390/bpf: Write back tail call counter for BPF_TRAMP_F_CALL_ORIG [+ + +]
Author: Ilya Leoshkevich <[email protected]>
Date:   Wed Aug 13 14:06:30 2025 +0200

    s390/bpf: Write back tail call counter for BPF_TRAMP_F_CALL_ORIG
    
    [ Upstream commit bc3905a71f02511607d3ccf732360580209cac4c ]
    
    The tailcall_bpf2bpf_hierarchy_fentry test hangs on s390. Its call
    graph is as follows:
    
      entry()
        subprog_tail()
          trampoline()
            fentry()
            the rest of subprog_tail()  # via BPF_TRAMP_F_CALL_ORIG
            return to entry()
    
    The problem is that the rest of subprog_tail() increments the tail call
    counter, but the trampoline discards the incremented value. This
    results in an astronomically large number of tail calls.
    
    Fix by making the trampoline write the incremented tail call counter
    back.
    
    Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()")
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/fair: Get rid of sched_domains_curr_level hack for tl->cpumask() [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Mon Aug 25 12:02:44 2025 +0000

    sched/fair: Get rid of sched_domains_curr_level hack for tl->cpumask()
    
    [ Upstream commit 661f951e371cc134ea31c84238dbdc9a898b8403 ]
    
    Leon [1] and Vinicius [2] noted a topology_span_sane() warning during
    their testing starting from v6.16-rc1. Debug that followed pointed to
    the tl->mask() for the NODE domain being incorrectly resolved to that of
    the highest NUMA domain.
    
    tl->mask() for NODE is set to the sd_numa_mask() which depends on the
    global "sched_domains_curr_level" hack. "sched_domains_curr_level" is
    set to the "tl->numa_level" during tl traversal in build_sched_domains()
    calling sd_init() but was not reset before topology_span_sane().
    
    Since "tl->numa_level" still reflected the old value from
    build_sched_domains(), topology_span_sane() for the NODE domain trips
    when the span of the last NUMA domain overlaps.
    
    Instead of replicating the "sched_domains_curr_level" hack, get rid of
    it entirely and instead, pass the entire "sched_domain_topology_level"
    object to tl->cpumask() function to prevent such mishap in the future.
    
    sd_numa_mask() now directly references "tl->numa_level" instead of
    relying on the global "sched_domains_curr_level" hack to index into
    sched_domains_numa_masks[].
    
    The original warning was reproducible on the following NUMA topology
    reported by Leon:
    
        $ sudo numactl -H
        available: 5 nodes (0-4)
        node 0 cpus: 0 1
        node 0 size: 2927 MB
        node 0 free: 1603 MB
        node 1 cpus: 2 3
        node 1 size: 3023 MB
        node 1 free: 3008 MB
        node 2 cpus: 4 5
        node 2 size: 3023 MB
        node 2 free: 3007 MB
        node 3 cpus: 6 7
        node 3 size: 3023 MB
        node 3 free: 3002 MB
        node 4 cpus: 8 9
        node 4 size: 3022 MB
        node 4 free: 2718 MB
        node distances:
        node   0   1   2   3   4
          0:  10  39  38  37  36
          1:  39  10  38  37  36
          2:  38  38  10  37  36
          3:  37  37  37  10  36
          4:  36  36  36  36  10
    
    The above topology can be mimicked using the following QEMU cmd that was
    used to reproduce the warning and test the fix:
    
         sudo qemu-system-x86_64 -enable-kvm -cpu host \
         -m 20G -smp cpus=10,sockets=10 -machine q35 \
         -object memory-backend-ram,size=4G,id=m0 \
         -object memory-backend-ram,size=4G,id=m1 \
         -object memory-backend-ram,size=4G,id=m2 \
         -object memory-backend-ram,size=4G,id=m3 \
         -object memory-backend-ram,size=4G,id=m4 \
         -numa node,cpus=0-1,memdev=m0,nodeid=0 \
         -numa node,cpus=2-3,memdev=m1,nodeid=1 \
         -numa node,cpus=4-5,memdev=m2,nodeid=2 \
         -numa node,cpus=6-7,memdev=m3,nodeid=3 \
         -numa node,cpus=8-9,memdev=m4,nodeid=4 \
         -numa dist,src=0,dst=1,val=39 \
         -numa dist,src=0,dst=2,val=38 \
         -numa dist,src=0,dst=3,val=37 \
         -numa dist,src=0,dst=4,val=36 \
         -numa dist,src=1,dst=0,val=39 \
         -numa dist,src=1,dst=2,val=38 \
         -numa dist,src=1,dst=3,val=37 \
         -numa dist,src=1,dst=4,val=36 \
         -numa dist,src=2,dst=0,val=38 \
         -numa dist,src=2,dst=1,val=38 \
         -numa dist,src=2,dst=3,val=37 \
         -numa dist,src=2,dst=4,val=36 \
         -numa dist,src=3,dst=0,val=37 \
         -numa dist,src=3,dst=1,val=37 \
         -numa dist,src=3,dst=2,val=37 \
         -numa dist,src=3,dst=4,val=36 \
         -numa dist,src=4,dst=0,val=36 \
         -numa dist,src=4,dst=1,val=36 \
         -numa dist,src=4,dst=2,val=36 \
         -numa dist,src=4,dst=3,val=36 \
         ...
    
      [ prateek: Moved common functions to include/linux/sched/topology.h,
        reuse the common bits for s390 and ppc, commit message ]
    
    Closes: https://lore.kernel.org/lkml/20250610110701.GA256154@unreal/ [1]
    Fixes: ccf74128d66c ("sched/topology: Assert non-NUMA topology masks don't (partially) overlap") # ce29a7da84cd, f55dac1dafb3
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reported-by: Leon Romanovsky <[email protected]>
    Signed-off-by: K Prateek Nayak <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Valentin Schneider <[email protected]>
    Reviewed-by: Shrikanth Hegde <[email protected]>
    Tested-by: Valentin Schneider <[email protected]> # x86
    Tested-by: Shrikanth Hegde <[email protected]> # powerpc
    Link: https://lore.kernel.org/lkml/a3de98387abad28592e6ab591f3ff6107fe01dc1.1755893468.git.tim.c.chen@linux.intel.com/ [2]
    Signed-off-by: Sasha Levin <[email protected]>

 
scripts/misc-check: update export checks for EXPORT_SYMBOL_FOR_MODULES() [+ + +]
Author: Vlastimil Babka <[email protected]>
Date:   Mon Aug 25 17:00:37 2025 +0200

    scripts/misc-check: update export checks for EXPORT_SYMBOL_FOR_MODULES()
    
    [ Upstream commit 0354e81b7bd629f9c3379c9524e988ebc504fa25 ]
    
    The module export checks are looking for EXPORT_SYMBOL_GPL_FOR_MODULES()
    which was renamed to EXPORT_SYMBOL_FOR_MODULES(). Update the checks.
    
    Fixes: 6d3c3ca4c77e ("module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES")
    Signed-off-by: Vlastimil Babka <[email protected]>
    Reviewed-by: Daniel Gomez <[email protected]>
    Reviewed-by: Nicolas Schier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: libsas: Add dev_parent_is_expander() helper [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Thu Aug 14 19:32:18 2025 +0200

    scsi: libsas: Add dev_parent_is_expander() helper
    
    [ Upstream commit e5eb72c92eb724aa14c50c7d92d1a576dd50d7e6 ]
    
    Many libsas drivers check if the parent of the device is an expander.
    Create a helper that the libsas drivers will use in follow up commits.
    
    Suggested-by: Damien Le Moal <[email protected]>
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Reviewed-by: Jason Yan <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: ad70c6bc776b ("scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpt3sas: Fix crash in transport port remove by using ioc_info() [+ + +]
Author: Ranjan Kumar <[email protected]>
Date:   Mon Sep 22 15:21:10 2025 +0530

    scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()
    
    [ Upstream commit 1703fe4f8ae50d1fb6449854e1fcaed1053e3a14 ]
    
    During mpt3sas_transport_port_remove(), messages were logged with
    dev_printk() against &mpt3sas_port->port->dev. At this point the SAS
    transport device may already be partially unregistered or freed, leading
    to a crash when accessing its struct device.
    
    Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),
    guaranteed to remain valid until driver removal.
    
    [83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI
    [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G           OE       6.16.0-rc1+ #1 PREEMPT(voluntary)
    [83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024
    [83428.295799] RIP: 0010:__dev_printk+0x1f/0x70
    [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff
    [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206
    [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32
    [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845
    [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8
    [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000
    [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30
    [83428.295833] FS:  00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000
    [83428.295837] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0
    [83428.295844] PKRU: 55555554
    [83428.295846] Call Trace:
    [83428.295848]  <TASK>
    [83428.295850]  _dev_printk+0x5c/0x80
    [83428.295857]  ? srso_alias_return_thunk+0x5/0xfbef5
    [83428.295863]  mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas]
    [83428.295882]  _scsih_remove_device+0x21b/0x280 [mpt3sas]
    [83428.295894]  ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas]
    [83428.295906]  ? srso_alias_return_thunk+0x5/0xfbef5
    [83428.295910]  mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas]
    [83428.295921]  _scsih_expander_node_remove+0x129/0x140 [mpt3sas]
    [83428.295933]  _scsih_expander_node_remove+0x6a/0x140 [mpt3sas]
    [83428.295944]  scsih_remove+0x3f0/0x4a0 [mpt3sas]
    [83428.295957]  pci_device_remove+0x3b/0xb0
    [83428.295962]  device_release_driver_internal+0x193/0x200
    [83428.295968]  driver_detach+0x44/0x90
    [83428.295971]  bus_remove_driver+0x69/0xf0
    [83428.295975]  pci_unregister_driver+0x2a/0xb0
    [83428.295979]  _mpt3sas_exit+0x1f/0x300 [mpt3sas]
    [83428.295991]  __do_sys_delete_module.constprop.0+0x174/0x310
    [83428.295997]  ? srso_alias_return_thunk+0x5/0xfbef5
    [83428.296000]  ? __x64_sys_getdents64+0x9a/0x110
    [83428.296005]  ? srso_alias_return_thunk+0x5/0xfbef5
    [83428.296009]  ? syscall_trace_enter+0xf6/0x1b0
    [83428.296014]  do_syscall_64+0x7b/0x2c0
    [83428.296019]  ? srso_alias_return_thunk+0x5/0xfbef5
    [83428.296023]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
    Signed-off-by: Ranjan Kumar <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: myrs: Fix dma_alloc_coherent() error check [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Fri Jul 25 10:31:06 2025 +0200

    scsi: myrs: Fix dma_alloc_coherent() error check
    
    [ Upstream commit edb35b1ffc686fd9b5a91902f034eb9f4d2c9f6b ]
    
    Check for NULL return value with dma_alloc_coherent(), because DMA
    address is not always set by dma_alloc_coherent() on failure.
    
    Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm80xx: Add helper function to get the local phy id [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Thu Aug 14 19:32:23 2025 +0200

    scsi: pm80xx: Add helper function to get the local phy id
    
    [ Upstream commit b4ec98303f9fc9b1da0053106716db6a7e002d8b ]
    
    Avoid duplicated code by adding a helper to get the local phy id.
    
    No functional changes intended.
    
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: ad70c6bc776b ("scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Thu Aug 14 19:32:17 2025 +0200

    scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod
    
    [ Upstream commit 251be2f6037fb7ab399f68cd7428ff274133d693 ]
    
    Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when
    device is gone") UBSAN reports:
    
      UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17
      index 28 is out of range for type 'pm8001_phy [16]'
    
    on rmmod when using an expander.
    
    For a direct attached device, attached_phy contains the local phy id.
    For a device behind an expander, attached_phy contains the remote phy
    id, not the local phy id.
    
    I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for a
    device behind an expander, attached_phy can be much larger than
    pm8001_ha->chip->n_phy (depending on the amount of phys of the
    expander).
    
    E.g. on my system pm8001_ha has 8 phys with phy ids 0-7.  One of the
    ports has an expander connected.  The expander has 31 phys with phy ids
    0-30.
    
    The pm8001_ha->phy array only contains the phys of the HBA.  It does not
    contain the phys of the expander.  Thus, it is wrong to use attached_phy
    to index the pm8001_ha->phy array for a device behind an expander.
    
    Thus, we can only clear phy_attached for devices that are directly
    attached.
    
    Fixes: f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when device is gone")
    Reviewed-by: Igor Pylypiv <[email protected]>
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Tested-by: Damien Le Moal <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Thu Aug 14 19:32:24 2025 +0200

    scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander
    
    [ Upstream commit ad70c6bc776b53e61c8db6533c833aff0ff5da8b ]
    
    For a direct attached device, attached_phy contains the local phy id.
    For a device behind an expander, attached_phy contains the remote phy
    id, not the local phy id.
    
    The pm8001_ha->phy array only contains the phys of the HBA.  It does not
    contain the phys of the expander.
    
    Thus, you cannot use attached_phy to index the pm8001_ha->phy array,
    without first verifying that the device is directly attached.
    
    Use the pm80xx_get_local_phy_id() helper to make sure that we use the
    local phy id to index the array, regardless if the device is directly
    attached or not.
    
    Fixes: 869ddbdcae3b ("scsi: pm80xx: corrected SATA abort handling sequence.")
    Reviewed-by: Igor Pylypiv <[email protected]>
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm80xx: Restore support for expanders [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Thu Aug 14 19:32:16 2025 +0200

    scsi: pm80xx: Restore support for expanders
    
    [ Upstream commit eeee1086073e0058243c8554738271561bde81f1 ]
    
    Commit 0f630c58e31a ("scsi: pm80xx: Do not use libsas port ID") broke
    support for expanders. After the commit, devices behind an expander are
    no longer detected.
    
    Simply reverting the commit restores support for devices behind an
    expander.
    
    Instead of reverting the commit (and reintroducing a helper to get the
    port), get the port directly from the lldd_port pointer in struct
    asd_sas_port.
    
    Fixes: 0f630c58e31a ("scsi: pm80xx: Do not use libsas port ID")
    Suggested-by: Igor Pylypiv <[email protected]>
    Reviewed-by: Igor Pylypiv <[email protected]>
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Tested-by: Damien Le Moal <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm80xx: Use dev_parent_is_expander() helper [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Thu Aug 14 19:32:22 2025 +0200

    scsi: pm80xx: Use dev_parent_is_expander() helper
    
    [ Upstream commit 35e388696c3f3b6bf70e2010873c5e0c1d37d579 ]
    
    Make use of the dev_parent_is_expander() helper.
    
    Signed-off-by: Niklas Cassel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Reviewed-by: Igor Pylypiv <[email protected]>
    Acked-by: Jack Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: ad70c6bc776b ("scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: edif: Fix incorrect sign of error code [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Fri Sep 5 15:54:43 2025 +0800

    scsi: qla2xxx: edif: Fix incorrect sign of error code
    
    [ Upstream commit 066b8f3fa85c1be7fb7dbae202231e131d38f7bc ]
    
    Change the error code EAGAIN to -EAGAIN in qla24xx_sadb_update() and
    qla_edif_process_els() to align with qla2x00_start_sp() returning
    negative error codes or QLA_SUCCESS, preventing logical errors.
    
    Fixes: 0b3f3143d473 ("scsi: qla2xxx: edif: Add retry for ELS passthrough")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Fix incorrect sign of error code in qla_nvme_xmt_ls_rsp() [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Fri Sep 5 15:54:45 2025 +0800

    scsi: qla2xxx: Fix incorrect sign of error code in qla_nvme_xmt_ls_rsp()
    
    [ Upstream commit 9877c004e9f4d10e7786ac80a50321705d76e036 ]
    
    Change the error code EAGAIN to -EAGAIN in qla_nvme_xmt_ls_rsp() to
    align with qla2x00_start_sp() returning negative error codes or
    QLA_SUCCESS, preventing logical errors.
    
    Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Fix incorrect sign of error code in START_SP_W_RETRIES() [+ + +]
Author: Qianfeng Rong <[email protected]>
Date:   Fri Sep 5 15:54:44 2025 +0800

    scsi: qla2xxx: Fix incorrect sign of error code in START_SP_W_RETRIES()
    
    [ Upstream commit 1f037e3acda79639a78f096355f2c308a3d45492 ]
    
    Change the error code EAGAIN to -EAGAIN in START_SP_W_RETRIES() to align
    with qla2x00_start_sp() returning negative error codes or QLA_SUCCESS,
    preventing logical errors.  Additionally, the '_rval' variable should
    store negative error codes to conform to Linux kernel error code
    conventions.
    
    Fixes: 9803fb5d2759 ("scsi: qla2xxx: Fix task management cmd failure")
    Signed-off-by: Qianfeng Rong <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Fix data race in CPU latency PM QoS request handling [+ + +]
Author: Zhongqiu Han <[email protected]>
Date:   Wed Sep 17 17:41:43 2025 +0800

    scsi: ufs: core: Fix data race in CPU latency PM QoS request handling
    
    [ Upstream commit 79dde5f7dc7c038eec903745dc1550cd4139980e ]
    
    The cpu_latency_qos_add/remove/update_request interfaces lack internal
    synchronization by design, requiring the caller to ensure thread safety.
    The current implementation relies on the 'pm_qos_enabled' flag, which is
    insufficient to prevent concurrent access and cannot serve as a proper
    synchronization mechanism. This has led to data races and list
    corruption issues.
    
    A typical race condition call trace is:
    
    [Thread A]
    ufshcd_pm_qos_exit()
      --> cpu_latency_qos_remove_request()
        --> cpu_latency_qos_apply();
          --> pm_qos_update_target()
            --> plist_del              <--(1) delete plist node
        --> memset(req, 0, sizeof(*req));
      --> hba->pm_qos_enabled = false;
    
    [Thread B]
    ufshcd_devfreq_target
      --> ufshcd_devfreq_scale
        --> ufshcd_scale_clks
          --> ufshcd_pm_qos_update     <--(2) pm_qos_enabled is true
            --> cpu_latency_qos_update_request
              --> pm_qos_update_target
                --> plist_del          <--(3) plist node use-after-free
    
    Introduces a dedicated mutex to serialize PM QoS operations, preventing
    data races and ensuring safe access to PM QoS resources, including sysfs
    interface reads.
    
    Fixes: 2777e73fc154 ("scsi: ufs: core: Add CPU latency QoS support for UFS driver")
    Signed-off-by: Zhongqiu Han <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Tested-by: Huan Tang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Fix PM QoS mutex initialization [+ + +]
Author: Marek Szyprowski <[email protected]>
Date:   Mon Sep 29 13:27:30 2025 +0200

    scsi: ufs: core: Fix PM QoS mutex initialization
    
    commit 0ba7a254afd037cfc2b656f379c54b43c6e574e8 upstream.
    
    hba->pm_qos_mutex is used very early as a part of ufshcd_init(), so it
    need to be initialized before that call. This fixes the following
    warning:
    
    ------------[ cut here ]------------
    DEBUG_LOCKS_WARN_ON(lock->magic != lock)
    WARNING: kernel/locking/mutex.c:577 at __mutex_lock+0x268/0x894, CPU#4: kworker/u32:4/72
    Modules linked in:
    CPU: 4 UID: 0 PID: 72 Comm: kworker/u32:4 Not tainted 6.17.0-rc7-next-20250926+ #11223 PREEMPT
    Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
    Workqueue: events_unbound deferred_probe_work_func
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __mutex_lock+0x268/0x894
    lr : __mutex_lock+0x268/0x894
    ...
    Call trace:
     __mutex_lock+0x268/0x894 (P)
     mutex_lock_nested+0x24/0x30
     ufshcd_pm_qos_update+0x30/0x78
     ufshcd_setup_clocks+0x2d4/0x3c4
     ufshcd_init+0x234/0x126c
     ufshcd_pltfrm_init+0x62c/0x82c
     ufs_qcom_probe+0x20/0x58
     platform_probe+0x5c/0xac
     really_probe+0xbc/0x298
     __driver_probe_device+0x78/0x12c
     driver_probe_device+0x40/0x164
     __device_attach_driver+0xb8/0x138
     bus_for_each_drv+0x80/0xdc
     __device_attach+0xa8/0x1b0
     device_initial_probe+0x14/0x20
     bus_probe_device+0xb0/0xb4
     deferred_probe_work_func+0x8c/0xc8
     process_one_work+0x208/0x60c
     worker_thread+0x244/0x388
     kthread+0x150/0x228
     ret_from_fork+0x10/0x20
    irq event stamp: 57267
    hardirqs last  enabled at (57267): [<ffffd761485e868c>] _raw_spin_unlock_irqrestore+0x74/0x78
    hardirqs last disabled at (57266): [<ffffd76147b13c44>] clk_enable_lock+0x7c/0xf0
    softirqs last  enabled at (56270): [<ffffd7614734446c>] handle_softirqs+0x4c4/0x4dc
    softirqs last disabled at (56265): [<ffffd76147290690>] __do_softirq+0x14/0x20
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 79dde5f7dc7c ("scsi: ufs: core: Fix data race in CPU latency PM QoS request handling")
    Signed-off-by: Marek Szyprowski <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
seccomp: Fix a race with WAIT_KILLABLE_RECV if the tracer replies too fast [+ + +]
Author: Johannes Nixdorf <[email protected]>
Date:   Fri Jul 25 18:31:18 2025 +0200

    seccomp: Fix a race with WAIT_KILLABLE_RECV if the tracer replies too fast
    
    [ Upstream commit cce436aafc2abad691fdd37de63ec8a4490b42ce ]
    
    Normally the tracee starts in SECCOMP_NOTIFY_INIT, sends an
    event to the tracer, and starts to wait interruptibly. With
    SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV, if the tracer receives the
    message (SECCOMP_NOTIFY_SENT is reached) while the tracee was waiting
    and is subsequently interrupted, the tracee begins to wait again
    uninterruptibly (but killable).
    
    This fails if SECCOMP_NOTIFY_REPLIED is reached before the tracee
    is interrupted, as the check only considered SECCOMP_NOTIFY_SENT as a
    condition to begin waiting again. In this case the tracee is interrupted
    even though the tracer already acted on its behalf. This breaks the
    assumption SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV wanted to ensure,
    namely that the tracer can be sure the syscall is not interrupted or
    restarted on the tracee after it is received on the tracer. Fix this
    by also considering SECCOMP_NOTIFY_REPLIED when evaluating whether to
    switch to uninterruptible waiting.
    
    With the condition changed the loop in seccomp_do_user_notification()
    would exit immediately after deciding that noninterruptible waiting
    is required if the operation already reached SECCOMP_NOTIFY_REPLIED,
    skipping the code that processes pending addfd commands first. Prevent
    this by executing the remaining loop body one last time in this case.
    
    Fixes: c2aa2dfef243 ("seccomp: Add wait_killable semantic to seccomp user notifier")
    Reported-by: Ali Polatel <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220291
    Signed-off-by: Johannes Nixdorf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftest/futex: Compile also with libnuma < 2.0.16 [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Mon Sep 15 23:26:30 2025 +0200

    selftest/futex: Compile also with libnuma < 2.0.16
    
    [ Upstream commit ed323aeda5e09fa1ab95946673939c8c425c329c ]
    
    After using numa_set_mempolicy_home_node() the test fails to compile on
    systems with libnuma library versioned lower than 2.0.16.
    
    In order to allow lower library version add a pkg-config related check
    and exclude that part of the code. Without the proper MPOL setup it
    can't be tested.
    
    Make a total number of tests two. The first one is the first batch and
    the second is the MPOL related one. The goal is to let the user know if
    it has been skipped due to library limitation.
    
    Remove test_futex_mpol(), it was unused and it is now complained by the
    compiler if the part is not compiled.
    
    Fixes: 0ecb4232fc65e ("selftests/futex: Set the home_node in futex_numa_mpol")
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftest/futex: Make the error check more precise for futex_numa_mpol [+ + +]
Author: André Almeida <[email protected]>
Date:   Mon Sep 15 23:26:28 2025 +0200

    selftest/futex: Make the error check more precise for futex_numa_mpol
    
    [ Upstream commit c1c863457780adfb2e29fa9a85897179ad3903e6 ]
    
    Instead of just checking if the syscall failed as expected, check as
    well if the returned error code matches the expected error code.
    
    [ bigeasy: reword the commmit message ]
    
    Signed-off-by: André Almeida <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Waiman Long <[email protected]>
    Stable-dep-of: ed323aeda5e0 ("selftest/futex: Compile also with libnuma < 2.0.16")
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Copy test_kmods when installing selftest [+ + +]
Author: Amery Hung <[email protected]>
Date:   Tue Aug 12 10:50:39 2025 -0700

    selftests/bpf: Copy test_kmods when installing selftest
    
    [ Upstream commit 07866544e410e4c895a729971e4164861b41fad5 ]
    
    Commit d6212d82bf26 ("selftests/bpf: Consolidate kernel modules into
    common directory") consolidated the Makefile of test_kmods. However,
    since it removed test_kmods from TEST_GEN_PROGS_EXTENDED, the kernel
    modules required by bpf selftests are now missing from kselftest_install
    when "make install". Fix it by adding test_kmod to TEST_GEN_FILES.
    
    Fixes: d6212d82bf26 ("selftests/bpf: Consolidate kernel modules into common directory")
    Signed-off-by: Amery Hung <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix count write in testapp_xdp_metadata_copy() [+ + +]
Author: Ricardo B. Marlière <[email protected]>
Date:   Fri Aug 29 16:33:49 2025 -0300

    selftests/bpf: Fix count write in testapp_xdp_metadata_copy()
    
    [ Upstream commit c9110e6f7237f4a314e2b87b75a8a158b9877a7b ]
    
    Commit 4b302092553c ("selftests/xsk: Add tail adjustment tests and support
    check") added a new global to xsk_xdp_progs.c, but left out the access in
    the testapp_xdp_metadata_copy() function. Since bpf_map_update_elem() will
    write to the whole bss section, it gets truncated. Fix by writing to
    skel_rx->bss->count directly.
    
    Fixes: 4b302092553c ("selftests/xsk: Add tail adjustment tests and support check")
    Signed-off-by: Ricardo B. Marlière <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/20250829-selftests-bpf-xsk_regression_fix-v1-1-5f5acdb9fe6b@suse.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix realloc size in bpf_get_addrs [+ + +]
Author: Jiri Olsa <[email protected]>
Date:   Wed Oct 1 14:22:23 2025 +0200

    selftests/bpf: Fix realloc size in bpf_get_addrs
    
    [ Upstream commit 0c342bfc9949dffeaa83ebdde3b4b0ce59009348 ]
    
    We will segfault once we call realloc in bpf_get_addrs due to
    wrong size argument.
    
    Fixes: 6302bdeb91df ("selftests/bpf: Add a kprobe_multi subtest to use addrs instead of syms")
    Signed-off-by: Jiri Olsa <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix typos and grammar in test sources [+ + +]
Author: Shubham Sharma <[email protected]>
Date:   Tue Aug 26 18:27:46 2025 +0530

    selftests/bpf: Fix typos and grammar in test sources
    
    [ Upstream commit d3abefe897408718799ae3bd06295b89b870a38e ]
    
    Fix spelling typos and grammar errors in BPF selftests source code.
    
    Signed-off-by: Shubham Sharma <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 0c342bfc9949 ("selftests/bpf: Fix realloc size in bpf_get_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: move get_ksyms and get_addrs to trace_helpers.c [+ + +]
Author: Menglong Dong <[email protected]>
Date:   Thu Sep 4 10:10:09 2025 +0800

    selftests/bpf: move get_ksyms and get_addrs to trace_helpers.c
    
    [ Upstream commit 8bad31edf5490a38dc26163502cd7005a033ee05 ]
    
    We need to get all the kernel function that can be traced sometimes, so we
    move the get_syms() and get_addrs() in kprobe_multi_test.c to
    trace_helpers.c and rename it to bpf_get_ksyms() and bpf_get_addrs().
    
    Signed-off-by: Menglong Dong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Stable-dep-of: 0c342bfc9949 ("selftests/bpf: Fix realloc size in bpf_get_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/futex: Fix futex_wait() for 32bit ARM [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Aug 27 15:00:11 2025 +0200

    selftests/futex: Fix futex_wait() for 32bit ARM
    
    [ Upstream commit 237bfb76c90b184f57bb18fe35ff366c19393dc8 ]
    
    On 32bit ARM systems gcc-12 will use 32bit timestamps while gcc-13 and later
    will use 64bit timestamps.  The problem is that SYS_futex will continue
    pointing at the 32bit system call.  This makes the futex_wait test fail like
    this:
    
      waiter failed errno 110
      not ok 1 futex_wake private returned: 0 Success
      waiter failed errno 110
      not ok 2 futex_wake shared (page anon) returned: 0 Success
      waiter failed errno 110
      not ok 3 futex_wake shared (file backed) returned: 0 Success
    
    Instead of compiling differently depending on the gcc version, use the
    -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 options to ensure that 64bit timestamps
    are used.  Then use ifdefs to make SYS_futex point to the 64bit system call.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: André Almeida <[email protected]>
    Tested-by: Anders Roxell <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Stable-dep-of: ed323aeda5e0 ("selftest/futex: Compile also with libnuma < 2.0.16")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/futex: Fix some futex_numa_mpol subtests [+ + +]
Author: Waiman Long <[email protected]>
Date:   Wed Aug 27 15:00:08 2025 +0200

    selftests/futex: Fix some futex_numa_mpol subtests
    
    [ Upstream commit d8e2f919997b14665e4509ef9a5278f291598d6e ]
    
    The "Memory out of range" subtest of futex_numa_mpol assumes that memory
    access outside of the mmap'ed area is invalid. That may not be the case
    depending on the actual memory layout of the test application. When that
    subtest was run on an x86-64 system with latest upstream kernel, the test
    passed as an error was returned from futex_wake(). On another PowerPC system,
    the same subtest failed because futex_wake() returned 0.
    
      Bail out! futex2_wake(64, 0x86) should fail, but didn't
    
    Looking further into the passed subtest on x86-64, it was found that an
    -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned
    because the node value test with FLAGS_NUMA set failed with a node value
    of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed
    because the supposed node number wasn't valid. If that memory location
    happens to have a very small value (e.g. 0), the test will pass and no
    error will be returned.
    
    Since this subtest is non-deterministic, drop it unless a guard page beyond
    the mmap region is explicitly set.
    
    The other problematic test is the "Memory too small" test. The futex_wake()
    function returns the -EINVAL error code because the given futex address isn't
    8-byte aligned, not because only 4 of the 8 bytes are valid and the other
    4 bytes are not. So change the name of this subtest to "Mis-aligned futex" to
    reflect the reality.
    
      [ bp: Massage commit message. ]
    
    Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol")
    Signed-off-by: Waiman Long <[email protected]>
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Sebastian Andrzej Siewior <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

selftests/futex: Remove the -g parameter from futex_priv_hash [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Wed Aug 27 15:00:07 2025 +0200

    selftests/futex: Remove the -g parameter from futex_priv_hash
    
    [ Upstream commit 2e62688d583809e832433f461194334408b10817 ]
    
    The -g parameter was meant to the test the immutable global hash instead of the
    private hash which has been made immutable. The global hash is tested as part
    at the end of the regular test. The immutable private hash been removed.
    
    Remove last traces of the immutable private hash.
    
    Fixes: 16adc7f136dc1 ("selftests/futex: Remove support for IMMUTABLE")
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: André Almeida <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/kselftest_harness: Add harness-selftest.expected to TEST_FILES [+ + +]
Author: Yi Lai <[email protected]>
Date:   Tue Sep 9 16:26:19 2025 +0800

    selftests/kselftest_harness: Add harness-selftest.expected to TEST_FILES
    
    [ Upstream commit 3e23a3f688b457288c37899f8898180cc231ff97 ]
    
    The harness-selftest.expected is not installed in INSTALL_PATH.
    Attempting to execute harness-selftest.sh shows warning:
    
    diff: ./kselftest_harness/harness-selftest.expected: No such file or
    directory
    
    Add harness-selftest.expected to TEST_FILES.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: df82ffc5a3c1 ("selftests: harness: Add kselftest harness selftest")
    Signed-off-by: Yi Lai <[email protected]>
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/mm: fix va_high_addr_switch.sh failure on x86_64 [+ + +]
Author: Chunyu Hu <[email protected]>
Date:   Fri Sep 12 09:37:11 2025 +0800

    selftests/mm: fix va_high_addr_switch.sh failure on x86_64
    
    [ Upstream commit c56325259abc026205c98964616dcc0df5648912 ]
    
    The test will fail as below on x86_64 with cpu la57 support (will skip if
    no la57 support).  Note, the test requries nr_hugepages to be set first.
    
      # running bash ./va_high_addr_switch.sh
      # -------------------------------------
      # mmap(addr_switch_hint - pagesize, pagesize): 0x7f55b60fa000 - OK
      # mmap(addr_switch_hint - pagesize, (2 * pagesize)): 0x7f55b60f9000 - OK
      # mmap(addr_switch_hint, pagesize): 0x800000000000 - OK
      # mmap(addr_switch_hint, 2 * pagesize, MAP_FIXED): 0x800000000000 - OK
      # mmap(NULL): 0x7f55b60f9000 - OK
      # mmap(low_addr): 0x40000000 - OK
      # mmap(high_addr): 0x1000000000000 - OK
      # mmap(high_addr) again: 0xffff55b6136000 - OK
      # mmap(high_addr, MAP_FIXED): 0x1000000000000 - OK
      # mmap(-1): 0xffff55b6134000 - OK
      # mmap(-1) again: 0xffff55b6132000 - OK
      # mmap(addr_switch_hint - pagesize, pagesize): 0x7f55b60fa000 - OK
      # mmap(addr_switch_hint - pagesize, 2 * pagesize): 0x7f55b60f9000 - OK
      # mmap(addr_switch_hint - pagesize/2 , 2 * pagesize): 0x7f55b60f7000 - OK
      # mmap(addr_switch_hint, pagesize): 0x800000000000 - OK
      # mmap(addr_switch_hint, 2 * pagesize, MAP_FIXED): 0x800000000000 - OK
      # mmap(NULL, MAP_HUGETLB): 0x7f55b5c00000 - OK
      # mmap(low_addr, MAP_HUGETLB): 0x40000000 - OK
      # mmap(high_addr, MAP_HUGETLB): 0x1000000000000 - OK
      # mmap(high_addr, MAP_HUGETLB) again: 0xffff55b5e00000 - OK
      # mmap(high_addr, MAP_FIXED | MAP_HUGETLB): 0x1000000000000 - OK
      # mmap(-1, MAP_HUGETLB): 0x7f55b5c00000 - OK
      # mmap(-1, MAP_HUGETLB) again: 0x7f55b5a00000 - OK
      # mmap(addr_switch_hint - pagesize, 2*hugepagesize, MAP_HUGETLB): 0x800000000000 - FAILED
      # mmap(addr_switch_hint , 2*hugepagesize, MAP_FIXED | MAP_HUGETLB): 0x800000000000 - OK
      # [FAIL]
    
    addr_switch_hint is defined as DFEFAULT_MAP_WINDOW in the failed test (for
    x86_64, DFEFAULT_MAP_WINDOW is defined as (1UL<<47) - pagesize) in 64 bit.
    
    Before commit cc92882ee218 ("mm: drop hugetlb_get_unmapped_area{_*}
    functions"), for x86_64 hugetlb_get_unmapped_area() is handled in arch
    code arch/x86/mm/hugetlbpage.c and addr is checked with
    map_address_hint_valid() after align with 'addr &= huge_page_mask(h)'
    which is a round down way, and it will fail the check because the addr is
    within the DEFAULT_MAP_WINDOW but (addr + len) is above the
    DFEFAULT_MAP_WINDOW.  So it wil go through the
    hugetlb_get_unmmaped_area_top_down() to find an area within the
    DFEFAULT_MAP_WINDOW.
    
    After commit cc92882ee218 ("mm: drop hugetlb_get_unmapped_area{_*}
    functions").  The addr hint for hugetlb_get_unmmaped_area() will be
    rounded up and aligned to hugepage size with ALIGN() for all arches.  And
    after the align, the addr will be above the default MAP_DEFAULT_WINDOW,
    and the map_addresshint_valid() check will pass because both aligned addr
    (addr0) and (addr + len) are above the DEFAULT_MAP_WINDOW, and the aligned
    hint address (0x800000000000) is returned as an suitable gap is found
    there, in arch_get_unmapped_area_topdown().
    
    To still cover the case that addr is within the DEFAULT_MAP_WINDOW, and
    addr + len is above the DFEFAULT_MAP_WINDOW, change to choose the last
    hugepage aligned address within the DEFAULT_MAP_WINDOW as the hint addr,
    and the addr + len (2 hugepages) will be one hugepage above the
    DEFAULT_MAP_WINDOW.  An aligned address won't be affected by the page
    round up or round down from kernel, so it's determistic.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: cc92882ee218 ("mm: drop hugetlb_get_unmapped_area{_*} functions")
    Signed-off-by: Chunyu Hu <[email protected]>
    Suggested-by: David Hildenbrand <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/mm: skip soft-dirty tests when CONFIG_MEM_SOFT_DIRTY is disabled [+ + +]
Author: Lance Yang <[email protected]>
Date:   Wed Sep 17 21:31:37 2025 +0800

    selftests/mm: skip soft-dirty tests when CONFIG_MEM_SOFT_DIRTY is disabled
    
    commit 0389c305ef56cbadca4cbef44affc0ec3213ed30 upstream.
    
    The madv_populate and soft-dirty kselftests currently fail on systems
    where CONFIG_MEM_SOFT_DIRTY is disabled.
    
    Introduce a new helper softdirty_supported() into vm_util.c/h to ensure
    tests are properly skipped when the feature is not enabled.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 9f3265db6ae8 ("selftests: vm: add test for Soft-Dirty PTE bit")
    Signed-off-by: Lance Yang <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Suggested-by: David Hildenbrand <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Cc: Gabriel Krisman Bertazi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/nolibc: fix EXPECT_NZ macro [+ + +]
Author: Benjamin Berg <[email protected]>
Date:   Thu Jul 31 22:12:22 2025 +0200

    selftests/nolibc: fix EXPECT_NZ macro
    
    [ Upstream commit 6d33ce3634f99e0c6c9ce9fc111261f2c411cb48 ]
    
    The expect non-zero macro was incorrect and never used. Fix its
    definition.
    
    Fixes: 362aecb2d8cfa ("selftests/nolibc: add basic infrastructure to ease creation of nolibc tests")
    Signed-off-by: Benjamin Berg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: always install UAPI headers to the correct directory [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Thu Sep 18 11:56:36 2025 +0200

    selftests: always install UAPI headers to the correct directory
    
    [ Upstream commit 2c55daf7de07158df2ab3835321086beca25a691 ]
    
    Currently the UAPI headers are always installed into the source directory.
    When building out-of-tree this doesn't work, as the include path will be
    wrong and it dirties the source tree, leading to complains by kbuild.
    
    Make sure the 'headers' target installs the UAPI headers in the correctly.
    
    The real target directory can come from multiple places. To handle them all
    extract the target directory from KHDR_INCLUDES.
    
    Link: https://lore.kernel.org/r/20250918-kselftest-uapi-out-of-tree-v1-1-f4434f28adcd@linutronix.de
    Reported-by: Jason Gunthorpe <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Fixes: 1a59f5d31569 ("selftests: Add headers target")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: arm64: Check fread return value in exec_target [+ + +]
Author: Bala-Vignesh-Reddy <[email protected]>
Date:   Fri Aug 8 13:38:30 2025 +0530

    selftests: arm64: Check fread return value in exec_target
    
    [ Upstream commit a679e5683d3eef22ca12514ff8784b2b914ebedc ]
    
    Fix -Wunused-result warning generated when compiled with gcc 13.3.0,
    by checking fread's return value and handling errors, preventing
    potential failures when reading from stdin.
    
    Fixes compiler warning:
    warning: ignoring return value of 'fread' declared with attribute
    'warn_unused_result' [-Wunused-result]
    
    Fixes: 806a15b2545e ("kselftests/arm64: add PAuth test for whether exec() changes keys")
    
    Signed-off-by: Bala-Vignesh-Reddy <[email protected]>
    Reviewed-by: Mark Brown <[email protected]>
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: arm64: Fix -Waddress warning in tpidr2 test [+ + +]
Author: Bala-Vignesh-Reddy <[email protected]>
Date:   Thu Aug 7 17:12:29 2025 +0530

    selftests: arm64: Fix -Waddress warning in tpidr2 test
    
    [ Upstream commit 50af02425afc72b1b47c4a0a0b9c9bdaa1a1b347 ]
    
    Thanks to -Waddress, the compiler warns that the ksft_test_result()
    invocations in the arm64 tpidr2 selftest are always true. Oops.
    
    Fix the test by, err, actually running the test functions.
    
    Fixes: 6d80cb73131d ("kselftest/arm64: Convert tpidr2 test to use kselftest.h")
    Signed-off-by: Bala-Vignesh-Reddy <[email protected]>
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Mark Brown <[email protected]>
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: cgroup: Make test_pids backwards compatible [+ + +]
Author: Michal Koutný <[email protected]>
Date:   Wed Aug 27 17:53:00 2025 +0200

    selftests: cgroup: Make test_pids backwards compatible
    
    [ Upstream commit 3b0dec689a6301845761681b852f9538cb75a1d2 ]
    
    The predicates in test expect event counting from 73e75e6fc352b
    ("cgroup/pids: Separate semantics of pids.events related to pids.max")
    and the test would fail on older kernels. We want to have one version of
    tests for all, so detect the feature and skip the test on old kernels.
    (The test could even switch to check v1 semantics based on the flag but
    keep it simple for now.)
    
    Fixes: 9f34c566027b6 ("selftests: cgroup: Add basic tests for pids controller")
    Signed-off-by: Michal Koutný <[email protected]>
    Tested-by: Sebastian Chlad <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: vDSO: Fix -Wunitialized in powerpc VDSO_CALL() wrapper [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Tue Aug 12 07:39:02 2025 +0200

    selftests: vDSO: Fix -Wunitialized in powerpc VDSO_CALL() wrapper
    
    [ Upstream commit 9f15e0f9ef514b8e1a80707931f6d07362e8ebc4 ]
    
    The _rval register variable is meant to be an output operand of the asm
    statement but is instead used as input operand.
    clang 20.1 notices this and triggers -Wuninitialized warnings:
    
    tools/testing/selftests/timers/auxclock.c:154:10: error: variable '_rval' is uninitialized when used here [-Werror,-Wuninitialized]
      154 |                 return VDSO_CALL(self->vdso_clock_gettime64, 2, clockid, ts);
          |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    tools/testing/selftests/timers/../vDSO/vdso_call.h:59:10: note: expanded from macro 'VDSO_CALL'
       59 |                 : "r" (_rval)                                           \
          |                        ^~~~~
    tools/testing/selftests/timers/auxclock.c:154:10: note: variable '_rval' is declared here
    tools/testing/selftests/timers/../vDSO/vdso_call.h:47:2: note: expanded from macro 'VDSO_CALL'
       47 |         register long _rval asm ("r3");                                 \
          |         ^
    
    It seems the list of input and output operands have been switched around.
    However as the argument registers are not always initialized they can not
    be marked as pure inputs as that would trigger -Wuninitialized warnings.
    Adding _rval as another input and output operand does also not work as it
    would collide with the existing _r3 variable.
    
    Instead reuse _r3 for both the argument and the return value.
    
    Fixes: 6eda706a535c ("selftests: vDSO: fix the way vDSO functions are called for powerpc")
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

selftests: vDSO: vdso_test_abi: Correctly skip whole test with missing vDSO [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Tue Aug 12 07:39:03 2025 +0200

    selftests: vDSO: vdso_test_abi: Correctly skip whole test with missing vDSO
    
    [ Upstream commit 4b59a9f7628fd82b24f2148f62cf327a84d26555 ]
    
    If AT_SYSINFO_EHDR is missing the whole test needs to be skipped.
    Currently this results in the following output:
    
            TAP version 13
            1..16
            # AT_SYSINFO_EHDR is not present!
    
    This output is incorrect, as "1..16" still requires the subtest lines to
    be printed, which isn't done however.
    
    Switch to the correct skipping functions, so the output now correctly
    indicates that no subtests are being run:
    
            TAP version 13
            1..0 # SKIP AT_SYSINFO_EHDR is not present!
    
    Fixes: 693f5ca08ca0 ("kselftest: Extend vDSO selftest")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported [+ + +]
Author: Akhilesh Patil <[email protected]>
Date:   Sun Sep 14 20:58:41 2025 +0530

    selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported
    
    [ Upstream commit e8cfc524eaf3c0ed88106177edb6961e202e6716 ]
    
    Check if watchdog device supports WDIOF_KEEPALIVEPING option before
    entering keep_alive() ping test loop. Fix watchdog-test silently looping
    if ioctl based ping is not supported by the device. Exit from test in
    such case instead of getting stuck in loop executing failing keep_alive()
    
    watchdog_info:
     identity:              m41t93 rtc Watchdog
     firmware_version:      0
    Support/Status: Set timeout (in seconds)
    Support/Status: Watchdog triggers a management or other external alarm not a reboot
    
    Watchdog card disabled.
    Watchdog timeout set to 5 seconds.
    Watchdog ping rate set to 2 seconds.
    Watchdog card enabled.
    WDIOC_KEEPALIVE not supported by this device
    
    without this change
    Watchdog card disabled.
    Watchdog timeout set to 5 seconds.
    Watchdog ping rate set to 2 seconds.
    Watchdog card enabled.
    Watchdog Ticking Away!
    (Where test stuck here forver silently)
    
    Updated change log at commit time:
    Shuah Khan <[email protected]>
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: d89d08ffd2c5 ("selftests: watchdog: Fix ioctl SET* error paths to take oneshot exit path")
    Signed-off-by: Akhilesh Patil <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: max310x: Add error checking in probe() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Thu Aug 7 18:54:37 2025 +0300

    serial: max310x: Add error checking in probe()
    
    [ Upstream commit 672a37ba8af1f2ebcedeb94aea2cdd047f805f30 ]
    
    Check if devm_i2c_new_dummy_device() fails.
    
    Fixes: 2e1f2d9a9bdb ("serial: max310x: implement I2C support")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smb: client: fix crypto buffers in non-linear memory [+ + +]
Author: Enzo Matsumiya <[email protected]>
Date:   Thu Sep 25 12:10:33 2025 -0300

    smb: client: fix crypto buffers in non-linear memory
    
    [ Upstream commit 998a67b954680f26f3734040aeeed08642d49721 ]
    
    The crypto API, through the scatterlist API, expects input buffers to be
    in linear memory.  We handle this with the cifs_sg_set_buf() helper
    that converts vmalloc'd memory to their corresponding pages.
    
    However, when we allocate our aead_request buffer (@creq in
    smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly
    puts aead_request->__ctx in vmalloc area.
    
    AEAD algorithm then uses ->__ctx for its private/internal data and
    operations, and uses sg_set_buf() for such data on a few places.
    
    This works fine as long as @creq falls into kmalloc zone (small
    requests) or vmalloc'd memory is still within linear range.
    
    Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too
    many tasks will increment the base stacks' addresses to a point where
    virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that
    happens.
    
    In practice: too many parallel reads and writes on an encrypted mount
    will trigger this bug.
    
    To fix this, always alloc @creq with kmalloc() instead.
    Also drop the @sensitive_size variable/arguments since
    kfree_sensitive() doesn't need it.
    
    Backtrace:
    
    [  945.272081] ------------[ cut here ]------------
    [  945.272774] kernel BUG at include/linux/scatterlist.h:209!
    [  945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
    [  945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)
    [  945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
    [  945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)
    [  945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220
    [  945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b
    [  945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246
    [  945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030
    [  945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070
    [  945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000
    [  945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070
    [  945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010
    [  945.284407] FS:  0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000
    [  945.285262] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0
    [  945.286683] Call Trace:
    [  945.286952]  <TASK>
    [  945.287184]  ? crypt_message+0x33f/0xad0 [cifs]
    [  945.287719]  crypto_gcm_encrypt+0x36/0xe0
    [  945.288152]  crypt_message+0x54a/0xad0 [cifs]
    [  945.288724]  smb3_init_transform_rq+0x277/0x300 [cifs]
    [  945.289300]  smb_send_rqst+0xa3/0x160 [cifs]
    [  945.289944]  cifs_call_async+0x178/0x340 [cifs]
    [  945.290514]  ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
    [  945.291177]  smb2_async_writev+0x3e3/0x670 [cifs]
    [  945.291759]  ? find_held_lock+0x32/0x90
    [  945.292212]  ? netfs_advance_write+0xf2/0x310
    [  945.292723]  netfs_advance_write+0xf2/0x310
    [  945.293210]  netfs_write_folio+0x346/0xcc0
    [  945.293689]  ? __pfx__raw_spin_unlock_irq+0x10/0x10
    [  945.294250]  netfs_writepages+0x117/0x460
    [  945.294724]  do_writepages+0xbe/0x170
    [  945.295152]  ? find_held_lock+0x32/0x90
    [  945.295600]  ? kvm_sched_clock_read+0x11/0x20
    [  945.296103]  __writeback_single_inode+0x56/0x4b0
    [  945.296643]  writeback_sb_inodes+0x229/0x550
    [  945.297140]  __writeback_inodes_wb+0x4c/0xe0
    [  945.297642]  wb_writeback+0x2f1/0x3f0
    [  945.298069]  wb_workfn+0x300/0x490
    [  945.298472]  process_one_work+0x1fe/0x590
    [  945.298949]  worker_thread+0x1ce/0x3c0
    [  945.299397]  ? __pfx_worker_thread+0x10/0x10
    [  945.299900]  kthread+0x119/0x210
    [  945.300285]  ? __pfx_kthread+0x10/0x10
    [  945.300729]  ret_from_fork+0x119/0x1b0
    [  945.301163]  ? __pfx_kthread+0x10/0x10
    [  945.301601]  ret_from_fork_asm+0x1a/0x30
    [  945.302055]  </TASK>
    
    Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list")
    Signed-off-by: Enzo Matsumiya <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: client: fix sending the iwrap custom IRD/ORD negotiation messages [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Wed Aug 20 11:25:06 2025 +0200

    smb: client: fix sending the iwrap custom IRD/ORD negotiation messages
    
    [ Upstream commit ef71f1e046489c77a2f7d012edc762fba0a7aadc ]
    
    Do a real negotiation and check the servers initiator_depth and
    responder_resources.
    
    This should use big endian in order to be useful.
    I have captures of windows clients showing this.
    
    The fact that we used little endian up to now
    means that we sent very large numbers and the
    negotiation with the server truncated them to the
    server limits.
    
    Note the reason why this uses u8 for
    initiator_depth and responder_resources is
    that the rdma layer also uses it.
    
    The inconsitency regarding the initiator_depth
    and responder_resources values being reversed
    for iwarp devices in RDMA_CM_EVENT_ESTABLISHED
    should also be fixed later, but for now we should
    fix it.
    
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: Long Li <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Fixes: c7398583340a ("CIFS: SMBD: Implement RDMA memory registration")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: server: fix IRD/ORD negotiation with the client [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Wed Aug 20 15:34:58 2025 +0200

    smb: server: fix IRD/ORD negotiation with the client
    
    [ Upstream commit fad988a2158d743da7971884b93482a73735b25e ]
    
    Already do real negotiation in smb_direct_handle_connect_request()
    where we see the requested initiator_depth and responder_resources
    from the client.
    
    We should detect legacy iwarp clients using MPA v1
    with the custom IRD/ORD negotiation.
    
    We need to send the custom IRD/ORD in big endian,
    but we need to try to let clients with broken requests
    using little endian (older cifs.ko) to work.
    
    Note the reason why this uses u8 for
    initiator_depth and responder_resources is
    that the rdma layer also uses it.
    
    Acked-by: Namjae Jeon <[email protected]>
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smc: Fix use-after-free in __pnet_find_base_ndev(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:19 2025 +0000

    smc: Fix use-after-free in __pnet_find_base_ndev().
    
    [ Upstream commit 3d3466878afd8d43ec0ca2facfbc7f03e40d0f79 ]
    
    syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),
    which was called during connect(). [0]
    
    smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passes
    down to pnet_find_base_ndev(), where RTNL is held.  Then, UAF happened
    at __pnet_find_base_ndev() when the dev is first used.
    
    This means dev had already been freed before acquiring RTNL in
    pnet_find_base_ndev().
    
    While dev is going away, dst->dev could be swapped with blackhole_netdev,
    and the dev's refcnt by dst will be released.
    
    We must hold dev's refcnt before calling smc_pnet_find_ism_resource().
    
    Also, smc_pnet_find_roce_resource() has the same problem.
    
    Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.
    
    [0]:
    BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926
    Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609
    
    CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
    Call Trace:
     <TASK>
     dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0xca/0x240 mm/kasan/report.c:482
     kasan_report+0x118/0x150 mm/kasan/report.c:595
     __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926
     pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline]
     smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline]
     smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154
     smc_find_ism_device net/smc/af_smc.c:1030 [inline]
     smc_find_proposal_devices net/smc/af_smc.c:1115 [inline]
     __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545
     smc_connect+0x877/0xd90 net/smc/af_smc.c:1715
     __sys_connect_file net/socket.c:2086 [inline]
     __sys_connect+0x313/0x440 net/socket.c:2105
     __do_sys_connect net/socket.c:2111 [inline]
     __se_sys_connect net/socket.c:2108 [inline]
     __x64_sys_connect+0x7a/0x90 net/socket.c:2108
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f47cbf8eba9
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9
    RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b
    RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8
     </TASK>
    
    The buggy address belongs to the physical page:
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac
    flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
    raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000
    raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as freed
    page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466
     set_page_owner include/linux/page_owner.h:32 [inline]
     post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851
     prep_new_page mm/page_alloc.c:1859 [inline]
     get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858
     __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148
     alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416
     ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317
     __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348
     __do_kmalloc_node mm/slub.c:4364 [inline]
     __kvmalloc_node_noprof+0x6d/0x5f0 mm/slub.c:5067
     alloc_netdev_mqs+0xa3/0x11b0 net/core/dev.c:11812
     tun_set_iff+0x532/0xef0 drivers/net/tun.c:2775
     __tun_chr_ioctl+0x788/0x1df0 drivers/net/tun.c:3085
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:598 [inline]
     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    page last free pid 18610 tgid 18608 stack trace:
     reset_page_owner include/linux/page_owner.h:25 [inline]
     free_pages_prepare mm/page_alloc.c:1395 [inline]
     __free_frozen_pages+0xbc4/0xd30 mm/page_alloc.c:2895
     free_large_kmalloc+0x13a/0x1f0 mm/slub.c:4820
     device_release+0x99/0x1c0 drivers/base/core.c:-1
     kobject_cleanup lib/kobject.c:689 [inline]
     kobject_release lib/kobject.c:720 [inline]
     kref_put include/linux/kref.h:65 [inline]
     kobject_put+0x22b/0x480 lib/kobject.c:737
     netdev_run_todo+0xd2e/0xea0 net/core/dev.c:11513
     rtnl_unlock net/core/rtnetlink.c:157 [inline]
     rtnl_net_unlock include/linux/rtnetlink.h:135 [inline]
     rtnl_dellink+0x537/0x710 net/core/rtnetlink.c:3563
     rtnetlink_rcv_msg+0x7cc/0xb70 net/core/rtnetlink.c:6946
     netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552
     netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
     netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346
     netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
     sock_sendmsg_nosec net/socket.c:714 [inline]
     __sock_sendmsg+0x219/0x270 net/socket.c:729
     ____sys_sendmsg+0x505/0x830 net/socket.c:2614
     ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
     __sys_sendmsg net/socket.c:2700 [inline]
     __do_sys_sendmsg net/socket.c:2705 [inline]
     __se_sys_sendmsg net/socket.c:2703 [inline]
     __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Memory state around the buggy address:
     ffff888036bac200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ffff888036bac280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    >ffff888036bac300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                            ^
     ffff888036bac380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ffff888036bac400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    
    Fixes: 0afff91c6f5e ("net/smc: add pnetid support")
    Fixes: 1619f770589a ("net/smc: add pnetid support for SMC-D and ISM")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:20 2025 +0000

    smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
    
    [ Upstream commit 935d783e5de9b64587f3adb25641dd8385e64ddb ]
    
    smc_clc_prfx_set() is called during connect() and not under RCU
    nor RTNL.
    
    Using sk_dst_get(sk)->dev could trigger UAF.
    
    Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()
    after kernel_getsockname().
    
    Note that the returned value of smc_clc_prfx_set() is not used
    in the caller.
    
    While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()
    not to touch dst there.
    
    Fixes: a046d57da19f ("smc: CLC handshake (incl. preparation steps)")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:21 2025 +0000

    smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().
    
    [ Upstream commit 235f81045c008169cc4e1955b4a64e118eebe61b ]
    
    smc_clc_prfx_match() is called from smc_listen_work() and
    not under RCU nor RTNL.
    
    Using sk_dst_get(sk)->dev could trigger UAF.
    
    Let's use __sk_dst_get() and dst_dev_rcu().
    
    Note that the returned value of smc_clc_prfx_match() is not
    used in the caller.
    
    Fixes: a046d57da19f ("smc: CLC handshake (incl. preparation steps)")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:22 2025 +0000

    smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk().
    
    [ Upstream commit 0b0e4d51c6554e5ecc3f8cc73c2eaf12da21249a ]
    
    smc_vlan_by_tcpsk() fetches sk_dst_get(sk)->dev before RTNL and
    passes it to netdev_walk_all_lower_dev(), which is illegal.
    
    Also, smc_vlan_by_tcpsk_walk() does not require RTNL at all.
    
    Let's use __sk_dst_get(), dst_dev_rcu(), and
    netdev_walk_all_lower_dev_rcu().
    
    Note that the returned value of smc_vlan_by_tcpsk() is not used
    in the caller.
    
    Fixes: 0cfdd8f92cac ("smc: connection and link group creation")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smp: Fix up and expand the smp_call_function_many() kerneldoc [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Tue Sep 9 13:44:14 2025 +0200

    smp: Fix up and expand the smp_call_function_many() kerneldoc
    
    [ Upstream commit ccf09357ffef2ab472369ab9cdf470c9bc9b821a ]
    
    The smp_call_function_many() kerneldoc comment got out of sync with the
    function definition (bool parameter "wait" is incorrectly described as a
    bitmask in it), so fix it up by copying the "wait" description from the
    smp_call_function() kerneldoc and add information regarding the handling
    of the local CPU to it.
    
    Fixes: 49b3bd213a9f ("smp: Fix all kernel-doc warnings")
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: mediatek: mtk-svs: fix device leaks on mt8183 probe failure [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Sep 9 11:56:50 2025 +0200

    soc: mediatek: mtk-svs: fix device leaks on mt8183 probe failure
    
    [ Upstream commit 6ab4f79ea92324f7f2eb22692054a34bbba7cf35 ]
    
    Make sure to drop the references taken by of_find_device_by_node() when
    looking up the thermal sensor and opp devices during probe on probe
    failure (e.g. probe deferral) and on driver unbind.
    
    Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine")
    Cc: Roger Lu <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: mediatek: mtk-svs: fix device leaks on mt8192 probe failure [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Sep 9 11:56:51 2025 +0200

    soc: mediatek: mtk-svs: fix device leaks on mt8192 probe failure
    
    [ Upstream commit f1a68ba5739e42353609438e27a83b08d7f5cfd6 ]
    
    Make sure to drop the references taken by of_find_device_by_node() when
    looking up the thermal sensor and opp devices during probe on probe
    failure (e.g. probe deferral) and on driver unbind.
    
    Fixes: 0bbb09b2af9d ("soc: mediatek: SVS: add mt8192 SVS GPU driver")
    Cc: Roger Lu <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS [+ + +]
Author: Sneh Mankad <[email protected]>
Date:   Mon Aug 25 11:53:50 2025 +0530

    soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS
    
    [ Upstream commit f87412d18edb5b8393eb8cb1c2d4a54f90185a21 ]
    
    Unconditionally clear the TCS_AMC_MODE_TRIGGER bit when a
    transaction completes. Previously this bit was only cleared when
    a wake TCS was borrowed as an AMC TCS but not for dedicated
    AMC TCS. Leaving this bit set for AMC TCS and entering deeper low
    power modes can generate a false completion IRQ.
    
    Prevent this scenario by always clearing the TCS_AMC_MODE_TRIGGER
    bit upon receiving a completion IRQ.
    
    Fixes: 15b3bf61b8d4 ("soc: qcom: rpmh-rsc: Clear active mode configuration for wake TCS")
    Signed-off-by: Sneh Mankad <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sparc: fix accurate exception reporting in copy_to_user for Niagara 4 [+ + +]
Author: Michael Karcher <[email protected]>
Date:   Fri Sep 5 00:03:33 2025 +0200

    sparc: fix accurate exception reporting in copy_to_user for Niagara 4
    
    [ Upstream commit 5a746c1a2c7980de6c888b6373299f751ad7790b ]
    
    The referenced commit introduced exception handlers on user-space memory
    references in copy_from_user and copy_to_user. These handlers return from
    the respective function and calculate the remaining bytes left to copy
    using the current register contents. This commit fixes a bad calculation.
    This will fix the return value of copy_to_user in a specific faulting case.
    The behaviour of memcpy stays unchanged.
    
    Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.")
    Tested-by: John Paul Adrian Glaubitz <[email protected]> # on Oracle SPARC T4-1
    Signed-off-by: Michael Karcher <[email protected]>
    Reviewed-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-4-1ca72dda195b@mkarcher.dialup.fu-berlin.de
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sparc: fix accurate exception reporting in copy_{from,to}_user for M7 [+ + +]
Author: Michael Karcher <[email protected]>
Date:   Fri Sep 5 00:03:34 2025 +0200

    sparc: fix accurate exception reporting in copy_{from,to}_user for M7
    
    [ Upstream commit 936fb512752af349fc30ccbe0afe14a2ae6d7159 ]
    
    The referenced commit introduced exception handlers on user-space memory
    references in copy_from_user and copy_to_user. These handlers return from
    the respective function and calculate the remaining bytes left to copy
    using the current register contents. This commit fixes a couple of bad
    calculations. This will fix the return value of copy_from_user and
    copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
    
    Fixes: 34060b8fffa7 ("arch/sparc: Add accurate exception reporting in M7memcpy")
    Tested-by: John Paul Adrian Glaubitz <[email protected]> # on Oracle SPARC S7
    Tested-by: Tony Rodriguez <[email protected]> # S7, see https://lore.kernel.org/r/98564e2e68df2dda0e00c67a75c7f7dfedb33c7e.camel@physik.fu-berlin.de
    Signed-off-by: Michael Karcher <[email protected]>
    Reviewed-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-5-1ca72dda195b@mkarcher.dialup.fu-berlin.de
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara [+ + +]
Author: Michael Karcher <[email protected]>
Date:   Fri Sep 5 00:03:32 2025 +0200

    sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
    
    [ Upstream commit 0b67c8fc10b13a9090340c5f8a37d308f4e1571c ]
    
    The referenced commit introduced exception handlers on user-space memory
    references in copy_from_user and copy_to_user. These handlers return from
    the respective function and calculate the remaining bytes left to copy
    using the current register contents. This commit fixes a couple of bad
    calculations and a broken epilogue in the exception handlers. This will
    prevent crashes and ensure correct return values of copy_from_user and
    copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
    
    Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
    Tested-by: John Paul Adrian Glaubitz <[email protected]> # on SPARC T4 with modified kernel to use Niagara 1 code
    Tested-by: Magnus Lindholm <[email protected]> # on Sun Fire T2000
    Signed-off-by: Michael Karcher <[email protected]>
    Tested-by: Ethan Hawke <[email protected]> # on Sun Fire T2000
    Tested-by: Ken Link <[email protected]> # on Sun Fire T1000
    Reviewed-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-3-1ca72dda195b@mkarcher.dialup.fu-berlin.de
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC [+ + +]
Author: Michael Karcher <[email protected]>
Date:   Fri Sep 5 00:03:30 2025 +0200

    sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC
    
    [ Upstream commit 4fba1713001195e59cfc001ff1f2837dab877efb ]
    
    The referenced commit introduced exception handlers on user-space memory
    references in copy_from_user and copy_to_user. These handlers return from
    the respective function and calculate the remaining bytes left to copy
    using the current register contents. This commit fixes a couple of bad
    calculations. This will fix the return value of copy_from_user and
    copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
    
    Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.")
    Tested-by: John Paul Adrian Glaubitz <[email protected]> # on QEMU 10.0.3
    Tested-by: René Rebe <[email protected]> # on Ultra 5 UltraSparc IIi
    Tested-by: Jonathan 'theJPster' Pallant <[email protected]> # on Sun Netra T1
    Signed-off-by: Michael Karcher <[email protected]>
    Reviewed-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-1-1ca72dda195b@mkarcher.dialup.fu-berlin.de
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III [+ + +]
Author: Michael Karcher <[email protected]>
Date:   Fri Sep 5 00:03:31 2025 +0200

    sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
    
    [ Upstream commit 47b49c06eb62504075f0f2e2227aee2e2c2a58b3 ]
    
    Anthony Yznaga tracked down that a BUG_ON in ext4 code with large folios
    enabled resulted from copy_from_user() returning impossibly large values
    greater than the size to be copied. This lead to __copy_from_iter()
    returning impossible values instead of the actual number of bytes it was
    able to copy.
    
    The BUG_ON has been reported in
    https://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de
    
    The referenced commit introduced exception handlers on user-space memory
    references in copy_from_user and copy_to_user. These handlers return from
    the respective function and calculate the remaining bytes left to copy
    using the current register contents. The exception handlers expect that
    %o2 has already been masked during the bulk copy loop, but the masking was
    performed after that loop. This will fix the return value of copy_from_user
    and copy_to_user in the faulting case. The behaviour of memcpy stays
    unchanged.
    
    Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
    Tested-by: John Paul Adrian Glaubitz <[email protected]> # on Sun Netra 240
    Reviewed-by: Anthony Yznaga <[email protected]>
    Tested-by: René Rebe <[email protected]> # on UltraSparc III+ and UltraSparc IIIi
    Signed-off-by: Michael Karcher <[email protected]>
    Reviewed-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-2-1ca72dda195b@mkarcher.dialup.fu-berlin.de
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: fix return code when spi device has too many chipselects [+ + +]
Author: Jonas Gorski <[email protected]>
Date:   Mon Sep 15 20:37:19 2025 +0200

    spi: fix return code when spi device has too many chipselects
    
    [ Upstream commit 188f63235bcdd207646773a8739387d85347ed76 ]
    
    Don't return a positive value when there are too many chipselects.
    
    Fixes: 4d8ff6b0991d ("spi: Add multi-cs memories support in SPI core")
    Signed-off-by: Jonas Gorski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Squashfs: fix uninit-value in squashfs_get_parent [+ + +]
Author: Phillip Lougher <[email protected]>
Date:   Fri Sep 19 00:33:08 2025 +0100

    Squashfs: fix uninit-value in squashfs_get_parent
    
    commit 74058c0a9fc8b2b4d5f4a0ef7ee2cfa66a9e49cf upstream.
    
    Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.
    
    This is caused by open_by_handle_at() being called with a file handle
    containing an invalid parent inode number.  In particular the inode number
    is that of a symbolic link, rather than a directory.
    
    Squashfs_get_parent() gets called with that symbolic link inode, and
    accesses the parent member field.
    
            unsigned int parent_ino = squashfs_i(inode)->parent;
    
    Because non-directory inodes in Squashfs do not have a parent value, this
    is uninitialised, and this causes an uninitialised value access.
    
    The fix is to initialise parent with the invalid inode 0, which will cause
    an EINVAL error to be returned.
    
    Regular inodes used to share the parent field with the block_list_start
    field.  This is removed in this commit to enable the parent field to
    contain the invalid inode number 0.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 122601408d20 ("Squashfs: export operations")
    Signed-off-by: Phillip Lougher <[email protected]>
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
srcu/tiny: Remove preempt_disable/enable() in srcu_gp_start_if_needed() [+ + +]
Author: Zqiang <[email protected]>
Date:   Thu Sep 11 20:51:55 2025 +0800

    srcu/tiny: Remove preempt_disable/enable() in srcu_gp_start_if_needed()
    
    [ Upstream commit e6a43aeb71852a39432332dcc3a6d11bb464b075 ]
    
    Currently, the srcu_gp_start_if_needed() is always be invoked in
    preempt disable's critical section, this commit therefore remove
    redundant preempt_disable/enable() in srcu_gp_start_if_needed()
    and adds a call to lockdep_assert_preemption_disabled() in order
    to enable lockdep to diagnose mistaken invocations of this function
    from preempts-enabled code.
    
    Fixes: 65b4a59557f6 ("srcu: Make Tiny SRCU explicitly disable preemption")
    Signed-off-by: Zqiang <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sunrpc: fix null pointer dereference on zero-length checksum [+ + +]
Author: Lei Lu <[email protected]>
Date:   Mon Aug 11 21:58:48 2025 +0800

    sunrpc: fix null pointer dereference on zero-length checksum
    
    commit 6df164e29bd4e6505c5a2e0e5f1e1f6957a16a42 upstream.
    
    In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes
    checksum.data to be set to NULL. This triggers a NPD when accessing
    checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that
    the value of checksum.len is not less than XDR_UNIT.
    
    Fixes: 0653028e8f1c ("SUNRPC: Convert gss_verify_header() to use xdr_stream")
    Cc: [email protected]
    Signed-off-by: Lei Lu <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tcp: fix __tcp_close() to only send RST when required [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Sep 3 08:47:18 2025 +0000

    tcp: fix __tcp_close() to only send RST when required
    
    [ Upstream commit 5f9238530970f2993b23dd67fdaffc552a2d2e98 ]
    
    If the receive queue contains payload that was already
    received, __tcp_close() can send an unexpected RST.
    
    Refine the code to take tp->copied_seq into account,
    as we already do in tcp recvmsg().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Neal Cardwell <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Jason Xing <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tcp: use skb->len instead of skb->truesize in tcp_can_ingest() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Sat Sep 27 09:28:27 2025 +0000

    tcp: use skb->len instead of skb->truesize in tcp_can_ingest()
    
    [ Upstream commit f017c1f768b670bced4464476655b27dfb937e67 ]
    
    Some applications are stuck to the 20th century and still use
    small SO_RCVBUF values.
    
    After the blamed commit, we can drop packets especially
    when using LRO/hw-gro enabled NIC and small MSS (1500) values.
    
    LRO/hw-gro NIC pack multiple segments into pages, allowing
    tp->scaling_ratio to be set to a high value.
    
    Whenever the receive queue gets full, we can receive a small packet
    filling RWIN, but with a high skb->truesize, because most NIC use 4K page
    plus sk_buff metadata even when receiving less than 1500 bytes of payload.
    
    Even if we refine how tp->scaling_ratio is estimated,
    we could have an issue at the start of the flow, because
    the first round of packets (IW10) will be sent based on
    the initial tp->scaling_ratio (1/2)
    
    Relax tcp_can_ingest() to use skb->len instead of skb->truesize,
    allowing the peer to use final RWIN, assuming a 'perfect'
    scaling_ratio of 1.
    
    Fixes: 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp_metrics: use dst_dev_net_rcu() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 28 19:58:21 2025 +0000

    tcp_metrics: use dst_dev_net_rcu()
    
    [ Upstream commit 50c127a69cd6285300931853b352a1918cfa180f ]
    
    Replace three dst_dev() with a lockdep enabled helper.
    
    Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tee: fix register_shm_helper() [+ + +]
Author: Jens Wiklander <[email protected]>
Date:   Fri Sep 19 10:48:31 2025 +0200

    tee: fix register_shm_helper()
    
    commit d5cf5b37064b1699d946e8b7ab4ac7d7d101814c upstream.
    
    In register_shm_helper(), fix incorrect error handling for a call to
    iov_iter_extract_pages(). A case is missing for when
    iov_iter_extract_pages() only got some pages and return a number larger
    than 0, but not the requested amount.
    
    This fixes a possible NULL pointer dereference following a bad input from
    ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.
    
    Cc: [email protected]
    Reported-by: Masami Ichikawa <[email protected]>
    Closes: https://lore.kernel.org/op-tee/CACOXgS-Bo2W72Nj1_44c7bntyNYOavnTjJAvUbEiQfq=u9W+-g@mail.gmail.com/
    Tested-by: Masami Ichikawa <[email protected]>
    Fixes: 7bdee4157591 ("tee: Use iov_iter to better support shared buffer registration")
    Signed-off-by: Jens Wiklander <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
thermal/drivers/qcom/lmh: Add missing IRQ includes [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Mon Jul 28 15:18:24 2025 +0300

    thermal/drivers/qcom/lmh: Add missing IRQ includes
    
    [ Upstream commit b50b2c53f98fcdb6957e184eb488c16502db9575 ]
    
    As reported by LKP, the Qualcomm LMH driver needs to include several
    IRQ-related headers, which decrlare necessary IRQ functionality.
    Currently driver builds on ARM64 platforms, where the headers are pulled
    in implicitly by other headers, but fails to build on other platforms.
    
    Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal/drivers/qcom: Make LMH select QCOM_SCM [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Mon Jul 28 15:18:23 2025 +0300

    thermal/drivers/qcom: Make LMH select QCOM_SCM
    
    [ Upstream commit 57eda47bd14b0c2876f2db42e757c57b7a671965 ]
    
    The QCOM_SCM symbol is not user-visible, so it makes little sense to
    depend on it. Make LMH driver select QCOM_SCM as all other drivers do
    and, as the dependecy is now correctly handled, enable || COMPILE_TEST
    in order to include the driver into broader set of build tests.
    
    Fixes: 9e5a4fb84230 ("thermal/drivers/qcom/lmh: make QCOM_LMH depends on QCOM_SCM")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
thunderbolt: Fix use-after-free in tb_dp_dprx_work [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Tue Sep 23 13:13:57 2025 +0800

    thunderbolt: Fix use-after-free in tb_dp_dprx_work
    
    commit 67600ccfc4f38ebd331b9332ac94717bfbc87ea7 upstream.
    
    The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(),
    which does not ensure that the delayed work item tunnel->dprx_work has
    fully completed if it was already running. This leads to use-after-free
    scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while
    tunnel->dprx_work remains active and attempts to dereference tb_tunnel
    in tb_dp_dprx_work().
    
    A typical race condition is illustrated below:
    
    CPU 0                            | CPU 1
    tb_dp_tunnel_active()            |
      tb_deactivate_and_free_tunnel()| tb_dp_dprx_start()
        tb_tunnel_deactivate()       |   queue_delayed_work()
          tb_dp_activate()           |
            tb_dp_dprx_stop()        | tb_dp_dprx_work() //delayed worker
              cancel_delayed_work()  |
        tb_tunnel_put(tunnel);       |
                                     |   tunnel = container_of(...); //UAF
                                     |   tunnel-> //UAF
    
    Replacing cancel_delayed_work() with cancel_delayed_work_sync() is
    not feasible as it would introduce a deadlock: both tb_dp_dprx_work()
    and the cleanup path acquire tb->lock, and cancel_delayed_work_sync()
    would wait indefinitely for the work item that cannot proceed.
    
    Instead, implement proper reference counting:
    - If cancel_delayed_work() returns true (work is pending), we release
      the reference in the stop function.
    - If it returns false (work is executing or already completed), the
      reference is released in delayed work function itself.
    
    This ensures the tb_tunnel remains valid during work item execution
    while preventing memory leaks.
    
    This bug was found by static analysis.
    
    Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously")
    Cc: [email protected]
    Signed-off-by: Duoming Zhou <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tick: Do not set device to detached state in tick_shutdown() [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Sat Sep 6 14:49:51 2025 +0800

    tick: Do not set device to detached state in tick_shutdown()
    
    [ Upstream commit fe2a449a45b13df1562419e0104b4777b6ea5248 ]
    
    tick_shutdown() sets the state of the clockevent device to detached
    first and the invokes clockevents_exchange_device(), which in turn
    invokes clockevents_switch_state().
    
    But clockevents_switch_state() returns without invoking the device shutdown
    callback as the device is already in detached state. As a consequence the
    timer device is not shutdown when a CPU goes offline.
    
    tick_shutdown() does this because it was originally invoked on a online CPU
    and not on the outgoing CPU. It therefore could not access the clockevent
    device of the already offlined CPU and just set the state.
    
    Since commit 3b1596a21fbf tick_shutdown() is called on the outgoing CPU, so
    the hardware device can be accessed.
    
    Remove the state set before calling clockevents_exchange_device(), so that
    the subsequent clockevents_switch_state() handles the state transition and
    invokes the shutdown callback of the clockevent device.
    
    [ tglx: Massaged change log ]
    
    Fixes: 3b1596a21fbf ("clockevents: Shutdown and unregister current clockevents at CPUHP_AP_TICK_DYING")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Frederic Weisbecker <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Sep 16 21:47:23 2025 +0000

    tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().
    
    [ Upstream commit c65f27b9c3be2269918e1cbad6d8884741f835c5 ]
    
    get_netdev_for_sock() is called during setsockopt(),
    so not under RCU.
    
    Using sk_dst_get(sk)->dev could trigger UAF.
    
    Let's use __sk_dst_get() and dst_dev_rcu().
    
    Note that the only ->ndo_sk_get_lower_dev() user is
    bond_sk_get_lower_dev(), which uses RCU.
    
    Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tools/nolibc: add stdbool.h to nolibc includes [+ + +]
Author: André Almeida <[email protected]>
Date:   Thu Sep 25 11:14:23 2025 -0300

    tools/nolibc: add stdbool.h to nolibc includes
    
    [ Upstream commit 2d965c1ae4135ed6f505661458f6dabd39488dac ]
    
    Otherwise tests compiled with only "-include nolibc.h" will fail with
    "error: unknown type name 'bool'", even though a stdbool.h is available
    from nolibc.
    
    Fixes: ae1f550efc11 ("tools/nolibc: add stdbool.h header")
    Fixes: f2662ec26b26 ("selftests: kselftest: Create ksft_print_dbg_msg()")
    Reported-by: Mark Brown <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: André Almeida <[email protected]>
    [Thomas: add Fixes tags and massage commit message a bit]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tools/nolibc: avoid error in dup2() if old fd equals new fd [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Wed Aug 20 10:29:27 2025 +0200

    tools/nolibc: avoid error in dup2() if old fd equals new fd
    
    [ Upstream commit d1ff0e2d13d6ac3a15be7870e15216726b0a809a ]
    
    dup2() allows both 'old' and 'new' to have the same value, which dup3()
    does not. If libc dup2() is implemented through the dup3() system call,
    then it would incorrectly fail in this case.
    
    Avoid the error by handling old == new explicitly.
    
    Fixes: 30ca20517ac1 ("tools headers: Move the nolibc header from rcutorture to tools/include/nolibc/")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Acked-by: Willy Tarreau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tools/nolibc: fix error return value of clock_nanosleep() [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Thu Jul 31 10:00:31 2025 +0200

    tools/nolibc: fix error return value of clock_nanosleep()
    
    [ Upstream commit 1201f6fb5bfdbd10985ac3c8f49ef8f4f88b5c94 ]
    
    clock_nanosleep() returns a positive error value. Unlike other libc
    functions it *does not* return -1 nor set errno.
    
    Fix the return value and also adapt nanosleep().
    
    Fixes: 7c02bc4088af ("tools/nolibc: add support for clock_nanosleep() and nanosleep()")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Acked-by: Willy Tarreau <[email protected]>
    Link: https://lore.kernel.org/r/20250731-nolibc-clock_nanosleep-ret-v1-1-9e4af7855e61@linutronix.de
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tools/nolibc: make time_t robust if __kernel_old_time_t is missing in host headers [+ + +]
Author: Zhouyi Zhou <[email protected]>
Date:   Fri Sep 19 01:46:43 2025 +0000

    tools/nolibc: make time_t robust if __kernel_old_time_t is missing in host headers
    
    [ Upstream commit 0ff52df6b32a6b04a7c9dfe3d7a387aff215b482 ]
    
    Commit d5094bcb5bfd ("tools/nolibc: define time_t in terms of
    __kernel_old_time_t") made nolibc use the kernel's time type so that
    `time_t` matches `timespec::tv_sec` on all ABIs (notably x32).
    
    But since __kernel_old_time_t is fairly new, notably from 2020 in commit
    94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t"),
    nolibc builds that rely on host headers may fail.
    
    Switch to __kernel_time_t, which is the same as __kernel_old_time_t and
    has existed for longer.
    
    Tested in PPC VM of Open Source Lab of Oregon State University
    (./tools/testing/selftests/rcutorture/bin/mkinitrd.sh)
    
    Fixes: d5094bcb5bfd ("tools/nolibc: define time_t in terms of __kernel_old_time_t")
    Signed-off-by: Zhouyi Zhou <[email protected]>
    [Thomas: Reformat commit and its message a bit]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tools: ynl: fix undefined variable name [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Sep 9 23:07:47 2025 +0200

    tools: ynl: fix undefined variable name
    
    [ Upstream commit 7a3aaaa9fce710938c3557e5708ba5b00dd38226 ]
    
    This variable used in the error path was not defined according to Ruff.
    msg_format.attr_set is used instead, presumably the one that was
    supposed to be used originally.
    
    This is linked to Ruff error F821 [1]:
    
      An undefined name is likely to raise NameError at runtime.
    
    Fixes: 1769e2be4baa ("tools/net/ynl: Add 'sub-message' attribute decoding to ynl")
    Link: https://docs.astral.sh/ruff/rules/undefined-name/ [1]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Reviewed-by: Donald Hunter <[email protected]>
    Reviewed-by: Asbjørn Sloth Tønnesen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tpm: Disable TPM2_TCG_HMAC by default [+ + +]
Author: Jarkko Sakkinen <[email protected]>
Date:   Mon Aug 25 23:32:23 2025 +0300

    tpm: Disable TPM2_TCG_HMAC by default
    
    commit 4bddf4587c131d7b8ce8952cd32b284dcda0dd1f upstream.
    
    After reading all the feedback, right now disabling the TPM2_TCG_HMAC
    is the right call.
    
    Other views discussed:
    
    A. Having a kernel command-line parameter or refining the feature
       otherwise. This goes to the area of improvements.  E.g., one
       example is my own idea where the null key specific code would be
       replaced with a persistent handle parameter (which can be
       *unambigously* defined as part of attestation process when
       done correctly).
    
    B. Removing the code. I don't buy this because that is same as saying
       that HMAC encryption cannot work at all (if really nitpicking) in
       any form. Also I disagree on the view that the feature could not
       be refined to something more reasoable.
    
    Also, both A and B are worst options in terms of backporting.
    
    Thuss, this is the best possible choice.
    
    Cc: [email protected] # v6.10+
    Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation")
    Suggested-by: Chris Fenner <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tracing: Fix irqoff tracers on failure of acquiring calltime [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Wed Oct 8 11:49:43 2025 -0400

    tracing: Fix irqoff tracers on failure of acquiring calltime
    
    commit c834a97962c708ff5bb8582ca76b0e1225feb675 upstream.
    
    The functions irqsoff_graph_entry() and irqsoff_graph_return() both call
    func_prolog_dec() that will test if the data->disable is already set and
    if not, increment it and return. If it was set, it returns false and the
    caller exits.
    
    The caller of this function must decrement the disable counter, but misses
    doing so if the calltime fails to be acquired.
    
    Instead of exiting out when calltime is NULL, change the logic to do the
    work if it is not NULL and still do the clean up at the end of the
    function if it is NULL.
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: a485ea9e3ef3 ("tracing: Fix irqsoff and wakeup latency tracers when using function graph")
    Reported-by: Sasha Levin <[email protected]>
    Closes: https://lore.kernel.org/linux-trace-kernel/[email protected]/
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tracing: Fix lock imbalance in s_start() memory allocation failure path [+ + +]
Author: Sasha Levin <[email protected]>
Date:   Mon Sep 29 07:32:38 2025 -0400

    tracing: Fix lock imbalance in s_start() memory allocation failure path
    
    commit 61e19cd2e5c5235326a13a68df1a2f8ec4eeed7b upstream.
    
    When s_start() fails to allocate memory for set_event_iter, it returns NULL
    before acquiring event_mutex. However, the corresponding s_stop() function
    always tries to unlock the mutex, causing a lock imbalance warning:
    
      WARNING: bad unlock balance detected!
      6.17.0-rc7-00175-g2b2e0c04f78c #7 Not tainted
      -------------------------------------
      syz.0.85611/376514 is trying to release lock (event_mutex) at:
      [<ffffffff8dafc7a4>] traverse.part.0.constprop.0+0x2c4/0x650 fs/seq_file.c:131
      but there are no more locks to release!
    
    The issue was introduced by commit b355247df104 ("tracing: Cache ':mod:'
    events for modules not loaded yet") which added the kzalloc() allocation before
    the mutex lock, creating a path where s_start() could return without locking
    the mutex while s_stop() would still try to unlock it.
    
    Fix this by unconditionally acquiring the mutex immediately after allocation,
    regardless of whether the allocation succeeded.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/[email protected]
    Fixes: b355247df104 ("tracing: Cache ":mod:" events for modules not loaded yet")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tracing: Fix race condition in kprobe initialization causing NULL pointer dereference [+ + +]
Author: Yuan Chen <[email protected]>
Date:   Wed Oct 1 03:20:25 2025 +0100

    tracing: Fix race condition in kprobe initialization causing NULL pointer dereference
    
    commit 9cf9aa7b0acfde7545c1a1d912576e9bab28dc6f upstream.
    
    There is a critical race condition in kprobe initialization that can lead to
    NULL pointer dereference and kernel crash.
    
    [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000
    ...
    [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)
    [1135630.269239] pc : kprobe_perf_func+0x30/0x260
    [1135630.277643] lr : kprobe_dispatcher+0x44/0x60
    [1135630.286041] sp : ffffaeff4977fa40
    [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400
    [1135630.302837] x27: 0000000000000000 x26: 0000000000000000
    [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528
    [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50
    [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50
    [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000
    [1135630.349985] x17: 0000000000000000 x16: 0000000000000000
    [1135630.359285] x15: 0000000000000000 x14: 0000000000000000
    [1135630.368445] x13: 0000000000000000 x12: 0000000000000000
    [1135630.377473] x11: 0000000000000000 x10: 0000000000000000
    [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000
    [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000
    [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000
    [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006
    [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000
    [1135630.429410] Call trace:
    [1135630.434828]  kprobe_perf_func+0x30/0x260
    [1135630.441661]  kprobe_dispatcher+0x44/0x60
    [1135630.448396]  aggr_pre_handler+0x70/0xc8
    [1135630.454959]  kprobe_breakpoint_handler+0x140/0x1e0
    [1135630.462435]  brk_handler+0xbc/0xd8
    [1135630.468437]  do_debug_exception+0x84/0x138
    [1135630.475074]  el1_dbg+0x18/0x8c
    [1135630.480582]  security_file_permission+0x0/0xd0
    [1135630.487426]  vfs_write+0x70/0x1c0
    [1135630.493059]  ksys_write+0x5c/0xc8
    [1135630.498638]  __arm64_sys_write+0x24/0x30
    [1135630.504821]  el0_svc_common+0x78/0x130
    [1135630.510838]  el0_svc_handler+0x38/0x78
    [1135630.516834]  el0_svc+0x8/0x1b0
    
    kernel/trace/trace_kprobe.c: 1308
    0xffff3df8995039ec <kprobe_perf_func+0x2c>:     ldr     x21, [x24,#120]
    include/linux/compiler.h: 294
    0xffff3df8995039f0 <kprobe_perf_func+0x30>:     ldr     x1, [x21,x0]
    
    kernel/trace/trace_kprobe.c
    1308: head = this_cpu_ptr(call->perf_events);
    1309: if (hlist_empty(head))
    1310:   return 0;
    
    crash> struct trace_event_call -o
    struct trace_event_call {
      ...
      [120] struct hlist_head *perf_events;  //(call->perf_event)
      ...
    }
    
    crash> struct trace_event_call ffffaf015340e528
    struct trace_event_call {
      ...
      perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0
      ...
    }
    
    Race Condition Analysis:
    
    The race occurs between kprobe activation and perf_events initialization:
    
      CPU0                                    CPU1
      ====                                    ====
      perf_kprobe_init
        perf_trace_event_init
          tp_event->perf_events = list;(1)
          tp_event->class->reg (2)← KPROBE ACTIVE
                                              Debug exception triggers
                                              ...
                                              kprobe_dispatcher
                                                kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE)
                                                  head = this_cpu_ptr(call->perf_events)(3)
                                                  (perf_events is still NULL)
    
    Problem:
    1. CPU0 executes (1) assigning tp_event->perf_events = list
    2. CPU0 executes (2) enabling kprobe functionality via class->reg()
    3. CPU1 triggers and reaches kprobe_dispatcher
    4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)
    5. CPU1 calls kprobe_perf_func() and crashes at (3) because
       call->perf_events is still NULL
    
    CPU1 sees that kprobe functionality is enabled but does not see that
    perf_events has been assigned.
    
    Add pairing read and write memory barriers to guarantee that if CPU1
    sees that kprobe functionality is enabled, it must also see that
    perf_events has been assigned.
    
    Link: https://lore.kernel.org/all/[email protected]/
    
    Fixes: 50d780560785 ("tracing/kprobes: Add probe handler dispatcher to support perf and ftrace concurrent use")
    Cc: [email protected]
    Signed-off-by: Yuan Chen <[email protected]>
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tracing: Fix tracing_mark_raw_write() to use buf and not ubuf [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Fri Oct 10 23:51:42 2025 -0400

    tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
    
    commit bda745ee8fbb63330d8f2f2ea4157229a5df959e upstream.
    
    The fix to use a per CPU buffer to read user space tested only the writes
    to trace_marker. But it appears that the selftests are missing tests to
    the trace_maker_raw file. The trace_maker_raw file is used by applications
    that writes data structures and not strings into the file, and the tools
    read the raw ring buffer to process the structures it writes.
    
    The fix that reads the per CPU buffers passes the new per CPU buffer to
    the trace_marker file writes, but the update to the trace_marker_raw write
    read the data from user space into the per CPU buffer, but then still used
    then passed the user space address to the function that records the data.
    
    Pass in the per CPU buffer and not the user space address.
    
    TODO: Add a test to better test trace_marker_raw.
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tracing: Fix wakeup tracers on failure of acquiring calltime [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Wed Oct 8 11:48:35 2025 -0400

    tracing: Fix wakeup tracers on failure of acquiring calltime
    
    commit 4f7bf54b07e5acf79edd58dafede4096854776cd upstream.
    
    The functions wakeup_graph_entry() and wakeup_graph_return() both call
    func_prolog_preempt_disable() that will test if the data->disable is
    already set and if not, increment it and disable preemption. If it was
    set, it returns false and the caller exits.
    
    The caller of this function must decrement the disable counter, but misses
    doing so if the calltime fails to be acquired.
    
    Instead of exiting out when calltime is NULL, change the logic to do the
    work if it is not NULL and still do the clean up at the end of the
    function if it is NULL.
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: a485ea9e3ef3 ("tracing: Fix irqsoff and wakeup latency tracers when using function graph")
    Reported-by: Sasha Levin <[email protected]>
    Closes: https://lore.kernel.org/linux-trace-kernel/[email protected]/
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tracing: Have trace_marker use per-cpu data to read user space [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Wed Oct 8 12:45:10 2025 -0400

    tracing: Have trace_marker use per-cpu data to read user space
    
    commit 64cf7d058a005c5c31eb8a0b741f35dc12915d18 upstream.
    
    It was reported that using __copy_from_user_inatomic() can actually
    schedule. Which is bad when preemption is disabled. Even though there's
    logic to check in_atomic() is set, but this is a nop when the kernel is
    configured with PREEMPT_NONE. This is due to page faulting and the code
    could schedule with preemption disabled.
    
    Link: https://lore.kernel.org/all/[email protected]/
    
    The solution was to change the __copy_from_user_inatomic() to
    copy_from_user_nofault(). But then it was reported that this caused a
    regression in Android. There's several applications writing into
    trace_marker() in Android, but now instead of showing the expected data,
    it is showing:
    
      tracing_mark_write: <faulted>
    
    After reverting the conversion to copy_from_user_nofault(), Android was
    able to get the data again.
    
    Writes to the trace_marker is a way to efficiently and quickly enter data
    into the Linux tracing buffer. It takes no locks and was designed to be as
    non-intrusive as possible. This means it cannot allocate memory, and must
    use pre-allocated data.
    
    A method that is actively being worked on to have faultable system call
    tracepoints read user space data is to allocate per CPU buffers, and use
    them in the callback. The method uses a technique similar to seqcount.
    That is something like this:
    
            preempt_disable();
            cpu = smp_processor_id();
            buffer = this_cpu_ptr(&pre_allocated_cpu_buffers, cpu);
            do {
                    cnt = nr_context_switches_cpu(cpu);
                    migrate_disable();
                    preempt_enable();
                    ret = copy_from_user(buffer, ptr, size);
                    preempt_disable();
                    migrate_enable();
            } while (!ret && cnt != nr_context_switches_cpu(cpu));
    
            if (!ret)
                    ring_buffer_write(buffer);
            preempt_enable();
    
    It's a little more involved than that, but the above is the basic logic.
    The idea is to acquire the current CPU buffer, disable migration, and then
    enable preemption. At this moment, it can safely use copy_from_user().
    After reading the data from user space, it disables preemption again. It
    then checks to see if there was any new scheduling on this CPU. If there
    was, it must assume that the buffer was corrupted by another task. If
    there wasn't, then the buffer is still valid as only tasks in preemptable
    context can write to this buffer and only those that are running on the
    CPU.
    
    By using this method, where trace_marker open allocates the per CPU
    buffers, trace_marker writes can access user space and even fault it in,
    without having to allocate or take any locks of its own.
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Cc: Luo Gengkun <[email protected]>
    Cc: Wattson CI <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: 3d62ab32df065 ("tracing: Fix tracing_marker may trigger page fault during preempt_disable")
    Reported-by: Runping Lai <[email protected]>
    Tested-by: Runping Lai <[email protected]>
    Closes: https://lore.kernel.org/linux-trace-kernel/[email protected]/
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tracing: Stop fortify-string from warning in tracing_mark_raw_write() [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Sat Oct 11 11:20:32 2025 -0400

    tracing: Stop fortify-string from warning in tracing_mark_raw_write()
    
    commit 54b91e54b113d4f15ab023a44f508251db6e22e7 upstream.
    
    The way tracing_mark_raw_write() records its data is that it has the
    following structure:
    
      struct {
            struct trace_entry;
            int id;
            char buf[];
      };
    
    But memcpy(&entry->id, buf, size) triggers the following warning when the
    size is greater than the id:
    
     ------------[ cut here ]------------
     memcpy: detected field-spanning write (size 6) of single field "&entry->id" at kernel/trace/trace.c:7458 (size 4)
     WARNING: CPU: 7 PID: 995 at kernel/trace/trace.c:7458 write_raw_marker_to_buffer.isra.0+0x1f9/0x2e0
     Modules linked in:
     CPU: 7 UID: 0 PID: 995 Comm: bash Not tainted 6.17.0-test-00007-g60b82183e78a-dirty #211 PREEMPT(voluntary)
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
     RIP: 0010:write_raw_marker_to_buffer.isra.0+0x1f9/0x2e0
     Code: 04 00 75 a7 b9 04 00 00 00 48 89 de 48 89 04 24 48 c7 c2 e0 b1 d1 b2 48 c7 c7 40 b2 d1 b2 c6 05 2d 88 6a 04 01 e8 f7 e8 bd ff <0f> 0b 48 8b 04 24 e9 76 ff ff ff 49 8d 7c 24 04 49 8d 5c 24 08 48
     RSP: 0018:ffff888104c3fc78 EFLAGS: 00010292
     RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: 1ffffffff6b363b4 RDI: 0000000000000001
     RBP: ffff888100058a00 R08: ffffffffb041d459 R09: ffffed1020987f40
     R10: 0000000000000007 R11: 0000000000000001 R12: ffff888100bb9010
     R13: 0000000000000000 R14: 00000000000003e3 R15: ffff888134800000
     FS:  00007fa61d286740(0000) GS:ffff888286cad000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000560d28d509f1 CR3: 00000001047a4006 CR4: 0000000000172ef0
     Call Trace:
      <TASK>
      tracing_mark_raw_write+0x1fe/0x290
      ? __pfx_tracing_mark_raw_write+0x10/0x10
      ? security_file_permission+0x50/0xf0
      ? rw_verify_area+0x6f/0x4b0
      vfs_write+0x1d8/0xdd0
      ? __pfx_vfs_write+0x10/0x10
      ? __pfx_css_rstat_updated+0x10/0x10
      ? count_memcg_events+0xd9/0x410
      ? fdget_pos+0x53/0x5e0
      ksys_write+0x182/0x200
      ? __pfx_ksys_write+0x10/0x10
      ? do_user_addr_fault+0x4af/0xa30
      do_syscall_64+0x63/0x350
      entry_SYSCALL_64_after_hwframe+0x76/0x7e
     RIP: 0033:0x7fa61d318687
     Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
     RSP: 002b:00007ffd87fe0120 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
     RAX: ffffffffffffffda RBX: 00007fa61d286740 RCX: 00007fa61d318687
     RDX: 0000000000000006 RSI: 0000560d28d509f0 RDI: 0000000000000001
     RBP: 0000560d28d509f0 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000006
     R13: 00007fa61d4715c0 R14: 00007fa61d46ee80 R15: 0000000000000000
      </TASK>
     ---[ end trace 0000000000000000 ]---
    
    This is because fortify string sees that the size of entry->id is only 4
    bytes, but it is writing more than that. But this is OK as the
    dynamic_array is allocated to handle that copy.
    
    The size allocated on the ring buffer was actually a bit too big:
    
      size = sizeof(*entry) + cnt;
    
    But cnt includes the 'id' and the buffer data, so adding cnt to the size
    of *entry actually allocates too much on the ring buffer.
    
    Change the allocation to:
    
      size = struct_size(entry, buf, cnt - sizeof(entry->id));
    
    and the memcpy() to unsafe_memcpy() with an added justification.
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Fixes: 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tty: n_gsm: Don't block input queue by waiting MSC [+ + +]
Author: Seppo Takalo <[email protected]>
Date:   Wed Aug 27 15:26:56 2025 +0300

    tty: n_gsm: Don't block input queue by waiting MSC
    
    [ Upstream commit 3cf0b3c243e56bc43be560617416c1d9f301f44c ]
    
    Currently gsm_queue() processes incoming frames and when opening
    a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
    If basic mode is used it calls gsm_modem_upd_via_msc() and it
    cannot block the input queue by waiting the response to come
    into the same input queue.
    
    Instead allow sending Modem Status Command without waiting for remote
    end to respond. Define a new function gsm_modem_send_initial_msc()
    for this purpose. As MSC is only valid for basic encoding, it does
    not do anything for advanced or when convergence layer type 2 is used.
    
    Fixes: 48473802506d ("tty: n_gsm: fix missing update of modem controls after DLCI open")
    Signed-off-by: Seppo Takalo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
uio_hv_generic: Let userspace take care of interrupt mask [+ + +]
Author: Naman Jain <[email protected]>
Date:   Thu Aug 28 10:12:00 2025 +0530

    uio_hv_generic: Let userspace take care of interrupt mask
    
    commit b15b7d2a1b09ef5428a8db260251897405a19496 upstream.
    
    Remove the logic to set interrupt mask by default in uio_hv_generic
    driver as the interrupt mask value is supposed to be controlled
    completely by the user space. If the mask bit gets changed
    by the driver, concurrently with user mode operating on the ring,
    the mask bit may be set when it is supposed to be clear, and the
    user-mode driver will miss an interrupt which will cause a hang.
    
    For eg- when the driver sets inbound ring buffer interrupt mask to 1,
    the host does not interrupt the guest on the UIO VMBus channel.
    However, setting the mask does not prevent the host from putting a
    message in the inbound ring buffer. So let’s assume that happens,
    the host puts a message into the ring buffer but does not interrupt.
    
    Subsequently, the user space code in the guest sets the inbound ring
    buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.
    User space code then calls pread() to wait for an interrupt.
    Then one of two things happens:
    
    * The host never sends another message. So the pread() waits forever.
    * The host does send another message. But because there’s already a
      message in the ring buffer, it doesn’t generate an interrupt.
      This is the correct behavior, because the host should only send an
      interrupt when the inbound ring buffer transitions from empty to
      not-empty. Adding an additional message to a ring buffer that is not
      empty is not supposed to generate an interrupt on the guest.
      Since the guest is waiting in pread() and not removing messages from
      the ring buffer, the pread() waits forever.
    
    This could be easily reproduced in hv_fcopy_uio_daemon if we delay
    setting interrupt mask to 0.
    
    Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
    there’s a race condition. Once user space empties the inbound ring
    buffer, but before user space sets interrupt_mask to 0, the host could
    put another message in the ring buffer but it wouldn’t interrupt.
    Then the next pread() would hang.
    
    Fix these by removing all instances where interrupt_mask is changed,
    while keeping the one in set_event() unchanged to enable userspace
    control the interrupt mask by writing 0/1 to /dev/uioX.
    
    Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
    Suggested-by: John Starks <[email protected]>
    Signed-off-by: Naman Jain <[email protected]>
    Cc: [email protected]
    Reviewed-by: Michael Kelley <[email protected]>
    Reviewed-by: Long Li <[email protected]>
    Reviewed-by: Tianyu Lan <[email protected]>
    Tested-by: Tianyu Lan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
uprobes: uprobe_warn should use passed task [+ + +]
Author: Jeremy Linton <[email protected]>
Date:   Sun Aug 24 22:34:21 2025 -0500

    uprobes: uprobe_warn should use passed task
    
    [ Upstream commit ba1afc94deb849eab843a372b969444581add2c9 ]
    
    uprobe_warn() is passed a task structure, yet its using current. For
    the most part this shouldn't matter, but since a task structure is
    provided, lets use it.
    
    Fixes: 248d3a7b2f10 ("uprobes: Change uprobe_copy_process() to dup return_instances")
    Signed-off-by: Jeremy Linton <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Acked-by: Oleg Nesterov <[email protected]>
    Acked-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: cdns3: cdnsp-pci: remove redundant pci_disable_device() call [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Wed Sep 3 22:16:13 2025 +0800

    usb: cdns3: cdnsp-pci: remove redundant pci_disable_device() call
    
    commit e9c206324eeb213957a567a9d066bdeb355c7491 upstream.
    
    The cdnsp-pci driver uses pcim_enable_device() to enable a PCI device,
    which means the device will be automatically disabled on driver detach
    through the managed device framework. The manual pci_disable_device()
    call in the error path is therefore redundant.
    
    Found via static anlaysis and this is similar to commit 99ca0b57e49f
    ("thermal: intel: int340x: processor: Fix warning during module unload").
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Cc: [email protected]
    Signed-off-by: Miaoqian Lin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: configfs: Correctly set use_os_string at bind [+ + +]
Author: William Wu <[email protected]>
Date:   Fri Aug 22 11:36:09 2025 +0800

    usb: gadget: configfs: Correctly set use_os_string at bind
    
    [ Upstream commit e271cc0d25015f4be6c88bd7731444644eb352c2 ]
    
    Once the use_os_string flag is set to true for some functions
    (e.g. adb/mtp) which need to response the OS string, and then
    if we re-bind the ConfigFS gadget to use the other functions
    (e.g. hid) which should not to response the OS string, however,
    because the use_os_string flag is still true, so the usb gadget
    response the OS string descriptor incorrectly, this can cause
    the USB device to be unrecognizable on the Windows system.
    
    An example of this as follows:
    
    echo 1 > os_desc/use
    ln -s functions/ffs.adb configs/b.1/function0
    start adbd
    echo "<udc device>" > UDC   #succeed
    
    stop adbd
    rm configs/b.1/function0
    echo 0 > os_desc/use
    ln -s functions/hid.gs0 configs/b.1/function0
    echo "<udc device>" > UDC  #fail to connect on Windows
    
    This patch sets the use_os_string flag to false at bind if
    the functions not support OS Descriptors.
    
    Signed-off-by: William Wu <[email protected]>
    Fixes: 87213d388e92 ("usb: gadget: configfs: OS String support")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Thu Aug 7 18:55:00 2025 +0300

    usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup
    
    [ Upstream commit 186e8f2bdba551f3ae23396caccd452d985c23e3 ]
    
    The kthread_run() function returns error pointers so the
    max3421_hcd->spi_thread pointer can be either error pointers or NULL.
    Check for both before dereferencing it.
    
    Fixes: 05dfa5c9bc37 ("usb: host: max3421-hcd: fix "spi_rd8" uses dynamic stack allocation warning")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls [+ + +]
Author: Komal Bajaj <[email protected]>
Date:   Thu Jul 31 14:31:32 2025 +0530

    usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls
    
    [ Upstream commit c0485e864a2eaa1d5a84c71e573dd236d0e885ae ]
    
    EUD_MODE_MANAGER2 register is mapped to a memory region that is marked
    as read-only for operating system running at EL1, enforcing access
    restrictions that prohibit direct memory-mapped writes via writel().
    
    Attempts to write to this region from HLOS can result in silent failures
    or memory access violations, particularly when toggling EUD (Embedded
    USB Debugger) state. To ensure secure register access, modify the driver
    to use qcom_scm_io_writel(), which routes the write operation to Qualcomm
    Secure Channel Monitor (SCM). SCM has the necessary permissions to access
    protected memory regions, enabling reliable control over EUD state.
    
    SC7280, the only user of EUD is also affected, indicating that this could
    never have worked on a properly fused device.
    
    Fixes: 9a1bf58ccd44 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)")
    Signed-off-by: Melody Olvera <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Souradeep Chowdhury <[email protected]>
    Signed-off-by: Komal Bajaj <[email protected]>
    Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: phy: twl6030: Fix incorrect type for ret [+ + +]
Author: Xichao Zhao <[email protected]>
Date:   Fri Aug 22 17:22:24 2025 +0800

    usb: phy: twl6030: Fix incorrect type for ret
    
    [ Upstream commit b570b346ddd727c4b41743a6a2f49e7217c5317f ]
    
    In the twl6030_usb_probe(), the variable ret is declared as
    a u32 type. However, since ret may receive -ENODEV when accepting
    the return value of omap_usb2_set_comparator().Therefore, its type
    should be changed to int.
    
    Fixes: 0e98de67bacba ("usb: otg: make twl6030_usb as a comparator driver to omap_usb2")
    Signed-off-by: Xichao Zhao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: typec: tipd: Clear interrupts first [+ + +]
Author: Sven Peter <[email protected]>
Date:   Sun Sep 14 12:56:06 2025 +0000

    usb: typec: tipd: Clear interrupts first
    
    commit be5ae730ffa6fd774a00a4705c1e11e078b08ca1 upstream.
    
    Right now the interrupt handler first reads all updated status registers
    and only then clears the interrupts. It's possible that a duplicate
    interrupt for a changed register or plug state comes in after the
    interrupts have been processed but before they have been cleared:
    
    * plug is inserted, TPS_REG_INT_PLUG_EVENT is set
    * TPS_REG_INT_EVENT1 is read
    * tps6598x_handle_plug_event() has run and registered the plug
    * plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again)
    * TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared
    
    We then have no plug connected and no pending interrupt but the tipd
    core still thinks there is a plug. It's possible to trigger this with
    e.g. a slightly broken Type-C to USB A converter.
    
    Fix this by first clearing the interrupts and only then reading the
    updated registers.
    
    Fixes: 45188f27b3d0 ("usb: typec: tipd: Add support for Apple CD321X")
    Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
    Cc: [email protected]
    Reviewed-by: Heikki Krogerus <[email protected]>
    Reviewed-by: Neal Gompa <[email protected]>
    Signed-off-by: Sven Peter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: vhci-hcd: Prevent suspending virtually attached devices [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Tue Sep 2 15:15:46 2025 +0300

    usb: vhci-hcd: Prevent suspending virtually attached devices
    
    [ Upstream commit e40b984b6c4ce3f80814f39f86f87b2a48f2e662 ]
    
    The VHCI platform driver aims to forbid entering system suspend when at
    least one of the virtual USB ports are bound to an active USB/IP
    connection.
    
    However, in some cases, the detection logic doesn't work reliably, i.e.
    when all devices attached to the virtual root hub have been already
    suspended, leading to a broken suspend state, with unrecoverable resume.
    
    Ensure the virtually attached devices do not enter suspend by setting
    the syscore PM flag.  Note this is currently limited to the client side
    only, since the server side doesn't implement system suspend prevention.
    
    Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver")
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Acked-by: Shuah Khan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vdso/datastore: Gate time data behind CONFIG_GENERIC_GETTIMEOFDAY [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Tue Aug 26 08:17:04 2025 +0200

    vdso/datastore: Gate time data behind CONFIG_GENERIC_GETTIMEOFDAY
    
    [ Upstream commit 7c0c01a216e6d9e1d169c0f6f3b5522e6da708ed ]
    
    When the generic vDSO does not provide time functions, as for example on
    riscv32, then the time data store is not necessary.
    
    Avoid allocating these time data pages when not used.
    
    Fixes: df7fcbefa710 ("vdso: Add generic time data storage")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
vdso: Add struct __kernel_old_timeval forward declaration to gettime.h [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Fri Aug 15 12:41:10 2025 +0200

    vdso: Add struct __kernel_old_timeval forward declaration to gettime.h
    
    [ Upstream commit 437054b1bbe11be87ab0a522b8ccbae3f785c642 ]
    
    The prototype of __vdso_gettimeofday() uses this struct.  However
    gettime.h's own includes do not provide a definition for it.
    
    Add a forward declaration, similar to other used structs.
    
    Fixes: 42874e4eb35b ("arch: vdso: consolidate gettime prototypes")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
vfio/pds: replace bitmap_free with vfree [+ + +]
Author: Zilin Guan <[email protected]>
Date:   Sat Sep 13 15:31:54 2025 +0000

    vfio/pds: replace bitmap_free with vfree
    
    [ Upstream commit acb59a4bb8ed34e738a4c3463127bf3f6b5e11a9 ]
    
    host_seq_bmp is allocated with vzalloc but is currently freed with
    bitmap_free, which uses kfree internally. This mismach prevents the
    resource from being released properly and may result in memory leaks
    or other issues.
    
    Fix this by freeing host_seq_bmp with vfree to match the vzalloc
    allocation.
    
    Fixes: f232836a9152 ("vfio/pds: Add support for dirty page tracking")
    Signed-off-by: Zilin Guan <[email protected]>
    Reviewed-by: Brett Creeley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vhost: vringh: Fix copy_to_iter return value check [+ + +]
Author: Michael S. Tsirkin <[email protected]>
Date:   Thu Sep 25 02:04:08 2025 -0400

    vhost: vringh: Fix copy_to_iter return value check
    
    [ Upstream commit 439263376c2c4e126cac0d07e4987568de4eaba5 ]
    
    The return value of copy_to_iter can't be negative, check whether the
    copied length is equal to the requested length instead of checking for
    negative values.
    
    Cc: zhang jiao <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Fixes: 309bba39c945 ("vringh: iterate on iotlb_translate to handle large translations")
    Link: https://patch.msgid.link/cd637504a6e3967954a9e80fc1b75e8c0978087b.1758723310.git.mst@redhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

vhost: vringh: Modify the return value check [+ + +]
Author: zhang jiao <[email protected]>
Date:   Wed Sep 10 17:17:38 2025 +0800

    vhost: vringh: Modify the return value check
    
    [ Upstream commit 82a8d0fda55b35361ee7f35b54fa2b66d7847d2b ]
    
    The return value of copy_from_iter and copy_to_iter can't be negative,
    check whether the copied lengths are equal.
    
    Fixes: 309bba39c945 ("vringh: iterate on iotlb_translate to handle large translations")
    Cc: "Stefano Garzarella" <[email protected]>
    Signed-off-by: zhang jiao <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
watchdog: intel_oc_wdt: Do not try to write into const memory [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Sun Aug 17 07:48:17 2025 -0700

    watchdog: intel_oc_wdt: Do not try to write into const memory
    
    [ Upstream commit bdbb4a2d2aeae3d115bbdc402adac72aec071492 ]
    
    The code tries to update the intel_oc_wdt_info data structure if the
    watchdog is locked. That data structure is marked as const and can not
    be written into. Copy it into struct intel_oc_wdt and modify it there
    to fix the problem.
    
    Reported-by: Petar Kulić <[email protected]>
    Cc: Diogo Ivo <[email protected]>
    Fixes: 535d1784d8a9 ("watchdog: Add driver for Intel OC WDT")
    Signed-off-by: Guenter Roeck <[email protected]>
    Reviewed-by: Diogo Ivo <[email protected]>
    Tested-by: Diogo Ivo <[email protected]>
    Link: https://lore.kernel.org/linux-watchdog/[email protected]/T/#t
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling the watchdog [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Tue Aug 12 14:51:26 2025 +0200

    watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling the watchdog
    
    [ Upstream commit 7dfd80f70ef00d871df5af7c391133f7ba61ad9b ]
    
    When the watchdog gets enabled with this driver, it leaves enough time
    for the core watchdog subsystem to start pinging it. But when the
    watchdog is already started by hardware or by the boot loader, little
    time remains before it fires and it happens that the core watchdog
    subsystem doesn't have time to start pinging it.
    
    Until commit 19ce9490aa84 ("watchdog: mpc8xxx: use the core worker
    function") pinging was managed by the driver itself and the watchdog
    was immediately pinged by setting the timer expiry to 0.
    
    So restore similar behaviour by pinging it when enabling it so that
    if it was already enabled the watchdog timer counter is reloaded.
    
    Fixes: 19ce9490aa84 ("watchdog: mpc8xxx: use the core worker function")
    Signed-off-by: Christophe Leroy <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: ath10k: avoid unnecessary wait for service ready message [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Mon Aug 11 17:26:45 2025 +0800

    wifi: ath10k: avoid unnecessary wait for service ready message
    
    [ Upstream commit 51a73f1b2e56b0324b4a3bb8cebc4221b5be4c7a ]
    
    Commit e57b7d62a1b2 ("wifi: ath10k: poll service ready message before
    failing") works around the failure in waiting for the service ready
    message by active polling. Note the polling is triggered after initial
    wait timeout, which means that the wait-till-timeout can not be avoided
    even the message is ready.
    
    A possible fix is to do polling once before wait as well, however this
    can not handle the race that the message arrives right after polling.
    So the solution is to do periodic polling until timeout.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1
    
    Fixes: e57b7d62a1b2 ("wifi: ath10k: poll service ready message before failing")
    Reported-by: Paul Menzel <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/20250811-ath10k-avoid-unnecessary-wait-v1-1-db2deb87c39b@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: Add fallback for invalid channel number in PHY metadata [+ + +]
Author: Sriram R <[email protected]>
Date:   Thu Jul 24 00:36:51 2025 +0530

    wifi: ath12k: Add fallback for invalid channel number in PHY metadata
    
    [ Upstream commit 26f8fc0b24fd1a9dba1000bc9b5f2b199b7775a0 ]
    
    Currently, ath12k_dp_rx_h_ppdu() determines the band and frequency
    based on the channel number and center frequency from the RX descriptor's
    PHY metadata. However, in rare cases, it is observed that frequency
    retrieved from the metadata may be invalid or unexpected especially for
    6 GHz frames.
    This can result in a NULL sband, which prevents proper frequency assignment
    in rx_status and potentially leading to incorrect RX packet classification.
    
    To fix this potential issue, add a fallback mechanism that uses
    ar->rx_channel to populate the band and frequency when the derived
    sband is invalid or missing.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Sriram R <[email protected]>
    Co-developed-by: Vinith Kumar R <[email protected]>
    Signed-off-by: Vinith Kumar R <[email protected]>
    Signed-off-by: Aishwarya R <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: Fix flush cache failure during RX queue update [+ + +]
Author: Nithyanantham Paramasivam <[email protected]>
Date:   Wed Aug 6 16:47:49 2025 +0530

    wifi: ath12k: Fix flush cache failure during RX queue update
    
    [ Upstream commit 5e32edc6942570429d9c64d0641fc2addbf92be1 ]
    
    Flush cache failures were observed after RX queue update for TID
    delete. This occurred because the queue was invalid during flush.
    Set the VLD bit in the RX queue update command for TID delete.
    This ensures the queue remains valid during the flush cache process.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Nithyanantham Paramasivam <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/20250806111750.3214584-7-nithyanantham.paramasivam@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix HAL_PHYRX_COMMON_USER_INFO handling in monitor mode [+ + +]
Author: Kang Yang <[email protected]>
Date:   Tue Jul 22 17:59:33 2025 +0800

    wifi: ath12k: fix HAL_PHYRX_COMMON_USER_INFO handling in monitor mode
    
    [ Upstream commit 6b46e85129185ec076f9c3bd2813dfd2f968522b ]
    
    Current monitor mode will parse TLV HAL_PHYRX_OTHER_RECEIVE_INFO with
    struct hal_phyrx_common_user_info.
    
    Obviously, they do not match. The original intention here was to parse
    HAL_PHYRX_COMMON_USER_INFO. So fix it by correctly parsing
    HAL_PHYRX_COMMON_USER_INFO instead.
    
    Also add LTF parsing and report to radiotap along with GI.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
    
    Fixes: d939919a36f4 ("wifi: ath12k: Add HAL_PHYRX_OTHER_RECEIVE_INFO TLV parsing support")
    Signed-off-by: Kang Yang <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix overflow warning on num_pwr_levels [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Mon Aug 4 11:03:11 2025 +0800

    wifi: ath12k: fix overflow warning on num_pwr_levels
    
    [ Upstream commit ea2b0af4c9e3f7187b5be4b7fc1511ea239046c0 ]
    
    In ath12k_mac_parse_tx_pwr_env(), for the non-PSD case num_pwr_levels is
    limited by ATH12K_NUM_PWR_LEVELS which is 16:
    
            if (tpc_info->num_pwr_levels > ATH12K_NUM_PWR_LEVELS)
                    tpc_info->num_pwr_levels = ATH12K_NUM_PWR_LEVELS;
    
    Then it is used to iterate entries in local_non_psd->power[] and
    reg_non_psd->power[]:
    
            for (i = 0; i < tpc_info->num_pwr_levels; i++) {
                    tpc_info->tpe[i] = min(local_non_psd->power[i],
                                           reg_non_psd->power[i]) / 2;
    
    Since the two array are of size 5, Smatch warns:
    
    drivers/net/wireless/ath/ath12k/mac.c:9812
    ath12k_mac_parse_tx_pwr_env() error: buffer overflow 'local_non_psd->power' 5 <= 15
    drivers/net/wireless/ath/ath12k/mac.c:9812
    ath12k_mac_parse_tx_pwr_env() error: buffer overflow 'reg_non_psd->power' 5 <= 15
    
    This is a false positive as there is already implicit limitation:
    
            tpc_info->num_pwr_levels = max(local_non_psd->count,
                                           reg_non_psd->count);
    
    meaning it won't exceed 5.
    
    However, to make robot happy, add explicit limit there.
    
    Also add the same to the PSD case, although no warning due to
    ATH12K_NUM_PWR_LEVELS equals IEEE80211_TPE_PSD_ENTRIES_320MHZ.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
    
    Fixes: cccbb9d0dd6a ("wifi: ath12k: add parse of transmit power envelope element")
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/20250804-ath12k-fix-smatch-warning-on-6g-vlp-v1-2-56f1e54152ab@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: Fix peer lookup in ath12k_dp_mon_rx_deliver_msdu() [+ + +]
Author: Hari Chandrakanthan <[email protected]>
Date:   Thu Jul 24 09:35:52 2025 +0530

    wifi: ath12k: Fix peer lookup in ath12k_dp_mon_rx_deliver_msdu()
    
    [ Upstream commit 7ca61ed8b3f3fc9a7decd68039cb1d7d1238c566 ]
    
    In ath12k_dp_mon_rx_deliver_msdu(), peer lookup fails because
    rxcb->peer_id is not updated with a valid value. This is expected
    in monitor mode, where RX frames bypass the regular RX
    descriptor path that typically sets rxcb->peer_id.
    As a result, the peer is NULL, and link_id and link_valid fields
    in the RX status are not populated. This leads to a WARN_ON in
    mac80211 when it receives data frame from an associated station
    with invalid link_id.
    
    Fix this potential issue by using ppduinfo->peer_id, which holds
    the correct peer id for the received frame. This ensures that the
    peer is correctly found and the associated link metadata is updated
    accordingly.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
    
    Fixes: bd00cc7e8a4c ("wifi: ath12k: replace the usage of rx desc with rx_info")
    Signed-off-by: Hari Chandrakanthan <[email protected]>
    Signed-off-by: Aishwarya R <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix signal in radiotap for WCN7850 [+ + +]
Author: Kang Yang <[email protected]>
Date:   Tue Jul 22 17:59:32 2025 +0800

    wifi: ath12k: fix signal in radiotap for WCN7850
    
    [ Upstream commit cf412ae7b7124e2b3bfe472616ec24b117b6008a ]
    
    Currently host will add ATH12K_DEFAULT_NOISE_FLOOR to rssi_comb to
    convert RSSI from dB to dBm.
    
    For WCN7850, this conversion is unnecessary because the RSSI value is
    already reported in dBm units.
    
    No longer convert for those firmware that already support dBM conversion.
    
    This patch won't affect QCN chips.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Kang Yang <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix the fetching of combined rssi [+ + +]
Author: Kang Yang <[email protected]>
Date:   Tue Jul 22 17:59:34 2025 +0800

    wifi: ath12k: fix the fetching of combined rssi
    
    [ Upstream commit 7695fa71c1d50a375e54426421acbc8d457bc5a3 ]
    
    Currently, host fetches combined rssi from rssi_comb in struct
    hal_rx_phyrx_rssi_legacy_info.
    
    rssi_comb is 8th to 15th bits of the second to last variable.
    rssi_comb_ppdu is the 0th to 7th of the last variable.
    
    When bandwidth = 20MHz, rssi_comb = rssi_comb_ppdu. But when bandwidth >
    20MHz, rssi_comb < rssi_comb_ppdu because rssi_comb only includes power
    of primary 20 MHz while rssi_comb_ppdu includes power of active
    RUs/subchannels. So should fetch combined rssi from rssi_comb_ppdu.
    
    Also related macro definitions are too long, rename them.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Kang Yang <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix wrong logging ID used for CE [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Fri Aug 15 09:44:57 2025 +0800

    wifi: ath12k: fix wrong logging ID used for CE
    
    [ Upstream commit 43746f13fec67f6f223d64cfe96c095c9b468e70 ]
    
    ATH12K_DBG_AHB is used for CE logging which is not proper. Add
    ATH12K_DBG_CE and replace ATH12K_DBG_AHB with it.
    
    Compile tested only.
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/20250815-ath-dont-warn-on-ce-enqueue-fail-v1-2-f955ddc3ba7a@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: initialize eirp_power before use [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Mon Aug 4 11:03:10 2025 +0800

    wifi: ath12k: initialize eirp_power before use
    
    [ Upstream commit bba2f9faf41ee9607c78fcd669527b7654543cfe ]
    
    Currently, at the end of ath12k_mac_fill_reg_tpc_info(), the
    reg_tpc_info struct is populated, including the following:
    reg_tpc_info->is_psd_power = is_psd_power;
    reg_tpc_info->eirp_power = eirp_power;
    
    Kernel test robot complains on uninitialized symbol:
    drivers/net/wireless/ath/ath12k/mac.c:10069
    ath12k_mac_fill_reg_tpc_info() error: uninitialized symbol 'eirp_power'
    
    This is because there are some code paths that never set eirp_power, so
    the assignment of reg_tpc_info->eirp_power can come from an
    uninitialized variable. Functionally this is OK since the eirp_power
    only has meaning when is_psd_power is true, and all code paths which set
    is_psd_power to true also set eirp_power. However, to keep the robot
    happy, always initialize eirp_power before use.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
    
    Fixes: aeda163bb0c7 ("wifi: ath12k: fill parameters for vdev set TPC power WMI command")
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/20250804-ath12k-fix-smatch-warning-on-6g-vlp-v1-1-56f1e54152ab@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: Refactor RX TID deletion handling into helper function [+ + +]
Author: Nithyanantham Paramasivam <[email protected]>
Date:   Wed Aug 6 16:47:45 2025 +0530

    wifi: ath12k: Refactor RX TID deletion handling into helper function
    
    [ Upstream commit 7c32476253f11210ac24c7818ca07e19bc032521 ]
    
    Refactor RX TID deletion handling by moving the REO command
    setup and send sequence into a new helper function:
    ath12k_dp_rx_tid_delete_handler().
    
    This improves code readability and modularity, and prepares
    the codebase for potential reuse of the REO command logic in
    other contexts where RX TID deletion is required.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Signed-off-by: Nithyanantham Paramasivam <[email protected]>
    Reviewed-by: Baochen Qiang <[email protected]>
    Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
    Link: https://patch.msgid.link/20250806111750.3214584-3-nithyanantham.paramasivam@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <[email protected]>
    Stable-dep-of: 5e32edc69425 ("wifi: ath12k: Fix flush cache failure during RX queue update")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW) [+ + +]
Author: Gokul Sivakumar <[email protected]>
Date:   Thu Jul 24 15:41:36 2025 +0530

    wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW)
    
    [ Upstream commit 74e2ef72bd4b25ce21c8f309d4f5b91b5df9ff5b ]
    
    Cypress(Infineon) is not the vendor for this 43752 SDIO WLAN chip, and so
    has not officially released any firmware binary for it. It is incorrect to
    maintain this WLAN chip with firmware vendor ID as "CYW". So relabel the
    chip's firmware Vendor ID as "WCC" as suggested by the maintainer.
    
    Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
    Fixes: f74f1ec22dc2 ("wifi: brcmfmac: add support for Cypress firmware api")
    Signed-off-by: Gokul Sivakumar <[email protected]>
    Acked-by: Arend van Spriel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: fix width unit in cfg80211_radio_chandef_valid() [+ + +]
Author: Ryder Lee <[email protected]>
Date:   Mon Sep 22 22:19:08 2025 +0000

    wifi: cfg80211: fix width unit in cfg80211_radio_chandef_valid()
    
    [ Upstream commit 17f34ab55a8518ecbd5dcacec48e6ee903f7c1d0 ]
    
    The original code used nl80211_chan_width_to_mhz(), which returns the width in MHz.
    However, the expected unit is KHz.
    
    Fixes: 510dba80ed66 ("wifi: cfg80211: add helper for checking if a chandef is valid on a radio")
    Signed-off-by: Ryder Lee <[email protected]>
    Link: https://patch.msgid.link/df54294e6c4ed0f3ceff6e818b710478ddfc62c0.1758579480.git.Ryder%20Lee%[email protected]/
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: Remove redundant header files [+ + +]
Author: Liao Yuanhong <[email protected]>
Date:   Tue Aug 19 20:11:51 2025 +0800

    wifi: iwlwifi: Remove redundant header files
    
    [ Upstream commit b4b34ba66443696cc5f3e95493f9d7597259b728 ]
    
    The header file "fw/img.h" is already included on line 9. Remove the
    redundant include.
    
    Fixes: 2594e4d9e1a2d ("wifi: iwlwifi: prepare for reading SAR tables from UEFI")
    Signed-off-by: Liao Yuanhong <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Miri Korenblit <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO [+ + +]
Author: Aditya Kumar Singh <[email protected]>
Date:   Tue Aug 12 12:53:30 2025 +0530

    wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO
    
    [ Upstream commit 36b75dcb1e25739a3a0975699208c98f4b55d012 ]
    
    Commit 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request
    during MLO") introduced a check that rejects scan requests if any link is
    already beaconing. This works fine when all links share the same radio, but
    breaks down in multi-radio setups.
    
    Consider a scenario where a 2.4 GHz link is beaconing and a scan is
    requested on a 5 GHz link, each backed by a different physical radio. The
    current logic still blocks the scan, even though it should be allowed. As a
    result, interface bring-up fails unnecessarily in valid configurations.
    
    Fix this by checking whether the scan is being requested on the same
    underlying radio as the beaconing link. Only reject the scan if it targets
    a link that is already beaconing and the NL80211_FEATURE_AP_SCAN is not
    set. This ensures correct behavior in multi-radio environments and avoids
    false rejections.
    
    Fixes: 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO")
    Signed-off-by: Aditya Kumar Singh <[email protected]>
    Link: https://patch.msgid.link/20250812-fix_scan_ap_flag_requirement_during_mlo-v4-3-383ffb6da213@oss.qualcomm.com
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: fix reporting of all valid links in sta_set_sinfo() [+ + +]
Author: Sarika Sharma <[email protected]>
Date:   Thu Sep 4 16:10:54 2025 +0530

    wifi: mac80211: fix reporting of all valid links in sta_set_sinfo()
    
    [ Upstream commit eebccbfea4184feb758c104783b870ec4ddb6aec ]
    
    Currently, sta_set_sinfo() fails to populate link-level station info
    when sinfo->valid_links is initially 0 and sta->sta.valid_links has
    bits set for links other than link 0. This typically occurs when
    association happens on a non-zero link or link 0 deleted dynamically.
    In such cases, the for_each_valid_link(sinfo, link_id) loop only
    executes for link 0 and terminates early, since sinfo->valid_links
    remains 0. As a result, only MLD-level information is reported to
    userspace.
    
    Hence to fix, initialize sinfo->valid_links with sta->sta.valid_links
    before entering the loop to ensure loop executes for each valid link.
    During iteration, mask out invalid links from sinfo->valid_links if
    any of sta->link[link_id], sdata->link[link_id], or sinfo->links[link_id]
    are not present, to report only valid link information.
    
    Fixes: 505991fba9ec ("wifi: mac80211: extend support to fill link level sinfo structure")
    Signed-off-by: Sarika Sharma <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [clarify comment]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: fix Rx packet handling when pubsta information is not available [+ + +]
Author: Aditya Kumar Singh <[email protected]>
Date:   Wed Sep 17 12:42:03 2025 +0530

    wifi: mac80211: fix Rx packet handling when pubsta information is not available
    
    [ Upstream commit 32d340ae675800672e1219444a17940a8efe5cca ]
    
    In ieee80211_rx_handle_packet(), if the caller does not provide pubsta
    information, an attempt is made to find the station using the address 2
    (source address) field in the header. Since pubsta is missing, link
    information such as link_valid and link_id is also unavailable. Now if such
    a situation comes, and if a matching ML station entry is found based on
    the source address, currently the packet is dropped due to missing link ID
    in the status field which is not correct.
    
    Hence, to fix this issue, if link_valid is not set and the station is an
    ML station, make an attempt to find a link station entry using the source
    address. If a valid link station is found, derive the link ID and proceed
    with packet processing. Otherwise, drop the packet as per the existing
    flow.
    
    Fixes: ea9d807b5642 ("wifi: mac80211: add link information in ieee80211_rx_status")
    Suggested-by: Vasanthakumar Thiagarajan <[email protected]>
    Signed-off-by: Aditya Kumar Singh <[email protected]>
    Link: https://patch.msgid.link/20250917-fix_data_packet_rx_with_mlo_and_no_pubsta-v1-1-8cf971a958ac@oss.qualcomm.com
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Make CONNECTION_MONITOR optional for MLO sta [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Tue Aug 26 13:54:31 2025 +0200

    wifi: mac80211: Make CONNECTION_MONITOR optional for MLO sta
    
    [ Upstream commit ac36daa83650c26fd55dee1a6ee5144769239911 ]
    
    Since commit '1bc892d76a6f ("wifi: mac80211: extend connection
    monitoring for MLO")' mac80211 supports connection monitor for MLO
    client interfaces. Remove the CONNECTION_MONITOR requirement in
    ieee80211_register_hw routine.
    
    Fixes: 1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/20250826-remove-conn-mon-check-ieee80211_register_hw-v2-1-5a1e2f038245@kernel.org
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: fix potential memory leak in mt76_wmac_probe() [+ + +]
Author: Abdun Nihaal <[email protected]>
Date:   Wed Jul 9 20:25:30 2025 +0530

    wifi: mt76: fix potential memory leak in mt76_wmac_probe()
    
    [ Upstream commit 42754b7de2b1a2cf116c5e3f1e8e78392f4ed700 ]
    
    In mt76_wmac_probe(), when the mt76_alloc_device() call succeeds, memory
    is allocated for both struct ieee80211_hw and a workqueue. However, on
    the error path, the workqueue is not freed. Fix that by calling
    mt76_free_device() on the error path.
    
    Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
    Signed-off-by: Abdun Nihaal <[email protected]>
    Reviewed-by: Jiri Slaby <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7915: fix mt7981 pre-calibration [+ + +]
Author: Zhi-Jun You <[email protected]>
Date:   Tue Sep 9 14:48:24 2025 +0800

    wifi: mt76: mt7915: fix mt7981 pre-calibration
    
    [ Upstream commit 2b660ee10a0c25b209d7fda3c41b821b75dd85d9 ]
    
    In vendor driver, size of group cal and dpd cal for mt7981 includes 6G
    although the chip doesn't support it.
    
    mt76 doesn't take this into account which results in reading from the
    incorrect offset.
    
    For devices with precal, this would lead to lower bitrate.
    
    Fix this by aligning groupcal size with vendor driver and switch to
    freq_list_v2 in mt7915_dpd_freq_idx in order to get the correct offset.
    
    Below are iwinfo of the test device with two clients connected
    (iPhone 16, Intel AX210).
    Before :
            Mode: Master  Channel: 36 (5.180 GHz)  HT Mode: HE80
            Center Channel 1: 42 2: unknown
            Tx-Power: 23 dBm  Link Quality: 43/70
            Signal: -67 dBm  Noise: -92 dBm
            Bit Rate: 612.4 MBit/s
            Encryption: WPA3 SAE (CCMP)
            Type: nl80211  HW Mode(s): 802.11ac/ax/n
            Hardware: embedded [MediaTek MT7981]
    
    After:
            Mode: Master  Channel: 36 (5.180 GHz)  HT Mode: HE80
            Center Channel 1: 42 2: unknown
            Tx-Power: 23 dBm  Link Quality: 43/70
            Signal: -67 dBm  Noise: -92 dBm
            Bit Rate: 900.6 MBit/s
            Encryption: WPA3 SAE (CCMP)
            Type: nl80211  HW Mode(s): 802.11ac/ax/n
            Hardware: embedded [MediaTek MT7981]
    
    Tested-on: mt7981 20240823
    
    Fixes: 19a954edec63 ("wifi: mt76: mt7915: add mt7986, mt7916 and mt7981 pre-calibration")
    Signed-off-by: Zhi-Jun You <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links() [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Sat Aug 30 00:26:47 2025 +0200

    wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links()
    
    [ Upstream commit fe5fffadc6c77c56f122cf1042dc830f59e904bf ]
    
    In order to avoid a possible NULL pointer dereference in
    mt7996_mac_sta_init_link routine, move the phy pointer check before
    running mt7996_mac_sta_init_link() in mt7996_mac_sta_add_links routine.
    
    Fixes: dd82a9e02c054 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/20250830-mt7996_mac_sta_add_links-fix-v1-1-4219fb8755ee@kernel.org
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Convert mt7996_wed_rro_addr to LE [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Tue Sep 9 11:45:19 2025 +0200

    wifi: mt76: mt7996: Convert mt7996_wed_rro_addr to LE
    
    [ Upstream commit 809054a60d613ccca6e7f243bc68966b58044163 ]
    
    Do not use bitmask in mt7996_wed_rro_addr DMA descriptor in order to not
    break endianness
    
    Fixes: 950d0abb5cd94 ("wifi: mt76: mt7996: add wed rx support")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Fix mt7996_mcu_bss_mld_tlv routine [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Thu Jul 10 10:26:19 2025 +0200

    wifi: mt76: mt7996: Fix mt7996_mcu_bss_mld_tlv routine
    
    [ Upstream commit ed01c310eca96453c11b59db46c855aa593cffdd ]
    
    Update mt7996_mcu_bss_mld_tlv routine to properly support MLO
    configuring the BSS.
    
    Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Fix mt7996_mcu_sta_ba wcid configuration [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Tue Jul 8 09:12:05 2025 +0200

    wifi: mt76: mt7996: Fix mt7996_mcu_sta_ba wcid configuration
    
    [ Upstream commit fe219a41adaf5354c59e75ebb642b8cb8a851d38 ]
    
    Fix the wcid pointer used in mt7996_mcu_sta_ba routine to properly
    support MLO scenario.
    
    Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Fix RX packets configuration for primary WED device [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Tue Sep 9 11:45:17 2025 +0200

    wifi: mt76: mt7996: Fix RX packets configuration for primary WED device
    
    [ Upstream commit cffed52dbf0ddd0db11f9df63f9976fe58ac9628 ]
    
    In order to properly set the number of rx packets for primary WED device
    if hif device is available, move hif pointer initialization before
    running mt7996_mmio_wed_init routine.
    
    Fixes: 83eafc9251d6d ("wifi: mt76: mt7996: add wed tx support")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Fix tx-queues initialization for second phy on mt7996 [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Tue Sep 9 11:45:16 2025 +0200

    wifi: mt76: mt7996: Fix tx-queues initialization for second phy on mt7996
    
    [ Upstream commit 77ff8caf3b17626ad91568cef63d75e288aa4052 ]
    
    Fix the second phy tx queue initialization if hif device is not
    available for MT7990 chipset.
    
    Fixes: 83eafc9251d6d ("wifi: mt76: mt7996: add wed tx support")
    Co-developed-by: Sujuan Chen <[email protected]>
    Signed-off-by: Sujuan Chen <[email protected]>
    Co-developed-by: Benjamin Lin <[email protected]>
    Signed-off-by: Benjamin Lin <[email protected]>
    Co-developed-by: Rex Lu <[email protected]>
    Signed-off-by: Rex Lu <[email protected]>
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: remove redundant per-phy mac80211 calls during restart [+ + +]
Author: Felix Fietkau <[email protected]>
Date:   Mon Sep 15 09:58:56 2025 +0200

    wifi: mt76: mt7996: remove redundant per-phy mac80211 calls during restart
    
    [ Upstream commit 0a5df0ec47f7edc04957925a9644101682041d27 ]
    
    There is only one wiphy, so extra calls must be removed.
    For calls that need to remain per-wiphy, use mt7996_for_each_phy
    
    Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Mon Sep 1 00:14:37 2025 +0200

    wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback
    
    [ Upstream commit afff4325548f0cf872e404df2856bf8bd9581c7e ]
    
    Do not always use deflink_id in link_sta_rc_update mac80211
    callback but use the proper link_id provided by mac80211.
    
    Fixes: 0762bdd30279f ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://patch.msgid.link/20250901-mt7996-fix-link_sta_rc_update-callback-v1-1-e24caf196222@kernel.org
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mwifiex: send world regulatory domain to driver [+ + +]
Author: Stefan Kerkmann <[email protected]>
Date:   Mon Aug 4 16:16:59 2025 +0200

    wifi: mwifiex: send world regulatory domain to driver
    
    [ Upstream commit 56819d00bc2ebaa6308913c28680da5d896852b8 ]
    
    The world regulatory domain is a restrictive subset of channel
    configurations which allows legal operation of the adapter all over the
    world. Changing to this domain should not be prevented.
    
    Fixes: dd4a9ac05c8e1 ("mwifiex: send regulatory domain info to firmware only if alpha2 changed") changed
    Signed-off-by: Stefan Kerkmann <[email protected]>
    Reviewed-by: Jeff Chen <[email protected]>
    Link: https://patch.msgid.link/20250804-fix-mwifiex-regulatory-domain-v1-1-e4715c770c4d@pengutronix.de
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: Lock rtwdev->mutex before setting the LED [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Fri Aug 1 23:08:24 2025 +0300

    wifi: rtw88: Lock rtwdev->mutex before setting the LED
    
    [ Upstream commit 26a8bf978ae9cd7688af1d08bc8760674d372e22 ]
    
    Some users report that the LED blinking breaks AP mode somehow. Most
    likely the LED code and the dynamic mechanism are trying to access the
    hardware registers at the same time. Fix it by locking rtwdev->mutex
    before setting the LED and unlocking it after.
    
    Fixes: 4b6652bc6d8d ("wifi: rtw88: Add support for LED blinking")
    Closes: https://github.com/lwfinger/rtw88/issues/305
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: Use led->brightness_set_blocking for PCI too [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Tue Aug 19 21:46:02 2025 +0300

    wifi: rtw88: Use led->brightness_set_blocking for PCI too
    
    [ Upstream commit fce6fee0817b8899e0ee38ab6b98f0d7e939ceed ]
    
    Commit 26a8bf978ae9 ("wifi: rtw88: Lock rtwdev->mutex before setting
    the LED") made rtw_led_set() sleep, but that's not allowed. Fix it by
    using the brightness_set_blocking member of struct led_classdev for
    PCI devices too. This one is allowed to sleep.
    
    bad: scheduling from the idle thread!
    nix kernel: CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G        W  O        6.16.0 #1-NixOS PREEMPT(voluntary)
    nix kernel: Tainted: [W]=WARN, [O]=OOT_MODULE
    nix kernel: Hardware name: [REDACTED]
    nix kernel: Call Trace:
    nix kernel:  <IRQ>
    nix kernel:  dump_stack_lvl+0x63/0x90
    nix kernel:  dequeue_task_idle+0x2d/0x50
    nix kernel:  __schedule+0x191/0x1310
    nix kernel:  ? xas_load+0x11/0xd0
    nix kernel:  schedule+0x2b/0xe0
    nix kernel:  schedule_preempt_disabled+0x19/0x30
    nix kernel:  __mutex_lock.constprop.0+0x3fd/0x7d0
    nix kernel:  rtw_led_set+0x27/0x60 [rtw_core]
    nix kernel:  led_blink_set_nosleep+0x56/0xb0
    nix kernel:  led_trigger_blink+0x49/0x80
    nix kernel:  ? __pfx_tpt_trig_timer+0x10/0x10 [mac80211]
    nix kernel:  call_timer_fn+0x2f/0x140
    nix kernel:  ? __pfx_tpt_trig_timer+0x10/0x10 [mac80211]
    nix kernel:  __run_timers+0x21a/0x2b0
    nix kernel:  run_timer_softirq+0x8e/0x100
    nix kernel:  handle_softirqs+0xea/0x2c0
    nix kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
    nix kernel:  __irq_exit_rcu+0xdc/0x100
    nix kernel:  sysvec_apic_timer_interrupt+0x7c/0x90
    nix kernel:  </IRQ>
    nix kernel:  <TASK>
    nix kernel:  asm_sysvec_apic_timer_interrupt+0x1a/0x20
    nix kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x450
    nix kernel: Code: 00 e8 08 7c 2e ff e8 d3 ee ff ff 49 89 c6 0f 1f 44 00 00 31 ff e8 c4 d1 2c ff 80 7d d7 00 0f 85 5d 02 00 00 fb 0f 1f 44 00 00 <45> 85 ff 0f 88 a0 01 00 00 49 63 f7 4c 89 f2 48 8d 0>
    nix kernel: RSP: 0018:ffffd579801c7e68 EFLAGS: 00000246
    nix kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
    nix kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    nix kernel: RBP: ffffd579801c7ea0 R08: 0000000000000000 R09: 0000000000000000
    nix kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8eab0462a400
    nix kernel: R13: ffffffff9a7d7a20 R14: 00000003aebe751d R15: 0000000000000003
    nix kernel:  ? cpuidle_enter_state+0xbc/0x450
    nix kernel:  cpuidle_enter+0x32/0x50
    nix kernel:  do_idle+0x1b1/0x210
    nix kernel:  cpu_startup_entry+0x2d/0x30
    nix kernel:  start_secondary+0x118/0x140
    nix kernel:  common_startup_64+0x13e/0x141
    nix kernel:  </TASK>
    
    Fixes: 26a8bf978ae9 ("wifi: rtw88: Lock rtwdev->mutex before setting the LED")
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw89: avoid circular locking dependency in ser_state_run() [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Sat Sep 20 00:08:50 2025 +0300

    wifi: rtw89: avoid circular locking dependency in ser_state_run()
    
    [ Upstream commit 570f94511766f9236d3462dfb8a3c719c2b54c23 ]
    
    Lockdep gives a splat [1] when ser_hdl_work item is executed.  It is
    scheduled at mac80211 workqueue via ieee80211_queue_work() and takes a
    wiphy lock inside.  However, this workqueue can be flushed when e.g.
    closing the interface and wiphy lock is already taken in that case.
    
    Choosing wiphy_work_queue() for SER is likely not suitable.  Back on to
    the global workqueue.
    
    [1]:
    
     WARNING: possible circular locking dependency detected
     6.17.0-rc2 #17 Not tainted
     ------------------------------------------------------
     kworker/u32:1/61 is trying to acquire lock:
     ffff88811bc00768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ser_state_run+0x5e/0x180 [rtw89_core]
    
     but task is already holding lock:
     ffffc9000048fd30 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}, at: process_one_work+0x7b5/0x1450
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #2 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}:
            process_one_work+0x7c6/0x1450
            worker_thread+0x49e/0xd00
            kthread+0x313/0x640
            ret_from_fork+0x221/0x300
            ret_from_fork_asm+0x1a/0x30
    
     -> #1 ((wq_completion)phy0){+.+.}-{0:0}:
            touch_wq_lockdep_map+0x8e/0x180
            __flush_workqueue+0x129/0x10d0
            ieee80211_stop_device+0xa8/0x110
            ieee80211_do_stop+0x14ce/0x2880
            ieee80211_stop+0x13a/0x2c0
            __dev_close_many+0x18f/0x510
            __dev_change_flags+0x25f/0x670
            netif_change_flags+0x7b/0x160
            do_setlink.isra.0+0x1640/0x35d0
            rtnl_newlink+0xd8c/0x1d30
            rtnetlink_rcv_msg+0x700/0xb80
            netlink_rcv_skb+0x11d/0x350
            netlink_unicast+0x49a/0x7a0
            netlink_sendmsg+0x759/0xc20
            ____sys_sendmsg+0x812/0xa00
            ___sys_sendmsg+0xf7/0x180
            __sys_sendmsg+0x11f/0x1b0
            do_syscall_64+0xbb/0x360
            entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
     -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}:
            __lock_acquire+0x124c/0x1d20
            lock_acquire+0x154/0x2e0
            __mutex_lock+0x17b/0x12f0
            ser_state_run+0x5e/0x180 [rtw89_core]
            rtw89_ser_hdl_work+0x119/0x220 [rtw89_core]
            process_one_work+0x82d/0x1450
            worker_thread+0x49e/0xd00
            kthread+0x313/0x640
            ret_from_fork+0x221/0x300
            ret_from_fork_asm+0x1a/0x30
    
     other info that might help us debug this:
    
     Chain exists of:
       &rdev->wiphy.mtx --> (wq_completion)phy0 --> (work_completion)(&ser->ser_hdl_work)
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock((work_completion)(&ser->ser_hdl_work));
                                    lock((wq_completion)phy0);
                                    lock((work_completion)(&ser->ser_hdl_work));
       lock(&rdev->wiphy.mtx);
    
      *** DEADLOCK ***
    
     2 locks held by kworker/u32:1/61:
      #0: ffff888103835148 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0xefa/0x1450
      #1: ffffc9000048fd30 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}, at: process_one_work+0x7b5/0x1450
    
     stack backtrace:
     CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Not tainted 6.17.0-rc2 #17 PREEMPT(voluntary)
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025
     Workqueue: phy0 rtw89_ser_hdl_work [rtw89_core]
     Call Trace:
      <TASK>
      dump_stack_lvl+0x5d/0x80
      print_circular_bug.cold+0x178/0x1be
      check_noncircular+0x14c/0x170
      __lock_acquire+0x124c/0x1d20
      lock_acquire+0x154/0x2e0
      __mutex_lock+0x17b/0x12f0
      ser_state_run+0x5e/0x180 [rtw89_core]
      rtw89_ser_hdl_work+0x119/0x220 [rtw89_core]
      process_one_work+0x82d/0x1450
      worker_thread+0x49e/0xd00
      kthread+0x313/0x640
      ret_from_fork+0x221/0x300
      ret_from_fork_asm+0x1a/0x30
      </TASK>
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: ebfc9199df05 ("wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yet")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw89: fix leak in rtw89_core_send_nullfunc() [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Sat Sep 20 00:08:49 2025 +0300

    wifi: rtw89: fix leak in rtw89_core_send_nullfunc()
    
    [ Upstream commit a9f0064f4716b0fd97085015ea1dd398bdfdc946 ]
    
    If there is no rtwsta_link found in rtw89_core_send_nullfunc(), allocated
    skb is leaked.  Free it on the error handling path.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: a8ba4acab7db ("wifi: rtw89: send nullfunc based on the given link")
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/vdso: Fix output operand size of RDPID [+ + +]
Author: Uros Bizjak <[email protected]>
Date:   Mon Jun 16 11:52:57 2025 +0200

    x86/vdso: Fix output operand size of RDPID
    
    [ Upstream commit ac9c408ed19d535289ca59200dd6a44a6a2d6036 ]
    
    RDPID instruction outputs to a word-sized register (64-bit on x86_64 and
    32-bit on x86_32). Use an unsigned long variable to store the correct size.
    
    LSL outputs to 32-bit register, use %k operand prefix to always print the
    32-bit name of the register.
    
    Use RDPID insn mnemonic while at it as the minimum binutils version of
    2.30 supports it.
    
      [ bp: Merge two patches touching the same function into a single one. ]
    
    Fixes: ffebbaedc861 ("x86/vdso: Introduce helper functions for CPU and node number")
    Signed-off-by: Uros Bizjak <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>