Changelog in Linux kernel 7.0.9

 
arm64: dts: broadcom: bcm2712-d-rpi-5-b: add fixes for pinctrl/pinctrl_aon [+ + +]
Author: Gregor Herburger <gregor.herburger@linutronix.de>
Date:   Thu Feb 26 09:55:58 2026 +0100

    arm64: dts: broadcom: bcm2712-d-rpi-5-b: add fixes for pinctrl/pinctrl_aon
    
    commit aeb078cebc40d421f61a8f07b0e7919aeb44d751 upstream.
    
    On the -d revision of the bcm2712 the pinctrl differs from the c0
    revision. The driver already supports both and distinguishes the two
    with the compatible string.
    
    Update the compatible string and reg length to reflect the different
    pinctrl.
    
    Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
    Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-5-60832d20ff04@linutronix.de
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: broadcom: bcm2712-d-rpi-5-b: update uart10 interrupt [+ + +]
Author: Gregor Herburger <gregor.herburger@linutronix.de>
Date:   Thu Feb 26 09:55:59 2026 +0100

    arm64: dts: broadcom: bcm2712-d-rpi-5-b: update uart10 interrupt
    
    commit 18d4a06e10051681de074a9250e54afc1f3ee312 upstream.
    
    On the -d revision of bcm2712 the uart interrupt is on 120. Update it
    accordingly.
    
    Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
    Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-6-60832d20ff04@linutronix.de
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Cc: Rasmus Villemoes <ravi@prevas.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: freescale: imx95-toradex-smarc: fix PMIC_SD2_VSEL label position [+ + +]
Author: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Date:   Thu Jan 29 11:47:35 2026 +0100

    arm64: dts: freescale: imx95-toradex-smarc: fix PMIC_SD2_VSEL label position
    
    commit 0c9d379d436e119285ef39a4f96b012f576ed74c upstream.
    
    Fix the PMIC_SD2_VSEL gpio-line-name position. It should be on line 19
    of gpio3, not line 20.
    
    Fixes: 90bbe88e0ea6 ("arm64: dts: freescale: add Toradex SMARC iMX95")
    Cc: stable@vger.kernel.org
    Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: lx2160a-cex7/lx2162a-sr-som: fix usd-cd & gpio pinmux [+ + +]
Author: Josua Mayer <josua@solid-run.com>
Date:   Tue Mar 24 13:40:55 2026 +0100

    arm64: dts: lx2160a-cex7/lx2162a-sr-som: fix usd-cd & gpio pinmux
    
    commit 70008aee892bbb5c2969bbe9e5778fc081b14bd2 upstream.
    
    Commit 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to
    support bus recovery") introduced pinmux nodes for lx2160 i2c
    interfaces, allowing runtime change between i2c and gpio functions
    implementing bus recovery.
    
    However, the dynamic configuration area (overwrite MUX) used by the
    pinctrl-single driver initially reads as zero and does not reflect the
    actual hardware state set by the Reset Configuration Word (RCW) at
    power-on.
    
    Because multiple groups of pins are configured from a single 32-bit
    register, the first write from the pinctrl driver unintentionally clears
    all other bits to zero.
    
    For example, on the LX2162A Clearfog, RCWSR12 is initialized to
    0x08000006. When any i2c pinmux is applied, it clears all other fields.
    This inadvertently disables SD card-detect (IIC2_PMUX) and some GPIOs
    (SDHC1_DIR_PMUX):
    
    LX2162-CF RCWSR12: 0b0000100000000000 0000000000000110
    IIC2_PMUX              |||   |||   || |   |||   |||XXX : I2C/GPIO/CD-WP
    SDHC1_DIR_PMUX         XXX   |||   || |   |||   |||    : SDHC/GPIO/SPI
    
    Reverting the commit in question was considered but bus recovery is an
    important feature.
    
    Instead add pinmux nodes for those pins that were unintentionally
    reconfigured on SolidRun LX2160A Clearfog-CX and LX2162A Clearfog
    boards.
    
    Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery")
    Cc: stable@vger.kernel.org
    Signed-off-by: Josua Mayer <josua@solid-run.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: kodiak: Fix PCIe1 PHY ref clock voting [+ + +]
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Date:   Fri Jan 23 17:42:27 2026 +0530

    arm64: dts: qcom: kodiak: Fix PCIe1 PHY ref clock voting
    
    commit 30e8b6d42e8988eaaf0c2efd8c3797cb3884faea upstream.
    
    GCC_PCIE_CLKREF_EN controls a repeater that provides the reference clock
    only to the PCIe0 PHY. PCIe1 PHY receives its refclk directly from the CXO
    source.
    
    If the PCIe1 driver in HLOS votes for or against GCC_PCIE_CLKREF_EN, it
    will inadvertently modify the refclk to PCIe0 as well. Since PCIe0 is
    managed by WPSS while PCIe1 is managed in HLOS, there is no mechanism to
    coordinate these votes. As a result, HLOS may disable this repeater
    during suspend and cut off the PCIe0 PHY refclk while PCIe0 is still
    active.
    
    Replace the unused GCC_PCIE_CLKREF_EN clock entry with RPMH_CXO_CLK to
    reflect the actual hardware wiring and prevent unintended changes to
    PCIe0 clocking.
    
    Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related nodes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20260123-fix_pcie1_phy_clk-v1-1-38f82ea01792@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: lemans: Correct QUP interrupt numbers [+ + +]
Author: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Date:   Wed Mar 25 18:30:37 2026 +0530

    arm64: dts: qcom: lemans: Correct QUP interrupt numbers
    
    commit c5b22c88cc09b180e3a23010b29f4d02ec117a44 upstream.
    
    Fix GIC_SPI interrupt numbers for QUPv3 SE6 nodes on Lemans SoC.
    Using incorrect interrupt lines can prevent IRQs from triggering
    and break I2C, SPI, and UART operation.
    
    Fixes: 34a407316b7d3 ("arm64: dts: qcom: sa8775p: Populate additional UART DT nodes")
    Fixes: 1b2d7ad5ac14d ("arm64: dts: qcom: sa8775p: add missing spi nodes")
    Fixes: ee2f5f906d69d ("arm64: dts: qcom: sa8775p: add missing i2c nodes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20260325-lemans-irq-num-v1-1-a470d544966a@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am62a7-sk: Fix pin name in comment from M19 to N22 [+ + +]
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Mon Mar 9 10:25:32 2026 +0530

    arm64: dts: ti: k3-am62a7-sk: Fix pin name in comment from M19 to N22
    
    commit 6ee0792d83d5c690205c350825a4c30746c0e0a2 upstream.
    
    The pin for GPMC0_CLK.GPIO0_31 at address 0x000F407C is N22 and not M19.
    Hence, fix the pin name in the comment to avoid confusion.
    
    Fixes: 8f023012eb4a ("arm64: dts: ti: k3-am62a: Enable UHS mode support for SD cards")
    Cc: stable@vger.kernel.org
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Andrew Davis <afd@ti.com>
    Reviewed-by: Bryan Brattlof <bb@ti.com>
    Link: https://patch.msgid.link/20260309045539.2070793-1-s-vadapalli@ti.com
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am69-aquila-clover: Fix DP regulator enable GPIO [+ + +]
Author: Franz Schnyder <franz.schnyder@toradex.com>
Date:   Mon Feb 2 09:36:01 2026 +0100

    arm64: dts: ti: k3-am69-aquila-clover: Fix DP regulator enable GPIO
    
    commit 8cfb2e517113543e0de9e8df5754d5e09cb3627e upstream.
    
    Correct the DP regulator enable GPIO to index 21.
    The 3.3V DP regulator was not being enabled by the assigned GPIO, as it
    is routed to GPIO index 21 and not 37, which was causing instability
    with displays connected over DP or via an active DP-to-HDMI adapter.
    
    Fixes: 9f748a6177e1 ("arm64: dts: ti: am69-aquila: Add Clover")
    Cc: stable@vger.kernel.org
    Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Link: https://patch.msgid.link/20260202083604.325060-3-fra.schnyder@gmail.com
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am69-aquila-dev: Fix DP regulator enable GPIO [+ + +]
Author: Franz Schnyder <franz.schnyder@toradex.com>
Date:   Mon Feb 2 09:36:00 2026 +0100

    arm64: dts: ti: k3-am69-aquila-dev: Fix DP regulator enable GPIO
    
    commit 222191225e69711089ecade3b98d79757d51e907 upstream.
    
    Correct the DP regulator enable GPIO to index 21.
    The 3.3V DP regulator was not being enabled by the assigned GPIO, as it
    is routed to GPIO index 21 and not 37, which was causing instability
    with displays connected over DP or via an active DP-to-HDMI adapter.
    
    Fixes: 39ac6623b1d8 ("arm64: dts: ti: Add Aquila AM69 Support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Link: https://patch.msgid.link/20260202083604.325060-2-fra.schnyder@gmail.com
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
batman-adv: bla: only purge non-released claims [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed May 6 22:20:51 2026 +0200

    batman-adv: bla: only purge non-released claims
    
    commit cf6b604011591865ae39ac82de8978c1120d17af upstream.
    
    When batadv_bla_purge_claims() goes through the list of claims, it is only
    traversing the hash list with an rcu_read_lock(). Due to a potential
    parallel batadv_claim_put(), it can happen that it encounters a claim which
    was actually in the process of being released+freed by
    batadv_claim_release(). In this case, backbone_gw is set to NULL before the
    delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is
    then no longer allowed because it would cause a NULL-ptr derefence.
    
    To avoid this, only claims with a valid reference counter must be purged.
    All others are already taken care of.
    
    Cc: stable@kernel.org
    Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: bla: prevent use-after-free when deleting claims [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed May 6 22:20:50 2026 +0200

    batman-adv: bla: prevent use-after-free when deleting claims
    
    commit 4ae1709a314060a196981b344610d023ea841e57 upstream.
    
    When batadv_bla_del_backbone_claims() removes all claims for a backbone, it
    does this by dropping the link entry in the hash list. This list entry
    itself was one of the references which need to be dropped at the same time
    via batadv_claim_put().
    
    But the batadv_claim_put() must not be done before the last access to the
    claim object in this function. Otherwise the claim might be freed already
    by the batadv_claim_release() function before the list entry was dropped.
    
    Cc: stable@kernel.org
    Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: bla: put backbone reference on failed claim hash insert [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed May 6 22:20:52 2026 +0200

    batman-adv: bla: put backbone reference on failed claim hash insert
    
    commit ba9d20ee9076dac32c371116bacbe72480eb356c upstream.
    
    When batadv_bla_add_claim() fails to insert a new claim into the hash, it
    leaked a reference to the backbone_gw for which the claim was intended.
    Call batadv_backbone_gw_put() on the error path to release the reference
    and avoid leaking the backbone_gw object.
    
    Cc: stable@kernel.org
    Fixes: 3db0decf1185 ("batman-adv: Fix non-atomic bla_claim::backbone_gw access")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: fix integer overflow on buff_pos [+ + +]
Author: Lyes Bourennani <lbourennani@fuzzinglabs.com>
Date:   Wed Apr 22 00:20:22 2026 +0200

    batman-adv: fix integer overflow on buff_pos
    
    commit 0799e5943611006b346b8813c7daf7dd5aa26bfd upstream.
    
    Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size
    check is done using the int type in batadv_iv_ogm_aggr_packet whereas the
    buff_pos variable uses the s16 type. This could lead to an out-of-bound
    read.
    
    Cc: stable@vger.kernel.org
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Signed-off-by: Lyes Bourennani <lbourennani@fuzzinglabs.com>
    Signed-off-by: Alexis Pinson <apinson@fuzzinglabs.com>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: reject new tp_meter sessions during teardown [+ + +]
Author: Jiexun Wang <wangjiexun2025@gmail.com>
Date:   Mon Apr 27 14:43:33 2026 +0800

    batman-adv: reject new tp_meter sessions during teardown
    
    commit 3243543592425beec83d453793e9d27caa0d8e66 upstream.
    
    Prevent tp_meter from starting new sender or receiver sessions after
    mesh_state has left BATADV_MESH_ACTIVE.
    
    Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation")
    Cc: stable@kernel.org
    Reported-by: Yuan Tan <yuantan098@gmail.com>
    Reported-by: Yifan Wu <yifanwucs@gmail.com>
    Reported-by: Juefei Pu <tomapufckgml@gmail.com>
    Reported-by: Xin Liu <bird@lzu.edu.cn>
    Co-developed-by: Luxing Yin <tr0jan@lzu.edu.cn>
    Signed-off-by: Luxing Yin <tr0jan@lzu.edu.cn>
    Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
    Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: stop caching unowned originator pointers in BAT IV [+ + +]
Author: Jiexun Wang <wangjiexun2025@gmail.com>
Date:   Sun May 3 12:28:58 2026 +0800

    batman-adv: stop caching unowned originator pointers in BAT IV
    
    commit f03e8583532941b07761c5429de7d50766fa3110 upstream.
    
    BAT IV keeps the last-hop neighbor address in each neigh_node, but some
    paths also cache an originator pointer derived from a temporary lookup.
    That pointer is not owned by the neigh_node and may no longer refer to a
    live originator entry after purge handling runs.
    
    Stop storing the auxiliary originator pointer in the BAT IV neighbor
    state. When BAT IV needs the neighbor originator data, resolve it from
    the stored neighbor address and drop the reference again after use.
    
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Cc: stable@kernel.org
    Reported-by: Yuan Tan <yuantan098@gmail.com>
    Reported-by: Yifan Wu <yifanwucs@gmail.com>
    Reported-by: Juefei Pu <tomapufckgml@gmail.com>
    Reported-by: Xin Liu <bird@lzu.edu.cn>
    Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
    Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
    [sven: avoid bonding logic for outgoing OGM]
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: stop tp_meter sessions during mesh teardown [+ + +]
Author: Jiexun Wang <wangjiexun2025@gmail.com>
Date:   Mon Apr 27 14:43:34 2026 +0800

    batman-adv: stop tp_meter sessions during mesh teardown
    
    commit 3d3cf6a7314aca4df0a6dde28ce784a2a30d0166 upstream.
    
    TP meter sessions remain linked on bat_priv->tp_list after the netlink
    request has already finished. When the mesh interface is removed,
    batadv_mesh_free() currently tears down the mesh without first draining
    these sessions.
    
    A running sender thread or a late incoming tp_meter packet can then keep
    processing against a mesh instance which is already shutting down.
    Synchronize tp_meter with the mesh lifetime by stopping all active
    sessions from batadv_mesh_free() and waiting for sender threads to exit
    before teardown continues.
    
    Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation")
    Cc: stable@kernel.org
    Reported-by: Yuan Tan <yuantan098@gmail.com>
    Reported-by: Yifan Wu <yifanwucs@gmail.com>
    Reported-by: Juefei Pu <tomapufckgml@gmail.com>
    Reported-by: Xin Liu <bird@lzu.edu.cn>
    Co-developed-by: Luxing Yin <tr0jan@lzu.edu.cn>
    Signed-off-by: Luxing Yin <tr0jan@lzu.edu.cn>
    Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
    Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

batman-adv: tp_meter: fix tp_num leak on kmalloc failure [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed May 6 22:20:49 2026 +0200

    batman-adv: tp_meter: fix tp_num leak on kmalloc failure
    
    commit ce425dd05d0fe7594930a0fb103634f35ac47bb6 upstream.
    
    When batadv_tp_start() or batadv_tp_init_recv() fail to allocate a new
    tp_vars object, the previously incremented bat_priv->tp_num counter is
    never decremented. This causes tp_num to drift upward on each allocation
    failure. Since only BATADV_TP_MAX_NUM sessions can be started and the count
    is never reduced for these failed allocations, it causes to an exhaustion
    of throughput meter sessions. In worst case, no new throughput meter
    session can be started until the mesh interface is removed.
    
    The error handling must decrement tp_num releasing the lock and aborting
    the creation of an throughput meter session
    
    Cc: stable@kernel.org
    Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Wed May 13 12:33:14 2026 -0400

    cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated
    
    [ Upstream commit 93618edf753838a727dbff63c7c291dee22d656b ]
    
    A chain of commits going back to v7.0 reworked rmdir to satisfy the
    controller invariant that a subsystem's ->css_offline() must not run while
    tasks are still doing kernel-side work in the cgroup.
    
    [1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out")
    [2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup")
    [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir")
    [4] 4c56a8ac6869 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition")
    [5] 13e786b64bd3 ("cgroup: Increment nr_dying_subsys_* from rmdir context")
    
    [1] moved task cset unlink from do_exit() to finish_task_switch() so a
    task's cset link drops only after the task has fully stopped scheduling.
    That made tasks past exit_signals() linger on cset->tasks until their final
    context switch, which led to a series of problems as what userspace expected
    to see after rmdir diverged from what the kernel needs to wait for. [2]-[5]
    tried to bridge that divergence: [2] filtered the exiting tasks from
    cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4]
    fixed the wait's condition; [5] made nr_dying_subsys_* visible
    synchronously.
    
    The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the
    rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g.
    host PID 1 systemd reaping orphan pids that were re-parented to it during
    the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those
    pids to free, the pids can't free because PID 1 is the reaper and it's stuck
    in rmdir, and the system A-A deadlocks. No internal lock ordering breaks
    this; the wait itself is the bug.
    
    The css killing side that drove the original reorder, however, can be made
    cleanly asynchronous: ->css_offline() is already async, run from
    css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to
    make that chain start only after all tasks have left the cgroup. rmdir's
    user-visible side then returns as soon as cgroup.procs and friends are
    empty, while ->css_offline() still runs only after the cgroup is fully
    drained.
    
    Verified by the original reproducer (pidns teardown + zombie reaper, runs
    under vng) which hangs vanilla and succeeds here, and by per-commit
    deterministic repros for [2], [3], [4], [5] with a boot parameter that
    widens the post-exit_signals() window so each state is reliably reachable.
    Some stress tests on top of that.
    
    cgroup_apply_control_disable() has the same shape of pre-existing race:
    when a controller is disabled via subtree_control, kill_css() ran
    synchronously while tasks past exit_signals() could still be linked to
    the cgroup's csets, and ->css_offline() could fire before they drained.
    This patch preserves the existing synchronous behavior at that call site
    (kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch
    will defer kill_css_finish() there using a per-css trigger.
    
    This seems like the right approach and I don't see problems with it. The
    changes are somewhat invasive but not excessively so, so backporting to
    -stable should be okay. If something does turn out to be wrong, the fallback
    is to revert the entire chain ([1]-[5]) and rework in the development branch
    instead.
    
    v2: Pin cgrp across the deferred destroy work with explicit
        cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1
        wasn't actually broken (ordered cgroup_offline_wq + queue_work order
        in cgroup_task_dead() saved it) but the explicit ref removes the
        dependency on those non-obvious invariants. Also note the
        pre-existing cgroup_apply_control_disable() race in the description;
        a follow-up will defer kill_css_finish() there.
    
    Fixes: 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir")
    Cc: stable@vger.kernel.org # v7.0+
    Reported-and-tested-by: Martin Pitt <martin@piware.de>
    Link: https://lore.kernel.org/all/afHNg2VX2jy9bW7y@piware.de/
    Link: https://lore.kernel.org/all/35e0670adb4abeab13da2c321582af9f@kernel.org/
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cgroup: Increment nr_dying_subsys_* from rmdir context [+ + +]
Author: Petr Malat <oss@malat.biz>
Date:   Wed May 13 12:33:13 2026 -0400

    cgroup: Increment nr_dying_subsys_* from rmdir context
    
    [ Upstream commit 13e786b64bd3fd81c7eb22aa32bf8305c32f2ccf ]
    
    Incrementing nr_dying_subsys_* in offline_css(), which is executed by
    cgroup_offline_wq worker, leads to a race where user can see the value
    to be 0 if he reads cgroup.stat after calling rmdir and before the worker
    executes. This makes the user wrongly expect resources released by the
    removed cgroup to be available for a new assignment.
    
    Increment nr_dying_subsys_* from kill_css(), which is called from the
    cgroup_rmdir() context.
    
    Fixes: ab0312526867 ("cgroup: Show # of subsystem CSSes in cgroup.stat")
    Signed-off-by: Petr Malat <oss@malat.biz>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Stable-dep-of: 93618edf7538 ("cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Change dither policy for 10 bpc output back to dithering [+ + +]
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Sat Mar 21 06:20:33 2026 +0100

    drm/amd/display: Change dither policy for 10 bpc output back to dithering
    
    commit d65bfb1782304b03862c8c725fac608015dffd36 upstream.
    
    Commit d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to
    round") degraded display of 12 bpc color precision output to 10 bpc sinks
    by switching 10 bpc output from dithering to "truncate to 10 bpc".
    
    I don't find the argumentation in that commit convincing, but the
    consequences highly unfortunate, especially for applications that
    require effective > 10 bpc precision output of > 10 bpc framebuffers.
    
    The argument wasn't something strong like "there are hardware design
    defects or limitations which require us to work around broken dithering
    to 10 bpc", or "there are some special use cases which do require
    truncation to 10 bpc", but essentially "at some point in the past we
    used truncation in Polaris/Vega times and it looks like it got
    inadvertently changed for Navi, so let's do that again". I couldn't find
    evidence for that in the git commit logs for this. The commit message also
    acknowledges that using dithering "...makes some sense for FP16...
    ...but not for ARGB2101010 surfaces..."
    
    The problem with this is that it makes fp16 surfaces, and especially
    rgba16 fixed point surfaces, less useful. These are now well
    supported by Mesa 25.3 and later via OpenGL + EGL, Vulkan/WSI, and by
    OSS AMDVLK Vulkan/WSI/display, and also by GNOME 50 mutter under Wayland,
    and they used to provide more than 10 bpc effective precision at the
    output.
    
    Even for 8 or 10 bpc surfaces, the color pipeline behind the framebuffer,
    e.g., gamma tables, CTM, can be used for color correction and will
    benefit from an effective > 10 bpc output precision via dithering,
    retaining some precision that would get lost on the way through the
    pipeline, e.g., due to non-linear gamma functions.
    
    Scientific apps rely on this for > 10 bpc display precision. Truncating
    to 10 bpc, instead of dithering the pipeline internal 12 bpc precision
    down to 10 bpc, causes a serious loss of precision. This also creates the
    undesirable and slightly absurd situation that using a cheap monitor
    with only 8 bpc input and display panel will yield roughly 12 bpc
    precision via dithering from 12 -> 8 bpc, whereas investment into a
    more expensive monitor with 10 bpc input and native 10 bpc display will
    only yield 10 bpc, even if a fp16 or rgb16 framebuffer and/or a properly
    set up color pipeline (gamma tables, CTM's etc. with more than 10 bpc out
    precision) would allow effective 12 bpc precision output.
    
    Therefore this patch proposes reverting that commit and going back to
    dithering down to 10 bpc, consistent with the behaviour for 6 bpc or 8 bpc
    output.
    
    Successfully tested on AMD Polaris DCE 11.2 and Raven Ridge DCN 1.0 with
    a native 10 bpc capable monitor, outputting a RGBA16 unorm framebuffer and
    measuring resulting color precision with a photometer. No apparent visual
    artifacts or problems were observed, and effective precision was measured
    to be 12 bpc again, as expected.
    
    Fixes: d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round")
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: stable@vger.kernel.org
    Cc: Aric Cyr <aric.cyr@amd.com>
    Cc: Anthony Koo <anthony.koo@amd.com>
    Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Cc: Krunoslav Kovac <krunoslav.kovac@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: fix math_mod() using arg1 instead of arg2 [+ + +]
Author: Wenjing Liu <wenjing.liu@amd.com>
Date:   Thu Mar 26 12:00:34 2026 -0400

    drm/amd/display: fix math_mod() using arg1 instead of arg2
    
    commit 2b104fc31be0607c04188fadbd4a9fa5b50f3b99 upstream.
    
    [Why]
    math_mod() multiplied by arg1 instead of arg2, returning a wrong
    result for any non-trivial modulo operation.
    
    [How]
    Replace arg1 with arg2 in the subtraction term to correctly
    implement fmod(arg1, arg2).
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Dillon Varone <dillon.varone@amd.com>
    Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/pm: fix incorrect FeatureCtrlMask setting on smu v14.0.x [+ + +]
Author: Yang Wang <kevinyang.wang@amd.com>
Date:   Thu Apr 2 22:44:29 2026 -0400

    drm/amd/pm: fix incorrect FeatureCtrlMask setting on smu v14.0.x
    
    commit 504f0098ebd074ac8c0ce3471795d79f68e3d265 upstream.
    
    OverDriveTable.FanMinimumPwm and FeatureCtrlMask.PP_OD_FEATURE_FAN_LEGACY_BIT
    have a hard dependency.
    Invalid handling of this dependency leads to disabled thermal monitoring
    and temperature boundary validation.
    
    v2: squash in typo fix (Yang)
    
    Fixes: 9710b84e2a6a ("drm/amd/pm: add overdrive support on smu v14.0.2/3")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd: Add missing firmware declaration for PSP v15.0.0 [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Apr 8 22:36:49 2026 -0500

    drm/amd: Add missing firmware declaration for PSP v15.0.0
    
    commit 2744103f58e8e03ce675c670bbfe3f46034e5f24 upstream.
    
    PSP v15.0.0 needs both TOC and TA firmware. Without the declaration
    it won't get included in initramfs and leads to following failure:
    
    ```
    Direct firmware load for amdgpu/psp_15_0_0_ta.bin failed with error -2
    early_init of IP block <psp> failed -19
    Fatal error during GPU init
    ```
    
    Fixes: 9b24f63d825e7 ("drm/amdgpu: Enable support for PSP 15_0_0")
    Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ [+ + +]
Author: John B. Moore <jbmoore61@gmail.com>
Date:   Tue Apr 28 11:35:12 2026 -0500

    drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ
    
    commit 7bbfb2559bcec39d1a4e1182d931a2046112c352 upstream.
    
    Remove the BUG_ON(flags & AMDGPU_FENCE_FLAG_64BIT) assertion from
    gfx_v9_0_ring_emit_fence_kiq().  The KIQ hardware supports 64-bit
    fence writes; the 32-bit writeback address constraint is an
    upper-layer convention, not a hardware limitation.  The check serves
    no purpose and should not be present.
    
    Found by code inspection while investigating related BUG_ON
    assertions in the GFX and compute ring emission paths.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: John B. Moore <jbmoore61@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 1b1101a46a426bb4328116bb5273c326a2780389)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/pm: add missing revision check for CI [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Apr 27 11:38:58 2026 -0400

    drm/amdgpu/pm: add missing revision check for CI
    
    commit 2a561b361b7681509710f3cfc3d95d54c87ac69f upstream.
    
    The ci_populate_all_memory_levels() workaround only
    applies to revision 0 SKUs.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816
    Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)")
    Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
    Reviewed-by: Kent Russell <kent.russell@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 1db15ba8f72f400bbad8ae0ce24fafc43429d4bd)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/pm: align Hawaii mclk workaround with radeon [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Apr 28 10:42:49 2026 -0400

    drm/amdgpu/pm: align Hawaii mclk workaround with radeon
    
    commit 1987c79b4fe5789dfa14423e78b5c25f6acf3e9d upstream.
    
    Align the hawaii mclk workaround with radeon and windows.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816
    Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)")
    Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
    Reviewed-by: Kent Russell <kent.russell@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 9649528b637f668c5af9f2b83ca4ad8576ae2121)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission [+ + +]
Author: John B. Moore <jbmoore61@gmail.com>
Date:   Mon Apr 27 16:06:28 2026 -0500

    drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission
    
    commit 78d2e624fa073c14970aa097adcf3ea31c157a66 upstream.
    
    sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions
    that verify fence writeback addresses are dword-aligned.  These
    assertions can be reached from unprivileged userspace via crafted
    DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a
    scheduler worker thread.
    
    Replace both BUG_ON() calls with WARN_ON() to log the condition without
    crashing the kernel.  A misaligned fence address at this point indicates
    a driver bug, but crashing the kernel is never the correct response when
    the assertion is reachable from userspace.
    
    The CS IOCTL path is the correct place to filter invalid submissions;
    the ring emission callback is too late to do anything about it.
    
    Fixes: 2130f89ced2c ("drm/amdgpu: add SDMA v4.0 implementation (v2)")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: John B. Moore <jbmoore61@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/userq: fix access to stale wptr mapping [+ + +]
Author: Sunil Khatri <sunil.khatri@amd.com>
Date:   Mon May 4 18:21:17 2026 +0530

    drm/amdgpu/userq: fix access to stale wptr mapping
    
    commit 6da7b1242da4455b11c24ce667d1cab1a348c8ea upstream.
    
    Use drm_exec to take both locks i.e vm root bo and
    wptr_obj bo to access the mapping data properly.
    
    This fixes the security issue of unmap the wptr_obj while
    a queue creation is in progress and passing other
    bo at same address.
    
    Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/vce: Prevent partial address patches [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Mon Mar 30 15:01:27 2026 -0400

    drm/amdgpu/vce: Prevent partial address patches
    
    commit de2a02cc28d6d5d37db07d00a9a684c754a5fd74 upstream.
    
    In the case that only one of lo/hi is valid, the patching could result
    in a bad address written to in FW.
    
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/vcn3: Avoid overflow on msg bound check [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Mon Apr 13 09:22:15 2026 -0400

    drm/amdgpu/vcn3: Avoid overflow on msg bound check
    
    commit e6e9faba8100628990cccd13f0f044a648c303cf upstream.
    
    As pointed out by SDL, the previous condition may be vulnerable to
    overflow.
    
    Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg")
    Cc: SDL <sdl@nppct.ru>
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit db00257ac9e4a51eb2515aaea161a019f7125e10)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Tue Mar 24 16:25:56 2026 -0400

    drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg
    
    commit b193019860d61e92da395eae2011f2f6716b182f upstream.
    
    Check bounds against the end of the BO whenever we access the msg.
    
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/vcn4: Avoid overflow on msg bound check [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Mon Apr 13 09:22:15 2026 -0400

    drm/amdgpu/vcn4: Avoid overflow on msg bound check
    
    commit 65bce27ea6192320448c30267ffc17ffa094e713 upstream.
    
    As pointed out by SDL, the previous condition may be vulnerable to
    overflow.
    
    Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg")
    Cc: SDL <sdl@nppct.ru>
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Wed Mar 25 09:09:27 2026 -0400

    drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg
    
    commit 0a78f2bac1424deb7c9d5e09c6b8e849d8e8b648 upstream.
    
    Check bounds against the end of the BO whenever we access the msg.
    
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/vcn4: Prevent OOB reads when parsing IB [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Tue Mar 24 16:42:05 2026 -0400

    drm/amdgpu/vcn4: Prevent OOB reads when parsing IB
    
    commit 2444eb0ec8283f4a3845eb7febad378476e1ba3c upstream.
    
    Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the
    bounds checks.
    
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: Add bounds checking to ib_{get,set}_value [+ + +]
Author: Benjamin Cheng <benjamin.cheng@amd.com>
Date:   Wed Mar 25 08:39:19 2026 -0400

    drm/amdgpu: Add bounds checking to ib_{get,set}_value
    
    commit 66085e206431ef88ce36f53c1f53d570790ccc9e upstream.
    
    The uvd/vce/vcn code accesses the IB at predefined offsets without
    checking that the IB is large enough. Check the bounds here. The caller
    is responsible for making sure it can handle arbitrary return values.
    
    Also make the idx a uint32_t to prevent overflows causing the condition
    to fail.
    
    Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Avoid reset in AMDGPU unload path for APUs with GFX V11 and higher. [+ + +]
Author: Shubhankar Milind Sardeshpande <Shubhankar.MilindSardeshpande@amd.com>
Date:   Tue Apr 21 17:01:21 2026 +0530

    drm/amdgpu: Avoid reset in AMDGPU unload path for APUs with GFX V11 and higher.
    
    commit 47776ac1e3f4a2aefcf7fe7c7e4a11151b676222 upstream.
    
    GFX V11 has GC block as default off IP.
    Every time AMDGPU driver sends a request to PMFW
    to unload MP1, PMFW will put GC in reset and
    power down the voltage.Hence, skipping reset
    for APUs with GFX V11 or later to avoid reset
    related failures.
    
    Fixes: 34355e61835e ("drm/amdgpu: Fix GFX hang on SteamDeck when amdgpu is reloaded")
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Shubhankar Milind Sardeshpande <Shubhankar.MilindSardeshpande@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit d0a8cadffc818f51d05bc234d8da1af228bc59a3)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: gate VM CPU HDP flush on reset lock [+ + +]
Author: Chenglei Xie <Chenglei.Xie@amd.com>
Date:   Tue Apr 7 10:51:24 2026 -0400

    drm/amdgpu: gate VM CPU HDP flush on reset lock
    
    commit ddda81c4d7e71e41b1be91d921fd85747eddbd12 upstream.
    
    During GPU reset, the application could still run CPU page table updates. Each commit called
    amdgpu_device_flush_hdp(), which on SR-IOV sends work through the KIQ ring.
    That can advance sync_seq while the GPU is being reset,
    leaving fence writeback out of sync and causing amdgpu_fence_emit_polling()
    to time out on later KIQ use.
    
    Fix:
    amdgpu_vm_cpu_commit():
      Reset will flush HDP anyway, the HDP flush in amdgpu_vm_cpu_commit() can be skipped
      when a reset is ongoging.
      Take reset_domain->sem with down_read_trylock() before amdgpu_device_flush_hdp().
      If the reset path holds the write lock, skip the HDP flush so no HDP-related HW
      access (including KIQ) runs during reset; state is re-established after reset.
    
    Signed-off-by: Chenglei Xie <Chenglei.Xie@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Use NBIF offset for register RCC_STRAP0_RCC_DEV0_EPF0_STRAP0 . [+ + +]
Author: Ramalingeswara Reddy, Kanala <Kanala.RamalingeswaraReddy@amd.com>
Date:   Fri Apr 10 11:20:20 2026 +0530

    drm/amdgpu: Use NBIF offset for register RCC_STRAP0_RCC_DEV0_EPF0_STRAP0 .
    
    commit 08cdf07b55bff236aeaea3d52a8d1ffe11d801ec upstream.
    
    Define and use regRCC_STRAP0_RCC_DEV0_EPF0_STRAP0_nbif_4_10,
    to get correct rev_id in nbif_v6_3_1_get_rev_id().
    
    Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
    Signed-off-by: Ramalingeswara Reddy, Kanala <Kanala.RamalingeswaraReddy@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Use SMUIO 15.0.0 offsets for TSC upper and lower count. [+ + +]
Author: Ramalingeswara Reddy, Kanala <Kanala.RamalingeswaraReddy@amd.com>
Date:   Tue Mar 31 17:23:22 2026 +0530

    drm/amdgpu: Use SMUIO 15.0.0 offsets for TSC upper and lower count.
    
    commit 574b3b14f7d1b329fc6e67b79328f0e6f4d4b3d4 upstream.
    
    Define and use regGOLDEN_TSC_COUNT_UPPER_smu_15_0_0 and
    regGOLDEN_TSC_COUNT_LOWER_smu_15_0_0 for TSC upper and lower count.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
    Signed-off-by: Ramalingeswara Reddy, Kanala <Kanala.RamalingeswaraReddy@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: zero-initialize GART table on allocation [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Mon Apr 27 09:30:23 2026 -0400

    drm/amdgpu: zero-initialize GART table on allocation
    
    commit e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741 upstream.
    
    GART TLB is flushed after unmapping but not after mapping. Since
    amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a
    single PTE is written the TLB may speculatively load other uninitialized
    entries from the same cacheline. Those garbage entries can appear valid,
    and a subsequent write to another PTE in the same cacheline may cause the
    GPU to use a stale garbage PTE from the TLB.
    
    Fix this by calling memset_io() to zero-initialize the GART table with
    gart_pte_flags immediately after allocation.
    
    Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work
    since SDMA needs GART to be initialized to work.
    
    Suggested-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Philip Yang <Philip.Yang@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdkfd: Add upper bound check for num_of_nodes [+ + +]
Author: Alysa Liu <Alysa.Liu@amd.com>
Date:   Mon Mar 30 10:50:07 2026 -0400

    drm/amdkfd: Add upper bound check for num_of_nodes
    
    commit 74b73fa56a395d46745e4f245225963e9f8be7f1 upstream.
    
    drm/amdkfd: Add upper bound check for num_of_nodes
    in kfd_ioctl_get_process_apertures_new.
    
    Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
    Signed-off-by: Alysa Liu <Alysa.Liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure [+ + +]
Author: Amir Shetaia <Amir.Shetaia@amd.com>
Date:   Fri Apr 10 10:38:13 2026 -0400

    drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure
    
    commit ad52d61d82181dbdb7f05826de38352d5e550cc2 upstream.
    
    KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE
    but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated
    VRAM with stale data from prior use observable by compute kernels.
    
    The GEM ioctl path already sets VRAM_CLEARED for all userspace
    allocations via amdgpu_gem_create_ioctl() and
    amdgpu_mode_dumb_create(). The KFD path was missing this flag,
    allowing stale page table remnants to leak into user buffers.
    
    This causes crashes in RCCL P2P transport where non-zero data in
    ptrExchange/head/tail fields corrupts the protocol handshake.
    
    Signed-off-by: Amir Shetaia <Amir.Shetaia@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdkfd: Make all TLB-flushes heavy-weight [+ + +]
Author: Felix Kuehling <felix.kuehling@amd.com>
Date:   Mon Apr 20 11:55:57 2026 -0400

    drm/amdkfd: Make all TLB-flushes heavy-weight
    
    commit 9b4e3495d1bd2469bf94b74930c153c2d534ddb7 upstream.
    
    With only one sequence number we cannot track the need for legacy vs
    heavy-weight flushes reliably. Always use heavy-weight.
    
    Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
    Reviewed-by: Philip Yang <philip.yang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit c1a3ff1d327820cd9a52bc1056b98681fc088949)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdkfd: validate SVM ioctl nattr against buffer size [+ + +]
Author: Alysa Liu <Alysa.Liu@amd.com>
Date:   Tue Apr 21 10:18:28 2026 -0400

    drm/amdkfd: validate SVM ioctl nattr against buffer size
    
    commit 045e0ff208f0838a246c10204105126611b267a1 upstream.
    
    Validate nattr field against the buffer size, preventing
    out-of-bounds buffer access via user-controlled attribute count.
    
    Reviewed-by: Amir Shetaia <Amir.Shetaia@amd.com>
    Signed-off-by: Alysa Liu <Alysa.Liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/appletbdrm: Use kvzalloc for big allocations [+ + +]
Author: Sasha Finkelstein <k@chaosmail.tech>
Date:   Mon Apr 20 14:17:43 2026 +0200

    drm/appletbdrm: Use kvzalloc for big allocations
    
    commit aaaa684bab1f6d9ecfc49db328facb1771fd0eb2 upstream.
    
    This driver is attached to a ~2000x80 screen, which is a lot more than
    a single page. This causes out of memory errors in some rare cases.
    
    Reported-by: soopyc <cassie@soopy.moe>
    Closes: https://github.com/t2linux/fedora/issues/51
    Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Aditya Garg <gargaditya08@live.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: 0670c2f56e45 ("drm/tiny: add driver for Apple Touch Bars in x86 Macs")
    Cc: <stable@vger.kernel.org> # v6.15+
    Link: https://patch.msgid.link/20260420-x86-tb-vmalloc-v1-1-7757ff657223@chaosmail.tech
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/atomic: Add affected colorops with affected planes [+ + +]
Author: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Date:   Tue Mar 10 17:02:38 2026 +0530

    drm/atomic: Add affected colorops with affected planes
    
    commit 6955d6bca0531ffbbaeecac844b7bae84345b3fb upstream.
    
    When drm_atomic_add_affected_planes() adds a plane to the atomic
    state, the associated colorops are not guaranteed to be included.
    This can leave colorop state out of the transaction when planes
    are pulled in implicitly (eg. during modeset or internal commits).
    
    Also add affected colorops when adding affected planes to keep
    plane and color pipeline state consistent within the atomic
    transaction.
    
    v2: Add affected colorops only when a pipeline is enabled
    
    Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property")
    Cc: <stable@vger.kernel.org> #v6.19+
    Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1
    Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
    Link: https://patch.msgid.link/20260310113238.3495981-3-chaitanya.kumar.borah@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/bridge: tda998x: Use __be32 for audio port OF property pointer [+ + +]
Author: Kory Maincent (TI) <kory.maincent@bootlin.com>
Date:   Tue Apr 28 11:04:56 2026 +0200

    drm/bridge: tda998x: Use __be32 for audio port OF property pointer
    
    commit 2a46a9356ba7b1bdd741c8b41e5374edcd960557 upstream.
    
    of_get_property() returns a pointer to big-endian (__be32) data, but
    port_data in tda998x_get_audio_ports() was declared as const u32 *,
    causing a sparse endianness type mismatch warning. Fix the declaration
    to use const __be32 *.
    
    Fixes: 7e567624dc5a4 ("drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://patch.msgid.link/20260428090457.121894-1-kory.maincent@bootlin.com
    Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/colorop: Fix blob property reference tracking in state lifecycle [+ + +]
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Thu Mar 12 16:41:45 2026 -0400

    drm/colorop: Fix blob property reference tracking in state lifecycle
    
    commit 235b333e2878d791cee09e1e72f44611a9400114 upstream.
    
    The colorop state blob property handling had memory leaks during state
    duplication, destruction, and reset operations. The implementation
    failed to follow the established pattern from drm_crtc's handling of
    DEGAMMA/GAMMA blob properties.
    
    Issues fixed:
    - drm_colorop_atomic_destroy_state() was freeing state memory without
      releasing the blob reference, causing a leak
    - drm_colorop_reset() was directly freeing old state with kfree()
      instead of properly destroying it, leaking blob references
    - drm_colorop_cleanup() had duplicate blob cleanup code
    
    Changes:
    - Add __drm_atomic_helper_colorop_destroy_state() helper to properly
      release blob references before freeing state memory
    - Update drm_colorop_atomic_destroy_state() to call the helper
    - Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()
      for proper cleanup of old state
    - Simplify drm_colorop_cleanup() to use the common destruction path
    
    This matches the well-tested pattern used by drm_crtc since 2016 and
    ensures proper reference counting throughout the state lifecycle.
    
    Co-developed by Claude Sonnet 4.5.
    
    Fixes: cfc27680ee20 ("drm/colorop: Introduce new drm_colorop mode object")
    Cc: Simon Ser <contact@emersion.fr>
    Cc: Alex Hung <alex.hung@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Daniel Stone <daniels@collabora.com>
    Cc: Melissa Wen <mwen@igalia.com>
    Cc: Sebastian Wick <sebastian.wick@redhat.com>
    Cc: Uma Shankar <uma.shankar@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Louis Chauvet <louis.chauvet@bootlin.com>
    Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
    Cc: <stable@vger.kernel.org> #v6.19+
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Link: https://patch.msgid.link/20260312204145.829714-1-harry.wentland@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/colorop: Preserve bypass value in duplicate_state() [+ + +]
Author: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Date:   Tue Mar 10 17:02:37 2026 +0530

    drm/colorop: Preserve bypass value in duplicate_state()
    
    commit 0d9710aeb6959ae244f255986187562fa50504b9 upstream.
    
    __drm_atomic_helper_colorop_duplicate_state() unconditionally
    sets state->bypass = true after copying the existing state.
    
    This override causes the new atomic state to no longer reflect
    the currently committed hardware state. Since the bypass property
    directly controls whether the colorop is active in hardware,
    resetting it to true can inadvertently disable an active colorop
    during a subsequent commit, particularly for internal driver commits
    where userspace does not touch the property.
    
    Drop the unconditional assignment and preserve the duplicated
    bypass value.
    
    Fixes: 8c5ea1745f4c ("drm/colorop: Add BYPASS property")
    Cc: <stable@vger.kernel.org> #v6.19+
    Reviewed-by: Uma Shankar <uma.shankar@intel.com>
    Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
    Link: https://patch.msgid.link/20260310113238.3495981-2-chaitanya.kumar.borah@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/exynos: remove bridge when component_add fails [+ + +]
Author: Osama Abdelkader <osama.abdelkader@gmail.com>
Date:   Thu Apr 23 22:06:20 2026 +0200

    drm/exynos: remove bridge when component_add fails
    
    commit 26f6654a9a60eb4d241f42a0ec85412e8821480b upstream.
    
    Use devm_drm_bridge_add() so the bridge is released if probe fails after
    registration, and drop the manual drm_bridge_remove() in remove().
    
    Check the return value of devm_drm_bridge_add().
    
    Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
    Fixes: 576d72fbfb45 ("drm/exynos: mic: add a bridge at probe")
    Cc: stable@vger.kernel.org
    Reviewed-by: Raphaël Gallais-Pou <rgallaispou@gmail.com>
    Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Link: https://patch.msgid.link/20260423200622.325076-2-osama.abdelkader@gmail.com
    Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() [+ + +]
Author: Ashutosh Desai <ashutoshdesai993@gmail.com>
Date:   Mon Apr 20 01:36:37 2026 +0000

    drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()
    
    commit 3d4c2268bd7243c3780fe32bf24ff876da272acf upstream.
    
    drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions
    using plain integer division:
    
      unsigned int width  = mode_cmd->width  / (i ? info->hsub : 1);
      unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
    
    However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses
    drm_format_info_plane_width/height() which round up dimensions via
    DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object
    size check for certain pixel format and dimension combinations.
    
    For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the
    GEM size validation path sees height=0 instead of height=1. The
    expression (height - 1) then wraps to UINT_MAX as an unsigned int,
    causing min_size to overflow and wrap back to a small value. A tiny
    GEM object therefore passes the size guard, yet when the GPU accesses
    the chroma plane it will read or write memory beyond the object's
    bounds.
    
    Fix by replacing the open-coded divisions with drm_format_info_plane_width()
    and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match
    the calculation already used in framebuffer_check().
    
    Fixes: 4c3dbb2c312c ("drm: Add GEM backed framebuffer library")
    Cc: stable@vger.kernel.org # v4.14+
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patch.msgid.link/20260420013637.457751-1-ashutoshdesai993@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/gpusvm: Allow device pages to be mapped in mixed mappings after system pages [+ + +]
Author: Matthew Brost <matthew.brost@intel.com>
Date:   Fri Jan 30 11:49:28 2026 -0800

    drm/gpusvm: Allow device pages to be mapped in mixed mappings after system pages
    
    commit ec49857ad181f2a68a3bea15422f2936ff366d47 upstream.
    
    The current code rejects device mappings whenever system pages have
    already been encountered. This is not the intended behavior when
    allow_mixed is set.
    
    Relax the restriction by permitting a single pagemap to be selected when
    allow_mixed is enabled, even if system pages were found earlier.
    
    Fixes: bce13d6ecd6c ("drm/gpusvm, drm/xe: Allow mixed mappings for userptr")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
    Reviewed-by: Francois Dugast <francois.dugast@intel.com>
    Link: https://patch.msgid.link/20260130194928.3255613-3-matthew.brost@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/gpusvm: Force unmapping on error in drm_gpusvm_get_pages [+ + +]
Author: Matthew Brost <matthew.brost@intel.com>
Date:   Fri Jan 30 11:49:27 2026 -0800

    drm/gpusvm: Force unmapping on error in drm_gpusvm_get_pages
    
    commit 556dba95473900073a6c03121361c11f646dc551 upstream.
    
    drm_gpusvm_get_pages() only sets the local flags prior to committing the
    pages. If an error occurs mid-mapping, has_dma_mapping will be clear,
    causing the unmap function to skip unmapping pages that were
    successfully mapped before the error. Fix this by forcibly setting
    has_dma_mapping in the error path to ensure all previously mapped pages
    are properly unmapped.
    
    Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
    Reviewed-by: Francois Dugast <francois.dugast@intel.com>
    Link: https://patch.msgid.link/20260130194928.3255613-2-matthew.brost@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/psr: Init variable to avoid early exit from et alignment loop [+ + +]
Author: Jouni Högander <jouni.hogander@intel.com>
Date:   Mon Apr 13 14:23:45 2026 +0300

    drm/i915/psr: Init variable to avoid early exit from et alignment loop
    
    commit 314f6179e370988ac00dadf373a4f6166eb3db15 upstream.
    
    Uninitialized boolean variable may cause unwanted exit from et alignment
    loop. Fix this by initializing it as false.
    
    Fixes: 1be2fca84f52 ("drm/i915/psr: Repeat Selective Update area alignment")
    Cc: <stable@vger.kernel.org> # v6.9+
    Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
    Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patch.msgid.link/20260413112345.88853-1-jouni.hogander@intel.com
    (cherry picked from commit 289678a90b8cf81e3514c9d6c667235cd39c7acf)
    Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/imx: parallel-display: Prefer bus format set via legacy "interface-pix-fmt" DT property [+ + +]
Author: Marek Vasut <marex@nabladev.com>
Date:   Sat Jan 10 18:14:10 2026 +0100

    drm/imx: parallel-display: Prefer bus format set via legacy "interface-pix-fmt" DT property
    
    commit cdf26e1462c220629bb79d487263b66f8b679eab upstream.
    
    Prefer bus format set via legacy "interface-pix-fmt" DT property
    over panel bus format. This is necessary to retain support for
    DTs which configure the IPUv3 parallel output as 24bit DPI, but
    connect 18bit DPI panels to it with hardware swizzling.
    
    This used to work up to Linux 6.12, but stopped working in 6.13,
    reinstate the behavior to support old DTs.
    
    Cc: stable@vger.kernel.org
    Fixes: 5f6e56d3319d ("drm/imx: parallel-display: switch to drm_panel_bridge")
    Signed-off-by: Marek Vasut <marex@nabladev.com>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Link: https://patch.msgid.link/20260110171510.692666-1-marex@nabladev.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata() [+ + +]
Author: Yasuaki Torimaru <yasuakitorimaru@gmail.com>
Date:   Wed Mar 25 20:46:34 2026 +0900

    drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata()
    
    commit 47cbfe2608314b833ad61a65827d8fb363bc2d2d upstream.
    
    msm_ioctl_gem_info_get_metadata() always returns 0 regardless of
    errors. When copy_to_user() fails or the user buffer is too small,
    the error code stored in ret is ignored because the function
    unconditionally returns 0. This causes userspace to believe the
    ioctl succeeded when it did not.
    
    Additionally, kmemdup() can return NULL on allocation failure, but
    the return value is not checked. This leads to a NULL pointer
    dereference in the subsequent copy_to_user() call.
    
    Add the missing NULL check for kmemdup() and return ret instead of 0.
    
    Note that the SET counterpart (msm_ioctl_gem_info_set_metadata)
    correctly returns ret.
    
    Fixes: 9902cb999e4e ("drm/msm/gem: Add metadata")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yasuaki Torimaru <yasuakitorimaru@gmail.com>
    Patchwork: https://patchwork.freedesktop.org/patch/714478/
    Message-ID: <20260325114635.383241-1-yasuakitorimaru@gmail.com>
    Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm/hdmi: Fix wrong CTRL1 register used in writing info frames [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Date:   Wed Mar 11 20:16:21 2026 +0100

    drm/msm/hdmi: Fix wrong CTRL1 register used in writing info frames
    
    commit 8c6c93b7db42d15c6e8c2540a648d32986a04b1a upstream.
    
    Commit 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi
    framework") changed the unconditional register writes in few places to
    updates: read, apply mask, write.  The new code reads
    REG_HDMI_INFOFRAME_CTRL1 register, applies fields/mask for
    HDMI_INFOFRAME_CTRL0 register and finally writes to
    HDMI_INFOFRAME_CTRL0.  This difference between CTRL1 and CTRL0 looks
    unintended and may result in wrong data being written to HDMI bridge
    registers.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi framework")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Patchwork: https://patchwork.freedesktop.org/patch/711156/
    Link: https://lore.kernel.org/r/20260311191620.245394-2-krzysztof.kozlowski@oss.qualcomm.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm: always recover the gpu [+ + +]
Author: Anna Maniscalco <anna.maniscalco2000@gmail.com>
Date:   Tue Feb 10 17:29:42 2026 +0100

    drm/msm: always recover the gpu
    
    commit 01a0d6cd7032e9993feea19fadb03ef9d5b488f2 upstream.
    
    Previously, in case there was no more work to do, recover worker
    wouldn't trigger recovery and would instead rely on the gpu going to
    sleep and then resuming when more work is submitted.
    
    Recover_worker will first increment the fence of the hung ring so, if
    there's only one job submitted to a ring and that causes an hang, it
    will early out.
    
    There's no guarantee that the gpu will suspend and resume before more
    work is submitted and if the gpu is in a hung state it will stay in that
    state and probably trigger a timeout again.
    
    Just stop checking and always recover the gpu.
    
    Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com>
    Cc: stable@vger.kernel.org
    Patchwork: https://patchwork.freedesktop.org/patch/704066/
    Message-ID: <20260210-recovery_suspend_fix-v1-1-00ed9013da04@gmail.com>
    Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/panel: boe-tv101wum-nl6: restore MODE_LPM after sending disable cmds [+ + +]
Author: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Date:   Sun May 3 17:17:08 2026 +0800

    drm/panel: boe-tv101wum-nl6: restore MODE_LPM after sending disable cmds
    
    commit 570cf799e87ae805eacfab3b4ba66676b5fccdb6 upstream.
    
    When preparing the panel, it seems that it always expects commands to be
    transferred in LP mode. However, the disable function removes the
    MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
    
    As the unprepare function contains no DSI commands, re-adding the flag
    just after disabling the panel should be safe. Add the code re-adding
    the flag after the two commands for disabling the panel are sent.
    
    This fixes error messages shown in kernel log when unblanking on
    mt8183-kukui-kodama-sku32 device.
    
    Cc: stable@vger.kernel.org
    Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel")
    Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patch.msgid.link/20260503091708.1079962-1-zhengxingda@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds [+ + +]
Author: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Date:   Sun Apr 26 00:57:51 2026 +0800

    drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds
    
    commit 2d4e80271f784aa0c7b17676e9762c7e8156be1c upstream.
    
    When preparing the panel, it seems that it always expects commands to be
    transferred in LP mode. However, the disable function removes the
    MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
    
    As the unprepare function contains no DSI commands, re-adding the flag
    just after disabling the panel should be safe. Add the code re-adding
    the flag after the two commands for disabling the panel are sent.
    
    This fixes screen unblanking (after blanking once) on
    mt8188-geralt-ciri-sku1 device.
    
    Cc: stable@vger.kernel.org # 6.11+
    Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver")
    Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patch.msgid.link/20260425165751.1716569-1-zhengxingda@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/radeon: add missing revision check for CI [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Apr 27 11:40:25 2026 -0400

    drm/radeon: add missing revision check for CI
    
    commit 17223816498f7b117d138d18eb0eba63604dc74e upstream.
    
    The memory level workarounds only apply to revision 0 SKUs.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816
    Fixes: 127e056e2a82 ("drm/radeon: fix mclk vddc configuration for cards for hawaii")
    Fixes: 21b8a369046f ("drm/radeon: fix dram timing for certain hawaii boards")
    Fixes: 90b2fee35cb9 ("drm/radeon: fix dpm mc init for certain hawaii boards")
    Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
    Reviewed-by: Kent Russell <kent.russell@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 4d8dcc14311515077062b5740f39f427075de5c9)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/sti: remove bridge when sti_hda component_add fails [+ + +]
Author: Osama Abdelkader <osama.abdelkader@gmail.com>
Date:   Thu Apr 23 22:06:19 2026 +0200

    drm/sti: remove bridge when sti_hda component_add fails
    
    commit 84ae1840260fece9b6b70d3872b79384bbe5a90b upstream.
    
    Use devm_drm_bridge_add() so the bridge is released if probe fails after
    registration, and drop the manual drm_bridge_remove() in remove().
    
    Check the return value of devm_drm_bridge_add().
    
    Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
    Fixes: d28726efc637 ("drm/sti: hda: add bridge before attaching")
    Cc: stable@vger.kernel.org
    Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Acked-by: Raphaël Gallais-Pou <rgallaispou@gmail.com>
    Link: https://patch.msgid.link/20260423200622.325076-1-osama.abdelkader@gmail.com
    Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/udl: Increase GET_URB_TIMEOUT [+ + +]
Author: Shixiong Ou <oushixiong@kylinos.cn>
Date:   Fri Apr 24 20:44:27 2026 +0800

    drm/udl: Increase GET_URB_TIMEOUT
    
    commit ac2c996675755c725a0065dbe3e2ebffded9080b upstream.
    
    [WHY]
    A situation has occurred where udl_handle_damage() executed successfully
    and the kernel log appears normal, but the display fails to show any output.
    This is because the call to udl_get_urb() in udl_crtc_helper_atomic_enable()
    failed without generating any error message.
    
    [HOW]
    1. Increase timeout of getting urb.
    2. Add error messages when calling udl_get_urb() failed in
    udl_crtc_helper_atomic_enable().
    
    Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)")
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: <stable@vger.kernel.org> # v3.4+
    Link: https://patch.msgid.link/20260424124427.657-1-oushixiong1025@163.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/v3d: Reject empty multisync extension to prevent infinite loop [+ + +]
Author: Ashutosh Desai <ashutoshdesai993@gmail.com>
Date:   Wed Apr 15 05:00:00 2026 +0000

    drm/v3d: Reject empty multisync extension to prevent infinite loop
    
    commit fb44d589bf3148e13452185a6e772a7efbf2d684 upstream.
    
    v3d_get_extensions() walks a userspace-provided singly-linked list of
    ioctl extensions without any bound on the chain length. A local user
    can craft a self-referential extension (ext->next == &ext) with zero
    in_sync_count and out_sync_count, which bypasses the existing duplicate-
    extension guard:
    
        if (se->in_sync_count || se->out_sync_count)
                return -EINVAL;
    
    The guard never fires because v3d_get_multisync_post_deps() returns
    immediately when count is zero, leaving both fields at zero on every
    iteration. The result is an infinite loop in kernel context, blocking
    the calling thread and pegging a CPU core indefinitely.
    
    Fix this by rejecting a multisync extension where both in_sync_count
    and out_sync_count are zero in v3d_get_multisync_submit_deps(). An
    empty multisync carries no synchronization information and serves no
    useful purpose, so returning -EINVAL for such an extension is the
    correct defense against this attack vector.
    
    Fixes: e4165ae8304e ("drm/v3d: add multiple syncobjs support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
    Link: https://patch.msgid.link/20260415050000.3816128-1-ashutoshdesai993@gmail.com
    Signed-off-by: Maíra Canal <mcanal@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/xe/bo: Fix bo leak on GGTT flag validation in xe_bo_init_locked() [+ + +]
Author: Shuicheng Lin <shuicheng.lin@intel.com>
Date:   Wed Apr 8 17:52:53 2026 +0000

    drm/xe/bo: Fix bo leak on GGTT flag validation in xe_bo_init_locked()
    
    commit 1d0adf2fd94fb0c0037c643fadd8f2cf3cffc009 upstream.
    
    When XE_BO_FLAG_GGTT_ALL is set without XE_BO_FLAG_GGTT, the function
    returns an error without freeing a caller-provided bo, violating the
    documented contract that bo is freed on failure.
    
    Add xe_bo_free(bo) before returning the error.
    
    Fixes: 5a3b0df25d6a ("drm/xe: Allow bo mapping on multiple ggtts")
    Cc: stable@vger.kernel.org
    Assisted-by: Claude:claude-opus-4.6
    Reviewed-by: Matthew Brost <matthew.brost@intel.com>
    Link: https://patch.msgid.link/20260408175255.3402838-3-shuicheng.lin@intel.com
    Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
    (cherry picked from commit 3fbd6cf43cac7b60757f3ce3d95195d3843a902c)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/xe/bo: Fix bo leak on unaligned size validation in xe_bo_init_locked() [+ + +]
Author: Shuicheng Lin <shuicheng.lin@intel.com>
Date:   Wed Apr 8 17:52:52 2026 +0000

    drm/xe/bo: Fix bo leak on unaligned size validation in xe_bo_init_locked()
    
    commit 09a8f3c1c11977a6e10c167f26dd298790b31c32 upstream.
    
    When type is ttm_bo_type_device and aligned_size != size, the function
    returns an error without freeing a caller-provided bo, violating the
    documented contract that bo is freed on failure.
    
    Add xe_bo_free(bo) before returning the error.
    
    Fixes: 4e03b584143e ("drm/xe/uapi: Reject bo creation of unaligned size")
    Cc: stable@vger.kernel.org
    Assisted-by: Claude:claude-opus-4.6
    Reviewed-by: Matthew Brost <matthew.brost@intel.com>
    Link: https://patch.msgid.link/20260408175255.3402838-2-shuicheng.lin@intel.com
    Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
    (cherry picked from commit 601c2aa087b6f21014300a3f107a08ee4dde7bdf)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status() [+ + +]
Author: Gustavo Sousa <gustavo.sousa@intel.com>
Date:   Thu Apr 16 15:17:19 2026 -0300

    drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()
    
    commit 60a1e131a811b68703da58fd805ab359b704ab03 upstream.
    
    When media GT is disabled via configfs, there is no allocation for
    media_gt, which is kept as NULL.  In such scenario,
    intel_hdcp_gsc_check_status() results in a kernel pagefault error due to
    >->uc.gsc being evaluated as an invalid memory address.
    
    Fix that by introducing a NULL check on media_gt and bailing out early
    if so.
    
    While at it, also drop the NULL check for gsc, since it can't be NULL if
    media_gt is not NULL.
    
    v2:
      - Get address for gsc only after checking that gt is not NULL.
        (Shuicheng)
      - Drop the NULL check for gsc. (Shuicheng)
    v3:
      - Add "Fixes" and "Cc: <stable...>" tags. (Matt)
    
    Fixes: 4af50beb4e0f ("drm/xe: Use gsc_proxy_init_done to check proxy status")
    Cc: <stable@vger.kernel.org> # v6.10+
    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
    Link: https://patch.msgid.link/20260416-check-for-null-media_gt-in-intel_hdcp_gsc_check_status-v2-1-9adb9fd3b621@intel.com
    Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
    (cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise [+ + +]
Author: Jia Yao <jia.yao@intel.com>
Date:   Fri Apr 17 05:59:16 2026 +0000

    drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise
    
    commit 4e5591c2fc1b30f4ea5e2eab4c3a695acc404e39 upstream.
    
    Add validation in xe_vm_madvise_ioctl() to reject PAT indices with
    XE_COH_NONE coherency mode when applied to CPU cached memory.
    
    Using coh_none with CPU cached buffers is a security issue. When the
    kernel clears pages before reallocation, the clear operation stays in
    CPU cache (dirty). GPU with coh_none can bypass CPU caches and read
    stale sensitive data directly from DRAM, potentially leaking data from
    previously freed pages of other processes.
    
    This aligns with the existing validation in vm_bind path
    (xe_vm_bind_ioctl_validate_bo).
    
    v2(Matthew brost)
    - Add fixes
    - Move one debug print to better place
    
    v3(Matthew Auld)
    - Should be drm/xe/uapi
    - More Cc
    
    v4(Shuicheng Lin)
    - Fix kmem leak issues by the way
    
    v5
    - Remove kmem leak because it has been merged by another patch
    
    v6
    - Remove the fix which is not related to current fix
    
    v7
    - No change
    
    v8
    - Rebase
    
    v9
    - Limit the restrictions to iGPU
    
    v10
    - No change
    
    Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe")
    Cc: <stable@vger.kernel.org> # v6.18+
    Cc: Shuicheng Lin <shuicheng.lin@intel.com>
    Cc: Mathew Alwin <alwin.mathew@intel.com>
    Cc: Michal Mrozek <michal.mrozek@intel.com>
    Cc: Matthew Brost <matthew.brost@intel.com>
    Cc: Matthew Auld <matthew.auld@intel.com>
    Signed-off-by: Jia Yao <jia.yao@intel.com>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Acked-by: Michal Mrozek <michal.mrozek@intel.com>
    Acked-by: José Roberto de Souza <jose.souza@intel.com>
    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
    Link: https://patch.msgid.link/20260417055917.2027459-2-jia.yao@intel.com
    (cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure [+ + +]
Author: Shuicheng Lin <shuicheng.lin@intel.com>
Date:   Wed Apr 8 17:52:54 2026 +0000

    drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure
    
    commit 93a528f67ce5095bcab46a69839eca97f43dd352 upstream.
    
    When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo
    is not freed. Add xe_bo_free(storage) before returning the error.
    
    xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the bo on
    error. Therefore, xe_dma_buf_init_obj() must also free the bo on its own
    error paths. Otherwise, since xe_gem_prime_import() cannot distinguish
    whether the failure originated from xe_dma_buf_init_obj() or from
    xe_bo_init_locked(), it cannot safely decide whether the bo should be
    freed.
    
    Add comments documenting the ownership semantics: on success, ownership
    of storage is transferred to the returned drm_gem_object; on failure,
    storage is freed before returning.
    
    v2: Add comments to explain the free logic.
    
    Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction")
    Cc: stable@vger.kernel.org
    Assisted-by: Claude:claude-opus-4.6
    Reviewed-by: Matthew Brost <matthew.brost@intel.com>
    Link: https://patch.msgid.link/20260408175255.3402838-4-shuicheng.lin@intel.com
    Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
    (cherry picked from commit 78a6c5f899f22338bbf48b44fb8950409c5a69b9)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import() [+ + +]
Author: Shuicheng Lin <shuicheng.lin@intel.com>
Date:   Wed Apr 8 17:52:55 2026 +0000

    drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()
    
    commit 111ab678471bf1f90d078d5513bb086b70596c3c upstream.
    
    When xe_dma_buf_init_obj() fails, the attachment from
    dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before
    returning the error. Note: we cannot use goto out_err here because
    xe_dma_buf_init_obj() already frees bo on failure, and out_err would
    double-free it.
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Cc: stable@vger.kernel.org
    Assisted-by: Claude:claude-opus-4.6
    Reviewed-by: Mattheq Brost <matthew.brost@intel.com>
    Link: https://patch.msgid.link/20260408175255.3402838-5-shuicheng.lin@intel.com
    Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
    (cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm: Set old handle to NULL before prime swap in change_handle [+ + +]
Author: Francis, David <David.Francis@amd.com>
Date:   Tue Apr 28 19:25:50 2026 +0000

    drm: Set old handle to NULL before prime swap in change_handle
    
    commit 5e28b7b94408897e41c63477aabc9e1db439bc8c upstream.
    
    There was a potential race condition in change_handle. The ioctl
    briefly had a single object with two idr entries; a concurrent
    gem_close could delete the object and remove one of the handles
    while leaving the other one dangling, which could subsequently
    be dereferenced for a use-after-free.
    
    To fix this, do the same dance that gem_close itself does.
    (f6cd7daecff5 drm: Release driver references to handle before making it available again)
    First idr_replace the old handle to NULL. Later, if the prime
    operations are successful, actually close it.
    
    create_tail required a similar dance to avoid a similar problem.
    (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail())
    It idr_allocs the new handle with NULL, then swaps in the correct
    object later to avoid races. We don't need to do that here, since
    the only operations that could race are drm_prime, and
    change_handle holds the prime lock for the entire duration.
    
    v2: cleanups of error paths
    
    Signed-off-by: David Francis <David.Francis@amd.com>
    Co-authored-by: Dave Airlie <airlied@gmail.com>
    Reported-by: Puttimet Thammasaeng <pwn8official@gmail.com>
    Tested-by: Vitaly Prosyak <Vitaly.Prosyak@amd.com>
    Cc: Simona Vetter <simona@ffwll.ch>
    Cc: stable@vger.kernel.org
    Cc: Christian Koenig <Christian.Koenig@amd.com>
    Fixes: 53096728b8910 ("drm: Add DRM prime interface to reassign GEM handle")
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
EDAC/versalnet: Fix device name memory leak [+ + +]
Author: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
Date:   Thu May 14 11:08:25 2026 -0400

    EDAC/versalnet: Fix device name memory leak
    
    [ Upstream commit 8cf5dd235eff6008cb04c3d8064d2acfa90616f1 ]
    
    The device name allocated via kzalloc() in init_one_mc() is assigned to
    dev->init_name but never freed on the normal removal path.  device_register()
    copies init_name and then sets dev->init_name to NULL, so the name pointer
    becomes unreachable from the device. Thus leaking memory.
    
    Use a stack-local char array instead of using kzalloc() for name.
    
    Fixes: d5fe2fec6c40 ("EDAC: Add a driver for the AMD Versal NET DDR controller")
    Signed-off-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20260401111856.2342975-1-ptsm@linux.microsoft.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

EDAC/versalnet: Refactor memory controller initialization and cleanup [+ + +]
Author: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Date:   Thu May 14 11:08:24 2026 -0400

    EDAC/versalnet: Refactor memory controller initialization and cleanup
    
    [ Upstream commit 62a9fc50e8d947601ea3484e732b1a65a0a54b96 ]
    
    Simplify the initialization and cleanup flow for Versal Net DDRMC
    controllers in the EDAC driver by carving out the single controller init
    into a separate function which allows for a much better and more
    readable error handling and unwinding.
    
      [ bp:
            - do the kzalloc allocations first
            - "publish" the structures only after they've been initialized
              properly so that you don't need to unwind unnecessarily when
              it fails later
            - remove_versalnet() is now trivial
       ]
    
    Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://patch.msgid.link/20251104093932.3838876-1-shubhrajyoti.datta@amd.com
    Stable-dep-of: 8cf5dd235eff ("EDAC/versalnet: Fix device name memory leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: appletb-kbd: fix UAF in inactivity-timer cleanup path [+ + +]
Author: Sangyun Kim <sangyun.kim@snu.ac.kr>
Date:   Mon Apr 20 14:13:17 2026 +0900

    HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
    
    commit 4db2af929279c799b5653a39eb0795c72baffca4 upstream.
    
    Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in
    appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to
    both the probe close_hw error path and appletb_kbd_remove(), but the
    way it was wired in left the inactivity timer reachable during driver
    tear-down via two distinct windows.
    
    Window A -- put_device() before timer_delete_sync():
    
            put_device(&kbd->backlight_dev->dev);
            timer_delete_sync(&kbd->inactivity_timer);
    
    The inactivity_timer softirq reads kbd->backlight_dev and calls
    backlight_device_set_brightness() -> mutex_lock(&ops_lock).  If a
    concurrent hid_appletb_bl unbind drops the last devm reference
    between these two calls, the backlight_device is freed and the
    mutex_lock() touches freed memory.
    
    Window B -- backlight cleanup before hid_hw_stop():
    
            if (kbd->backlight_dev) {
                    timer_delete_sync(...);
                    put_device(...);
            }
            hid_hw_close(hdev);
            hid_hw_stop(hdev);
    
    Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run
    afterwards, so a late ".event" callback from the HID core (USB URB
    completion on real Apple hardware) can arrive after
    timer_delete_sync() drained the softirq but before put_device() drops
    the reference.  That callback reaches reset_inactivity_timer(), which
    calls mod_timer() and re-arms the timer.  The freshly re-armed timer
    can then fire on the about-to-be-freed backlight_device.
    
    Both windows produce the same KASAN slab-use-after-free:
    
      BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0
      Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0
      Call Trace:
       <IRQ>
       __mutex_lock
       backlight_device_set_brightness
       appletb_inactivity_timer
       call_timer_fn
       run_timer_softirq
       handle_softirqs
      Allocated by task N:
       devm_backlight_device_register
       appletb_bl_probe
      Freed by task M:
       (concurrent hid_appletb_bl unbind path)
    
    Close both windows at once by reworking the tear-down in
    appletb_kbd_remove() and in the probe close_hw error path so that
    
     1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup,
        guaranteeing no further .event callback can fire and re-arm the
        timer, and
     2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync()
        runs before put_device(), so the softirq is drained before the
        final reference is dropped.
    
    Fixes: 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: appletb-kbd: run inactivity autodim from workqueues [+ + +]
Author: Sangyun Kim <sangyun.kim@snu.ac.kr>
Date:   Mon Apr 20 14:13:18 2026 +0900

    HID: appletb-kbd: run inactivity autodim from workqueues
    
    commit 1654e53349d4e657b331de354313461f401f5063 upstream.
    
    The autodim code in hid-appletb-kbd takes backlight_device->ops_lock
    via backlight_device_set_brightness() -> mutex_lock() from two
    different atomic contexts:
    
     * appletb_inactivity_timer() is a struct timer_list callback, so it
       runs in softirq context.  Every expiry triggers
    
         BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
         Call Trace:
          <IRQ>
          __might_resched
          __mutex_lock
          backlight_device_set_brightness
          appletb_inactivity_timer
          call_timer_fn
          run_timer_softirq
    
     * reset_inactivity_timer() is called from appletb_kbd_hid_event() and
       appletb_kbd_inp_event().  On real USB hardware these run in
       softirq/IRQ context (URB completion and input-event dispatch).
       When the Touch Bar has already been dimmed or turned off, the
       reset path calls backlight_device_set_brightness() directly to
       restore brightness, producing the same warning.
    
    Both call sites hit the same mutex_lock()-from-atomic bug.  Fix them
    together by moving the blocking work onto the system workqueue:
    
     * Convert the inactivity timer from struct timer_list to
       struct delayed_work; the callback (appletb_inactivity_work) now
       runs in process context where mutex_lock() is legal.
     * Add a dedicated struct work_struct restore_brightness_work and have
       reset_inactivity_timer() schedule it instead of calling
       backlight_device_set_brightness() directly.
    
    Cancel both works synchronously during driver tear-down alongside the
    existing backlight reference drop.
    
    The semantics are unchanged (same delays, same state transitions on
    dim, turn-off and user activity); only the execution context of the
    sleeping call changes.  The timer field and callback are renamed to
    match their new type; reset_inactivity_timer() keeps its name because
    it is invoked from input event paths that read naturally as "reset
    the inactivity timer".
    
    Fixes: 93a0fc489481 ("HID: hid-appletb-kbd: add support for automatic brightness control while using the touchbar")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: pidff: Fix integer overflow in pidff_rescale [+ + +]
Author: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
Date:   Sun May 10 14:23:52 2026 +0200

    HID: pidff: Fix integer overflow in pidff_rescale
    
    commit 48d1677779ad6816978ad4a4f7588aec5ec960fe upstream.
    
    Rescaling values close to the max (U16_MAX) temporarily creates values
    that exceed the s32 range. This caused value overflow in case when, for
    example, a periodic effect phase was higer than 180 degrees. In turn,
    rescale function could return values outised of the logical range of the
    HID field.
    
    Fix by using 64 bit signed integer to store the value during calculation
    but still return only 32 bit integer.
    
    Closes: https://github.com/JacKeTUs/universal-pidff/issues/116
    Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: playstation: Clamp num_touch_reports [+ + +]
Author: T.J. Mercier <tjmercier@google.com>
Date:   Fri Apr 17 08:47:02 2026 -0700

    HID: playstation: Clamp num_touch_reports
    
    commit cac61b58a3b6340c52afa06bb15eac033158db2f upstream.
    
    A device would never lie about the number of touch reports would it?
    
    If it does the loop in dualshock4_parse_report will read off the end of
    the touch_reports array, up to about 2 KiB for the maximum number of 256
    loop iteraions. The data that is read is emitted via evdev if the
    DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by
    clamping the num_touch_reports value provided by the device to the
    maximum size of the touch_reports array.
    
    Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.")
    Cc: stable@vger.kernel.org
    Reported-by: Xingyu Jin <xingyuj@google.com>
    Signed-off-by: T.J. Mercier <tjmercier@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
io_uring/zcrx: use guards for locking [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Mar 23 12:43:57 2026 +0000

    io_uring/zcrx: use guards for locking
    
    commit 898ad80d1207cbdb22b21bafb6de4adfd7627bd0 upstream.
    
    Convert last several places using manual locking to guards to simplify
    the code.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://patch.msgid.link/eb4667cfaf88c559700f6399da9e434889f5b04a.1774261953.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring/zcrx: warn on freelist violations [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Tue Apr 21 09:45:29 2026 +0100

    io_uring/zcrx: warn on freelist violations
    
    commit 770594e78c3964cf23cf5287f849437cdde9b7d0 upstream.
    
    The freelist is appropriately sized to always be able to take a free
    niov, but let's be more defensive and check the invariant with a
    warning. That should help to catch any double-free issues.
    
    Suggested-by: Kai Aizen <kai@snailsploit.com>
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://patch.msgid.link/2f3cea363b04649755e3b6bb9ab66485a95936d5.1776760901.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kho: fix error handling in kho_add_subtree() [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Thu May 14 15:25:53 2026 -0400

    kho: fix error handling in kho_add_subtree()
    
    [ Upstream commit 9ec95329894864170a1a7685b9a11b739393131a ]
    
    Fix two error handling issues in kho_add_subtree(), where it doesn't
    handle the error path correctly.
    
    1. If fdt_setprop() fails after the subnode has been created, the
       subnode is not removed. This leaves an incomplete node in the FDT
       (missing "preserved-data" or "blob-size" properties).
    
    2. The fdt_setprop() return value (an FDT error code) is stored
       directly in err and returned to the caller, which expects -errno.
    
    Fix both by storing fdt_setprop() results in fdt_err, jumping to a new
    out_del_node label that removes the subnode on failure, and only setting
    err = 0 on the success path, otherwise returning -ENOMEM (instead of
    FDT_ERR_ errors that would come from fdt_setprop).
    
    No user-visible changes.  This patch fixes error handling in the KHO
    (Kexec HandOver) subsystem, which is used to preserve data across kexec
    reboots.  The fix only affects a rare failure path during kexec
    preparation — specifically when the kernel runs out of space in the
    Flattened Device Tree buffer while registering preserved memory regions.
    
    In the unlikely event that this error path was triggered, the old code
    would leave a malformed node in the device tree and return an incorrect
    error code to the calling subsystem, which could lead to confusing log
    messages or incorrect recovery decisions.  With this fix, the incomplete
    node is properly cleaned up and the appropriate errno value is propagated,
    this error code is not returned to the user.
    
    Link: https://lore.kernel.org/20260410-kho_fix_send-v2-1-1b4debf7ee08@debian.org
    Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Suggested-by: Pratyush Yadav <pratyush@kernel.org>
    Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
    Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
    Cc: Alexander Graf <graf@amazon.com>
    Cc: Breno Leitao <leitao@debian.org>
    Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 7.0.9 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun May 17 17:16:34 2026 +0200

    Linux 7.0.9
    
    Link: https://lore.kernel.org/r/20260515154658.538039039@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Pavel Machek (CIP) <pavel@nabladev.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Brett A C Sheffield <bacs@librecast.net>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Barry K. Nathan <barryn@pobox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: chips-media: wave5: add missing spinlock protection for handle_dynamic_resolution_change() [+ + +]
Author: Ziyi Guo <n7l8m4@u.northwestern.edu>
Date:   Sat Jan 31 22:19:07 2026 +0000

    media: chips-media: wave5: add missing spinlock protection for handle_dynamic_resolution_change()
    
    commit cb8bdd3ffca280d014311ab395651d33f58a8708 upstream.
    
    Add spin_lock_irqsave()/spin_unlock_irqrestore() around the
    handle_dynamic_resolution_change() call in initialize_sequence() to fix
    the missing lock protection.
    
    initialize_sequence() calls handle_dynamic_resolution_change() without
    holding inst->state_spinlock. However, handle_dynamic_resolution_change()
    has lockdep_assert_held(&inst->state_spinlock) indicating that callers
    must hold this lock.
    
    Other callers of handle_dynamic_resolution_change() properly acquire the
    spinlock:
    - wave5_vpu_dec_finish_decode()
    - wave5_vpu_dec_device_run()
    
    Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Fixes: 9707a6254a8a6b ("media: chips-media: wave5: Add the v4l2 layer")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: chips-media: wave5: add missing spinlock protection for send_eos_event() [+ + +]
Author: Ziyi Guo <n7l8m4@u.northwestern.edu>
Date:   Sat Jan 31 22:03:23 2026 +0000

    media: chips-media: wave5: add missing spinlock protection for send_eos_event()
    
    commit f48050436746be75227fbc90066a8658cbe94d17 upstream.
    
    Add spin_lock_irqsave()/spin_unlock_irqrestore() around send_eos_event()
    calls in the VB2 buffer queue and streamoff callbacks to fix the missing
    lock protection.
    
    wave5_vpu_dec_buf_queue_dst() and streamoff_output() call send_eos_event()
    without holding inst->state_spinlock. However, send_eos_event() has
    lockdep_assert_held(&inst->state_spinlock) indicating that callers must
    hold this lock.
    
    Other callers of send_eos_event() properly acquire the spinlock:
    - wave5_vpu_dec_finish_decode() acquires lock at line 431
    - wave5_vpu_dec_encoder_cmd() acquires lock at line 821
    - wave5_vpu_dec_device_run() acquires lock at line 1592
    
    Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Fixes: 9707a6254a8a6b ("media: chips-media: wave5: Add the v4l2 layer")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: chips-media: wave5: fix a potential memory leak in wave5_vdi_init() [+ + +]
Author: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Date:   Sun Jan 25 22:19:15 2026 +0800

    media: chips-media: wave5: fix a potential memory leak in wave5_vdi_init()
    
    commit 95bd174a453f77b09ea66e1e22834680754ba501 upstream.
    
    Add wave5_vdi_free_dma_memory() in the error path of
    wave5_vdi_init() to prevent a potential memory leak.
    
    Fixes: 45d1a2b93277 ("media: chips-media: wave5: Add vpuapi layer")
    Cc: stable@vger.kernel.org
    Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dib8000: avoid division by 0 in dib8000_set_dds() [+ + +]
Author: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Date:   Fri Feb 6 17:22:26 2026 +0300

    media: dib8000: avoid division by 0 in dib8000_set_dds()
    
    commit dde3c37af95cd6fa301c4906f33d627bc9dd874c upstream.
    
    In dib8000_set_dds(), 1 << 26 (67108864) divided by e.g. 1 apparently can't
    fit into 16-bit variable unit_khz_dds_val, being truncated to 0; this will
    cause division by 0 while calling dprintk() with debugging enabled (via the
    module parameter).  Use s32 instead of s16 to declare the variable, getting
    rid of the cast to u16 in the *else* branch as well...
    
    Found by Linux Verification Center (linuxtesting.org) with the Svace static
    analysis tool.
    
    Fixes: 173a64cb3fcf ("[media] dib8000: enhancement")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88} [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Wed Mar 4 23:00:41 2026 +0200

    media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}
    
    commit 35c8178ed2bd9821a75a406d762b2f2e161f9c70 upstream.
    
    With the introduction of the RK3588 SoC, and RK3576 afterwards, three
    register blocks have been provided for the video decoder unit instead of
    just one, which are further referenced in vendor's datasheet by 'link
    table', 'function' and 'cache'.  The former is present at the top of the
    listing, starting at video decoder unit base address.
    
    However, while documenting RK3588, the binding broke the convention
    expecting the unit address to indicate the start of the primary register
    range, i.e. the 'function' block got listed before the 'link' one.
    
    Since the binding changes have been already released and a fix would
    bring up an ABI break, mark the current 'reg-names' ordering as
    deprecated and introduce an alternative 'link,function,cache' listing
    which follows the address-based ordering according to the TRM.
    
    Additionally, drop the 'reg' description items as the order is not fixed
    anymore, while the information they offer is not very relevant anyway.
    
    It's worth noting there are currently no (known) users impacted by these
    binding changes, since the video decoder support for the aforementioned
    SoCs in mainline driver and devicetrees hasn't been released yet - it
    landed in v7.0-rc1 while all DTS updates resulting from this will be
    handled before v7.0 is out.
    
    Fixes: c6ffb7e1fb90 ("media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings")
    Fixes: a5c4a6526476 ("media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings")
    Cc: stable@vger.kernel.org
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88} [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Wed Mar 4 23:00:40 2026 +0200

    media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}
    
    commit a11db8d8b403eba1f82728f440727128e9997edd upstream.
    
    The Rockchip Video Decoder driver expects reg-names to be mandatory for
    RK3576 and RK3588 SoCs, however the binding does not currently require
    the use of them.
    
    As a consequence, driver would fail to probe with a hypothetical
    devicetree that doesn't provide the reg-names for these SoCs, but which
    is otherwise a perfectly valid DT from the binding perspective.
    
    Update the binding and make reg-names required for the aforementioned
    SoCs.  While this change introduces an ABI break, the expected impact on
    potential users would be minimal, if any, since the old SoCs are
    unaffected, while the video decoder support for these newer variants in
    mainline driver and devicetrees hasn't been released yet.
    
    Moreover, this is also a prerequisite for a subsequent binding update
    introducing an alternative reg-names order, according to the
    address-based listing in the vendor's datasheet.
    
    Reported-by: Conor Dooley <conor@kernel.org>
    Closes: https://lore.kernel.org/all/20260227-urologist-gratitude-7984733f2d41@spud/
    Fixes: c6ffb7e1fb90 ("media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings")
    Fixes: a5c4a6526476 ("media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings")
    Cc: stable@vger.kernel.org
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: imx283: Enter full standby when stopping streaming [+ + +]
Author: Jai Luthra <jai.luthra@ideasonboard.com>
Date:   Sat Feb 14 18:35:21 2026 +0530

    media: i2c: imx283: Enter full standby when stopping streaming
    
    commit bce1349dbf6348ddee47308e2ed08878356de317 upstream.
    
    Use IMX283_STANDBY (bit 0) instead of IMX283_STBLOGIC (bit 1) when
    stopping streaming. STBLOGIC only puts the sensor logic into standby but
    leaves the MIPI interface (along with other components) in an
    indeterminate state.
    
    This (presumably) causes the CSI receiver (e.g. Raspberry Pi's CFE) to
    miss the LP-11 to HS transition when streaming restarts, resulting in a
    hang of 10+ seconds. The issue is most visible when immediately
    restarting a full-resolution stream after stopping a 3x3 binned one, so
    that runtime suspend hasn't yet been triggered.
    
    Writing IMX283_STANDBY puts the entire sensor into standby. The
    imx283_standby_cancel() sequence already handles the full wakeup from
    this suspended state.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/raspberrypi/linux/issues/7153
    Link: https://github.com/will127534/OneInchEye/issues/12
    Fixes: ccb4eb4496fa ("media: i2c: Add imx283 camera sensor driver")
    Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
    Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: imx283: Fix hang when going from large to small resolution [+ + +]
Author: Jai Luthra <jai.luthra@ideasonboard.com>
Date:   Sat Feb 14 18:35:22 2026 +0530

    media: i2c: imx283: Fix hang when going from large to small resolution
    
    commit 9206359b2c396ff594adf39bc7daaadab0fcb367 upstream.
    
    When switching between modes (e.g. full resolution to binned),
    standby_cancel() previously cleared XMSTA (starting master mode data
    output) before the new mode's MDSEL, crop, and timing registers were
    programmed in start_streaming(). This caused the sensor to briefly
    output MIPI data using the previous mode's configuration.
    
    On receivers like imx-mipi-csis, this leads to FIFO overflow errors
    when switching from a higher to a lower resolution, as the receiver is
    configured for the new smaller frame size but receives stale
    full-resolution data.
    
    Fix this by moving the XMSTA and SYNCDRV register writes from
    standby_cancel() to the end of start_streaming(), after all mode,
    crop, and timing registers have been configured. Also explicitly stop
    master mode (XMSTA=1) when stopping the stream, matching the pattern
    used by other Sony sensor drivers (imx290, imx415).
    
    Use named macros IMX283_XMSTA_START/STOP instead of raw 0/BIT(0) for
    readability.
    
    Cc: stable@vger.kernel.org
    Fixes: ccb4eb4496fa ("media: i2c: Add imx283 camera sensor driver")
    Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
    Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: imx412: Assert reset GPIO during probe [+ + +]
Author: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Date:   Fri Jan 23 17:19:55 2026 +0800

    media: i2c: imx412: Assert reset GPIO during probe
    
    commit 8467c5ff5acae28513bc1e0af535e06b41b04344 upstream.
    
    Assert the reset GPIO before first power up. This avoids a mismatch where
    the first power up (when the reset GPIO defaults deasserted) differs from
    subsequent cycles.
    
    Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
    Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: ov08d10: fix image vertical start setting [+ + +]
Author: Matthias Fend <matthias.fend@emfend.at>
Date:   Tue Mar 24 11:41:36 2026 +0100

    media: i2c: ov08d10: fix image vertical start setting
    
    commit 5d150fa0f16096d736bd24d13e04495da5116fab upstream.
    
    The current settings for the "image vertical start" register appear to be
    incorrect. While this only results in an incorrect start line for native
    modes, this faulty setting causes actual problems in binning mode. At least
    on an i.MX8MP test system, only corrupted frames could be received.
    To correct this, the recommended settings from the reference register sets
    are used for all modes. Since this shifts the start by one line, the Bayer
    pattern also changes, which has also been corrected.
    
    Fixes: 7be91e02ed57 ("media: i2c: Add ov08d10 camera sensor driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: ov08d10: fix runtime PM handling in probe [+ + +]
Author: Matthias Fend <matthias.fend@emfend.at>
Date:   Tue Mar 24 11:41:35 2026 +0100

    media: i2c: ov08d10: fix runtime PM handling in probe
    
    commit 35c7046be2be5e60be8128facb359a47f39e99cd upstream.
    
    Set the device's runtime PM status and enable runtime PM before registering
    the async sub-device. This is needed to avoid the case where the device is
    runtime PM resumed while runtime PM has not been enabled yet.
    
    Remove the related, non-driver-specific comment while at it.
    
    Fixes: 7be91e02ed57 ("media: i2c: Add ov08d10 camera sensor driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: ov5647: Fix runtime PM refcount leak in s_ctrl [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Wed Feb 25 16:56:21 2026 +0800

    media: i2c: ov5647: Fix runtime PM refcount leak in s_ctrl
    
    commit f11ae9c04f8368a3b5a0280ef595198dace1c983 upstream.
    
    Three control cases (AUTOGAIN, EXPOSURE_AUTO, ANALOGUE_GAIN) directly
    return without calling pm_runtime_put(), causing runtime PM reference
    count leaks.
    
    Change these cases from 'return' to 'ret = ... break' pattern to ensure
    pm_runtime_put() is always called before function exit.
    
    Fixes: 4f66f36388d5 ("media: i2c: ov5647: Convert to CCI register access helpers")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io>
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: ov8856: free control handler on error in ov8856_init_controls() [+ + +]
Author: Alexander Koskovich <akoskovich@pm.me>
Date:   Thu Mar 12 17:16:20 2026 +0000

    media: i2c: ov8856: free control handler on error in ov8856_init_controls()
    
    commit f75e160745663ce9b13362ae6e90bd439c58df69 upstream.
    
    The control handler wasn't freed if adding controls failed, add an error
    exit label and convert the existing error return to use it.
    
    Fixes: 879347f0c258 ("media: ov8856: Add support for OV8856 sensor")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: intel/ipu6: fix error pointer dereference [+ + +]
Author: Ethan Tidmore <ethantidmore06@gmail.com>
Date:   Fri Mar 6 21:03:55 2026 -0600

    media: intel/ipu6: fix error pointer dereference
    
    commit 8dd088b8b106f7b119664f965b691785998edcfb upstream.
    
    In a error path isp->psys is confirmed to be an error pointer not NULL so
    this condition is true and the error pointer is dereferenced. So isp-psys
    should be set to NULL before going to out_ipu6_bus_del_devices.
    
    Detected by Smatch:
    drivers/media/pci/intel/ipu6/ipu6.c:690 ipu6_pci_probe() error:
    'isp->psys' dereferencing possible ERR_PTR()
    
    Fixes: 25fedc021985a ("media: intel/ipu6: add Intel IPU6 PCI device driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
    [Sakari Ailus: Fix commit message.]
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: ipu-bridge: Add upside-down sensor DMI quirk for Dell XPS 13 9340 and XPS 14 9440 [+ + +]
Author: Hans de Goede <johannes.goede@oss.qualcomm.com>
Date:   Wed Feb 25 21:30:54 2026 +0100

    media: ipu-bridge: Add upside-down sensor DMI quirk for Dell XPS 13 9340 and XPS 14 9440
    
    commit 2c10400e4a233200046d023ab2377bc56fd48dea upstream.
    
    The Dell XPS 13 9340 and XPS 14 9440 have an upside-down mounted OV02C10
    sensor, just like the XPS 13 9350 and XPS 16 9640 models.
    
    Extend the existing DMI matches for handling these laptops with DMI
    matches for these 2 models
    
    Reported-by: Heimir Thor Sverrisson <heimir.sverrisson@gmail.com> # XPS 14 9440
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2440581 # XPS 13 9340
    Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: iris: Fix dma_free_attrs() size in iris_hfi_queues_init() [+ + +]
Author: Thomas Fourier <fourier.thomas@gmail.com>
Date:   Fri Feb 13 10:13:27 2026 +0100

    media: iris: Fix dma_free_attrs() size in iris_hfi_queues_init()
    
    commit 4a49ae56b0e4268d48fd96babe0cc68596bc301a upstream.
    
    The core->iface_q_table_vaddr buffer is alloc'd with size queue_size
    but freed with sizeof(*q_tbl_hdr) which is different.
    
    Change the dma_free_attrs() size.
    
    Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
    Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Fixes: d7378f84e94e ("media: iris: introduce iris core state management with shared queues")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: iris: fix QCOM_MDT_LOADER dependency [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Feb 5 15:56:19 2026 +0100

    media: iris: fix QCOM_MDT_LOADER dependency
    
    commit a297c5165f91366cbc3490e630aabd1c0f70efb8 upstream.
    
    When build-testined with CONFIG_QCOM_MDT_LOADER=m and VIDEO_QCOM_IRIS=y,
    the kernel fails to link:
    
    x86_64-linux-ld: drivers/media/platform/qcom/iris/iris_firmware.o: in function `iris_fw_load':
    iris_firmware.c:(.text+0xb0): undefined reference to `qcom_mdt_get_size'
    iris_firmware.c:(.text+0xfd): undefined reference to `qcom_mdt_load'
    
    The problem is the conditional 'select' statement. Change this to
    make the driver built-in here regardless of CONFIG_ARCH_QCOM.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Fixes: d19b163356b8 ("media: iris: implement video firmware load/unload")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: iris: Fix use-after-free in iris_release_internal_buffers() [+ + +]
Author: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Date:   Mon Feb 16 12:37:42 2026 +0530

    media: iris: Fix use-after-free in iris_release_internal_buffers()
    
    commit f27cfdcfc916bb59297825805f4c3499f89f9e76 upstream.
    
    The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy
    internal buffers after FW releases") introduced a regression where
    session_release_buf() may free the buffer. The caller,
    iris_release_internal_buffers(), continued to access `buffer` after the
    call, leading to a potential use-after-free.
    
    Fix this by setting BUF_ATTR_PENDING_RELEASE before calling
    session_release_buf(), and reverting the flag if the call fails. This
    ensures no dereference occurs after potential freeing.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Closes: https://lore.kernel.org/lkml/aYXvKAX3Pg3sL37P@stanley.mountain/#r
    Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
    Fixes: 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: iris: fix use-after-free of fmt_src during MBPF check [+ + +]
Author: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Date:   Thu Mar 5 18:58:31 2026 +0530

    media: iris: fix use-after-free of fmt_src during MBPF check
    
    commit 3d9593ad1a58c5acc3e5fa2a48222bb7632e6812 upstream.
    
    During concurrency testing, multiple instances can run in parallel, and
    each instance uses its own inst->lock while the core->lock protects the
    list of active instances. The race happens because these locks cover
    different scopes, inst->lock protects only the internals of a single
    instance, while the Macro Blocks Per Frame (MBPF) checker walks the
    core list under core->lock and reads fields like fmt_src->width and
    fmt_src->height. At the same time, iris_close() may free fmt_src and
    fmt_dst under inst->lock while the instance is still present in the core
    list. This allows a situation where the MBPF checker, still iterating
    through the core list, reaches an instance whose fmt_src was already
    freed by another thread and ends up dereferencing a dangling pointer,
    resulting in a use-after-free. This happens because the MBPF checker
    assumes that any instance in the core list is fully valid, but the
    freeing of fmt_src and fmt_dst without removing the instance from the
    core list is not correct.
    
    The correct ordering is to defer freeing fmt_src and fmt_dst until after
    the instance has been removed from the core list and all teardown under
    the core lock has completed, ensuring that no dangling pointers are ever
    exposed during MBPF checks.
    
    Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
    Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
    Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Fixes: 5ad964ad5656 ("media: iris: Initialize and deinitialize encoder instance structure")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: iris: switch to hardware mode after firmware boot [+ + +]
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Date:   Fri Mar 13 18:49:36 2026 +0530

    media: iris: switch to hardware mode after firmware boot
    
    commit 95a337f92f0a602d4f935315bfbc8bf07f475e65 upstream.
    
    Currently the driver switches the vcodec GDSC to hardware (HW) mode
    before firmware load and boot sequence. GDSC can be powered off, keeping
    in hw mode, thereby the vcodec registers programmed in TrustZone (TZ)
    carry default (reset) values.
    Move the transition to HW mode after firmware load and boot sequence.
    
    The bug was exposed with driver configuring different stream ids to
    different devices via iommu-map. With registers carrying reset values,
    VPU would not generate desired stream-id, thereby leading to SMMU fault.
    
    For vpu4, when GDSC is switched to HW mode, there is a need to perform
    the reset operation. Without reset, there are occasional issues of
    register corruption observed. Hence the vpu GDSC switch also involves
    the reset.
    
    Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
    Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
    Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
    Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    [bod: occassional => occasional]
    Fixes: dde659d37036 ("media: iris: Introduce vpu ops for vpu4 with necessary hooks")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: mali-c55: Fix Iridix bypass macros [+ + +]
Author: Daniel Scally <dan.scally@ideasonboard.com>
Date:   Thu Feb 12 11:03:09 2026 +0000

    media: mali-c55: Fix Iridix bypass macros
    
    commit db7faf488ecf846c46884310ff1bf28daf2ad39a upstream.
    
    The Mali C55 Iridix block has a digital gain function and tone mapping
    function, whose enablement is controlled by two different bits
    in the BYPASS_3 register.
    
    Unfortunately, the "Gain" and "Tonemap" bypass bit definitions are the
    wrong way around. Swap them.
    
    Cc: stable@vger.kernel.org
    Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver")
    Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
    Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
    Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: mali-c55: Fully reset the ISP configuration [+ + +]
Author: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Date:   Mon Jan 19 12:50:26 2026 +0100

    media: mali-c55: Fully reset the ISP configuration
    
    commit 26ad493bea57efdccc32ffedbf731da2b7463b6c upstream.
    
    The Mali C55 driver uses an auto-suspend delay of 2000 milli-seconds.
    
    As the delay is quite large, it is certainly possible that two
    consecutive calls to enable_streams() do not go through a suspend of the
    peripheral, meaning we cannot rely on POW register values for the ISP
    configuration.
    
    To prevent a streaming session to be initialized with settings from the
    previous one, reset the full ISP configuration to know state disabling or
    bypassing all the ISP blocks the driver supports.
    
    Cc: stable@vger.kernel.org
    Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: mali-c55: Initialize the ISP in enable_streams() [+ + +]
Author: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Date:   Mon Jan 19 12:20:56 2026 +0100

    media: mali-c55: Initialize the ISP in enable_streams()
    
    commit d5c24b71da547fdb5bea51a69d62f9e2a609431d upstream.
    
    The Mali C55 driver initializes the ISP in two points:
    
    1) At probe time it disables ISP blocks by configuring them in bypass
       mode
    2) At enable_streams() it initializes the crop rectangles and the image
       processing pipeline using the current image format
    
    However, as ISP blocks are configured by userspace, if their
    configuration is not reset, from the second enable_streams() call
    onwards the ISP configuration will depend on the previous streaming
    session configuration.
    
    To re-initialize the ISP completely at enable_streams() time consolidate
    the ISP block bypass configuration and the image processing path
    configuration in a single function to be called at enabled_streams()
    time.
    
    Cc: stable@vger.kernel.org
    Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: nxp: imx8-isi: Reduce minimum queued buffers from 2 to 0 [+ + +]
Author: Guoniu Zhou <guoniu.zhou@nxp.com>
Date:   Thu Mar 12 11:12:34 2026 +0800

    media: nxp: imx8-isi: Reduce minimum queued buffers from 2 to 0
    
    commit 2f38622d0f85f317be9e6b131da6cd511db94fd2 upstream.
    
    Fix a hang issue when capturing a single frame with applications like cam
    in libcamera. It would hang waiting for the driver to complete the buffer,
    but streaming never starts because min_queued_buffers was set to 2.
    
    The ISI module uses a ping-pong buffer mechanism that requires two buffers
    to be programmed at all times. However, when fewer than 2 user buffers are
    available, the driver use internal discard buffers to fill the remaining
    slot(s). Reduce minimum queued buffers from 2 to 0 allows streaming to
    start without any queued buffers.
    
    Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://patch.msgid.link/20260312-isi_min_buffers-v2-1-d5ea1c79ad81@nxp.com
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: omap3isp: drop the use count of v4l2 pipeline [+ + +]
Author: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Date:   Mon Jan 26 09:44:12 2026 +0800

    media: omap3isp: drop the use count of v4l2 pipeline
    
    commit 9da49bd9d4224035cff39b40d7395310abb10201 upstream.
    
    In isp_video_open(), drop the use count of v4l2
    pipeline if vb2_queue_init() fails.
    
    Fixes: 8fd390b89cc8 ("media: Split v4l2_pipeline_pm_use into v4l2_pipeline_pm_{get, put}")
    Cc: stable@vger.kernel.org
    Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: pci: zoran: fix potential memory leak in zoran_probe() [+ + +]
Author: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Date:   Thu Mar 12 18:02:56 2026 +0530

    media: pci: zoran: fix potential memory leak in zoran_probe()
    
    commit 8ea21435fe36fb853706f4935d78bc11beb63fb4 upstream.
    
    The memory allocated for codec in videocodec_attach() is not freed in
    one of the error paths, due to an incorrect goto label. Fix the label
    to free it on error.
    
    Fixes: 8f7cc5c0b0eb ("media: staging: media: zoran: introduce zoran_i2c_init")
    Cc: stable@vger.kernel.org
    Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: qcom: camss: Add missing clocks for VFE lite on sa8775p [+ + +]
Author: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Date:   Fri Mar 13 18:13:04 2026 +0800

    media: qcom: camss: Add missing clocks for VFE lite on sa8775p
    
    commit d31fac47b39f5e1ed85a587688ca70b793e421b4 upstream.
    
    Add missing required clocks (cpas_ahb and camnoc_axi) for VFE lite
    instances on sa8775p platform. These clocks are necessary for proper
    VFE lite operation:
    
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
    Fixes: e7b59e1d06fb ("media: qcom: camss: Add support for VFE 690")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: qcom: camss: Fix csid clock configuration for sa8775p [+ + +]
Author: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Date:   Fri Mar 13 18:13:03 2026 +0800

    media: qcom: camss: Fix csid clock configuration for sa8775p
    
    commit fe56c674118aa46da1a3e65aa22ca709ebd7d812 upstream.
    
    Fix the mismatch between clock list and clock rate table for CSID lite
    instances. The current implementation has 5 clocks defined but only 2
    are actually needed (vfe_lite_csid and vfe_lite_cphy_rx), while the
    clock rate table doesn't match this configuration.
    
    Update both clock list and rate table to maintain consistency:
    - Remove unused clocks: cpas_vfe_lite, vfe_lite_ahb, vfe_lite
    - Update clock rate table to match the remaining two clocks
    
    Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Fixes: ed03e99de0fa ("media: qcom: camss: Add support for CSID 690")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: qcom: camss: Fix csid IRQ offset for sa8775p [+ + +]
Author: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Date:   Fri Mar 13 18:13:02 2026 +0800

    media: qcom: camss: Fix csid IRQ offset for sa8775p
    
    commit dd1b373941079cc102cc18bc68884e18245f5912 upstream.
    
    Fix BUF_DONE_IRQ_STATUS_RDI_OFFSET calculation for csid lite on
    sa8775p platform. The offset should be 0 for csid lite on sa8775p,
    
    Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Fixes: ed03e99de0fa ("media: qcom: camss: Add support for CSID 690")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: qcom: iris: increase H265D_MAX_SLICE to fix H.265 decoding on SC7280 [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Date:   Fri Mar 27 22:19:55 2026 +0200

    media: qcom: iris: increase H265D_MAX_SLICE to fix H.265 decoding on SC7280
    
    commit 3e0b2053751657ed2924adfe3ff25b1450231e33 upstream.
    
    Follow the commit bfe1326573ff ("venus: Fix for H265 decoding failure.")
    and increase H265D_MAX_SLICE following firmware requirements on that
    platform. Otherwise decoding of the H.265 streams fails with the
    "insufficient scratch_1 buffer size" from the firmware.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    [bod: Fixed commit log withthe => with the]
    Fixes: e1f5d32608ec ("media: iris: Add internal buffer calculation for HEVC and VP9 decoders")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rc: streamzap: Error handling in probe [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Feb 11 19:06:21 2026 +0100

    media: rc: streamzap: Error handling in probe
    
    commit 42844992664f03ef9f930e64f7370fa481e9c267 upstream.
    
    If submitting the URB fails, the device will be unusable.
    Probe() must fail.
    
    Fixes: 7a569f524dd36 ("V4L/DVB: IR/streamzap: functional in-kernel decoding")
    Cc: stable@vger.kernel.org
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rc: xbox_remote: heed DMA restrictions [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Feb 11 19:09:44 2026 +0100

    media: rc: xbox_remote: heed DMA restrictions
    
    commit e280d1e5e3f2595bbb43fe6e1bce00c59a43c0ff upstream.
    
    The buffer for IO must not be part of the device structure
    because that violates the DMA coherency rules.
    
    Fixes: 02d32bdad3123 ("media: rc: add driver for Xbox DVD Movie Playback Kit")
    Cc: stable@vger.kernel.org
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: renesas: vin: Fix RAW8 (again) [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Date:   Tue Jan 27 10:56:12 2026 +0200

    media: renesas: vin: Fix RAW8 (again)
    
    commit 40c6da8a9c0f897f99a439330584d93ca7d41226 upstream.
    
    Commit e7376745ad5c ("media: rcar-vin: Fix stride setting for RAW8
    formats") removed dividing the stride by two for RAW8 formats. It is
    unclear how this was tested, but in any of the recent tests this does
    not seem to work and produces quite distorted images.
    
    However, reverting the patch fixes the issues only partially. VNIS_REG
    requires alignment to 16 bytes, and when dividing the stride by 2, in
    some cases we end up with a non-aligned stride, producing a tilted
    image. This issue has to be fixed in rvin_format_bytesperline() where we
    do the alignment for bytesperline.
    
    Adding back the stride division and increasing the alignment for RAW8
    formats to 0x20 fixes the problems related to RAW8.
    
    Fixes: e7376745ad5c ("media: rcar-vin: Fix stride setting for RAW8 formats")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: renesas: vsp1: Fix NULL pointer deref on module unload [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Date:   Thu Jan 15 11:22:35 2026 +0200

    media: renesas: vsp1: Fix NULL pointer deref on module unload
    
    commit 58b1e9664d8f74d55d8411cc7a7b275a76a6f24f upstream.
    
    When unloading the module on gen 4, we hit a NULL pointer dereference.
    This is caused by the cleanup code calling vsp1_drm_cleanup() where it
    should be calling vsp1_vspx_cleanup().
    
    Fix this by checking the IP version and calling the drm or vspx function
    accordingly, the same way as the init code does.
    
    Fixes: d06c1a9f348d ("media: vsp1: Add VSPX support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rockchip: rkcif: Add missing MUST_CONNECT flag to pads [+ + +]
Author: Dang Huynh <dang.huynh@mainlining.org>
Date:   Thu Jan 29 14:24:02 2026 +0700

    media: rockchip: rkcif: Add missing MUST_CONNECT flag to pads
    
    commit 8e3c751259dc2d1325838eff26f41032523c7b57 upstream.
    
    The pads missed checks for connected devices which may a null dereference
    when the stream is enabled.
    
    Unable to handle kernel NULL pointer dereference at virtual address
    0000000000000020
    pc : rkcif_interface_enable_streams+0x48/0xf0
    lr : rkcif_interface_enable_streams+0x44/0xf0
    Call trace:
     rkcif_interface_enable_streams+0x48/0xf0
     v4l2_subdev_enable_streams+0x26c/0x3f0
     rkcif_stream_start_streaming+0x140/0x278
     vb2_start_streaming+0x74/0x188
     vb2_core_streamon+0xe0/0x1d8
     vb2_ioctl_streamon+0x60/0xa8
     v4l_streamon+0x2c/0x40
     __video_do_ioctl+0x34c/0x400
     video_usercopy+0x2d0/0x800
     video_ioctl2+0x20/0x60
     v4l2_ioctl+0x48/0x78
    
    Fixes: 501802e2ad51 ("media: rockchip: rkcif: add abstraction for dma blocks")
    Fixes: 85411d17bee9 ("media: rockchip: rkcif: add abstraction for interface and crop blocks")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dang Huynh <dang.huynh@mainlining.org>
    Reviewed-by: Michael Riesch <michael.riesch@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rzv2h-ivc: Avoid double job scheduling [+ + +]
Author: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
Date:   Wed Feb 11 15:30:00 2026 +0100

    media: rzv2h-ivc: Avoid double job scheduling
    
    commit b1de0940a19c1b0001425f8069d6a82369986af7 upstream.
    
    The scheduling of a new buffer transfer in the IVC driver is triggered
    by two occurrences of the "frame completed" interrupt.
    
    The first interrupt occurrence identifies when all image data have been
    transferred to the ISP, the second occurrence identifies when the
    post-transfer VBLANK has completed and a new buffer can be transferred.
    
    Under heavy system load conditions the actual execution of the workqueue
    item might be delayed and two items might happen to run concurrently,
    leading to a new frame transfer being triggered while the previous one
    has not yet finished.
    
    This error condition is only visible because the driver maintains a
    status variable that counts the number of interrupts since the last
    transfer, and warns in case an IRQ happens before the counter has been
    reset.
    
    To ensure sequential execution of the worqueue items and avoid a double
    buffer transfer to run concurrently, protect the whole function body
    with the spinlock that so far was solely used to reset the counter and
    inspect the interrupt counter variable at the beginning of the buffer
    transfer function.
    
    As soon as the ongoing transfer completes, the workqueue item will be
    re-scheduled and will consume the pending buffer.
    
    Cc: stable@vger.kernel.org
    Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rzv2h-ivc: Fix concurrent buffer list access [+ + +]
Author: Barnabás Pőcze <barnabas.pocze+renesas@ideasonboard.com>
Date:   Fri Feb 6 17:30:54 2026 +0100

    media: rzv2h-ivc: Fix concurrent buffer list access
    
    commit 72773ff1cdfaebc593f53b1719b2c1773ecf8c43 upstream.
    
    The list of buffers (`rzv2h_ivc::buffers.queue`) is protected by a
    spinlock (`rzv2h_ivc::buffers.lock`). However, in
    `rzv2h_ivc_transfer_buffer()`, which runs in a separate workqueue, the
    `list_del()` call is executed without holding the spinlock, which makes
    it possible for the list to be concurrently modified
    
    Fix that by removing a buffer from the list in the lock protected section.
    
    Cc: stable@vger.kernel.org
    Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Barnabás Pőcze <barnabas.pocze+renesas@ideasonboard.com>
    [assign ivc->buffers.curr in critical section as reported by Barnabas]
    Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rzv2h-ivc: Fix FM_STOP register write [+ + +]
Author: Barnabás Pőcze <barnabas.pocze+renesas@ideasonboard.com>
Date:   Thu Feb 12 16:51:29 2026 +0100

    media: rzv2h-ivc: Fix FM_STOP register write
    
    commit 562d2e0a672075292e92538dad61664e89b34d30 upstream.
    
    Bit 20 should be written in this register to stop frame processing.
    So fix that, as well as the poll condition.
    
    Cc: stable@vger.kernel.org
    Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Barnabás Pőcze <barnabas.pocze+renesas@ideasonboard.com>
    Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rzv2h-ivc: Write AXIRX_PIXFMT once [+ + +]
Author: Barnabás Pőcze <barnabas.pocze+renesas@ideasonboard.com>
Date:   Thu Feb 12 16:45:48 2026 +0100

    media: rzv2h-ivc: Write AXIRX_PIXFMT once
    
    commit d901c428350245f2b26431e03c4ba0bdc7a71243 upstream.
    
    The documentation prescribes that invalid formats should not be set,
    so do a single write to ensure that both the CLFMT and DTYPE fields
    are set to valid values.
    
    Cc: stable@vger.kernel.org
    Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Barnabás Pőcze <barnabas.pocze+renesas@ideasonboard.com>
    Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: saa7164: add ioremap return checks and cleanups [+ + +]
Author: Wang Jun <1742789905@qq.com>
Date:   Mon Mar 16 20:24:01 2026 +0800

    media: saa7164: add ioremap return checks and cleanups
    
    commit d51c60a498e83c9a79884c8e420f97e3885c9583 upstream.
    
    Add checks for ioremap return values in saa7164_dev_setup(). If
    ioremap for BAR0 or BAR2 fails, release the already allocated PCI
    memory regions, remove the device from the global list, decrement
    the device count, and return -ENODEV.
    
    This prevents potential null pointer dereferences and ensures proper
    cleanup on memory mapping failures.
    
    Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon")
    Cc: stable@vger.kernel.org
    Signed-off-by: Wang Jun <1742789905@qq.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: staging: imx: request mbus_config in csi_start [+ + +]
Author: Michael Tretter <m.tretter@pengutronix.de>
Date:   Fri Nov 7 11:34:33 2025 +0100

    media: staging: imx: request mbus_config in csi_start
    
    commit 9df2aaa64890c0b6226057eb6fcb6352bd2df432 upstream.
    
    Request the upstream mbus_config in csi_start, which starts the stream,
    instead of caching it in link_validate.
    
    This allows to get rid of the mbus_cfg field in the struct csi_priv and
    avoids state in the driver.
    
    Fixes: 4a34ec8e470c ("[media] media: imx: Add CSI subdev driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: ti: vpe: Add missing v4l2_device_unregister in vip_remove() [+ + +]
Author: Felix Gu <ustc.gu@gmail.com>
Date:   Sun Mar 1 21:39:25 2026 +0800

    media: ti: vpe: Add missing v4l2_device_unregister in vip_remove()
    
    commit f3e969a5b54304cab6891a58d9dd8b29072bde4c upstream.
    
    The v4l2_device is registered during probe but was not being unregistered
    during remove. Add the missing v4l2_device_unregister() call to properly
    clean up resources.
    
    Fixes: fc2873aa4a21 ("media: ti: vpe: Add the VIP driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Gu <ustc.gu@gmail.com>
    Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: uvcvideo: Enable VB2_DMABUF for metadata stream [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Mar 9 15:01:54 2026 +0000

    media: uvcvideo: Enable VB2_DMABUF for metadata stream
    
    commit fbac03467e53d8d72e5099c03df26d9adae11416 upstream.
    
    The UVC driver has two video streams, one for the frames and another one
    for the metadata. Both streams share most of the codebase, but only the
    data stream declares support for DMABUF transfer mode.
    
    I have tried the DMABUF transfer mode with CONFIG_DMABUF_HEAPS_SYSTEM
    and the frames looked correct.
    
    This patch announces the support for DMABUF for the metadata stream.
    This is useful for apps/HALs that only want to support DMABUF.
    
    Cc: stable@vger.kernel.org
    Fixes: 088ead2552458 ("media: uvcvideo: Add a metadata device node")
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
    Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-1-fc8b87bd29c5@chromium.org
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: venus: fix QCOM_MDT_LOADER dependency [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 30 12:08:21 2026 +0100

    media: venus: fix QCOM_MDT_LOADER dependency
    
    commit aa23c94cc433b145d1ce93820ecdfe16d8940e28 upstream.
    
    When build-testined with CONFIG_QCOM_MDT_LOADER=m and VIDEO_QCOM_VENUS=y,
    the kernel fails to link:
    
    x86_64-linux-ld: drivers/media/platform/qcom/venus/firmware.o: in function `venus_boot':
    firmware.c:(.text+0x1e3): undefined reference to `qcom_mdt_get_size'
    firmware.c:(.text+0x25a): undefined reference to `qcom_mdt_load'
    firmware.c:(.text+0x272): undefined reference to `qcom_mdt_load_no_init'
    
    The problem is the conditional 'select' statement. Change this to
    make the driver built-in here regardless of CONFIG_ARCH_QCOM,
    same as for the similar IRIS driver.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
    Fixes: 0399b696f7f4 ("media: venus: fix compile-test build on non-qcom ARM platform")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: videobuf2: Set vma_flags in vb2_dma_sg_mmap [+ + +]
Author: Janne Grunau <j@jannau.net>
Date:   Sun Feb 15 18:42:59 2026 +0100

    media: videobuf2: Set vma_flags in vb2_dma_sg_mmap
    
    commit 7254b31a13aaa0c2c0f9ffbc335b718656117ff4 upstream.
    
    vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not
    see a reason why vb2_dma_sg should behave differently. This avoids
    hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in
    drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of
    tree Apple ISP camera capture driver which uses vb2_dma_sg_memops.
    
    gst-launch-1.0 v4l2src ! gtk4paintablesink
    
    [   38.201528] ------------[ cut here ]------------
    [   38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210
    [   38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer
    snd_seq snd_seq_device uinput nf_conntrack_netbios_ns
    nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib
    nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat
    nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep
    nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc
    hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic
    cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev
    aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2
    snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor
    macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi
    macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3
    snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon
    apple_sart apple_dockchannel macsmc apple_rtkit_helper
    spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses
    pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core
    spi_apple
    [   38.203300]  videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram
    [   38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G        W           6.17.6+ #asahi-dev PREEMPT(full)
    [   38.219040] Tainted: [W]=WARN
    [   38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)
    [   38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    [   38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210
    [   38.221643] lr : drm_gem_mmap_obj+0x78/0x210
    [   38.222178] sp : ffffc0008dc678e0
    [   38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480
    [   38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968
    [   38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0
    [   38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968
    [   38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8
    [   38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff
    [   38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8
    [   38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000
    [   38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038
    [   38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb
    [   38.231488] Call trace:
    [   38.231806]  drm_gem_mmap_obj+0x1f8/0x210 (P)
    [   38.232342]  drm_gem_mmap+0x140/0x260
    [   38.232813]  __mmap_region+0x488/0x9a0
    [   38.233277]  mmap_region+0xd0/0x148
    [   38.233703]  do_mmap+0x350/0x5c0
    [   38.234148]  vm_mmap_pgoff+0x14c/0x200
    [   38.234612]  ksys_mmap_pgoff+0x150/0x208
    [   38.235107]  __arm64_sys_mmap+0x34/0x50
    [   38.235611]  invoke_syscall+0x50/0x120
    [   38.236075]  el0_svc_common.constprop.0+0x48/0xf0
    [   38.236680]  do_el0_svc+0x24/0x38
    [   38.237113]  el0_svc+0x38/0x168
    [   38.237507]  el0t_64_sync_handler+0xa0/0xe8
    [   38.238034]  el0t_64_sync+0x198/0x1a0
    [   38.238491] ---[ end trace 0000000000000000 ]---
    
    There were discussions in [1] at the end of 2023 that mmap() on imported
    dma-bufs should not be supported but as of v6.17 drm_gem_shmem_mmap() in
    drm_gem_shmem_helper.c still supports it.
    This might affect all gpu or accel drivers using drm_gem_shmem_mmap() or
    the wrapper drm_gem_shmem_object_mmap().
    
    [1] https://lore.kernel.org/dri-devel/bc7f7844-0aa3-4802-b203-69d58e8be2fa@linux.intel.com/
    
    Cc: stable@vger.kernel.org
    Fixes: 5ba3f757f059 ("[media] v4l: videobuf2: add DMA scatter/gather allocator")
    Signed-off-by: Janne Grunau <j@jannau.net>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap() [+ + +]
Author: Lorenzo Stoakes <ljs@kernel.org>
Date:   Thu May 14 11:33:20 2026 +0100

    mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()
    
    [ Upstream commit 619eab23e1ce7c97e54bfc5a417306d94b3f6f13 ]
    
    The mmap_prepare hook functionality includes the ability to invoke
    mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is
    ones which are capable of calling the mmap hooks of other drivers/file
    systems (e.g.  overlayfs, shm).
    
    As part of the mmap_prepare action functionality, we deal with errors by
    unmapping the VMA should one arise.  This works in the usual mmap_prepare
    case, as we invoke this action at the last moment, when the VMA is
    established in the maple tree.
    
    However, the mmap() hook passes a not-fully-established VMA pointer to the
    caller (which is the motivation behind the mmap_prepare() work), which is
    detached.
    
    So attempting to unmap a VMA in this state will be problematic, with the
    most obvious symptom being a warning in vma_mark_detached(), because the
    VMA is already detached.
    
    It's also unncessary - the mmap() handler will clean up the VMA on error.
    
    So to fix this issue, this patch propagates whether or not an mmap action
    is being completed via the compatibility layer or directly.
    
    If the former, then we do not attempt VMA cleanup, if the latter, then we
    do.
    
    This patch also updates the userland VMA tests to reflect the change.
    
    Link: https://lore.kernel.org/20260421102150.189982-1-ljs@kernel.org
    Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc")
    Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
    Reported-by: syzbot+db390288d141a1dccf96@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/69e69734.050a0220.24bfd3.0027.GAE@google.com/
    Cc: David Hildenbrand <david@kernel.org>
    Cc: Jann Horn <jannh@google.com>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: Pedro Falcato <pfalcato@suse.de>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf build: fix "argument list too long" in second location [+ + +]
Author: Markus Mayer <mmayer@broadcom.com>
Date:   Wed May 13 16:46:38 2026 -0700

    perf build: fix "argument list too long" in second location
    
    commit 97ab89686a9e5d087042dbe73604a32b3de72653 upstream
    
    Turns out that displaying "RM $^" via quiet_cmd_rm can also upset the
    shell and cause it to display "argument list too long".
    
    Trying to quote $^ doesn't help.
    
    In the end, *not* displaying the (potentially long) list of files is
    probably the right thing to do for a "quiet" message, anyway. Instead,
    let's display a count of how many files were removed. There is always
    V=1 if more detail is required.
    
      TEST    linux/tools/perf/pmu-events/metric_test.log
      RM      ...634 orphan file(s)...
      LD      linux/tools/perf/util/perf-util-in.o
    
    Also move the comment regarding xargs before the rule, so it doesn't
    show up in the build output.
    
    Signed-off-by: Markus Mayer <mmayer@broadcom.com>
    Reviewed-by: James Clark <james.clark@linaro.org>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/x86: hp-wmi: Ignore backlight and FnLock events [+ + +]
Author: Krishna Chomal <krishna.chomal108@gmail.com>
Date:   Fri Apr 3 13:31:55 2026 +0530

    platform/x86: hp-wmi: Ignore backlight and FnLock events
    
    commit e8c597368b8500a824c639bfb5ed0044068c6870 upstream.
    
    On HP OmniBook 7 the keyboard backlight and FnLock keys are handled
    directly by the firmware. However, they still trigger WMI events which
    results in "Unknown key code" warnings in dmesg.
    
    Add these key codes to the keymap with KE_IGNORE to silence the warnings
    since no software action is needed.
    
    Tested-by: Artem S. Tashkinov <aros@gmx.com>
    Reported-by: Artem S. Tashkinov <aros@gmx.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221181
    Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
    Link: https://patch.msgid.link/20260403080155.169653-1-krishna.chomal108@gmail.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
regulator: act8945a: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:54 2026 +0200

    regulator: act8945a: fix OF node reference imbalance
    
    commit 0d15ce31375ccef4162f960b34547a821b7619d2 upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: 38c09961048b ("regulator: act8945a: add regulator driver for ACT8945A")
    Cc: stable@vger.kernel.org      # 4.6
    Cc: Wenyou Yang <wenyou.yang@atmel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-7-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: bd9571mwv: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:55 2026 +0200

    regulator: bd9571mwv: fix OF node reference imbalance
    
    commit 8498100ee1d00422b8c5b161b3e332278b92a59a upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: e85c5a153fe2 ("regulator: Add ROHM BD9571MWV-M PMIC regulator driver")
    Cc: stable@vger.kernel.org      # 4.12
    Cc: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-8-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: bq257xx: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:49 2026 +0200

    regulator: bq257xx: fix OF node reference imbalance
    
    commit 7ea07bc030d8d6395524dec22ff3267441a28c0d upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: 981dd162b635 ("regulator: bq257xx: Add bq257xx boost regulator driver")
    Cc: stable@vger.kernel.org      # 6.18
    Cc: Chris Morgan <macromorgan@hotmail.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: max77650: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:51 2026 +0200

    regulator: max77650: fix OF node reference imbalance
    
    commit 2edaf5f7ada0ab5c9ec1f0836bd19779a8d85262 upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: bcc61f1c44fd ("regulator: max77650: add regulator support")
    Cc: stable@vger.kernel.org      # 5.1
    Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-4-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: mt6357: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:52 2026 +0200

    regulator: mt6357: fix OF node reference imbalance
    
    commit 2f38e96c273e15f5e9f5d1fc2c0cbba703751602 upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: dafc7cde23dc ("regulator: add mt6357 regulator")
    Cc: stable@vger.kernel.org      # 6.2
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-5-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: rk808: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:50 2026 +0200

    regulator: rk808: fix OF node reference imbalance
    
    commit 65290b24d8a5f0b8cd065201e653db824c4a4da6 upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: 647e57351f8e ("regulator: rk808: reduce 'struct rk808' usage")
    Cc: stable@vger.kernel.org      # 6.2
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: s2dos05: fix OF node reference imbalance [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 8 09:30:53 2026 +0200

    regulator: s2dos05: fix OF node reference imbalance
    
    commit ebe694d67f159899b063eee61bacda4cb825ed7b upstream.
    
    The driver reuses the OF node of the parent multi-function device but
    fails to take another reference to balance the one dropped by the
    platform bus code when unbinding the MFD and deregistering the child
    devices.
    
    Fix this by using the intended helper for reusing OF nodes.
    
    Fixes: bb2441402392 ("regulator: add s2dos05 regulator support")
    Cc: stable@vger.kernel.org      # 6.18
    Cc: Dzmitry Sankouski <dsankouski@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260408073055.5183-6-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sched_ext: Skip tasks with stale task_rq in bypass_lb_cpu() [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Wed May 13 15:01:11 2026 +0200

    sched_ext: Skip tasks with stale task_rq in bypass_lb_cpu()
    
    commit da2d81b4118a74e65d2335e221a38d665902a98c upstream.
    
    bypass_lb_cpu() transfers tasks between per-CPU bypass DSQs without
    migrating them - task_cpu() only updates when the donee later consumes the
    task via move_remote_task_to_local_dsq(). If the LB timer fires again before
    consumption and the new DSQ becomes a donor, @p is still on the previous CPU
    and task_rq(@p) != donor_rq. @p can't be moved without its own rq locked.
    
    Skip such tasks.
    
    Fixes: 95d1df610cdc ("sched_ext: Implement load balancer for bypass mode")
    Cc: stable@vger.kernel.org # v6.19+
    Reported-by: Chris Mason <clm@meta.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Andrea Righi <arighi@nvidia.com>
    [ arighi: replace donor_rq with rq, not present in v7.0.y ]
    Signed-off-by: Andrea Righi <arighi@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sched_ext: Use HK_TYPE_DOMAIN_BOOT to detect isolcpus= domain isolation [+ + +]
Author: Andrea Righi <arighi@nvidia.com>
Date:   Wed May 13 13:24:38 2026 +0200

    sched_ext: Use HK_TYPE_DOMAIN_BOOT to detect isolcpus= domain isolation
    
    commit 6ae315d37924435516d697ea7dde0b799a5928e0 upstream.
    
    scx_enable() refuses to attach a BPF scheduler when isolcpus=domain is
    in effect by comparing housekeeping_cpumask(HK_TYPE_DOMAIN) against
    cpu_possible_mask.
    
    Since commit 27c3a5967f05 ("sched/isolation: Convert housekeeping
    cpumasks to rcu pointers"), HK_TYPE_DOMAIN's cpumask is RCU protected
    and dereferencing it requires either RCU read lock, the cpu_hotplug
    write lock, or the cpuset lock; scx_enable() holds none of these, so
    booting with isolcpus=domain and attaching any BPF scheduler triggers
    the following lockdep splat:
    
      =============================
      WARNING: suspicious RCU usage
      -----------------------------
      kernel/sched/isolation.c:60 suspicious rcu_dereference_check() usage!
    
      1 lock held by scx_flash/281:
       #0: ffffffff8379fce0 (update_mutex){+.+.}-{4:4}, at:
           bpf_struct_ops_link_create+0x134/0x1c0
    
      Call Trace:
       dump_stack_lvl+0x6f/0xb0
       lockdep_rcu_suspicious.cold+0x37/0x70
       housekeeping_cpumask+0xcd/0xe0
       scx_enable.isra.0+0x17/0x120
       bpf_scx_reg+0x5e/0x80
       bpf_struct_ops_link_create+0x151/0x1c0
       __sys_bpf+0x1e4b/0x33c0
       __x64_sys_bpf+0x21/0x30
       do_syscall_64+0x117/0xf80
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    In addition, commit 03ff73510169 ("cpuset: Update HK_TYPE_DOMAIN cpumask
    from cpuset") made HK_TYPE_DOMAIN include cpuset isolated partitions as
    well, which means the current check also rejects BPF schedulers when a
    cpuset partition is active. That contradicts the original intent of
    commit 9f391f94a173 ("sched_ext: Disallow loading BPF scheduler if
    isolcpus= domain isolation is in effect"), which explicitly noted that
    cpuset partitions are honored through per-task cpumasks and should not
    be rejected.
    
    Switch to housekeeping_enabled(HK_TYPE_DOMAIN_BOOT), which reads only
    the housekeeping flag bit (no RCU dereference) and reflects exactly the
    boot-time isolcpus= configuration that the error message refers to.
    
    Fixes: 27c3a5967f05 ("sched/isolation: Convert housekeeping cpumasks to rcu pointers")
    Cc: stable@vger.kernel.org # v7.0+
    Signed-off-by: Andrea Righi <arighi@nvidia.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL [+ + +]
Author: Ben Morris <bmorris@anthropic.com>
Date:   Thu May 7 17:14:55 2026 -0700

    sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL
    
    commit abb5f36771cc4c05899b34000829a787572a8817 upstream.
    
    The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with
    list_for_each_entry_safe(), which caches the next entry in @tmp before
    the loop body runs.  The body calls sctp_sendmsg_to_asoc(), which may
    drop the socket lock inside sctp_wait_for_sndbuf().
    
    While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the
    association cached in @tmp, migrating it to a new endpoint via
    sctp_sock_migrate() (list_del_init() + list_add_tail() to
    newep->asocs), and optionally close the new socket which frees the
    association via kfree_rcu().  The cached @tmp can also be freed by a
    network ABORT for that association, processed in softirq while the
    lock is dropped.
    
    sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock
    via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing
    revalidates @tmp.  After a successful return, the iterator advances to
    the stale @tmp, yielding either a use-after-free (if the peeled socket
    was closed) or a list-walk onto the new endpoint's list head (type
    confusion of &newep->asocs as a struct sctp_association *).
    
    Both are reachable from CapEff=0; the type-confusion path gives
    controlled indirect call via the outqueue.sched->init_sid pointer.
    
    Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc()
    returns.  @asoc is known to still be on ep->asocs at that point: the
    only callers that list_del an association from ep->asocs are
    sctp_association_free() (which sets asoc->base.dead) and
    sctp_assoc_migrate() (which changes asoc->base.sk), and
    sctp_wait_for_sndbuf() checks both under the lock before any
    successful return; a tripped check propagates as err < 0 and the loop
    bails before the re-derive.
    
    The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the
    loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so
    the @tmp cached by list_for_each_entry_safe() still covers the
    lock-held free that ba59fb027307 ("sctp: walk the list of asoc
    safely") was added for.
    
    Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ben Morris <bmorris@anthropic.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Link: https://patch.msgid.link/20260508001455.3137-1-joycathacker@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: amlogic-spisg: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:00 2026 +0200

    spi: amlogic-spisg: fix controller deregistration
    
    commit 84d31bb1f6256eea0db6cf64a3c7a53145f92bb9 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: cef9991e04ae ("spi: Add Amlogic SPISG driver")
    Cc: stable@vger.kernel.org      # 6.17: b8db95529979
    Cc: stable@vger.kernel.org      # 6.17
    Cc: Sunny Luo <sunny.luo@amlogic.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: aspeed-smc: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:01 2026 +0200

    spi: aspeed-smc: fix controller deregistration
    
    commit 1044e5a4ccd57bf5a64f90100a321b498e0267a2 upstream.
    
    Make sure to deregister the controller before disabling it to allow
    SPI device drivers to do I/O during deregistration.
    
    Fixes: e3228ed92893 ("spi: spi-mem: Convert Aspeed SMC driver to spi-mem")
    Cc: stable@vger.kernel.org      # 5.19
    Cc: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: at91-usart: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:02 2026 +0200

    spi: at91-usart: fix controller deregistration
    
    commit 9acecc9bcff058eaef40fd7a4c3650e88b06b220 upstream.
    
    Make sure to deregister the controller before disabling and releasing
    underlying resources like clocks and DMA during driver unbind.
    
    Fixes: e1892546ff66 ("spi: at91-usart: Add driver for at91-usart as SPI")
    Cc: stable@vger.kernel.org      # 4.20
    Cc: Radu Pirea <radu.pirea@microchip.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-4-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: atmel: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:03 2026 +0200

    spi: atmel: fix controller deregistration
    
    commit 8d4de97e83520be89d0ff40610ca633b3963a7de upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: 754ce4f29937 ("[PATCH] SPI: atmel_spi driver")
    Cc: stable@vger.kernel.org      # 2.6.21
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-5-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: bcm63xx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:04 2026 +0200

    spi: bcm63xx: fix controller deregistration
    
    commit c39e65a4e3b8e764efed0b2f5152a1a8547b80fd upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: b42dfed83d95 ("spi: add Broadcom BCM63xx SPI controller driver")
    Cc: stable@vger.kernel.org      # 3.4
    Cc: Florian Fainelli <florian@openwrt.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-6-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: bcmbca-hsspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:06 2026 +0200

    spi: bcmbca-hsspi: fix controller deregistration
    
    commit c3d97c3320b9a1ebbd6119857341be034f7b3efc upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like interrupts during driver unbind to allow SPI drivers to
    do I/O during deregistration.
    
    Note that clocks were also disabled before the recent commit
    e532e21a246d ("spi: bcm63xx-hsspi: Simplify clock handling with
    devm_clk_get_enabled()").
    
    Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller")
    Cc: stable@vger.kernel.org      # 6.3: deb269e0394f
    Cc: stable@vger.kernel.org      # 6.3
    Cc: William Zhang <william.zhang@broadcom.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-8-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence-quadspi: fix clock imbalance on probe failure [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:53:50 2026 +0200

    spi: cadence-quadspi: fix clock imbalance on probe failure
    
    commit cba53fe20c18688c17ca668ad0e4ec05e31c70d3 upstream.
    
    Drop the bogus runtime PM get on probe failures that was never needed
    and that leaks a usage count reference while preventing the clocks from
    being disabled (as runtime PM has not yet been enabled).
    
    Fixes: 1889dd208197 ("spi: cadence-quadspi: Fix clock disable on probe failure path")
    Cc: stable@vger.kernel.org      # 6.19
    Cc: Anurag Dutta <a-dutta@ti.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421125354.1534871-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence-quadspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 14 15:43:13 2026 +0200

    spi: cadence-quadspi: fix controller deregistration
    
    commit 964ee9793760e825b5c011741b4e3cfe06c87efc upstream.
    
    Make sure to deregister the controller before dropping the reference
    count that allows new operations to start to allow SPI drivers to do I/O
    during deregistration.
    
    Fixes: 7446284023e8 ("spi: cadence-quadspi: Implement refcount to handle unbind during busy")
    Cc: stable@vger.kernel.org      # 6.17
    Cc: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260414134319.978196-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence-quadspi: fix runtime pm and clock imbalance on unbind [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:53:52 2026 +0200

    spi: cadence-quadspi: fix runtime pm and clock imbalance on unbind
    
    commit 5e8bb0cc72f1d52d8ac2a88f4c952e2e98056aed upstream.
    
    Make sure to balance the runtime PM usage count before returning on
    probe failure (to allow the controller to suspend after a probe
    deferral) and to only drop the usage count on driver unbind to avoid a
    clock disable imbalance.
    
    Also restore the autosuspend setting.
    
    Fixes: 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support")
    Cc: stable@vger.kernel.org      # 6.7
    Cc: Dhruva Gole <d-gole@ti.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421125354.1534871-5-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence-quadspi: fix runtime pm disable imbalance on probe failure [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:53:49 2026 +0200

    spi: cadence-quadspi: fix runtime pm disable imbalance on probe failure
    
    commit 5ff4d5d1af0c7517bd8db83c95c4247a9729a548 upstream.
    
    A recent attempt to fix the probe error handling introduced a runtime PM
    disable depth imbalance by incorrectly disabling runtime PM on early
    failures (e.g. probe deferral).
    
    Fixes: f18c8cfa4f1a ("spi: cadence-qspi: Fix probe error path and remove")
    Cc: stable@vger.kernel.org      # 7.0
    Cc: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421125354.1534871-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence-quadspi: fix unclocked access on unbind [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:53:51 2026 +0200

    spi: cadence-quadspi: fix unclocked access on unbind
    
    commit 233db2cb14db8b1935dda52a6affd97276462b82 upstream.
    
    Make sure that the controller is runtime resumed before disabling it
    during driver unbind to avoid an unclocked register access.
    
    This issue was flagged by Sashiko when reviewing a controller
    deregistration fix.
    
    Fixes: 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support")
    Cc: stable@vger.kernel.org      # 6.7
    Cc: Dhruva Gole <d-gole@ti.com>
    Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=2
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421125354.1534871-4-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence: fix clock imbalance on probe failure [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:36:13 2026 +0200

    spi: cadence: fix clock imbalance on probe failure
    
    commit ecea4f0e9db2fb6ab4a68a59c5aba0d8f59a9566 upstream.
    
    Make sure that the controller is active before disabling clocks on probe
    failure to avoid unbalanced clock disable.
    
    Also drop the usage count before returning (so that the controller can
    be suspended after a probe deferral) and restore the autosuspend
    setting.
    
    Fixes: d36ccd9f7ea4 ("spi: cadence: Runtime pm adaptation")
    Cc: stable@vger.kernel.org      # 4.7
    Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421123615.1533617-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 14 15:43:12 2026 +0200

    spi: cadence: fix controller deregistration
    
    commit 666fa7e9ca98e71c880086ca24147ae843f1ed6e upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: c474b3866546 ("spi: Add driver for Cadence SPI controller")
    Cc: stable@vger.kernel.org      # 3.16
    Cc: Harini Katakam <harinik@xilinx.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260414134319.978196-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence: fix unclocked access on unbind [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:36:12 2026 +0200

    spi: cadence: fix unclocked access on unbind
    
    commit 5b1689a41f02955c5361944f748a4812a6ff9307 upstream.
    
    Make sure that the controller is runtime resumed before disabling it
    during driver unbind to avoid unclocked register access and unbalanced
    clock disable.
    
    Also restore the autosuspend setting.
    
    This issue was flagged by Sashiko when reviewing a controller
    deregistration fix.
    
    Fixes: d36ccd9f7ea4 ("spi: cadence: Runtime pm adaptation")
    Cc: stable@vger.kernel.org      # 4.7
    Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
    Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=1
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421123615.1533617-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cavium-thunderx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:08 2026 +0200

    spi: cavium-thunderx: fix controller deregistration
    
    commit dbb6b01267c0c866eaac4019cec19f414beec61d upstream.
    
    Make sure to deregister the controller before disabling it to avoid
    hanging or leaking resources associated with the queue when the queue
    non-empty.
    
    Fixes: 7347a6c7af8d ("spi: octeon: Add ThunderX driver")
    Cc: stable@vger.kernel.org      # 4.9
    Cc: Jan Glauber <jan.glauber@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-10-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: ch341: fix devres lifetime [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Mar 27 11:43:05 2026 +0100

    spi: ch341: fix devres lifetime
    
    commit abe572f630bc1f0e77041012ab075869036ede4f upstream.
    
    USB drivers bind to USB interfaces and any device managed resources
    should have their lifetime tied to the interface rather than parent USB
    device. This avoids issues like memory leaks when drivers are unbound
    without their devices being physically disconnected (e.g. on probe
    deferral or configuration changes).
    
    Fix the controller and driver data lifetime so that they are released
    on driver unbind.
    
    Note that this also makes sure that the SPI controller is placed
    correctly under the USB interface in the device tree.
    
    Fixes: 8846739f52af ("spi: add ch341a usb2spi driver")
    Cc: stable@vger.kernel.org      # 6.11
    Cc: Johannes Thumshirn <jth@kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260327104305.1309915-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: coldfire-qspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:09 2026 +0200

    spi: coldfire-qspi: fix controller deregistration
    
    commit e7c510e192ff2a1264d999575eea39a506424264 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks (via runtime pm) during driver unbind.
    
    Fixes: 34b8c6617366 ("spi: Add Freescale/Motorola Coldfire QSPI driver")
    Cc: stable@vger.kernel.org      # 2.6.34
    Cc: Steven King <sfking@fdwdc.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-11-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: dln2: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:10 2026 +0200

    spi: dln2: fix controller deregistration
    
    commit c353020fbfa8514ee91a6de2d88de4e5edca5803 upstream.
    
    Make sure to deregister the controller before disabling it to allow
    SPI device drivers to do I/O during deregistration.
    
    Fixes: 3d8c0d749da3 ("spi: add support for DLN-2 USB-SPI adapter")
    Cc: stable@vger.kernel.org      # 4.0
    Cc: Laurentiu Palcu <laurentiu.palcu@intel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-12-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: ep93xx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:11 2026 +0200

    spi: ep93xx: fix controller deregistration
    
    commit f4838934b695a58eda0833583cb8028e73a19529 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 011f23a3c2f2 ("spi/ep93xx: implemented driver for Cirrus EP93xx SPI controller")
    Cc: stable@vger.kernel.org      # 2.6.35
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-13-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: fsl-espi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:12 2026 +0200

    spi: fsl-espi: fix controller deregistration
    
    commit e506a700a7ad229f5c8f01f4b8350119cccb4158 upstream.
    
    Make sure to deregister the controller before disabling runtime PM
    (which can leave the controller disabled) to allow SPI device drivers to
    do I/O during deregistration.
    
    Fixes: e9abb4db8d10 ("spi: fsl-espi: add runtime PM")
    Cc: stable@vger.kernel.org      # 4.3
    Cc: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-14-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: fsl: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 08:47:49 2026 +0200

    spi: fsl: fix controller deregistration
    
    commit 9b7abfed4c3754062d1f3ffd452e65a38667f586 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 4178b6b1b595 ("spi: fsl-(e)spi: migrate to using devm_ functions to simplify cleanup")
    Cc: stable@vger.kernel.org      # 4.3
    Cc: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410064749.496888-1-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: img-spfi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:14 2026 +0200

    spi: img-spfi: fix controller deregistration
    
    commit fc3a83b0d9c16b941c9028f5a8db9541dce4ddf2 upstream.
    
    Make sure to deregister the controller before disabling and releasing
    underlying resources like clocks and DMA during driver unbind.
    
    Fixes: deba25800a12 ("spi: Add driver for IMG SPFI controller")
    Cc: stable@vger.kernel.org      # 3.19
    Cc: Andrew Bresticker <abrestic@chromium.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-16-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: imx: fix runtime pm leak on probe deferral [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:56:32 2026 +0200

    spi: imx: fix runtime pm leak on probe deferral
    
    commit a1d50a37d3b1df84f536a982f692371039df4a48 upstream.
    
    Make sure to balance the runtime PM usage count before returning on
    probe failure (e.g. probe deferral) so that the controller can be
    suspended when a driver is later bound.
    
    Fixes: 43b6bf406cd0 ("spi: imx: fix runtime pm support for !CONFIG_PM")
    Cc: stable@vger.kernel.org      # 5.10
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421125632.1537235-1-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: lantiq-ssc: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:15 2026 +0200

    spi: lantiq-ssc: fix controller deregistration
    
    commit b99206710d032c16b7f8b75e4bc18414d8e4b9f4 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like clocks during driver unbind.
    
    Fixes: 17f84b793c01 ("spi: lantiq-ssc: add support for Lantiq SSC SPI controller")
    Cc: stable@vger.kernel.org      # 4.11
    Cc: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-17-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: meson-spicc: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:16 2026 +0200

    spi: meson-spicc: fix controller deregistration
    
    commit 77953c76bec9af4191f8692a10225dd816208718 upstream.
    
    Make sure to deregister the controller before disabling it to allow SPI
    device drivers to do I/O during deregistration.
    
    Fixes: 454fa271bc4e ("spi: Add Meson SPICC driver")
    Cc: stable@vger.kernel.org      # 4.13
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-18-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mpc52xx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 14 15:43:14 2026 +0200

    spi: mpc52xx: fix controller deregistration
    
    commit 0f997fdae819a8c2cc83bd4ff7d935ad76c727c9 upstream.
    
    Make sure to deregister the controller before disabling and releasing
    underlying resources like interrupts and gpios during driver unbind.
    
    Fixes: 42bbb70980f3 ("powerpc/5200: Add mpc5200-spi (non-PSC) device driver")
    Fixes: b8d4e2ce60b6 ("mpc52xx_spi: add gpio chipselect")
    Cc: stable@vger.kernel.org      # 2.6.33
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Luotao Fu <l.fu@pengutronix.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260414134319.978196-4-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mpc52xx: fix use-after-free on registration failure [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 14:58:00 2026 +0200

    spi: mpc52xx: fix use-after-free on registration failure
    
    commit f62c060272b9d7423b1650b844e8e4e7b8f9f925 upstream.
    
    Make sure to disable and free the interrupts in case controller
    registration fails to avoid a potential use-after-free and resource
    leak.
    
    This issue was flagged by Sashiko when reviewing a controller
    deregistration fix.
    
    Fixes: 42bbb70980f3 ("powerpc/5200: Add mpc5200-spi (non-PSC) device driver")
    Cc: stable@vger.kernel.org      # 2.6.33
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=3
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421125800.1537361-1-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mpc52xx: fix use-after-free on unbind [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 14 15:43:15 2026 +0200

    spi: mpc52xx: fix use-after-free on unbind
    
    commit 706b3dc2ac7a998c55e14b3fd2e8f934c367e6e0 upstream.
    
    The state machine work is scheduled by the interrupt handler and
    therefore needs to be cancelled after disabling interrupts to avoid a
    potential use-after-free.
    
    Fixes: 984836621aad ("spi: mpc52xx: Add cancel_work_sync before module remove")
    Cc: stable@vger.kernel.org
    Cc: Pei Xiao <xiaopei01@kylinos.cn>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260414134319.978196-5-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mpfs: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:19 2026 +0200

    spi: mpfs: fix controller deregistration
    
    commit 573c7db8fce91a1b07dd64a260bb44b9e6d05943 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like interrupts during driver unbind.
    
    Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers")
    Cc: stable@vger.kernel.org      # 6.0
    Cc: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://patch.msgid.link/20260409120419.388546-21-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mt65xx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:31 2026 +0200

    spi: mt65xx: fix controller deregistration
    
    commit 2ad30599cccc572ba2fc11010670eb6e01ea6bfc upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173")
    Cc: stable@vger.kernel.org      # 4.3: ace145802350
    Cc: stable@vger.kernel.org      # 4.3
    Cc: Leilk Liu <leilk.liu@mediatek.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mtk-nor: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:32 2026 +0200

    spi: mtk-nor: fix controller deregistration
    
    commit 76336f24934621db286cabb20b483773ee01dcaa upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: 881d1ee9fe81 ("spi: add support for mediatek spi-nor controller")
    Cc: stable@vger.kernel.org      # 5.7
    Cc: Chuanhong Guo <gch981213@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mxic: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 14 15:43:16 2026 +0200

    spi: mxic: fix controller deregistration
    
    commit adbc595e272052181d40ec307a4c5ba98571b0fe upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks (via runtime pm) during driver unbind.
    
    Fixes: b942d80b0a39 ("spi: Add MXIC controller driver")
    Cc: stable@vger.kernel.org      # 5.0: cc53711b2191
    Cc: stable@vger.kernel.org      # 5.0
    Cc: Mason Yang <masonccyang@mxic.com.tw>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260414134319.978196-6-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: mxs: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:33 2026 +0200

    spi: mxs: fix controller deregistration
    
    commit 8b0d0011af20fb547aa67a1cefbf320992fd5e92 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 33e195acf268 ("spi: mxs: use devm_spi_register_master()")
    Cc: stable@vger.kernel.org      # 3.13
    Cc: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-4-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: npcm-pspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:34 2026 +0200

    spi: npcm-pspi: fix controller deregistration
    
    commit ebd81199e00e107980bf8c4d2c747ae50158f797 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: 2a22f1b30cee ("spi: npcm: add NPCM PSPI controller driver")
    Cc: stable@vger.kernel.org      # 5.0
    Cc: Tomer Maimon <tmaimon77@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-5-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: octeon: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Apr 9 14:04:07 2026 +0200

    spi: octeon: fix controller deregistration
    
    commit 3c49a4d8799bee423a80f392ba95b26af8e9ab91 upstream.
    
    Make sure to deregister the controller before disabling it to avoid
    hanging or leaking resources associated with the queue when the queue is
    non-empty.
    
    Fixes: 22ad2d8df77d ("spi: octeon: use devm_spi_register_master()")
    Cc: stable@vger.kernel.org      # 3.13
    Cc: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260409120419.388546-9-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: omap2-mcspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:35 2026 +0200

    spi: omap2-mcspi: fix controller deregistration
    
    commit fb45f95c377e4a4bdece2c5e17643b459c9c13e7 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: ccdc7bf92573 ("SPI: omap2_mcspi driver")
    Cc: stable@vger.kernel.org      # 2.6.23
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-6-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: orion: fix clock imbalance on registration failure [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 15:02:10 2026 +0200

    spi: orion: fix clock imbalance on registration failure
    
    commit 443cde0dc59c5d154156ac9f27a7dadef8ebc0c2 upstream.
    
    Make sure that the controller is not runtime suspended before disabling
    clocks on probe failure.
    
    Also restore the autosuspend setting.
    
    Fixes: 5c6786945b4e ("spi: spi-orion: add runtime PM support")
    Cc: stable@vger.kernel.org      # 3.17
    Cc: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421130211.1537628-3-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: orion: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 14 15:43:17 2026 +0200

    spi: orion: fix controller deregistration
    
    commit 220f4f11104a7f83b71543ef0e48dde1da2bc5d3 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: 60cadec9da7b ("spi: new orion_spi driver")
    Cc: stable@vger.kernel.org      # 2.6.27
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260414134319.978196-7-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: orion: fix runtime pm leak on unbind [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Apr 21 15:02:09 2026 +0200

    spi: orion: fix runtime pm leak on unbind
    
    commit 97b17dd8266d2e26d9ee3c75a0fa34ecde6944f0 upstream.
    
    Make sure to balance the runtime PM usage count on driver unbind so that
    the controller can be suspended when a driver is rebound.
    
    Also restore the autosuspend setting.
    
    This issue was flagged by Sashiko when reviewing a controller
    deregistration fix.
    
    Fixes: 5c6786945b4e ("spi: spi-orion: add runtime PM support")
    Cc: stable@vger.kernel.org      # 3.17
    Cc: Russell King <rmk+kernel@arm.linux.org.uk>
    Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=6
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260421130211.1537628-2-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: pic32-sqi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:37 2026 +0200

    spi: pic32-sqi: fix controller deregistration
    
    commit 420df79d1a618951eb0eb4331df95c9f4f763b8b upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 3270ac230f66 ("spi: pic32-sqi: add SPI driver for PIC32 SQI controller.")
    Cc: stable@vger.kernel.org      # 4.7
    Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-8-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: pic32: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:36 2026 +0200

    spi: pic32: fix controller deregistration
    
    commit 6b627bfe0c44e064aba464839e430dc1ca2b0bb8 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver")
    Cc: stable@vger.kernel.org      # 4.7
    Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-7-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: pl022: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:38 2026 +0200

    spi: pl022: fix controller deregistration
    
    commit 994b33366be9148240690e3e94bffe17c4d89458 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: b43d65f7e818 ("[ARM] 5546/1: ARM PL022 SSP/SPI driver v3")
    Cc: stable@vger.kernel.org      # 2.6.31
    Cc: Linus Walleij <linusw@kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-9-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: qup: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:39 2026 +0200

    spi: qup: fix controller deregistration
    
    commit 443e3a0005a4342b218b6dbd4c6387d3c7fed85a upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: 64ff247a978f ("spi: Add Qualcomm QUP SPI controller support")
    Cc: stable@vger.kernel.org      # 3.15
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-10-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: rspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:40 2026 +0200

    spi: rspi: fix controller deregistration
    
    commit 9944fa6726afb1e6eb7e2212764e7da0c97f2dcc upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 9e03d05eee4c ("spi: rcar: Use devm_spi_register_master()")
    Cc: stable@vger.kernel.org      # 3.14
    Cc: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-11-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: s3c64xx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:41 2026 +0200

    spi: s3c64xx: fix controller deregistration
    
    commit c1446b61e472da24d1547525193467b4bea4a7cb upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 91800f0e9005 ("spi/s3c64xx: Use managed registration")
    Cc: stable@vger.kernel.org      # 3.13: 76fbad410c0f
    Cc: stable@vger.kernel.org      # 3.13
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-12-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: sh-hspi: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:42 2026 +0200

    spi: sh-hspi: fix controller deregistration
    
    commit e63982e6392e45a6ecd68d6c317a081cc8e70143 upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like clocks during driver unbind.
    
    Fixes: 49e599b8595f ("spi: sh-hspi: control spi clock more correctly")
    Cc: stable@vger.kernel.org      # 3.4
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-13-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: sh-msiof: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:43 2026 +0200

    spi: sh-msiof: fix controller deregistration
    
    commit 45170f67a08b912ead6ccc387ba06954d1d4e53a upstream.
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Fixes: 1bd6363bc0c6 ("spi: sh-msiof: Use core message handling instead of spi-bitbang")
    Cc: stable@vger.kernel.org      # 3.15
    Cc: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-14-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: slave-mt27xx: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:45 2026 +0200

    spi: slave-mt27xx: fix controller deregistration
    
    commit ab840cbda4fe6c40e52f6415c47056797c663bb2 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks (by disabling runtime PM) during driver unbind.
    
    Fixes: 805be7ddf367 ("spi: mediatek: add spi slave for Mediatek MT2712")
    Cc: stable@vger.kernel.org      # 4.20
    Cc: Leilk Liu <leilk.liu@mediatek.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-16-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: sprd: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:46 2026 +0200

    spi: sprd: fix controller deregistration
    
    commit 123d17dbc5f07059752fa5e616385ca29a8f935a upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Note that the controller is suspended before disabling and releasing
    resources since commit de082d866cce ("spi: sprd: Add the SPI irq
    function for the SPI DMA mode") which avoids issues like unclocked
    accesses but prevents SPI device drivers from doing I/O during
    deregistration.
    
    Fixes: e7d973a31c24 ("spi: sprd: Add SPI driver for Spreadtrum SC9860")
    Cc: stable@vger.kernel.org      # 4.20
    Cc: Lanqing Liu <lanqing.liu@spreadtrum.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-17-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: st-ssc4: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Apr 10 10:17:47 2026 +0200

    spi: st-ssc4: fix controller deregistration
    
    commit 19857374010d06ca6a2f7c2c53464122eb804df0 upstream.
    
    Make sure to deregister the controller before disabling underlying
    resources like clocks during driver unbind.
    
    Fixes: 9e862375c542 ("spi: Add new driver for STMicroelectronics' SPI Controller")
    Cc: stable@vger.kernel.org      # 4.0
    Cc: Lee Jones <lee@kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-18-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: uniphier: fix controller deregistration [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu May 14 00:36:31 2026 -0400

    spi: uniphier: fix controller deregistration
    
    [ Upstream commit 0245435f777264ac45945ed2f325dd095a41d1af ]
    
    Make sure to deregister the controller before releasing underlying
    resources like DMA during driver unbind.
    
    Note that clocks were also disabled before the recent commit
    fdca270f8f87 ("spi: uniphier: Simplify clock handling with
    devm_clk_get_enabled()").
    
    Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
    Cc: stable@vger.kernel.org      # 4.19
    Cc: Keiji Hayashibara <hayashibara.keiji@socionext.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20260410081757.503099-25-johan@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: uniphier: Simplify clock handling with devm_clk_get_enabled() [+ + +]
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date:   Thu May 14 00:36:30 2026 -0400

    spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
    
    [ Upstream commit fdca270f8f87cae2eb5b619234b9dd11a863ce6b ]
    
    Replace devm_clk_get() followed by clk_prepare_enable() with
    devm_clk_get_enabled() for the clock. This removes the need for
    explicit clock enable and disable calls, as the managed API automatically
    handles clock disabling on device removal or probe failure.
    
    Remove the now-unnecessary clk_disable_unprepare() calls from the probe
    error path and the remove callback. Adjust error labels accordingly.
    
    Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
    Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Link: https://patch.msgid.link/b2deeefd4ef1a4bce71116aabfcb7e81400f6d37.1775546948.git.xiaopei01@kylinos.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 0245435f7772 ("spi: uniphier: fix controller deregistration")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
staging: media: atomisp: Disallow all private IOCTLs [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Feb 26 15:10:54 2026 +0200

    staging: media: atomisp: Disallow all private IOCTLs
    
    commit 2b7eb2c5dc72f0fc954ac4aa155f9e285e937f7c upstream.
    
    Disallow all private IOCTLs. These aren't quite as safe as one could
    assume of IOCTL handlers; disable them for now. Instead of removing the
    code, return in the beginning of the function if cmd is non-zero in order
    to keep static checkers happy.
    
    Reported-by: Soufiane Dani <soufianeda@tutanota.com>
    Closes: https://lore.kernel.org/linux-staging/20260210-atomisp-fix-v1-1-024429cbff31@tutanota.com/
    Cc: stable@vger.kernel.org
    Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
    Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: tcpm: reset internal port states on soft reset AMS [+ + +]
Author: Amit Sunil Dhamne <amitsd@google.com>
Date:   Tue Apr 14 00:58:32 2026 +0000

    usb: typec: tcpm: reset internal port states on soft reset AMS
    
    commit 2909f0d4994fb4306bf116df5ccee797791fce2c upstream.
    
    Reset internal port states (such as vdm_sm_running and
    explicit_contract) on soft reset AMS as the port needs to negotiate a
    new contract. The consequence of leaving the states in as-is cond are as
    follows:
      * port is in SRC power role and an explicit contract is negotiated
        with the port partner (in sink role)
      * port partner sends a Soft Reset AMS while VDM State Machine is
        running
      * port accepts the Soft Reset request and the port advertises src caps
      * port partner sends a Request message but since the explicit_contract
        and vdm_sm_running are true from previous negotiation, the port ends
        up sending Soft Reset instead of Accept msg.
    
    Stub Log:
    [  203.653942] AMS DISCOVER_IDENTITY start
    [  203.653947] PD TX, header: 0x176f
    [  203.655901] PD TX complete, status: 0
    [  203.657470] PD RX, header: 0x124f [1]
    [  203.657477] Rx VDM cmd 0xff008081 type 2 cmd 1 len 1
    [  203.657482] AMS DISCOVER_IDENTITY finished
    [  203.657484] cc:=4
    [  204.155698] PD RX, header: 0x144f [1]
    [  204.155718] Rx VDM cmd 0xeeee8001 type 0 cmd 1 len 1
    [  204.155741] PD TX, header: 0x196f
    [  204.157622] PD TX complete, status: 0
    [  204.160060] PD RX, header: 0x4d [1]
    [  204.160066] state change SRC_READY -> SOFT_RESET [rev2 SOFT_RESET_AMS]
    [  204.160076] PD TX, header: 0x163
    [  204.162486] PD TX complete, status: 0
    [  204.162832] AMS SOFT_RESET_AMS finished
    [  204.162840] cc:=4
    [  204.162891] AMS POWER_NEGOTIATION start
    [  204.162896] state change SOFT_RESET -> AMS_START [rev2 POWER_NEGOTIATION]
    [  204.162908] state change AMS_START -> SRC_SEND_CAPABILITIES [rev2 POWER_NEGOTIATION]
    [  204.162913] PD TX, header: 0x1361
    [  204.165529] PD TX complete, status: 0
    [  204.165571] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES_TIMEOUT @ 60 ms [rev2 POWER_NEGOTIATION]
    [  204.166996] PD RX, header: 0x1242 [1]
    [  204.167009] state change SRC_SEND_CAPABILITIES -> SRC_SOFT_RESET_WAIT_SNK_TX [rev2 POWER_NEGOTIATION]
    [  204.167019] AMS POWER_NEGOTIATION finished
    [  204.167020] cc:=4
    [  204.167083] AMS SOFT_RESET_AMS start
    [  204.167086] state change SRC_SOFT_RESET_WAIT_SNK_TX -> SOFT_RESET_SEND [rev2 SOFT_RESET_AMS]
    [  204.167092] PD TX, header: 0x16d
    [  204.168824] PD TX complete, status: 0
    [  204.168854] pending state change SOFT_RESET_SEND -> HARD_RESET_SEND @ 60 ms [rev2 SOFT_RESET_AMS]
    [  204.171876] PD RX, header: 0x43 [1]
    [  204.171879] AMS SOFT_RESET_AMS finished
    
    This causes COMMON.PROC.PD.11.2 check failure for
    TEST.PD.VDM.SRC.2_Rev2Src test on the PD compliance tester.
    
    Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
    Fixes: 8d3a0578ad1a ("usb: typec: tcpm: Respond Wait if VDM state machine is running")
    Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Cc: stable <stable@kernel.org>
    Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://patch.msgid.link/20260414-fix-soft-reset-v1-1-01d7cb9764e2@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vsock/virtio: fix accept queue count leak on transport mismatch [+ + +]
Author: Dudu Lu <phx0fer@gmail.com>
Date:   Mon Apr 13 21:14:09 2026 +0800

    vsock/virtio: fix accept queue count leak on transport mismatch
    
    commit 52bcb57a4e8a0865a76c587c2451906342ae1b2d upstream.
    
    virtio_transport_recv_listen() calls sk_acceptq_added() before
    vsock_assign_transport(). If vsock_assign_transport() fails or
    selects a different transport, the error path returns without
    calling sk_acceptq_removed(), permanently incrementing
    sk_ack_backlog.
    
    After approximately backlog+1 such failures, sk_acceptq_is_full()
    returns true, causing the listener to reject all new connections.
    
    Fix by moving sk_acceptq_added() to after the transport validation,
    matching the pattern used by vmci_transport and hyperv_transport.
    
    Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
    Signed-off-by: Dudu Lu <phx0fer@gmail.com>
    Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
    Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Link: https://patch.msgid.link/20260413131409.19022-1-phx0fer@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Cc: Luigi Leonardi <leonardi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vsock/virtio: fix empty payload in tap skb for non-linear buffers [+ + +]
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Fri May 8 18:44:11 2026 +0200

    vsock/virtio: fix empty payload in tap skb for non-linear buffers
    
    commit 3a3e3d90cbc79600544536723911657730759af3 upstream.
    
    For non-linear skbs, virtio_transport_build_skb() goes through
    virtio_transport_copy_nonlinear_skb() to copy the original payload
    in the new skb to be delivered to the vsockmon tap device.
    This manually initializes an iov_iter but does not set iov_iter.count.
    Since the iov_iter is zero-initialized, the copy length is zero and no
    payload is actually copied to the monitor interface, leaving data
    un-initialized.
    
    Fix this by removing the linear vs non-linear split and using
    skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as
    vhost-vsock already does. This handles both linear and non-linear skbs,
    properly initializes the iov_iter, and removes the now unused
    virtio_transport_copy_nonlinear_skb().
    
    While touching this code, let's also check the return value of
    skb_copy_datagram_iter(), even though it's unlikely to fail.
    
    Fixes: 4b0bf10eb077 ("vsock/virtio: non-linear skb handling for tap")
    Reported-by: Yiqi Sun <sunyiqixm@gmail.com>
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
    Reviewed-by: Arseniy Krasnov <avkrasnov@rulkc.org>
    Link: https://patch.msgid.link/20260508164411.261440-3-sgarzare@redhat.com
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Cc: Luigi Leonardi <leonardi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vsock/virtio: fix length and offset in tap skb for split packets [+ + +]
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Fri May 8 18:44:10 2026 +0200

    vsock/virtio: fix length and offset in tap skb for split packets
    
    commit 5f344d809e015fba3709e5219428c00b8ac5d7df upstream.
    
    virtio_transport_build_skb() builds a new skb to be delivered to the
    vsockmon tap device. To build the new skb, it uses the original skb
    data length as payload length, but as the comment notes, the original
    packet stored in the skb may have been split in multiple packets, so we
    need to use the length in the header, which is correctly updated before
    the packet is delivered to the tap, and the offset for the data.
    
    This was also similar to what we did before commit 71dc9ec9ac7d
    ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") where we probably
    missed something during the skb conversion.
    
    Also update the comment above, which was left stale by the skb
    conversion and still mentioned a buffer pointer that no longer exists.
    
    Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
    Reviewed-by: Arseniy Krasnov <avkrasnov@rulkc.org>
    Link: https://patch.msgid.link/20260508164411.261440-2-sgarzare@redhat.com
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Cc: Luigi Leonardi <leonardi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy [+ + +]
Author: Luigi Leonardi <leonardi@redhat.com>
Date:   Wed Apr 15 17:09:28 2026 +0200

    vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
    
    commit 080f22f5d30233faf3d83be3098f35b8be9b7a00 upstream.
    
    `virtio_transport_stream_do_peek()` does not account for the skb offset
    when computing the number of bytes to copy.
    
    This means that, after a partial recv() that advances the offset, a peek
    requesting more bytes than are available in the sk_buff causes
    `skb_copy_datagram_iter()` to go past the valid payload, resulting in
    a -EFAULT.
    
    The dequeue path already handles this correctly.
    Apply the same logic to the peek path.
    
    Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb")
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Acked-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
    Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
    Link: https://patch.msgid.link/20260415-fix_peek-v4-1-8207e872759e@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vsock: fix buffer size clamping order [+ + +]
Author: Norbert Szetei <norbert@doyensec.com>
Date:   Thu Apr 9 18:34:12 2026 +0200

    vsock: fix buffer size clamping order
    
    commit d114bfdc9b76bf93b881e195b7ec957c14227bab upstream.
    
    In vsock_update_buffer_size(), the buffer size was being clamped to the
    maximum first, and then to the minimum. If a user sets a minimum buffer
    size larger than the maximum, the minimum check overrides the maximum
    check, inverting the constraint.
    
    This breaks the intended socket memory boundaries by allowing the
    vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.
    
    Fix this by checking the minimum first, and then the maximum. This
    ensures the buffer size never exceeds the buffer_max_size.
    
    Fixes: b9f2b0ffde0c ("vsock: handle buffer_size sockopts in the core")
    Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Norbert Szetei <norbert@doyensec.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://patch.msgid.link/180118C5-8BCF-4A63-A305-4EE53A34AB9C@doyensec.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Cc: Luigi Leonardi <leonardi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>