commit a30cd70ab75aa6b7ee880b6ec2ecc492faf205b2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 2 10:32:11 2025 +0100

    Linux 6.6.69
    
    Link: https://lore.kernel.org/r/20241230154211.711515682@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Hardik Garg <hargar@linux.microsoft.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee18012c80155f6809522804099621070c69ec72
Author: Ming Lei <ming.lei@redhat.com>
Date:   Wed Dec 18 18:16:15 2024 +0800

    block: avoid to reuse `hctx` not removed from cpuhp callback list
    
    commit 85672ca9ceeaa1dcf2777a7048af5f4aee3fd02b upstream.
    
    If the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,
    otherwise use-after-free may be triggered.
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202412172217.b906db7c-lkp@intel.com
    Tested-by: kernel test robot <oliver.sang@intel.com>
    Fixes: 22465bbac53c ("blk-mq: move cpuhp callback registering out of q->sysfs_lock")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20241218101617.3275704-3-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 937fcde0e971d477525307380afa51538cd2e856
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Dec 5 10:28:33 2024 +0000

    ALSA: hda/realtek: Fix spelling mistake "Firelfy" -> "Firefly"
    
    commit 20c3b3e5f2641eff3d85f33e6a468ac052b169bd upstream.
    
    There is a spelling mistake in a literal string in the alc269_fixup_tbl
    quirk table. Fix it.
    
    Fixes: 0d08f0eec961 ("ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Link: https://patch.msgid.link/20241205102833.476190-1-colin.i.king@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff4dff0bbe7941c6a07f6e3ce9a63a6c9f125deb
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Wed May 29 19:36:05 2024 +0100

    x86/cpu/intel: Drop stray FAM6 check with new Intel CPU model defines
    
    commit 34b3fc558b537bdf99644dcde539e151716f6331 upstream.
    
    The outer if () should have been dropped when switching to c->x86_vfm.
    
    Fixes: 6568fc18c2f6 ("x86/cpu/intel: Switch to new Intel CPU model defines")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20240529183605.17520-1-andrew.cooper3@citrix.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0098f6a62ac704a7ca2418872c5c32b14d6fef5f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 20 12:44:16 2024 +0100

    ALSA: sh: Fix wrong argument order for copy_from_iter()
    
    commit 66a0a2b0473c39ae85c44628d14e4366fdc0aa0d upstream.
    
    Fix a brown paper bag bug I introduced at converting to the standard
    iter helper; the arguments were wrongly passed and have to be
    swapped.
    
    Fixes: 9b5f8ee43e48 ("ALSA: sh: Use standard helper for buffer accesses")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202412140019.jat5Dofr-lkp@intel.com/
    Link: https://patch.msgid.link/20241220114417.5898-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ce362065899ec7eb06518a04e1cb8b76fcaf8f8
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Dec 18 17:00:56 2024 +1030

    btrfs: sysfs: fix direct super block member reads
    
    commit fca432e73db2bec0fdbfbf6d98d3ebcd5388a977 upstream.
    
    The following sysfs entries are reading super block member directly,
    which can have a different endian and cause wrong values:
    
    - sys/fs/btrfs/<uuid>/nodesize
    - sys/fs/btrfs/<uuid>/sectorsize
    - sys/fs/btrfs/<uuid>/clone_alignment
    
    Thankfully those values (nodesize and sectorsize) are always aligned
    inside the btrfs_super_block, so it won't trigger unaligned read errors,
    just endian problems.
    
    Fix them by using the native cached members instead.
    
    Fixes: df93589a1737 ("btrfs: export more from FS_INFO to sysfs")
    CC: stable@vger.kernel.org
    Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e1a8225930719a9f352d56320214e33e2dde0a6
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Dec 9 16:43:44 2024 +0000

    btrfs: avoid monopolizing a core when activating a swap file
    
    commit 2c8507c63f5498d4ee4af404a8e44ceae4345056 upstream.
    
    During swap activation we iterate over the extents of a file and we can
    have many thousands of them, so we can end up in a busy loop monopolizing
    a core. Avoid this by doing a voluntary reschedule after processing each
    extent.
    
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13eb3cae1d8e23cce96c095abe34da8028c09ac5
Author: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
Date:   Mon Dec 9 11:46:15 2024 +0100

    power: supply: gpio-charger: Fix set charge current limits
    
    commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream.
    
    Fix set charge current limits for devices which allow to set the lowest
    charge current limit to be greater zero. If requested charge current limit
    is below lowest limit, the index equals current_limit_map_size which leads
    to accessing memory beyond allocated memory.
    
    Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
    Link: https://lore.kernel.org/r/20241209-fix-charge-current-limit-v1-1-760d9b8f2af3@liebherr.com
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c484dbafbae9124dcd987b3cb7f2f408a39b8bf5
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Wed Dec 18 12:07:42 2024 +0000

    i2c: microchip-core: fix "ghost" detections
    
    commit 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 upstream.
    
    Running i2c-detect currently produces an output akin to:
        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:                         08 -- 0a -- 0c -- 0e --
    10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f
    20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f
    30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e --
    40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e --
    70: 70 -- 72 -- 74 -- 76 --
    
    This happens because for an i2c_msg with a len of 0 the driver will
    mark the transmission of the message as a success once the START has
    been sent, without waiting for the devices on the bus to respond with an
    ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses
    the NAK is treated as part of the next test for the next address.
    
    Delete the fast path that marks a message as complete when idev->msg_len
    is zero after sending a START/RESTART since this isn't a valid scenario.
    
    CC: stable@vger.kernel.org
    Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1cc0e2560925bb5945353b89fa234a07e306ca8
Author: Carlos Song <carlos.song@nxp.com>
Date:   Wed Dec 18 12:42:38 2024 +0800

    i2c: imx: add imx7d compatible string for applying erratum ERR007805
    
    commit e0cec363197e41af870613e8e17b30bf0e3d41b5 upstream.
    
    Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver
    compatible string table, at the result, "fsl,imx21-i2c" will be
    matched, but it will cause erratum ERR007805 not be applied in fact.
    
    So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply
    the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf).
    
    "
    ERR007805 I2C: When the I2C clock speed is configured for 400 kHz,
    the SCL low period violates the I2C spec of 1.3 uS min
    
    Description: When the I2C module is programmed to operate at the
    maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL
    clock low period violates the I2C spec of 1.3 uS min. The user must
    reduce the clock speed to obtain the SCL low time to meet the 1.3us
    I2C minimum required. This behavior means the SoC is not compliant
    to the I2C spec at 400kHz.
    
    Workaround: To meet the clock low period requirement in fast speed
    mode, SCL must be configured to 384KHz or less.
    "
    
    "fsl,imx7d-i2c" already is documented in binding doc. This erratum
    fix has been included in imx6_i2c_hwdata and it is the same in all
    I.MX6/7/8, so just reuse it.
    
    Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
    Cc: stable@vger.kernel.org # v5.18+
    Signed-off-by: Carlos Song <carlos.song@nxp.com>
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/r/20241218044238.143414-1-carlos.song@nxp.com
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1f7476e07b93d65a1a3643dcb4a7bed80d4328d
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Dec 14 12:50:18 2024 +0100

    PCI/MSI: Handle lack of irqdomain gracefully
    
    commit a60b990798eb17433d0283788280422b1bd94b18 upstream.
    
    Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a
    RISCV platform which does not provide PCI/MSI support:
    
     WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32
     __pci_enable_msix_range+0x30c/0x596
     pci_msi_setup_msi_irqs+0x2c/0x32
     pci_alloc_irq_vectors_affinity+0xb8/0xe2
    
    RISCV uses hierarchical interrupt domains and correctly does not implement
    the legacy fallback. The warning triggers from the legacy fallback stub.
    
    That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent
    domain is associated with the device or not. There is a check for MSI-X,
    which has a legacy assumption. But that legacy fallback assumption is only
    valid when legacy support is enabled, but otherwise the check should simply
    return -ENOTSUPP.
    
    Loongarch tripped over the same problem and blindly enabled legacy support
    without implementing the legacy fallbacks. There are weak implementations
    which return an error, so the problem was papered over.
    
    Correct pci_msi_domain_supports() to evaluate the legacy mode and add
    the missing supported check into the MSI enable path to complete it.
    
    Fixes: d2a463b29741 ("PCI/MSI: Reject multi-MSI early")
    Reported-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/87ed2a8ow5.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f66c65f65251b07285a37ca3edf73a7fd1a9ebc
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Wed Dec 18 12:07:40 2024 +0000

    i2c: microchip-core: actually use repeated sends
    
    commit 9a8f9320d67b27ddd7f1ee88d91820197a0e908f upstream.
    
    At present, where repeated sends are intended to be used, the
    i2c-microchip-core driver sends a stop followed by a start. Lots of i2c
    devices must not malfunction in the face of this behaviour, because the
    driver has operated like this for years! Try to keep track of whether or
    not a repeated send is required, and suppress sending a stop in these
    cases.
    
    CC: stable@vger.kernel.org
    Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Link: https://lore.kernel.org/r/20241218-football-composure-e56df2461461@spud
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80120bb4eef7848d5aa3b1a0cd88367cd05fbe03
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Thu Dec 26 16:49:23 2024 +0000

    io_uring/sqpoll: fix sqpoll error handling races
    
    commit e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 upstream.
    
    BUG: KASAN: slab-use-after-free in __lock_acquire+0x370b/0x4a10 kernel/locking/lockdep.c:5089
    Call Trace:
    <TASK>
    ...
    _raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162
    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
    try_to_wake_up+0xb5/0x23c0 kernel/sched/core.c:4205
    io_sq_thread_park+0xac/0xe0 io_uring/sqpoll.c:55
    io_sq_thread_finish+0x6b/0x310 io_uring/sqpoll.c:96
    io_sq_offload_create+0x162/0x11d0 io_uring/sqpoll.c:497
    io_uring_create io_uring/io_uring.c:3724 [inline]
    io_uring_setup+0x1728/0x3230 io_uring/io_uring.c:3806
    ...
    
    Kun Hu reports that the SQPOLL creating error path has UAF, which
    happens if io_uring_alloc_task_context() fails and then io_sq_thread()
    manages to run and complete before the rest of error handling code,
    which means io_sq_thread_finish() is looking at already killed task.
    
    Note that this is mostly theoretical, requiring fault injection on
    the allocation side to trigger in practice.
    
    Cc: stable@vger.kernel.org
    Reported-by: Kun Hu <huk23@m.fudan.edu.cn>
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/0f2f1aa5729332612bd01fe0f2f385fd1f06ce7c.1735231717.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03041e474a6a8f1bfd4b96b164bb3165c48fa1a3
Author: Lizhi Xu <lizhi.xu@windriver.com>
Date:   Mon Dec 16 15:32:38 2024 +0800

    tracing: Prevent bad count for tracing_cpumask_write
    
    commit 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 upstream.
    
    If a large count is provided, it will trigger a warning in bitmap_parse_user.
    Also check zero for it.
    
    Cc: stable@vger.kernel.org
    Fixes: 9e01c1b74c953 ("cpumask: convert kernel trace functions")
    Link: https://lore.kernel.org/20241216073238.2573704-1-lizhi.xu@windriver.com
    Reported-by: syzbot+0aecfd34fb878546f3fd@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=0aecfd34fb878546f3fd
    Tested-by: syzbot+0aecfd34fb878546f3fd@syzkaller.appspotmail.com
    Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dafa7332e7c0a6b54c79be577dfad65bb40bb0b1
Author: Christian Göttsche <cgzones@googlemail.com>
Date:   Mon Nov 25 11:50:25 2024 +0100

    tracing: Constify string literal data member in struct trace_event_call
    
    commit 452f4b31e3f70a52b97890888eeb9eaa9a87139a upstream.
    
    The name member of the struct trace_event_call is assigned with
    generated string literals; declare them pointer to read-only.
    
    Reported by clang:
    
        security/landlock/syscalls.c:179:1: warning: initializing 'char *' with an expression of type 'const char[34]' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
          179 | SYSCALL_DEFINE3(landlock_create_ruleset,
              | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          180 |                 const struct landlock_ruleset_attr __user *const, attr,
              |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          181 |                 const size_t, size, const __u32, flags)
              |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ./include/linux/syscalls.h:226:36: note: expanded from macro 'SYSCALL_DEFINE3'
          226 | #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
              |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ./include/linux/syscalls.h:234:2: note: expanded from macro 'SYSCALL_DEFINEx'
          234 |         SYSCALL_METADATA(sname, x, __VA_ARGS__)                 \
              |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ./include/linux/syscalls.h:184:2: note: expanded from macro 'SYSCALL_METADATA'
          184 |         SYSCALL_TRACE_ENTER_EVENT(sname);                       \
              |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ./include/linux/syscalls.h:151:30: note: expanded from macro 'SYSCALL_TRACE_ENTER_EVENT'
          151 |                         .name                   = "sys_enter"#sname,    \
              |                                                   ^~~~~~~~~~~~~~~~~
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Mickaël Salaün <mic@digikod.net>
    Cc: Günther Noack <gnoack@google.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: Justin Stitt <justinstitt@google.com>
    Link: https://lore.kernel.org/20241125105028.42807-1-cgoettsche@seltendoof.de
    Fixes: b77e38aa240c3 ("tracing: add event trace infrastructure")
    Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1a26ea77f8138cc88e136ac5f15930e8ab2d5a0
Author: Chen Ridong <chenridong@huawei.com>
Date:   Tue Dec 17 00:48:18 2024 +0000

    freezer, sched: Report frozen tasks as 'D' instead of 'R'
    
    [ Upstream commit f718faf3940e95d5d34af9041f279f598396ab7d ]
    
    Before commit:
    
      f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
    
    the frozen task stat was reported as 'D' in cgroup v1.
    
    However, after rewriting the core freezer logic, the frozen task stat is
    reported as 'R'. This is confusing, especially when a task with stat of
    'S' is frozen.
    
    This bug can be reproduced with these steps:
    
            $ cd /sys/fs/cgroup/freezer/
            $ mkdir test
            $ sleep 1000 &
            [1] 739         // task whose stat is 'S'
            $ echo 739 > test/cgroup.procs
            $ echo FROZEN > test/freezer.state
            $ ps -aux | grep 739
            root     739  0.1  0.0   8376  1812 pts/0    R    10:56   0:00 sleep 1000
    
    As shown above, a task whose stat is 'S' was changed to 'R' when it was
    frozen.
    
    To solve this regression, simply maintain the same reported state as
    before the rewrite.
    
    [ mingo: Enhanced the changelog and comments ]
    
    Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Tejun Heo <tj@kernel.org>
    Acked-by: Michal Koutný <mkoutny@suse.com>
    Link: https://lore.kernel.org/r/20241217004818.3200515-1-chenridong@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60b57dc761d3a82666c6b84baeb20756b83cf5ca
Author: Jesse.zhang@amd.com <Jesse.zhang@amd.com>
Date:   Thu Dec 5 17:41:26 2024 +0800

    drm/amdkfd: pause autosuspend when creating pdd
    
    [ Upstream commit 438b39ac74e2a9dc0a5c9d653b7d8066877e86b1 ]
    
    When using MES creating a pdd will require talking to the GPU to
    setup the relevant context. The code here forgot to wake up the GPU
    in case it was in suspend, this causes KVM to EFAULT for passthrough
    GPU for example. This issue can be masked if the GPU was woken up by
    other things (e.g. opening the KMS node) first and have not yet gone to sleep.
    
    v4: do the allocation of proc_ctx_bo in a lazy fashion
    when the first queue is created in a process (Felix)
    
    Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
    Reviewed-by: Yunxiang Li <Yunxiang.Li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4312b60fa7aca47e70557de48a2c3b644465a51f
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Mon Jun 24 13:33:16 2024 +0530

    drm/amdkfd: Use device based logging for errors
    
    [ Upstream commit 62ec7d38b769ccf33b1080e69c2ae5b7344d116d ]
    
    Convert some pr_* to some dev_* APIs to identify the device.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f7042ffc7f328ba5675a20efe8e6e8f9db5bbfb
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Sep 26 12:00:23 2023 -0400

    drm/amdkfd: drop struct kfd_cu_info
    
    [ Upstream commit 0021d70a0654e668d457758110abec33dfbd3ba5 ]
    
    I think this was an abstraction back from when
    kfd supported both radeon and amdgpu.  Since we just
    support amdgpu now, there is no more need for this and
    we can use the amdgpu structures directly.
    
    This also avoids having the kfd_cu_info structures on
    the stack when inlining which can blow up the stack.
    
    Cc: Arnd Bergmann <arnd@kernel.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 798f21e8a6555cfae0f40ace794529e807004927
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Sep 21 10:32:09 2023 -0400

    drm/amdkfd: reduce stack size in kfd_topology_add_device()
    
    [ Upstream commit 4ff91f218547bfc3d230c00e46725b71a625acbc ]
    
    kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger than 1024 bytes
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866
    Cc: Arnd Bergmann <arnd@kernel.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8406848671ce9ae86f841037c97a7f4538d10134
Author: Len Brown <len.brown@intel.com>
Date:   Tue Nov 12 21:07:00 2024 -0500

    x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation
    
    [ Upstream commit c9a4b55431e5220347881e148725bed69c84e037 ]
    
    Under some conditions, MONITOR wakeups on Lunar Lake processors
    can be lost, resulting in significant user-visible delays.
    
    Add Lunar Lake to X86_BUG_MONITOR so that wake_up_idle_cpu()
    always sends an IPI, avoiding this potential delay.
    
    Reported originally here:
    
            https://bugzilla.kernel.org/show_bug.cgi?id=219364
    
    [ dhansen: tweak subject ]
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc:stable@vger.kernel.org
    Link: https://lore.kernel.org/all/a4aa8842a3c3bfdb7fe9807710eef159cbf0e705.1731463305.git.len.brown%40intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe48d03286b26d48539a4769246b0fc1cb0aad7a
Author: Tony Luck <tony.luck@intel.com>
Date:   Mon May 20 15:45:59 2024 -0700

    x86/cpu/intel: Switch to new Intel CPU model defines
    
    [ Upstream commit 6568fc18c2f62b4f35092e9680fe39f3500f4767 ]
    
    New CPU #defines encode vendor and family as well as model.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20240520224620.9480-29-tony.luck%40intel.com
    Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7ac1856b6ec8284682e9fe889a16b6437715fcd
Author: Tony Luck <tony.luck@intel.com>
Date:   Tue Apr 16 14:19:05 2024 -0700

    x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h
    
    [ Upstream commit f055b6260eb3ef20a6e310d1e555a5d5a0a28ca0 ]
    
    New CPU #defines encode vendor and family as well as model.
    
    Update the example usage comment in arch/x86/kernel/cpu/match.c
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20240416211941.9369-4-tony.luck@intel.com
    Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb3491e875f60580cd984490fd6fec87170d0533
Author: Tony Luck <tony.luck@intel.com>
Date:   Tue Apr 16 14:19:03 2024 -0700

    x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86
    
    [ Upstream commit a9d0adce69075192961f3be466c4810a21b7bc9e ]
    
    Refactor struct cpuinfo_x86 so that the vendor, family, and model
    fields are overlaid in a union with a 32-bit field that combines
    all three (together with a one byte reserved field in the upper
    byte).
    
    This will make it easy, cheap, and reliable to check all three
    values at once.
    
    See
    
      https://lore.kernel.org/r/Zgr6kT8oULbnmEXx@agluck-desk3
    
    for why the ordering is (low-to-high bits):
    
      (vendor, family, model)
    
      [ bp: Move comments over the line, add the backstory about the
        particular order of the fields. ]
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20240416211941.9369-2-tony.luck@intel.com
    Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3a3192993daa1ff0adcbfabbbf99aa9b4c5a350
Author: Tony Luck <tony.luck@intel.com>
Date:   Fri Mar 22 09:17:25 2024 -0700

    x86/cpu: Add model number for another Intel Arrow Lake mobile processor
    
    [ Upstream commit 8a8a9c9047d1089598bdb010ec44d7f14b4f9203 ]
    
    This one is the regular laptop CPU.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20240322161725.195614-1-tony.luck@intel.com
    Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 224d693c92037a01606c16de82e697f5d019aee6
Author: Tony Luck <tony.luck@intel.com>
Date:   Wed Jan 17 11:18:44 2024 -0800

    x86/cpu: Add model number for Intel Clearwater Forest processor
    
    [ Upstream commit 090e3bec01763e415bccae445f5bfe3d0c61b629 ]
    
    Server product based on the Atom Darkmont core.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20240117191844.56180-1-tony.luck@intel.com
    Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14172f8e9485c8fb100a683469d9f5fbe3849ee8
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 22 11:24:38 2024 -0500

    drm/amdgpu/hdp6.0: do a posting read when flushing HDP
    
    [ Upstream commit abe1cbaec6cfe9fde609a15cd6a12c812282ce77 ]
    
    Need to read back to make sure the write goes through.
    
    Cc: David Belanger <david.belanger@amd.com>
    Reviewed-by: Frank Min <frank.min@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9ad5cbf2495484e6408263f89b5010bfa3c06b7
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 22 11:23:56 2024 -0500

    drm/amdgpu/hdp5.0: do a posting read when flushing HDP
    
    [ Upstream commit cf424020e040be35df05b682b546b255e74a420f ]
    
    Need to read back to make sure the write goes through.
    
    Cc: David Belanger <david.belanger@amd.com>
    Reviewed-by: Frank Min <frank.min@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f60770d660dc6e1e371c7826ad4224143eb51551
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 22 11:22:51 2024 -0500

    drm/amdgpu/hdp4.0: do a posting read when flushing HDP
    
    [ Upstream commit c9b8dcabb52afe88413ff135a0953e3cc4128483 ]
    
    Need to read back to make sure the write goes through.
    
    Cc: David Belanger <david.belanger@amd.com>
    Reviewed-by: Frank Min <frank.min@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9cb2cc5b8b58d5b66cd9c11aadb9e287b9399b0
Author: Victor Zhao <Victor.Zhao@amd.com>
Date:   Mon Aug 19 11:16:13 2024 +0800

    drm/amd/amdgpu: allow use kiq to do hdp flush under sriov
    
    [ Upstream commit bf2bc61638033d118c9ef4ab1204295ba6694401 ]
    
    when use cpu to do page table update under sriov runtime, since mmio
    access is blocked, kiq has to be used to flush hdp.
    
    change WREG32_NO_KIQ to WREG32 to allow kiq.
    
    Signed-off-by: Victor Zhao <Victor.Zhao@amd.com>
    Reviewed-by: Emily Deng <Emily.Deng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: c9b8dcabb52a ("drm/amdgpu/hdp4.0: do a posting read when flushing HDP")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36a6e8aeae4a41767bb59f56b100c8cc9ffae2cb
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Fri Nov 22 14:42:02 2024 +0100

    pmdomain: core: Add missing put_device()
    
    [ Upstream commit b8f7bbd1f4ecff6d6277b8c454f62bb0a1c6dbe4 ]
    
    When removing a genpd we don't clean up the genpd->dev correctly. Let's add
    the missing put_device() in genpd_free_data() to fix this.
    
    Fixes: 401ea1572de9 ("PM / Domain: Add struct device to genpd")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Message-ID: <20241122134207.157283-2-ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13ced1c4980e021bc8005a220cc8afda74df287e
Author: Chris Chiu <chris.chiu@canonical.com>
Date:   Mon Dec 2 22:46:59 2024 +0800

    ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops
    
    [ Upstream commit 0d08f0eec961acdb0424a3e2cfb37cfb89154833 ]
    
    These HP laptops use Realtek HDA codec ALC3315 combined CS35L56
    Amplifiers. They need the quirk ALC285_FIXUP_HP_GPIO_LED to get
    the micmute LED working.
    
    Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
    Reviewed-by: Simon Trimmer <simont@opensource.cirrus.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241202144659.1553504-1-chris.chiu@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31fc2ce99308bf3d741f677cb1037684add5f41e
Author: Dirk Su <dirk.su@canonical.com>
Date:   Tue Nov 26 14:05:24 2024 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook X G1i
    
    [ Upstream commit 7ba81e4c3aa0ca25f06dc4456e7d36fa8e76385f ]
    
    HP EliteBook X G1i needs ALC285_FIXUP_HP_GPIO_LED quirk to
    make mic-mute/audio-mute working.
    
    Signed-off-by: Dirk Su <dirk.su@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241126060531.22759-1-dirk.su@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Stable-dep-of: 0d08f0eec961 ("ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d2b19ed4169c38dc6c61a186c5f7bdafc709691
Author: Qun-Wei Lin <qun-wei.lin@mediatek.com>
Date:   Tue Dec 24 16:10:57 2024 +0800

    sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers
    
    [ Upstream commit fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 ]
    
    When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the
    object_is_on_stack() function may produce incorrect results due to the
    presence of tags in the obj pointer, while the stack pointer does not have
    tags.  This discrepancy can lead to incorrect stack object detection and
    subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled.
    
    Example of the warning:
    
    ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364
    Modules linked in:
    CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4
    Hardware name: linux,dummy-virt (DT)
    pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __debug_object_init+0x330/0x364
    lr : __debug_object_init+0x330/0x364
    sp : ffff800082ea7b40
    x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534
    x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0
    x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418
    x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000
    x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e
    x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e
    x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800
    x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001
    x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4
    x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050
    Call trace:
     __debug_object_init+0x330/0x364
     debug_object_init_on_stack+0x30/0x3c
     schedule_hrtimeout_range_clock+0xac/0x26c
     schedule_hrtimeout+0x1c/0x30
     wait_task_inactive+0x1d4/0x25c
     kthread_bind_mask+0x28/0x98
     init_rescuer+0x1e8/0x280
     workqueue_init+0x1a0/0x3cc
     kernel_init_freeable+0x118/0x200
     kernel_init+0x28/0x1f0
     ret_from_fork+0x10/0x20
    ---[ end trace 0000000000000000 ]---
    ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.
    ------------[ cut here ]------------
    
    Link: https://lkml.kernel.org/r/20241113042544.19095-1-qun-wei.lin@mediatek.com
    Signed-off-by: Qun-Wei Lin <qun-wei.lin@mediatek.com>
    Cc: Andrew Yang <andrew.yang@mediatek.com>
    Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Cc: Casper Li <casper.li@mediatek.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Chinwen Chang <chinwen.chang@mediatek.com>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: Matthias Brugger <matthias.bgg@gmail.com>
    Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
    Cc: Shakeel Butt <shakeel.butt@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    [ Resolve line conflicts ]
    Signed-off-by: Wenshan Lan <jetlan9@163.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1258986bbd17954c674562971ad9a01171ff2127
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Tue Dec 24 14:22:39 2024 +0800

    MIPS: mipsregs: Set proper ISA level for virt extensions
    
    [ Upstream commit a640d6762a7d404644201ebf6d2a078e8dc84f97 ]
    
    c994a3ec7ecc ("MIPS: set mips32r5 for virt extensions") setted
    some instructions in virt extensions to ISA level mips32r5.
    
    However TLB related vz instructions was leftover, also this
    shouldn't be done to a R5 or R6 kernel buid.
    
    Reorg macros to set ISA level as needed when _ASM_SET_VIRT
    is called.
    
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37ee3b66eb62b91c234e1408a77a3221e4927e1d
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Tue Dec 24 14:09:18 2024 +0800

    MIPS: Probe toolchain support of -msym32
    
    [ Upstream commit 18ca63a2e23c5e170d2d7552b64b1f5ad019cd9b ]
    
    msym32 is not supported by LLVM toolchain.
    Workaround by probe toolchain support of msym32 for KBUILD_SYM32
    feature.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1544
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58bf93580fec30d84a46be41171c5fad98b5cc70
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Dec 6 19:16:07 2024 +0800

    blk-mq: move cpuhp callback registering out of q->sysfs_lock
    
    [ Upstream commit 22465bbac53c821319089016f268a2437de9b00a ]
    
    Registering and unregistering cpuhp callback requires global cpu hotplug lock,
    which is used everywhere. Meantime q->sysfs_lock is used in block layer
    almost everywhere.
    
    It is easy to trigger lockdep warning[1] by connecting the two locks.
    
    Fix the warning by moving blk-mq's cpuhp callback registering out of
    q->sysfs_lock. Add one dedicated global lock for covering registering &
    unregistering hctx's cpuhp, and it is safe to do so because hctx is
    guaranteed to be live if our request_queue is live.
    
    [1] https://lore.kernel.org/lkml/Z04pz3AlvI4o0Mr8@agluck-desk3/
    
    Cc: Reinette Chatre <reinette.chatre@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Peter Newman <peternewman@google.com>
    Cc: Babu Moger <babu.moger@amd.com>
    Reported-by: Luck Tony <tony.luck@intel.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20241206111611.978870-3-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 079fcc926b0bf5c0d2169f67254d43c8bfdcb054
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Dec 6 19:16:06 2024 +0800

    blk-mq: register cpuhp callback after hctx is added to xarray table
    
    [ Upstream commit 4bf485a7db5d82ddd0f3ad2b299893199090375e ]
    
    We need to retrieve 'hctx' from xarray table in the cpuhp callback, so the
    callback should be registered after this 'hctx' is added to xarray table.
    
    Cc: Reinette Chatre <reinette.chatre@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Peter Newman <peternewman@google.com>
    Cc: Babu Moger <babu.moger@amd.com>
    Cc: Luck Tony <tony.luck@intel.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20241206111611.978870-2-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 12c0ddd6c551c1e438b087f874b4f1223a75f7ea
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Nov 12 20:58:21 2024 +0800

    virtio-blk: don't keep queue frozen during system suspend
    
    [ Upstream commit 7678abee0867e6b7fb89aa40f6e9f575f755fb37 ]
    
    Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
    deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
    PM callbacks. And the motivation is to drain inflight IOs before suspending.
    
    block layer's queue freeze looks very handy, but it is also easy to cause
    deadlock, such as, any attempt to call into bio_queue_enter() may run into
    deadlock if the queue is frozen in current context. There are all kinds
    of ->suspend() called in suspend context, so keeping queue frozen in the
    whole suspend context isn't one good idea. And Marek reported lockdep
    warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().
    
    [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/
    
    Given the motivation is to drain in-flight IOs, it can be done by calling
    freeze & unfreeze, meantime restore to previous behavior by keeping queue
    quiesced during suspend.
    
    Cc: Yi Sun <yi.sun@unisoc.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Cc: virtualization@lists.linux.dev
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
    Link: https://lore.kernel.org/r/20241112125821.1475793-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9735d40f5fde9970aa46e828ecc85c32571d58a2
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Dec 4 15:20:07 2024 +0200

    drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()
    
    [ Upstream commit e54b00086f7473dbda1a7d6fc47720ced157c6a8 ]
    
    While receiving an MST up request message from one thread in
    drm_dp_mst_handle_up_req(), the MST topology could be removed from
    another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing
    mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.
    This could lead to a NULL deref/use-after-free of mst_primary in
    drm_dp_mst_handle_up_req().
    
    Avoid the above by holding a reference for mst_primary in
    drm_dp_mst_handle_up_req() while it's used.
    
    v2: Fix kfreeing the request if getting an mst_primary reference fails.
    
    Cc: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com> (v1)
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241204132007.3132494-1-imre.deak@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5edf9f786a186354dadf10b9e80b80bee68f1160
Author: Purushothama Siddaiah <psiddaiah@mvista.com>
Date:   Thu Dec 5 12:34:26 2024 +0530

    spi: omap2-mcspi: Fix the IS_ERR() bug for devm_clk_get_optional_enabled()
    
    [ Upstream commit 4c6ac5446d060f0bf435ccc8bc3aa7b7b5f718ad ]
    
    The devm_clk_get_optional_enabled() function returns error
    pointers(PTR_ERR()). So use IS_ERR() to check it.
    
    Verified on K3-J7200 EVM board, without clock node mentioned
    in the device tree.
    
    Signed-off-by: Purushothama Siddaiah <psiddaiah@mvista.com>
    Reviewed-by: Corey Minyard <cminyard@mvista.com>
    Link: https://patch.msgid.link/20241205070426.1861048-1-psiddaiah@mvista.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3556af9a68afc4d9decfbe0ef661e4aee6484a93
Author: Cathy Avery <cavery@redhat.com>
Date:   Wed Nov 27 13:13:24 2024 -0500

    scsi: storvsc: Do not flag MAINTENANCE_IN return of SRB_STATUS_DATA_OVERRUN as an error
    
    [ Upstream commit b1aee7f034615b6824d2c70ddb37ef9fc23493b7 ]
    
    This partially reverts commit 812fe6420a6e ("scsi: storvsc: Handle
    additional SRB status values").
    
    HyperV does not support MAINTENANCE_IN resulting in FC passthrough
    returning the SRB_STATUS_DATA_OVERRUN value. Now that
    SRB_STATUS_DATA_OVERRUN is treated as an error, multipath ALUA paths go
    into a faulty state as multipath ALUA submits RTPG commands via
    MAINTENANCE_IN.
    
    [    3.215560] hv_storvsc 1d69d403-9692-4460-89f9-a8cbcc0f94f3:
    tag#230 cmd 0xa3 status: scsi 0x0 srb 0x12 hv 0xc0000001
    [    3.215572] scsi 1:0:0:32: alua: rtpg failed, result 458752
    
    Make MAINTENANCE_IN return success to avoid the error path as is
    currently done with INQUIRY and MODE_SENSE.
    
    Suggested-by: Michael Kelley <mhklinux@outlook.com>
    Signed-off-by: Cathy Avery <cavery@redhat.com>
    Link: https://lore.kernel.org/r/20241127181324.3318443-1-cavery@redhat.com
    Reviewed-by: Michael Kelley <mhklinux@outlook.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf4bea16bb6d2def46b4d056276d6b33dff3dfbf
Author: Ranjan Kumar <ranjan.kumar@broadcom.com>
Date:   Sun Nov 10 23:03:40 2024 +0530

    scsi: mpt3sas: Diag-Reset when Doorbell-In-Use bit is set during driver load time
    
    [ Upstream commit 3f5eb062e8aa335643181c480e6c590c6cedfd22 ]
    
    Issue a Diag-Reset when the "Doorbell-In-Use" bit is set during the
    driver load/initialization.
    
    Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
    Link: https://lore.kernel.org/r/20241110173341.11595-2-ranjan.kumar@broadcom.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cecca8b420635f1c5a5ef51947f8acecc3f547c1
Author: Aapo Vienamo <aapo.vienamo@iki.fi>
Date:   Wed Dec 4 10:02:08 2024 +0200

    spi: intel: Add Panther Lake SPI controller support
    
    [ Upstream commit ceb259e43bf572ba7d766e1679ba73861d16203a ]
    
    The Panther Lake SPI controllers are compatible with the Cannon Lake
    controllers. Add support for following SPI controller device IDs:
     - H-series: 0xe323
     - P-series: 0xe423
     - U-series: 0xe423
    
    Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Link: https://patch.msgid.link/20241204080208.1036537-1-mika.westerberg@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb9b647a68342b8d2848dc7f596288efab0def05
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Sat Nov 23 23:47:00 2024 +0100

    platform/x86: asus-nb-wmi: Ignore unknown event 0xCF
    
    [ Upstream commit e9fba20c29e27dc99e55e1c550573a114561bf8c ]
    
    On the Asus X541UAK an unknown event 0xCF is emited when the charger
    is plugged in. This is caused by the following AML code:
    
        If (ACPS ())
        {
            ACPF = One
            Local0 = 0x58
            If (ATKP)
            {
                ^^^^ATKD.IANE (0xCF)
            }
        }
        Else
        {
            ACPF = Zero
            Local0 = 0x57
        }
    
        Notify (AC0, 0x80) // Status Change
        If (ATKP)
        {
            ^^^^ATKD.IANE (Local0)
        }
    
        Sleep (0x64)
        PNOT ()
        Sleep (0x0A)
        NBAT (0x80)
    
    Ignore the 0xCF event to silence the unknown event warning.
    
    Reported-by: Pau Espin Pedrol <pespin@espeweb.net>
    Closes: https://lore.kernel.org/platform-driver-x86/54d4860b-ec9c-4992-acf6-db3f90388293@espeweb.net
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20241123224700.18530-1-W_Armin@gmx.de
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4eb54230b0baeec9872dc6e16e176e681a763e98
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Mon Dec 2 16:42:08 2024 +0800

    LoongArch: BPF: Adjust the parameter of emit_jirl()
    
    [ Upstream commit c1474bb0b7cff4e8481095bd0618b8f6c2f0aeb4 ]
    
    The branch instructions beq, bne, blt, bge, bltu, bgeu and jirl belong
    to the format reg2i16, but the sequence of oprand is different for the
    instruction jirl. So adjust the parameter order of emit_jirl() to make
    it more readable correspond with the Instruction Set Architecture manual.
    
    Here are the instruction formats:
    
      beq     rj, rd, offs16
      bne     rj, rd, offs16
      blt     rj, rd, offs16
      bge     rj, rd, offs16
      bltu    rj, rd, offs16
      bgeu    rj, rd, offs16
      jirl    rd, rj, offs16
    
    Link: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#branch-instructions
    Suggested-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fc47124442da8549b70310eebba07fc7100ee87
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Mon Dec 2 16:42:07 2024 +0800

    LoongArch: Fix reserving screen info memory for above-4G firmware
    
    [ Upstream commit 55dc2f8f263448f1e6c7ef135d08e640d5a4826e ]
    
    Since screen_info.lfb_base is a __u32 type, an above-4G address need an
    ext_lfb_base to present its higher 32bits. In init_screen_info() we can
    use __screen_info_lfb_base() to handle this case for reserving screen
    info memory.
    
    Signed-off-by: Xuefeng Zhao <zhaoxuefeng@loongson.cn>
    Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
    Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e448ea8df48f205596479bc36f2a8d60a1d72a8
Author: Mark Brown <broonie@kernel.org>
Date:   Wed Nov 27 13:35:06 2024 +0000

    regmap: Use correct format specifier for logging range errors
    
    [ Upstream commit 3f1aa0c533d9dd8a835caf9a6824449c463ee7e2 ]
    
    The register addresses are unsigned ints so we should use %u not %d to
    log them.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://patch.msgid.link/20241127-regmap-test-high-addr-v1-1-74a48a9e0dc5@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ad1feaa0bd00d9a07c2138fcbc9236caca30b10
Author: Brahmajit Das <brahmajit.xyz@gmail.com>
Date:   Tue Nov 26 11:41:35 2024 +0530

    smb: server: Fix building with GCC 15
    
    [ Upstream commit e18655cf35a5958fbf4ae9ca3ebf28871a3a1801 ]
    
    GCC 15 introduces -Werror=unterminated-string-initialization by default,
    this results in the following build error
    
    fs/smb/server/smb_common.c:21:35: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-ini
    tialization]
       21 | static const char basechars[43] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_-!@#$%";
          |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    
    To this we are replacing char basechars[43] with a character pointer
    and then using strlen to get the length.
    
    Signed-off-by: Brahmajit Das <brahmajit.xyz@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7dbf2af85cd35d56f5b0e0fe8284d6e1a65b777c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 28 11:49:38 2024 +0100

    ALSA: sh: Use standard helper for buffer accesses
    
    [ Upstream commit 9b5f8ee43e48c25fbe1a10163ec04343d750acd0 ]
    
    The SH DAC audio driver uses the kmalloc'ed buffer as the main PCM
    buffer, and the data is transferred via hrtimer callbacks manually
    from there to the hardware.  Meanwhile, some of its code are written
    as if the buffer is on iomem and use the special helpers for the iomem
    (e.g. copy_from_iter_toio() or memset_io()).  Those are rather useless
    and the standard helpers should be used.
    
    Similarly, the PCM mmap callback is set to a special one with
    snd_pcm_lib_mmap_iomem, but this is also nonsense, because SH
    architecture doesn't support this function, hence it leads just to
    NULL -- the fallback to the standard helper.
    
    This patch replaces those special setups with the standard ones.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202411281337.I4M07b7i-lkp@intel.com/
    Link: https://patch.msgid.link/20241128104939.13755-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39c860c96c647d4d6d60b4e8171a9fabeadc43b4
Author: bo liu <bo.liu@senarytech.com>
Date:   Fri Nov 29 09:44:41 2024 +0800

    ALSA: hda/conexant: fix Z60MR100 startup pop issue
    
    [ Upstream commit 947c4012f8f03a8bb946beb6e5294d5e32817d67 ]
    
    When Z60MR100 startup, speaker will output a pop. To fix this issue,
    we mute codec by init verbs in bios when system startup, and set GPIO
    to low to unmute codec in codec driver when it loaded .
    
    [ white space fixes and compile warning fix by tiwai ]
    
    Signed-off-by: bo liu <bo.liu@senarytech.com>
    Link: https://patch.msgid.link/20241129014441.437205-1-bo.liu@senarytech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3dea3c59c4bd3a6957b04e7332ad1df2ac6ca47a
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 26 12:46:00 2024 +0100

    udf: Skip parent dir link count update if corrupted
    
    [ Upstream commit c5566903af56dd1abb092f18dcb0c770d6cd8dcb ]
    
    If the parent directory link count is too low (likely directory inode
    corruption), just skip updating its link count as if it goes to 0 too
    early it can cause unexpected issues.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f50783148ec98a1d38b87422e2ceaf2380b7b606
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Mon Sep 23 19:48:33 2024 +0200

    scsi: megaraid_sas: Fix for a potential deadlock
    
    [ Upstream commit 50740f4dc78b41dec7c8e39772619d5ba841ddd7 ]
    
    This fixes a 'possible circular locking dependency detected' warning
          CPU0                    CPU1
          ----                    ----
     lock(&instance->reset_mutex);
                                  lock(&shost->scan_mutex);
                                  lock(&instance->reset_mutex);
     lock(&shost->scan_mutex);
    
    Fix this by temporarily releasing the reset_mutex.
    
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20240923174833.45345-1-thenzl@redhat.com
    Acked-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbd7deb459b2a12f82b9e052f4fa95cf365dbfcd
Author: Magnus Lindholm <linmag7@gmail.com>
Date:   Wed Nov 13 23:51:49 2024 +0100

    scsi: qla1280: Fix hw revision numbering for ISP1020/1040
    
    [ Upstream commit c064de86d2a3909222d5996c5047f64c7a8f791b ]
    
    Fix the hardware revision numbering for Qlogic ISP1020/1040 boards.  HWMASK
    suggests that the revision number only needs four bits, this is consistent
    with how NetBSD does things in their ISP driver. Verified on a IPS1040B
    which is seen as rev 5 not as BIT_4.
    
    Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
    Link: https://lore.kernel.org/r/20241113225636.2276-1-linmag7@gmail.com
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab9ae7e789ab0bbe193e7b4278f6aa5e2e9b84c0
Author: Yassine Oudjana <y.oudjana@protonmail.com>
Date:   Wed Nov 6 10:47:55 2024 +0000

    watchdog: mediatek: Add support for MT6735 TOPRGU/WDT
    
    [ Upstream commit 15ddf704f56f8c95ff74dfd1157ed8646b322fa1 ]
    
    Add support for the Top Reset Generation Unit/Watchdog Timer found on
    MT6735.
    
    Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20241106104738.195968-3-y.oudjana@protonmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e64809e8754ae12d6b2464f164e6a9cd92022e74
Author: James Hilliard <james.hilliard1@gmail.com>
Date:   Fri Oct 25 00:34:40 2024 -0600

    watchdog: it87_wdt: add PWRGD enable quirk for Qotom QCML04
    
    [ Upstream commit 43439076383a7611300334d1357c0f8883f40816 ]
    
    For the watchdog timer to work properly on the QCML04 board we need to
    set PWRGD enable in the Environment Controller Configuration Registers
    Special Configuration Register 1 when it is not already set, this may
    be the case when the watchdog is not enabled from within the BIOS.
    
    Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20241025063441.3494837-1-james.hilliard1@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4d67fa7158daedfe0dbb264beb39238477f4023
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Wed Dec 11 09:10:55 2024 +0900

    tracing/kprobe: Make trace_kprobe's module callback called after jump_label update
    
    [ Upstream commit d685d55dfc86b1a4bdcec77c3c1f8a83f181264e ]
    
    Make sure the trace_kprobe's module notifer callback function is called
    after jump_label's callback is called. Since the trace_kprobe's callback
    eventually checks jump_label address during registering new kprobe on
    the loading module, jump_label must be updated before this registration
    happens.
    
    Link: https://lore.kernel.org/all/173387585556.995044.3157941002975446119.stgit@devnote2/
    
    Fixes: 614243181050 ("tracing/kprobes: Support module init function probing")
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23681bc4b59f6438b602df509372dc6a7d7e10f4
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Thu Dec 19 14:57:34 2024 +0100

    stddef: make __struct_group() UAPI C++-friendly
    
    [ Upstream commit 724c6ce38bbaeb4b3f109b0e066d6c0ecd15446c ]
    
    For the most part of the C++ history, it couldn't have type
    declarations inside anonymous unions for different reasons. At the
    same time, __struct_group() relies on the latters, so when the @TAG
    argument is not empty, C++ code doesn't want to build (even under
    `extern "C"`):
    
    ../linux/include/uapi/linux/pkt_cls.h:25:24: error:
    'struct tc_u32_sel::<unnamed union>::tc_u32_sel_hdr,' invalid;
    an anonymous union may only have public non-static data members
    [-fpermissive]
    
    The safest way to fix this without trying to switch standards (which
    is impossible in UAPI anyway) etc., is to disable tag declaration
    for that language. This won't break anything since for now it's not
    buildable at all.
    Use a separate definition for __struct_group() when __cplusplus is
    defined to mitigate the error, including the version from tools/.
    
    Fixes: 50d7bd38c3aa ("stddef: Introduce struct_group() helper macro")
    Reported-by: Christopher Ferris <cferris@google.com>
    Closes: https://lore.kernel.org/linux-hardening/Z1HZpe3WE5As8UAz@google.com
    Suggested-by: Kees Cook <kees@kernel.org> # __struct_group_tag()
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/r/20241219135734.2130002-1-aleksander.lobakin@intel.com
    Signed-off-by: Kees Cook <kees@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7f60ffdfd96f8fc826f1d61a1c6067d828e20b9
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Fri Dec 13 21:17:58 2024 -0800

    powerpc/pseries/vas: Add close() callback in vas_vm_ops struct
    
    [ Upstream commit 05aa156e156ef3168e7ab8a68721945196495c17 ]
    
    The mapping VMA address is saved in VAS window struct when the
    paste address is mapped. This VMA address is used during migration
    to unmap the paste address if the window is active. The paste
    address mapping will be removed when the window is closed or with
    the munmap(). But the VMA address in the VAS window is not updated
    with munmap() which is causing invalid access during migration.
    
    The KASAN report shows:
    [16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8
    [16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928
    
    [16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G    B              6.11.0-rc5-nxgzip #2
    [16386.255128] Tainted: [B]=BAD_PAGE
    [16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries
    [16386.255181] Call Trace:
    [16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable)
    [16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764
    [16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8
    [16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0
    [16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8
    [16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc
    [16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4
    ...
    
    [16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s:
    [16386.256149]  kasan_save_stack+0x34/0x68
    [16386.256163]  kasan_save_track+0x34/0x80
    [16386.256175]  kasan_save_alloc_info+0x58/0x74
    [16386.256196]  __kasan_slab_alloc+0xb8/0xdc
    [16386.256209]  kmem_cache_alloc_noprof+0x200/0x3d0
    [16386.256225]  vm_area_alloc+0x44/0x150
    [16386.256245]  mmap_region+0x214/0x10c4
    [16386.256265]  do_mmap+0x5fc/0x750
    [16386.256277]  vm_mmap_pgoff+0x14c/0x24c
    [16386.256292]  ksys_mmap_pgoff+0x20c/0x348
    [16386.256303]  sys_mmap+0xd0/0x160
    ...
    
    [16386.256350] Freed by task 0 on cpu 31 at 16386.204848s:
    [16386.256363]  kasan_save_stack+0x34/0x68
    [16386.256374]  kasan_save_track+0x34/0x80
    [16386.256384]  kasan_save_free_info+0x64/0x10c
    [16386.256396]  __kasan_slab_free+0x120/0x204
    [16386.256415]  kmem_cache_free+0x128/0x450
    [16386.256428]  vm_area_free_rcu_cb+0xa8/0xd8
    [16386.256441]  rcu_do_batch+0x2c8/0xcf0
    [16386.256458]  rcu_core+0x378/0x3c4
    [16386.256473]  handle_softirqs+0x20c/0x60c
    [16386.256495]  do_softirq_own_stack+0x6c/0x88
    [16386.256509]  do_softirq_own_stack+0x58/0x88
    [16386.256521]  __irq_exit_rcu+0x1a4/0x20c
    [16386.256533]  irq_exit+0x20/0x38
    [16386.256544]  interrupt_async_exit_prepare.constprop.0+0x18/0x2c
    ...
    
    [16386.256717] Last potentially related work creation:
    [16386.256729]  kasan_save_stack+0x34/0x68
    [16386.256741]  __kasan_record_aux_stack+0xcc/0x12c
    [16386.256753]  __call_rcu_common.constprop.0+0x94/0xd04
    [16386.256766]  vm_area_free+0x28/0x3c
    [16386.256778]  remove_vma+0xf4/0x114
    [16386.256797]  do_vmi_align_munmap.constprop.0+0x684/0x870
    [16386.256811]  __vm_munmap+0xe0/0x1f8
    [16386.256821]  sys_munmap+0x54/0x6c
    [16386.256830]  system_call_exception+0x1a0/0x4a0
    [16386.256841]  system_call_vectored_common+0x15c/0x2ec
    
    [16386.256868] The buggy address belongs to the object at c00000014a819670
                    which belongs to the cache vm_area_struct of size 168
    [16386.256887] The buggy address is located 0 bytes inside of
                    freed 168-byte region [c00000014a819670, c00000014a819718)
    
    [16386.256915] The buggy address belongs to the physical page:
    [16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81
    [16386.256950] memcg:c0000000ba430001
    [16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff)
    [16386.256975] page_type: 0xfdffffff(slab)
    [16386.256990] raw: 043ffff800000000 c00000000501c080 0000000000000000 5deadbee00000001
    [16386.257003] raw: 0000000000000000 00000000011a011a 00000001fdffffff c0000000ba430001
    [16386.257018] page dumped because: kasan: bad access detected
    
    This patch adds close() callback in vas_vm_ops vm_operations_struct
    which will be executed during munmap() before freeing VMA. The VMA
    address in the VAS window is set to NULL after holding the window
    mmap_mutex.
    
    Fixes: 37e6764895ef ("powerpc/pseries/vas: Add VAS migration handler")
    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20241214051758.997759-1-haren@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd45c87782738715d5e7c167f8dabf0814a7394a
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Oct 23 11:40:56 2024 +0300

    mtd: rawnand: fix double free in atmel_pmecc_create_user()
    
    commit d8e4771f99c0400a1873235704b28bb803c83d17 upstream.
    
    The "user" pointer was converted from being allocated with kzalloc() to
    being allocated by devm_kzalloc().  Calling kfree(user) will lead to a
    double free.
    
    Fixes: 6d734f1bfc33 ("mtd: rawnand: atmel: Fix possible memory leak")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e658f1c133b854b2ae799147301d82dddb8f3162
Author: Chen Ridong <chenridong@huawei.com>
Date:   Tue Oct 29 08:28:45 2024 +0000

    dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset
    
    commit c43ec96e8d34399bd9dab2f2dc316b904892133f upstream.
    
    The at_xdmac_memset_create_desc may return NULL, which will lead to a
    null pointer dereference. For example, the len input is error, or the
    atchan->free_descs_list is empty and memory is exhausted. Therefore, add
    check to avoid this.
    
    Fixes: b206d9a23ac7 ("dmaengine: xdmac: Add memset support")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Link: https://lore.kernel.org/r/20241029082845.1185380-1-chenridong@huaweicloud.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa2381a1ea39f2353e4a81ff0caabee1e2cb3d77
Author: Sasha Finkelstein <fnkl.kernel@gmail.com>
Date:   Sun Nov 24 16:48:28 2024 +0100

    dmaengine: apple-admac: Avoid accessing registers in probe
    
    commit 8d55e8a16f019211163f1180fd9f9fbe05901900 upstream.
    
    The ADMAC attached to the AOP has complex power sequencing, and is
    power gated when the probe callback runs. Move the register reads
    to other functions, where we can guarantee that the hardware is
    switched on.
    
    Fixes: 568aa6dd641f ("dmaengine: apple-admac: Allocate cache SRAM to channels")
    Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
    Link: https://lore.kernel.org/r/20241124-admac-power-v1-1-58f2165a4d55@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34d2c9c6de737eb3065d0a2e333bf3cc93fdff50
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Sat Dec 21 16:57:12 2024 +0900

    dmaengine: fsl-edma: implement the cleanup path of fsl_edma3_attach_pd()
    
    commit ccfa3131d4a0347988e73638edea5c8281b6d2c7 upstream.
    
    Current implementation of fsl_edma3_attach_pd() does not provide a
    cleanup path, resulting in a memory leak. For example,
    dev_pm_domain_detach() is not called after dev_pm_domain_attach_by_id(),
    and the device link created with the DL_FLAG_STATELESS is not released
    explicitly.
    
    Therefore, provide a cleanup function fsl_edma3_detach_pd() and call it
    upon failure. Also add a devm_add_action_or_reset() call with this
    function after a successful fsl_edma3_attach_pd().
    
    Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://lore.kernel.org/r/20241221075712.3297200-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2705359161f3ecce2b7712581d62e2755d30124
Author: Akhil R <akhilrajeev@nvidia.com>
Date:   Thu Dec 12 18:14:12 2024 +0530

    dmaengine: tegra: Return correct DMA status when paused
    
    commit ebc008699fd95701c9af5ebaeb0793eef81a71d5 upstream.
    
    Currently, the driver does not return the correct DMA status when a DMA
    pause is issued by the client drivers. This causes GPCDMA users to
    assume that DMA is still running, while in reality, the DMA is paused.
    
    Return DMA_PAUSED for tx_status() if the channel is paused in the middle
    of a transfer.
    
    Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
    Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
    Link: https://lore.kernel.org/r/20241212124412.5650-1-kkartik@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8cf5aa06d07453c5331711ca6496ee9bf6a9d148
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Nov 4 11:50:50 2024 +0200

    dmaengine: dw: Select only supported masters for ACPI devices
    
    commit f0e870a0e9c5521f2952ea9f3ea9d3d122631a89 upstream.
    
    The recently submitted fix-commit revealed a problem in the iDMA 32-bit
    platform code. Even though the controller supported only a single master
    the dw_dma_acpi_filter() method hard-coded two master interfaces with IDs
    0 and 1. As a result the sanity check implemented in the commit
    b336268dde75 ("dmaengine: dw: Add peripheral bus width verification")
    got incorrect interface data width and thus prevented the client drivers
    from configuring the DMA-channel with the EINVAL error returned. E.g.,
    the next error was printed for the PXA2xx SPI controller driver trying
    to configure the requested channels:
    
    > [  164.525604] pxa2xx_spi_pci 0000:00:07.1: DMA slave config failed
    > [  164.536105] pxa2xx_spi_pci 0000:00:07.1: failed to get DMA TX descriptor
    > [  164.543213] spidev spi-SPT0001:00: SPI transfer failed: -16
    
    The problem would have been spotted much earlier if the iDMA 32-bit
    controller supported more than one master interfaces. But since it
    supports just a single master and the iDMA 32-bit specific code just
    ignores the master IDs in the CTLLO preparation method, the issue has
    been gone unnoticed so far.
    
    Fix the problem by specifying the default master ID for both memory
    and peripheral devices in the driver data. Thus the issue noticed for
    the iDMA 32-bit controllers will be eliminated and the ACPI-probed
    DW DMA controllers will be configured with the correct master ID by
    default.
    
    Cc: stable@vger.kernel.org
    Fixes: b336268dde75 ("dmaengine: dw: Add peripheral bus width verification")
    Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware")
    Reported-by: Ferry Toth <fntoth@gmail.com>
    Closes: https://lore.kernel.org/dmaengine/ZuXbCKUs1iOqFu51@black.fi.intel.com/
    Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Closes: https://lore.kernel.org/dmaengine/ZuXgI-VcHpMgbZ91@black.fi.intel.com/
    Tested-by: Ferry Toth <fntoth@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20241104095142.157925-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f92f287b0fafee347adcee5f89077925c115535
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Fri Oct 11 22:57:59 2024 +0200

    dmaengine: mv_xor: fix child node refcount handling in early exit
    
    commit 362f1bf98a3ecb5a2a4fcbdaa9718c8403beceb2 upstream.
    
    The for_each_child_of_node() loop requires explicit calls to
    of_node_put() to decrement the child's refcount upon early exits (break,
    goto, return).
    
    Add the missing calls in the two early exits before the goto
    instructions.
    
    Cc: stable@vger.kernel.org
    Fixes: f7d12ef53ddf ("dma: mv_xor: add Device Tree binding")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20241011-dma_mv_xor_of_node_put-v1-1-3c2de819f463@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 908806a2e789998f8897ebab83be10b4b058b6e2
Author: Chukun Pan <amadeus@jmu.edu.cn>
Date:   Fri Nov 22 15:30:06 2024 +0800

    phy: rockchip: naneng-combphy: fix phy reset
    
    commit fbcbffbac994aca1264e3c14da96ac9bfd90466e upstream.
    
    Currently, the USB port via combophy on the RK3528/RK3588 SoC is broken.
    
      usb usb8-port1: Cannot enable. Maybe the USB cable is bad?
    
    This is due to the combphy of RK3528/RK3588 SoC has multiple resets, but
    only "phy resets" need assert and deassert, "apb resets" don't need.
    So change the driver to only match the phy resets, which is also what
    the vendor kernel does.
    
    Fixes: 7160820d742a ("phy: rockchip: add naneng combo phy for RK3568")
    Cc: FUKAUMI Naoki <naoki@radxa.com>
    Cc: Michael Zimmermann <sigmaepsilon92@gmail.com>
    Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Tested-by: FUKAUMI Naoki <naoki@radxa.com>
    Link: https://lore.kernel.org/r/20241122073006.99309-2-amadeus@jmu.edu.cn
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96173874d6b8a346c0c1b2aa098ccc78f4b7d435
Author: Justin Chen <justin.chen@broadcom.com>
Date:   Thu Oct 24 14:35:40 2024 -0700

    phy: usb: Toggle the PHY power during init
    
    commit 0a92ea87bdd6f77ca4e17fe19649882cf5209edd upstream.
    
    When bringing up the PHY, it might be in a bad state if left powered.
    One case is we lose the PLL lock if the PLL is gated while the PHY
    is powered. Toggle the PHY power so we can start from a known state.
    
    Fixes: 4e5b9c9a73b3 ("phy: usb: Add support for new Synopsys USB controller on the 7216")
    Signed-off-by: Justin Chen <justin.chen@broadcom.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20241024213540.1059412-1-justin.chen@broadcom.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94dd7d0665ec0e97eea5ae26e92565d165d855ca
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Fri Dec 13 20:36:43 2024 +0800

    phy: core: Fix that API devm_phy_destroy() fails to destroy the phy
    
    commit 4dc48c88fcf82b89fdebd83a906aaa64f40fb8a9 upstream.
    
    For devm_phy_destroy(), its comment says it needs to invoke phy_destroy()
    to destroy the phy, but it will not actually invoke the function since
    devres_destroy() does not call devm_phy_consume(), and the missing
    phy_destroy() call will cause that the phy fails to be destroyed.
    
    Fortunately, the faulty API has not been used by current kernel tree.
    Fix by using devres_release() instead of devres_destroy() within the API.
    
    Fixes: ff764963479a ("drivers: phy: add generic PHY framework")
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20241213-phy_core_fix-v6-3-40ae28f5015a@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 216b9f8335b5346e1e9689c62476402ccf0f6fd3
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Fri Dec 13 20:36:42 2024 +0800

    phy: core: Fix that API devm_of_phy_provider_unregister() fails to unregister the phy provider
    
    commit c0b82ab95b4f1fbc3e3aeab9d829d012669524b6 upstream.
    
    For devm_of_phy_provider_unregister(), its comment says it needs to invoke
    of_phy_provider_unregister() to unregister the phy provider, but it will
    not actually invoke the function since devres_destroy() does not call
    devm_phy_provider_release(), and the missing of_phy_provider_unregister()
    call will cause:
    
    - The phy provider fails to be unregistered.
    - Leak both memory and the OF node refcount.
    
    Fortunately, the faulty API has not been used by current kernel tree.
    Fix by using devres_release() instead of devres_destroy() within the API.
    
    Fixes: ff764963479a ("drivers: phy: add generic PHY framework")
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/stable/20241213-phy_core_fix-v6-2-40ae28f5015a%40quicinc.com
    Link: https://lore.kernel.org/r/20241213-phy_core_fix-v6-2-40ae28f5015a@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58068f8b7a5528d34d48e9a3cde77739998e6ae9
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Fri Dec 13 20:36:41 2024 +0800

    phy: core: Fix that API devm_phy_put() fails to release the phy
    
    commit fe4bfa9b6d7bd752bfe4700c937f235aa8ce997b upstream.
    
    For devm_phy_put(), its comment says it needs to invoke phy_put() to
    release the phy, but it will not actually invoke the function since
    devres_destroy() does not call devm_phy_release(), and the missing
    phy_put() call will cause:
    
    - The phy fails to be released.
    - devm_phy_put() can not fully undo what API devm_phy_get() does.
    - Leak refcount of both the module and device for below typical usage:
    
      devm_phy_get(); // or its variant
      ...
      err = do_something();
      if (err)
          goto err_out;
      ...
      err_out:
      devm_phy_put(); // leak refcount here
    
      The file(s) affected by this issue are shown below since they have such
      typical usage.
      drivers/pci/controller/cadence/pcie-cadence.c
      drivers/net/ethernet/ti/am65-cpsw-nuss.c
    
    Fix by using devres_release() instead of devres_destroy() within the API.
    
    Fixes: ff764963479a ("drivers: phy: add generic PHY framework")
    Cc: stable@vger.kernel.org
    Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Cc: Krzysztof Wilczyński <kw@linux.com>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20241213-phy_core_fix-v6-1-40ae28f5015a@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80a6eeb3a73ae8bab2ac51b982f72698516ac11d
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Fri Dec 13 20:36:45 2024 +0800

    phy: core: Fix an OF node refcount leakage in of_phy_provider_lookup()
    
    commit a2d633cb1421e679b56f1a9fe1f42f089706f1ed upstream.
    
    For macro for_each_child_of_node(parent, child), refcount of @child has
    been increased before entering its loop body, so normally needs to call
    of_node_put(@child) before returning from the loop body to avoid refcount
    leakage.
    
    of_phy_provider_lookup() has such usage but does not call of_node_put()
    before returning, so cause leakage of the OF node refcount.
    
    Fix by simply calling of_node_put() before returning from the loop body.
    
    The APIs affected by this issue are shown below since they indirectly
    invoke problematic of_phy_provider_lookup().
    phy_get()
    of_phy_get()
    devm_phy_get()
    devm_of_phy_get()
    devm_of_phy_get_by_index()
    
    Fixes: 2a4c37016ca9 ("phy: core: Fix of_phy_provider_lookup to return PHY provider for sub node")
    Cc: stable@vger.kernel.org
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20241213-phy_core_fix-v6-5-40ae28f5015a@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 293b3748ababc2c3ba2ba321abf7d57486be0aa4
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Fri Dec 13 20:36:44 2024 +0800

    phy: core: Fix an OF node refcount leakage in _of_phy_get()
    
    commit 5ebdc6be16c2000e37fcb8b4072d442d268ad492 upstream.
    
    _of_phy_get() will directly return when suffers of_device_is_compatible()
    error, but it forgets to decrease refcount of OF node @args.np before error
    return, the refcount was increased by previous of_parse_phandle_with_args()
    so causes the OF node's refcount leakage.
    
    Fix by decreasing the refcount via of_node_put() before the error return.
    
    Fixes: b7563e2796f8 ("phy: work around 'phys' references to usb-nop-xceiv devices")
    Cc: stable@vger.kernel.org
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20241213-phy_core_fix-v6-4-40ae28f5015a@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 826acec1a9f9282168c07b2a4532ec965799fb9d
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Tue Nov 12 14:58:31 2024 +0530

    phy: qcom-qmp: Fix register name in RX Lane config of SC8280XP
    
    commit 8886fb3240931a0afce82dea87edfe46bcb0a586 upstream.
    
    In RX Lane configuration sequence of SC8280XP, the register
    V5_RX_UCDR_FO_GAIN is incorrectly spelled as RX_UCDR_SO_GAIN and
    hence the programming sequence is wrong. Fix the register sequence
    accordingly to avoid any compliance failures. This has been tested
    on SA8775P by checking device mode enumeration in SuperSpeed.
    
    Cc: stable@vger.kernel.org
    Fixes: c0c7769cdae2 ("phy: qcom-qmp: Add SC8280XP USB3 UNI phy")
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20241112092831.4110942-1-quic_kriskura@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36094da8b40228982bd65a6b8fcc24a1e7a08ba0
Author: Maciej Andrzejewski <maciej.andrzejewski@m-works.net>
Date:   Mon Dec 2 19:58:36 2024 +0100

    mtd: rawnand: arasan: Fix missing de-registration of NAND
    
    commit 11e6831fd81468cf48155b9b3c11295c391da723 upstream.
    
    The NAND chip-selects are registered for the Arasan driver during
    initialization but are not de-registered when the driver is unloaded. As a
    result, if the driver is loaded again, the chip-selects remain registered
    and busy, making them unavailable for use.
    
    Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Maciej Andrzejewski ICEYE <maciej.andrzejewski@m-works.net>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 649ba9c1712bc2f7ef154a622f4c3238ee1b2c76
Author: Maciej Andrzejewski <maciej.andrzejewski@m-works.net>
Date:   Mon Dec 2 13:51:07 2024 +0100

    mtd: rawnand: arasan: Fix double assertion of chip-select
    
    commit b086a46dae48829e11c0c02580e30d920b76743c upstream.
    
    When two chip-selects are configured in the device tree, and the second is
    a non-native GPIO, both the GPIO-based chip-select and the first native
    chip-select may be asserted simultaneously. This double assertion causes
    incorrect read and write operations.
    
    The issue occurs because when nfc->ncs <= 2, nfc->spare_cs is always
    initialized to 0 due to static initialization. Consequently, when the
    second chip-select (GPIO-based) is selected in anfc_assert_cs(), it is
    detected by anfc_is_gpio_cs(), and nfc->native_cs is assigned the value 0.
    This results in both the GPIO-based chip-select being asserted and the
    NAND controller register receiving 0, erroneously selecting the native
    chip-select.
    
    This patch resolves the issue, as confirmed by oscilloscope testing with
    configurations involving two or more chip-selects in the device tree.
    
    Fixes: acbd3d0945f9 ("mtd: rawnand: arasan: Leverage additional GPIO CS")
    Cc: stable@vger.kernel.org
    Signed-off-by: Maciej Andrzejewski <maciej.andrzejewski@m-works.net>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3970d6b335fb138562eb601a8fca74afea978b1b
Author: Zichen Xie <zichenxie0106@gmail.com>
Date:   Wed Oct 23 16:13:10 2024 -0500

    mtd: diskonchip: Cast an operand to prevent potential overflow
    
    commit 9b458e8be0d13e81ed03fffa23f8f9b528bbd786 upstream.
    
    There may be a potential integer overflow issue in inftl_partscan().
    parts[0].size is defined as "uint64_t"  while mtd->erasesize and
    ip->firstUnit are defined as 32-bit unsigned integer. The result of
    the calculation will be limited to 32 bits without correct casting.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zichen Xie <zichenxie0106@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15c184b4e7cf2093f0d92df0d550377caba66be4
Author: NeilBrown <neilb@suse.de>
Date:   Fri Dec 20 15:28:18 2024 +1100

    nfsd: restore callback functionality for NFSv4.0
    
    [ Upstream commit 7917f01a286ce01e9c085e24468421f596ee1a0c ]
    
    A recent patch inadvertently broke callbacks for NFSv4.0.
    
    In the 4.0 case we do not expect a session to be found but still need to
    call setup_callback_client() which will not try to dereference it.
    
    This patch moves the check for failure to find a session into the 4.1+
    branch of setup_callback_client()
    
    Fixes: 1e02c641c3a4 ("NFSD: Prevent NULL dereference in nfsd4_process_cb_update()")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 488304065d0d4368c95a0d114e0550889cceddab
Author: Yang Erkun <yangerkun@huawei.com>
Date:   Mon Dec 16 22:21:52 2024 +0800

    nfsd: Revert "nfsd: release svc_expkey/svc_export with rcu_work"
    
    [ Upstream commit 69d803c40edeaf94089fbc8751c9b746cdc35044 ]
    
    This reverts commit f8c989a0c89a75d30f899a7cabdc14d72522bb8d.
    
    Before this commit, svc_export_put or expkey_put will call path_put with
    sync mode. After this commit, path_put will be called with async mode.
    And this can lead the unexpected results show as follow.
    
    mkfs.xfs -f /dev/sda
    echo "/ *(rw,no_root_squash,fsid=0)" > /etc/exports
    echo "/mnt *(rw,no_root_squash,fsid=1)" >> /etc/exports
    exportfs -ra
    service nfs-server start
    mount -t nfs -o vers=4.0 127.0.0.1:/mnt /mnt1
    mount /dev/sda /mnt/sda
    touch /mnt1/sda/file
    exportfs -r
    umount /mnt/sda # failed unexcepted
    
    The touch will finally call nfsd_cross_mnt, add refcount to mount, and
    then add cache_head. Before this commit, exportfs -r will call
    cache_flush to cleanup all cache_head, and path_put in
    svc_export_put/expkey_put will be finished with sync mode. So, the
    latter umount will always success. However, after this commit, path_put
    will be called with async mode, the latter umount may failed, and if
    we add some delay, umount will success too. Personally I think this bug
    and should be fixed. We first revert before bugfix patch, and then fix
    the original bug with a different way.
    
    Fixes: f8c989a0c89a ("nfsd: release svc_expkey/svc_export with rcu_work")
    Signed-off-by: Yang Erkun <yangerkun@huawei.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0326fbf6931125feac1f139d54e617d029e61996
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Thu Dec 12 19:40:54 2024 -0800

    bpf: Check negative offsets in __bpf_skb_min_len()
    
    [ Upstream commit 9ecc4d858b92c1bb0673ad9c327298e600c55659 ]
    
    skb_network_offset() and skb_transport_offset() can be negative when
    they are called after we pull the transport header, for example, when
    we use eBPF sockmap at the point of ->sk_data_ready().
    
    __bpf_skb_min_len() uses an unsigned int to get these offsets, this
    leads to a very large number which then causes bpf_skb_change_tail()
    failed unexpectedly.
    
    Fix this by using a signed int to get these offsets and ensure the
    minimum is at least zero.
    
    Fixes: 5293efe62df8 ("bpf: add bpf_skb_change_tail helper")
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20241213034057.246437-2-xiyou.wangcong@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 343a932a05f41d321b6643fc28d6315b2457d9f8
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Tue Dec 10 01:20:39 2024 +0000

    tcp_bpf: Add sk_rmem_alloc related logic for tcp_bpf ingress redirection
    
    [ Upstream commit d888b7af7c149c115dd6ac772cc11c375da3e17c ]
    
    When we do sk_psock_verdict_apply->sk_psock_skb_ingress, an sk_msg will
    be created out of the skb, and the rmem accounting of the sk_msg will be
    handled by the skb.
    
    For skmsgs in __SK_REDIRECT case of tcp_bpf_send_verdict, when redirecting
    to the ingress of a socket, although we sk_rmem_schedule and add sk_msg to
    the ingress_msg of sk_redir, we do not update sk_rmem_alloc. As a result,
    except for the global memory limit, the rmem of sk_redir is nearly
    unlimited. Thus, add sk_rmem_alloc related logic to limit the recv buffer.
    
    Since the function sk_msg_recvmsg and __sk_psock_purge_ingress_msg are
    used in these two paths. We use "msg->skb" to test whether the sk_msg is
    skb backed up. If it's not, we shall do the memory accounting explicitly.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20241210012039.1669389-3-zijianzhang@bytedance.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9dbc7e0e5ce5adaf00d07a925ca4e11e50a9bfbb
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Tue Dec 10 01:20:38 2024 +0000

    tcp_bpf: Charge receive socket buffer in bpf_tcp_ingress()
    
    [ Upstream commit 54f89b3178d5448dd4457afbb98fc1ab99090a65 ]
    
    When bpf_tcp_ingress() is called, the skmsg is being redirected to the
    ingress of the destination socket. Therefore, we should charge its
    receive socket buffer, instead of sending socket buffer.
    
    Because sk_rmem_schedule() tests pfmemalloc of skb, we need to
    introduce a wrapper and call it for skmsg.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20241210012039.1669389-2-zijianzhang@bytedance.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ef08c3fe7643dab88cd16c4f15d7650289d5b31
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Dec 12 13:31:26 2024 -0800

    mm/vmstat: fix a W=1 clang compiler warning
    
    [ Upstream commit 30c2de0a267c04046d89e678cc0067a9cfb455df ]
    
    Fix the following clang compiler warning that is reported if the kernel is
    built with W=1:
    
    ./include/linux/vmstat.h:518:36: error: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Werror,-Wenum-enum-conversion]
      518 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
          |                               ~~~~~~~~~~~ ^ ~~~
    
    Link: https://lkml.kernel.org/r/20241212213126.1269116-1-bvanassche@acm.org
    Fixes: 9d7ea9a297e6 ("mm/vmstat: add helpers to get vmstat item names for each enum type")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Cc: Konstantin Khlebnikov <koct9i@gmail.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d41fa58fca6f55608133c6e6077c87118f785d1b
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Sat Dec 7 17:33:25 2024 +0100

    ceph: allocate sparse_ext map only for sparse reads
    
    [ Upstream commit 18d44c5d062b97b97bb0162d9742440518958dc1 ]
    
    If mounted with sparseread option, ceph_direct_read_write() ends up
    making an unnecessarily allocation for O_DIRECT writes.
    
    Fixes: 03bc06c7b0bd ("ceph: add new mount option to enable sparse reads")
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Markuze <amarkuze@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44e518abbb498075ae85c7d1d1a503a6bb05ea2d
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Dec 6 17:32:59 2024 +0100

    ceph: fix memory leak in ceph_direct_read_write()
    
    [ Upstream commit 66e0c4f91461d17d48071695271c824620bed4ef ]
    
    The bvecs array which is allocated in iter_get_bvecs_alloc() is leaked
    and pages remain pinned if ceph_alloc_sparse_ext_map() fails.
    
    There is no need to delay the allocation of sparse_ext map until after
    the bvecs array is set up, so fix this by moving sparse_ext allocation
    a bit earlier.  Also, make a similar adjustment in __ceph_sync_read()
    for consistency (a leak of the same kind in __ceph_sync_read() has been
    addressed differently).
    
    Cc: stable@vger.kernel.org
    Fixes: 03bc06c7b0bd ("ceph: add new mount option to enable sparse reads")
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Markuze <amarkuze@redhat.com>
    Stable-dep-of: 18d44c5d062b ("ceph: allocate sparse_ext map only for sparse reads")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb98248fc4a26e73d032e53160aee5d566d410cc
Author: Xiubo Li <xiubli@redhat.com>
Date:   Tue Nov 7 10:44:41 2023 +0800

    ceph: try to allocate a smaller extent map for sparse read
    
    [ Upstream commit aaefabc4a5f7ae48682c4d2d5d10faaf95c08eb9 ]
    
    In fscrypt case and for a smaller read length we can predict the
    max count of the extent map. And for small read length use cases
    this could save some memories.
    
    [ idryomov: squash into a single patch to avoid build break, drop
      redundant variable in ceph_alloc_sparse_ext_map() ]
    
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Stable-dep-of: 18d44c5d062b ("ceph: allocate sparse_ext map only for sparse reads")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d6de21f00293d819b5ca6dbe75ff1f3b6392140
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Fri May 17 08:58:00 2024 -0700

    media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg
    
    [ Upstream commit 2dd59fe0e19e1ab955259978082b62e5751924c7 ]
    
    Syzbot reports [1] an uninitialized value issue found by KMSAN in
    dib3000_read_reg().
    
    Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case
    that call fails, the buffer may end up with some undefined values.
    
    Since no elaborate error handling is expected in dib3000_write_reg(),
    simply zero out rb buffer to mitigate the problem.
    
    [1] Syzkaller report
    dvb-usb: bulk message failed: -22 (6/0)
    =====================================================
    BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
     dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
     dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31
     dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290
     dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]
     dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]
     dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310
     dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110
    ...
    Local variable rb created at:
     dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54
     dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
    ...
    
    Fixes: 74340b0a8bc6 ("V4L/DVB (4457): Remove dib3000-common-module")
    Reported-by: syzbot+c88fc0ebe0d5935c70da@syzkaller.appspotmail.com
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://lore.kernel.org/r/20240517155800.9881-1-n.zhandarovich@fintech.ru
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>