commit ef3ce4bf49dcd49fcd5e08743c4048abaca32811
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Feb 8 09:52:39 2025 +0100

    Linux 6.6.76
    
    Link: https://lore.kernel.org/r/20250205134420.279368572@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Hardik Garg <hargar@linux.microsoft.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/r/20250206155234.095034647@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b7f5ef4bacea93383c18f5f0c6b77236526d9a9
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Sun Jan 26 21:49:59 2025 +0800

    LoongArch: Change 8 to 14 for LOONGARCH_MAX_{BRP,WRP}
    
    commit f502ea618bf16d615d7dc6138c8988d3118fe750 upstream.
    
    The maximum number of load/store watchpoints and fetch instruction
    watchpoints is 14 each according to LoongArch Reference Manual, so
    change 8 to 14 for the related code.
    
    Link: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
    Cc: stable@vger.kernel.org
    Fixes: edffa33c7bb5 ("LoongArch: Add hardware breakpoints/watchpoints support")
    Reviewed-by: WANG Xuerui <git@xen0n.name>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cefbf9f892ceaebba2f45c5713f4e9608f7bc266
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jan 22 19:54:27 2025 -0700

    s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS
    
    commit 3b8b80e993766dc96d1a1c01c62f5d15fafc79b9 upstream.
    
    GCC changed the default C standard dialect from gnu17 to gnu23,
    which should not have impacted the kernel because it explicitly requests
    the gnu11 standard in the main Makefile. However, there are certain
    places in the s390 code that use their own CFLAGS without a '-std='
    value, which break with this dialect change because of the kernel's own
    definitions of bool, false, and true conflicting with the C23 reserved
    keywords.
    
      include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
         11 |         false   = 0,
            |         ^~~~~
      include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
      include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef'
         35 | typedef _Bool                   bool;
            |                                 ^~~~
      include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards
    
    Add '-std=gnu11' to the decompressor and purgatory CFLAGS to eliminate
    these errors and make the C standard version of these areas match the
    rest of the kernel.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Heiko Carstens <hca@linux.ibm.com>
    Link: https://lore.kernel.org/r/20250122-s390-fix-std-for-gcc-15-v1-1-8b00cadee083@kernel.org
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49b8241c5aaf9226a8e194e81e0fbf6c2bf5d7b0
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Dec 10 15:23:06 2024 +1030

    btrfs: output the reason for open_ctree() failure
    
    commit d0f038104fa37380e2a725e669508e43d0c503e9 upstream.
    
    There is a recent ML report that mounting a large fs backed by hardware
    RAID56 controller (with one device missing) took too much time, and
    systemd seems to kill the mount attempt.
    
    In that case, the only error message is:
    
      BTRFS error (device sdj): open_ctree failed
    
    There is no reason on why the failure happened, making it very hard to
    understand the reason.
    
    At least output the error number (in the particular case it should be
    -EINTR) to provide some clue.
    
    Link: https://lore.kernel.org/linux-btrfs/9b9c4d2810abcca2f9f76e32220ed9a90febb235.camel@scientia.org/
    Reported-by: Christoph Anton Mitterer <calestyo@scientia.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Filipe Manana <fdmanana@suse.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 1b2af918bb714937a8be6cb637f528585461cd98
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Oct 17 23:34:16 2024 +0300

    media: imx-jpeg: Fix potential error pointer dereference in detach_pm()
    
    commit 1378ffec30367233152b7dbf4fa6a25ee98585d1 upstream.
    
    The proble is on the first line:
    
            if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i]))
    
    If jpeg->pd_dev[i] is an error pointer, then passing it to
    pm_runtime_suspended() will lead to an Oops.  The other conditions
    check for both error pointers and NULL, but it would be more clear to
    use the IS_ERR_OR_NULL() check for that.
    
    Fixes: fd0af4cd35da ("media: imx-jpeg: Ensure power suppliers be suspended before detach them")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfde3d63afbaae664c4d36e53cfb4045d5374561
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Date:   Tue Dec 17 08:51:50 2024 +0200

    staging: media: max96712: fix kernel oops when removing module
    
    commit ee1b5046d5cd892a0754ab982aeaaad3702083a5 upstream.
    
    The following kernel oops is thrown when trying to remove the max96712
    module:
    
    Unable to handle kernel paging request at virtual address 00007375746174db
    Mem abort info:
      ESR = 0x0000000096000004
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x04: level 0 translation fault
    Data abort info:
      ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000
    [00007375746174db] pgd=0000000000000000, p4d=0000000000000000
    Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan
        snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2
        imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev
        snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils
        max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse
        [last unloaded: imx8_isi]
    CPU: 0 UID: 0 PID: 754 Comm: rmmod
                Tainted: G         C    6.12.0-rc6-06364-g327fec852c31 #17
    Tainted: [C]=CRAP
    Hardware name: NXP i.MX95 19X19 board (DT)
    pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : led_put+0x1c/0x40
    lr : v4l2_subdev_put_privacy_led+0x48/0x58
    sp : ffff80008699bbb0
    x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000
    x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8
    x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000
    x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010
    x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d
    x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1
    x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473
    Call trace:
     led_put+0x1c/0x40
     v4l2_subdev_put_privacy_led+0x48/0x58
     v4l2_async_unregister_subdev+0x2c/0x1a4
     max96712_remove+0x1c/0x38 [max96712]
     i2c_device_remove+0x2c/0x9c
     device_remove+0x4c/0x80
     device_release_driver_internal+0x1cc/0x228
     driver_detach+0x4c/0x98
     bus_remove_driver+0x6c/0xbc
     driver_unregister+0x30/0x60
     i2c_del_driver+0x54/0x64
     max96712_i2c_driver_exit+0x18/0x1d0 [max96712]
     __arm64_sys_delete_module+0x1a4/0x290
     invoke_syscall+0x48/0x10c
     el0_svc_common.constprop.0+0xc0/0xe0
     do_el0_svc+0x1c/0x28
     el0_svc+0x34/0xd8
     el0t_64_sync_handler+0x120/0x12c
     el0t_64_sync+0x190/0x194
    Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)
    ---[ end trace 0000000000000000 ]---
    
    This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()
    is called again and the data is overwritten to point to sd, instead of
    priv. So, in remove(), the wrong pointer is passed to
    v4l2_async_unregister_subdev(), leading to a crash.
    
    Fixes: 5814f32fef13 ("media: staging: max96712: Add basic support for MAX96712 GMSL2 deserializer")
    Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16907219ad6763f401700e1b57b2da4f3e07f047
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Dec 11 00:31:36 2024 +0000

    usb: gadget: f_tcm: Don't free command immediately
    
    commit c225d006a31949d673e646d585d9569bc28feeb9 upstream.
    
    Don't prematurely free the command. Wait for the status completion of
    the sense status. It can be freed then. Otherwise we will double-free
    the command.
    
    Fixes: cff834c16d23 ("usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/ae919ac431f16275e05ec819bdffb3ac5f44cbe1.1733876548.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd3bbcb6b3a7caa5ce67de76723b6d8531fb7f64
Author: Calvin Owens <calvin@wbinvd.org>
Date:   Mon Nov 11 20:13:29 2024 -0800

    pps: Fix a use-after-free
    
    commit c79a39dc8d060b9e64e8b0fa9d245d44befeefbe upstream.
    
    On a board running ntpd and gpsd, I'm seeing a consistent use-after-free
    in sys_exit() from gpsd when rebooting:
    
        pps pps1: removed
        ------------[ cut here ]------------
        kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.
        WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
        CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
        Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
        pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : kobject_put+0x120/0x150
        lr : kobject_put+0x120/0x150
        sp : ffffffc0803d3ae0
        x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001
        x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440
        x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600
        x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000
        x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20
        x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000
        x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
        x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
        x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
        x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
        Call trace:
         kobject_put+0x120/0x150
         cdev_put+0x20/0x3c
         __fput+0x2c4/0x2d8
         ____fput+0x1c/0x38
         task_work_run+0x70/0xfc
         do_exit+0x2a0/0x924
         do_group_exit+0x34/0x90
         get_signal+0x7fc/0x8c0
         do_signal+0x128/0x13b4
         do_notify_resume+0xdc/0x160
         el0_svc+0xd4/0xf8
         el0t_64_sync_handler+0x140/0x14c
         el0t_64_sync+0x190/0x194
        ---[ end trace 0000000000000000 ]---
    
    ...followed by more symptoms of corruption, with similar stacks:
    
        refcount_t: underflow; use-after-free.
        kernel BUG at lib/list_debug.c:62!
        Kernel panic - not syncing: Oops - BUG: Fatal exception
    
    This happens because pps_device_destruct() frees the pps_device with the
    embedded cdev immediately after calling cdev_del(), but, as the comment
    above cdev_del() notes, fops for previously opened cdevs are still
    callable even after cdev_del() returns. I think this bug has always
    been there: I can't explain why it suddenly started happening every time
    I reboot this particular board.
    
    In commit d953e0e837e6 ("pps: Fix a use-after free bug when
    unregistering a source."), George Spelvin suggested removing the
    embedded cdev. That seems like the simplest way to fix this, so I've
    implemented his suggestion, using __register_chrdev() with pps_idr
    becoming the source of truth for which minor corresponds to which
    device.
    
    But now that pps_idr defines userspace visibility instead of cdev_add(),
    we need to be sure the pps->dev refcount can't reach zero while
    userspace can still find it again. So, the idr_remove() call moves to
    pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev.
    
        pps_core: source serial1 got cdev (251:1)
        <...>
        pps pps1: removed
        pps_core: unregistering pps1
        pps_core: deallocating pps1
    
    Fixes: d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Calvin Owens <calvin@wbinvd.org>
    Reviewed-by: Michal Schmidt <mschmidt@redhat.com>
    Link: https://lore.kernel.org/r/a17975fd5ae99385791929e563f72564edbcf28f.1731383727.git.calvin@wbinvd.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c36dcd662ec5276782838660f8533a7cb26be49
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Fri Nov 8 01:51:30 2024 +0200

    media: uvcvideo: Fix double free in error path
    
    commit c6ef3a7fa97ec823a1e1af9085cf13db9f7b3bac upstream.
    
    If the uvc_status_init() function fails to allocate the int_urb, it will
    free the dev->status pointer but doesn't reset the pointer to NULL. This
    results in the kfree() call in uvc_status_cleanup() trying to
    double-free the memory. Fix it by resetting the dev->status pointer to
    NULL after freeing it.
    
    Fixes: a31a4055473b ("V4L/DVB:usbvideo:don't use part of buffer for USB transfer #4")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20241107235130.31372-1-laurent.pinchart@ideasonboard.com
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b32d60a852bb3952886625d0c3b1c9a88c3ceb7c
Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Date:   Fri Nov 22 18:51:27 2024 +0100

    remoteproc: core: Fix ida_free call while not allocated
    
    commit 7378aeb664e5ebc396950b36a1f2dedf5aabec20 upstream.
    
    In the rproc_alloc() function, on error, put_device(&rproc->dev) is
    called, leading to the call of the rproc_type_release() function.
    An error can occurs before ida_alloc is called.
    
    In such case in rproc_type_release(), the condition (rproc->index >= 0) is
    true as rproc->index has been  initialized to 0.
    ida_free() is called reporting a warning:
    [    4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164
    [    4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0
    [    4.188854] ida_free called for id=0 which is not allocated.
    [    4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000
    [    4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)
    [    4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442
    [    4.231481] Hardware name: STM32 (Device Tree Support)
    [    4.236627] Workqueue: events_unbound deferred_probe_work_func
    [    4.242504] Call trace:
    [    4.242522]  unwind_backtrace from show_stack+0x10/0x14
    [    4.250218]  show_stack from dump_stack_lvl+0x50/0x64
    [    4.255274]  dump_stack_lvl from __warn+0x80/0x12c
    [    4.260134]  __warn from warn_slowpath_fmt+0x114/0x188
    [    4.265199]  warn_slowpath_fmt from ida_free+0x100/0x164
    [    4.270565]  ida_free from rproc_type_release+0x38/0x60
    [    4.275832]  rproc_type_release from device_release+0x30/0xa0
    [    4.281601]  device_release from kobject_put+0xc4/0x294
    [    4.286762]  kobject_put from rproc_alloc.part.0+0x208/0x28c
    [    4.292430]  rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4
    [    4.298393]  devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]
    [    4.305575]  stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc
    
    Calling ida_alloc earlier in rproc_alloc ensures that the rproc->index is
    properly set.
    
    Fixes: 08333b911f01 ("remoteproc: Directly use ida_alloc()/free()")
    Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20241122175127.2188037-1-arnaud.pouliquen@foss.st.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0263fb2e7b7b88075a5d86e74c4384ee4400828d
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Jan 23 19:05:56 2025 +0100

    mptcp: handle fastopen disconnect correctly
    
    commit 619af16b3b57a3a4ee50b9a30add9ff155541e71 upstream.
    
    Syzbot was able to trigger a data stream corruption:
    
      WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024
      Modules linked in:
      CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0
      Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
      RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024
      Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07
      RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293
      RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928
      R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000
      R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000
      FS:  00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074
       mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493
       release_sock+0x1aa/0x1f0 net/core/sock.c:3640
       inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]
       __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703
       mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755
       mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830
       sock_sendmsg_nosec net/socket.c:711 [inline]
       __sock_sendmsg+0x1a6/0x270 net/socket.c:726
       ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583
       ___sys_sendmsg net/socket.c:2637 [inline]
       __sys_sendmsg+0x269/0x350 net/socket.c:2669
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
      RIP: 0033:0x7f6e86ebfe69
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69
      RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003
      RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc
      R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508
       </TASK>
    
    The root cause is the bad handling of disconnect() generated internally
    by the MPTCP protocol in case of connect FASTOPEN errors.
    
    Address the issue increasing the socket disconnect counter even on such
    a case, to allow other threads waiting on the same socket lock to
    properly error out.
    
    Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+ebc0b8ae5d3590b2c074@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/67605870.050a0220.37aaf.0137.GAE@google.com
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/537
    Tested-by: syzbot+ebc0b8ae5d3590b2c074@syzkaller.appspotmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20250123-net-mptcp-syzbot-issues-v1-3-af73258a726f@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f6c72b8ef8130760710e337dc8fbe7263954884
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Jan 23 19:05:54 2025 +0100

    mptcp: consolidate suboption status
    
    commit c86b000782daba926c627d2fa00c3f60a75e7472 upstream.
    
    MPTCP maintains the received sub-options status is the bitmask carrying
    the received suboptions and in several bitfields carrying per suboption
    additional info.
    
    Zeroing the bitmask before parsing is not enough to ensure a consistent
    status, and the MPTCP code has to additionally clear some bitfiled
    depending on the actually parsed suboption.
    
    The above schema is fragile, and syzbot managed to trigger a path where
    a relevant bitfield is not cleared/initialized:
    
      BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]
      BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]
      BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]
      BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209
       __mptcp_expand_seq net/mptcp/options.c:1030 [inline]
       mptcp_expand_seq net/mptcp/protocol.h:864 [inline]
       ack_update_msk net/mptcp/options.c:1060 [inline]
       mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209
       tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233
       tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264
       tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916
       tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351
       ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205
       ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
       NF_HOOK include/linux/netfilter.h:314 [inline]
       ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
       dst_input include/net/dst.h:460 [inline]
       ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447
       NF_HOOK include/linux/netfilter.h:314 [inline]
       ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567
       __netif_receive_skb_one_core net/core/dev.c:5704 [inline]
       __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817
       process_backlog+0x4ad/0xa50 net/core/dev.c:6149
       __napi_poll+0xe7/0x980 net/core/dev.c:6902
       napi_poll net/core/dev.c:6971 [inline]
       net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093
       handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
       __do_softirq+0x14/0x1a kernel/softirq.c:595
       do_softirq+0x9a/0x100 kernel/softirq.c:462
       __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389
       local_bh_enable include/linux/bottom_half.h:33 [inline]
       rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
       __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493
       dev_queue_xmit include/linux/netdevice.h:3168 [inline]
       neigh_hh_output include/net/neighbour.h:523 [inline]
       neigh_output include/net/neighbour.h:537 [inline]
       ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236
       __ip_finish_output+0x287/0x810
       ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324
       NF_HOOK_COND include/linux/netfilter.h:303 [inline]
       ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434
       dst_output include/net/dst.h:450 [inline]
       ip_local_out net/ipv4/ip_output.c:130 [inline]
       __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536
       ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550
       __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468
       tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]
       tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829
       __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012
       tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618
       __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130
       __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496
       mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550
       mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889
       mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]
       mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]
       mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]
       mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750
       genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
       genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210
       netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2542
       genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219
       netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
       netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1347
       netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1891
       sock_sendmsg_nosec net/socket.c:711 [inline]
       __sock_sendmsg+0x30f/0x380 net/socket.c:726
       ____sys_sendmsg+0x877/0xb60 net/socket.c:2583
       ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2637
       __sys_sendmsg net/socket.c:2669 [inline]
       __do_sys_sendmsg net/socket.c:2674 [inline]
       __se_sys_sendmsg net/socket.c:2672 [inline]
       __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2672
       x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Uninit was stored to memory at:
       mptcp_get_options+0x2c0f/0x2f20 net/mptcp/options.c:397
       mptcp_incoming_options+0x19a/0x3d30 net/mptcp/options.c:1150
       tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233
       tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264
       tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916
       tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351
       ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205
       ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
       NF_HOOK include/linux/netfilter.h:314 [inline]
       ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
       dst_input include/net/dst.h:460 [inline]
       ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447
       NF_HOOK include/linux/netfilter.h:314 [inline]
       ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567
       __netif_receive_skb_one_core net/core/dev.c:5704 [inline]
       __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817
       process_backlog+0x4ad/0xa50 net/core/dev.c:6149
       __napi_poll+0xe7/0x980 net/core/dev.c:6902
       napi_poll net/core/dev.c:6971 [inline]
       net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093
       handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
       __do_softirq+0x14/0x1a kernel/softirq.c:595
    
      Uninit was stored to memory at:
       put_unaligned_be32 include/linux/unaligned.h:68 [inline]
       mptcp_write_options+0x17f9/0x3100 net/mptcp/options.c:1417
       mptcp_options_write net/ipv4/tcp_output.c:465 [inline]
       tcp_options_write+0x6d9/0xe90 net/ipv4/tcp_output.c:759
       __tcp_transmit_skb+0x294b/0x4900 net/ipv4/tcp_output.c:1414
       tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]
       tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829
       __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012
       tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618
       __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130
       __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496
       mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550
       mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889
       mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]
       mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]
       mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]
       mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750
       genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
       genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210
       netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2542
       genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219
       netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
       netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1347
       netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1891
       sock_sendmsg_nosec net/socket.c:711 [inline]
       __sock_sendmsg+0x30f/0x380 net/socket.c:726
       ____sys_sendmsg+0x877/0xb60 net/socket.c:2583
       ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2637
       __sys_sendmsg net/socket.c:2669 [inline]
       __do_sys_sendmsg net/socket.c:2674 [inline]
       __se_sys_sendmsg net/socket.c:2672 [inline]
       __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2672
       x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Uninit was stored to memory at:
       mptcp_pm_add_addr_signal+0x3d7/0x4c0
       mptcp_established_options_add_addr net/mptcp/options.c:666 [inline]
       mptcp_established_options+0x1b9b/0x3a00 net/mptcp/options.c:884
       tcp_established_options+0x2c4/0x7d0 net/ipv4/tcp_output.c:1012
       __tcp_transmit_skb+0x5b7/0x4900 net/ipv4/tcp_output.c:1333
       tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]
       tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829
       __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012
       tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618
       __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130
       __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496
       mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550
       mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889
       mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]
       mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]
       mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]
       mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750
       genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
       genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210
       netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2542
       genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219
       netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
       netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1347
       netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1891
       sock_sendmsg_nosec net/socket.c:711 [inline]
       __sock_sendmsg+0x30f/0x380 net/socket.c:726
       ____sys_sendmsg+0x877/0xb60 net/socket.c:2583
       ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2637
       __sys_sendmsg net/socket.c:2669 [inline]
       __do_sys_sendmsg net/socket.c:2674 [inline]
       __se_sys_sendmsg net/socket.c:2672 [inline]
       __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2672
       x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Uninit was stored to memory at:
       mptcp_pm_add_addr_received+0x95f/0xdd0 net/mptcp/pm.c:235
       mptcp_incoming_options+0x2983/0x3d30 net/mptcp/options.c:1169
       tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233
       tcp_rcv_state_process+0x2a38/0x49d0 net/ipv4/tcp_input.c:6972
       tcp_v4_do_rcv+0xbf9/0x11a0 net/ipv4/tcp_ipv4.c:1939
       tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351
       ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205
       ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
       NF_HOOK include/linux/netfilter.h:314 [inline]
       ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
       dst_input include/net/dst.h:460 [inline]
       ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447
       NF_HOOK include/linux/netfilter.h:314 [inline]
       ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567
       __netif_receive_skb_one_core net/core/dev.c:5704 [inline]
       __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817
       process_backlog+0x4ad/0xa50 net/core/dev.c:6149
       __napi_poll+0xe7/0x980 net/core/dev.c:6902
       napi_poll net/core/dev.c:6971 [inline]
       net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093
       handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
       __do_softirq+0x14/0x1a kernel/softirq.c:595
    
      Local variable mp_opt created at:
       mptcp_incoming_options+0x119/0x3d30 net/mptcp/options.c:1127
       tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233
    
    The current schema is too fragile; address the issue grouping all the
    state-related data together and clearing the whole group instead of
    just the bitmask. This also cleans-up the code a bit, as there is no
    need to individually clear "random" bitfield in a couple of places
    any more.
    
    Fixes: 84dfe3677a6f ("mptcp: send out dedicated ADD_ADDR packet")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+23728c2df58b3bd175ad@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/6786ac51.050a0220.216c54.00a7.GAE@google.com
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/541
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20250123-net-mptcp-syzbot-issues-v1-1-af73258a726f@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f10f641b489a89cbb858fa26a3e5b90fcca8396
Author: Kyle Tso <kyletso@google.com>
Date:   Tue Jan 14 22:24:35 2025 +0800

    usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS
    
    commit 4d27afbf256028a1f54363367f30efc8854433c3 upstream.
    
    The Source can drop its output voltage to the minimum of the requested
    PPS APDO voltage range when it is in Current Limit Mode. If this voltage
    falls within the range of vPpsShutdown, the Source initiates a Hard
    Reset and discharges Vbus. However, currently the Sink may disconnect
    before the voltage reaches vPpsShutdown, leading to unexpected behavior.
    
    Prevent premature disconnection by setting the Sink's disconnect
    threshold to the minimum vPpsShutdown value. Additionally, consider the
    voltage drop due to IR drop when calculating the appropriate threshold.
    This ensures a robust and reliable interaction between the Source and
    Sink during SPR PPS Current Limit Mode operation.
    
    Fixes: 4288debeaa4e ("usb: typec: tcpci: Fix up sink disconnect thresholds for PD")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Kyle Tso <kyletso@google.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
    Link: https://lore.kernel.org/r/20250114142435.2093857-1-kyletso@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76bae35d44f325e17f55d1a099703040ddc1dc47
Author: Jos Wang <joswang@lenovo.com>
Date:   Sun Jan 5 21:52:45 2025 +0800

    usb: typec: tcpm: set SRC_SEND_CAPABILITIES timeout to PD_T_SENDER_RESPONSE
    
    commit 2eb3da037c2c20fa30bc502bc092479b2a1aaae2 upstream.
    
    As PD2.0 spec ("8.3.3.2.3 PE_SRC_Send_Capabilities state"), after the
    Source receives the GoodCRC Message from the Sink in response to the
    Source_Capabilities message, it should start the SenderResponseTimer,
    after the timer times out, the state machine transitions to the
    HARD_RESET state.
    
    Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jos Wang <joswang@lenovo.com>
    Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
    Link: https://lore.kernel.org/r/20250105135245.7493-1-joswang1221@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 876b1bf63b6f40107d3d5e685127f4b9ba1469fd
Author: Kyle Tso <kyletso@google.com>
Date:   Wed Jan 15 12:45:48 2025 +0800

    usb: dwc3: core: Defer the probe until USB power supply ready
    
    commit 66e0ea341a2a78d14336117f19763bd9be26d45d upstream.
    
    Currently, DWC3 driver attempts to acquire the USB power supply only
    once during the probe. If the USB power supply is not ready at that
    time, the driver simply ignores the failure and continues the probe,
    leading to permanent non-functioning of the gadget vbus_draw callback.
    
    Address this problem by delaying the dwc3 driver initialization until
    the USB power supply is registered.
    
    Fixes: 6f0764b5adea ("usb: dwc3: add a power supply for current control")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Kyle Tso <kyletso@google.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20250115044548.2701138-1-kyletso@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0962220d7a986c4e00cfc6f35563542a67ff4a69
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Thu Jan 9 09:16:38 2025 +0900

    usb: dwc3-am62: Fix an OF node leak in phy_syscon_pll_refclk()
    
    commit a266462b937beba065e934a563efe13dd246a164 upstream.
    
    phy_syscon_pll_refclk() leaks an OF node obtained by
    of_parse_phandle_with_fixed_args(), thus add an of_node_put() call.
    
    Cc: stable <stable@kernel.org>
    Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20250109001638.70033-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e7fc92a0572d9be2ad1633de81dedfad69f3d84
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Dec 11 00:31:55 2024 +0000

    usb: gadget: f_tcm: Fix Get/SetInterface return value
    
    commit 3b997089903b909684114aca6f79d683e5c64a0e upstream.
    
    Check to make sure that the GetInterface and SetInterface are for valid
    interface. Return proper alternate setting number on GetInterface.
    
    Fixes: 0b8b1a1fede0 ("usb: gadget: f_tcm: Provide support to get alternate setting in tcm function")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/ffd91b4640945ea4d3b4f4091cf1abbdbd9cf4fc.1733876548.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e490b665ca3b012afc9a1fdab3ab69feee6d667
Author: Sean Rhodes <sean@starlabs.systems>
Date:   Tue Nov 19 08:58:15 2024 +0000

    drivers/card_reader/rtsx_usb: Restore interrupt based detection
    
    commit 235b630eda072d7e7b102ab346d6b8a2c028a772 upstream.
    
    This commit reintroduces interrupt-based card detection previously
    used in the rts5139 driver. This functionality was removed in commit
    00d8521dcd23 ("staging: remove rts5139 driver code").
    
    Reintroducing this mechanism fixes presence detection for certain card
    readers, which with the current driver, will taken approximately 20
    seconds to enter S3 as `mmc_rescan` has to be frozen.
    
    Fixes: 00d8521dcd23 ("staging: remove rts5139 driver code")
    Cc: stable@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sean Rhodes <sean@starlabs.systems>
    Link: https://lore.kernel.org/r/20241119085815.11769-1-sean@starlabs.systems
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b649f0d5bc256f691c7d234c3986685d54053de1
Author: Michal Pecio <michal.pecio@gmail.com>
Date:   Fri Dec 27 14:01:40 2024 +0200

    usb: xhci: Fix NULL pointer dereference on certain command aborts
    
    commit 1e0a19912adb68a4b2b74fd77001c96cd83eb073 upstream.
    
    If a command is queued to the final usable TRB of a ring segment, the
    enqueue pointer is advanced to the subsequent link TRB and no further.
    If the command is later aborted, when the abort completion is handled
    the dequeue pointer is advanced to the first TRB of the next segment.
    
    If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
    the ring pointers unequal and assumes that there is a pending command,
    so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.
    
    Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
    ring likely is unnecessary too, but it's harmless. Leave it alone.
    
    This is probably Bug 219532, but no confirmation has been received.
    
    The issue has been independently reproduced and confirmed fixed using
    a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
    Everything continued working normally after several prevented crashes.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219532
    Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
    CC: stable@vger.kernel.org
    Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20241227120142.1035206-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c706829ceb6e347bd4ddfd17f1d3048acd69da2
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Fri Jan 24 01:30:20 2025 -0800

    net: usb: rtl8150: enable basic endpoint checking
    
    commit 90b7f2961798793275b4844348619b622f983907 upstream.
    
    Syzkaller reports [1] encountering a common issue of utilizing a wrong
    usb endpoint type during URB submitting stage. This, in turn, triggers
    a warning shown below.
    
    For now, enable simple endpoint checking (specifically, bulk and
    interrupt eps, testing control one is not essential) to mitigate
    the issue with a view to do other related cosmetic changes later,
    if they are necessary.
    
    [1] Syzkaller report:
    usb 1-1: BOGUS urb xfer, pipe 3 != type 1
    WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>
    Modules linked in:
    CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
    Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>
    RSP: 0018:ffffc9000441f740 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9
    RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001
    RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
    R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c
    FS:  00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733
     __dev_open+0x2d4/0x4e0 net/core/dev.c:1474
     __dev_change_flags+0x561/0x720 net/core/dev.c:8838
     dev_change_flags+0x8f/0x160 net/core/dev.c:8910
     devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177
     inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003
     sock_do_ioctl+0x116/0x280 net/socket.c:1222
     sock_ioctl+0x22e/0x6c0 net/socket.c:1341
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl fs/ioctl.c:893 [inline]
     __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fc04ef73d49
    ...
    
    This change has not been tested on real hardware.
    
    Reported-and-tested-by: syzbot+d7e968426f644b567e31@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d7e968426f644b567e31
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://patch.msgid.link/20250124093020.234642-1-n.zhandarovich@fintech.ru
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e75091a93b93ed161c62172474e43e14ec64209
Author: Lianqin Hu <hulianqin@vivo.com>
Date:   Sun Jan 26 03:51:11 2025 +0000

    ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro
    
    commit d85fc52cbb9a719c8335d93a28d6a79d7acd419f upstream.
    
    Audio control requests that sets sampling frequency sometimes fail on
    this card. Adding delay between control messages eliminates that problem.
    
    usb 1-1: New USB device found, idVendor=2fc6, idProduct=f0b7
    usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    usb 1-1: Product: iBasso DC07 Pro
    usb 1-1: Manufacturer: iBasso
    usb 1-1: SerialNumber: CTUA171130B
    
    Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/TYUPR06MB62174A48D04E09A37996DF84D2ED2@TYUPR06MB6217.apcprd06.prod.outlook.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe215b8dd76c836bc4680edf58e05e34155d29cb
Author: Ricardo B. Marliere <rbm@suse.com>
Date:   Thu Dec 5 17:50:35 2024 -0300

    ktest.pl: Check kernelrelease return in get_version
    
    commit a4e17a8f239a545c463f8ec27db4ed6e74b31841 upstream.
    
    In the case of a test that uses the special option ${KERNEL_VERSION} in one
    of its settings but has no configuration available in ${OUTPUT_DIR}, for
    example if it's a new empty directory, then the `make kernelrelease` call
    will fail and the subroutine will chomp an empty string, silently. Fix that
    by adding an empty configuration and retrying.
    
    Cc: stable@vger.kernel.org
    Cc: John Hawley <warthog9@eaglescrag.net>
    Fixes: 5f9b6ced04a4e ("ktest: Bisecting, install modules, add logging")
    Link: https://lore.kernel.org/20241205-ktest_kver_fallback-v2-1-869dae4c7777@suse.com
    Signed-off-by: Ricardo B. Marliere <rbm@suse.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bab3e9f342e0385a65ff0e5372a43954f1b5343b
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Tue Jan 14 09:51:32 2025 -0500

    selftests/rseq: Fix handling of glibc without rseq support
    
    commit 336d02bc4c6bec5c3d933e5d470a94970f830957 upstream.
    
    When porting librseq commit:
    
    commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
    
    from librseq to the kernel selftests, the following line was missed
    at the end of rseq_init():
    
      rseq_size = get_rseq_kernel_feature_size();
    
    which effectively leaves rseq_size initialized to -1U when glibc does not
    have rseq support. glibc supports rseq from version 2.35 onwards.
    
    In a following librseq commit
    
    commit c67d198627c2 ("Only set 'rseq_size' on first thread registration")
    
    to mimic the libc behavior, a new approach is taken: don't set the
    feature size in 'rseq_size' until at least one thread has successfully
    registered. This allows using 'rseq_size' in fast-paths to test for both
    registration status and available features. The caveat is that on libc
    either all threads are registered or none are, while with bare librseq
    it is the responsability of the user to register all threads using rseq.
    
    This combines the changes from the following librseq git commits:
    
    commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
    commit c67d198627c2 ("Only set 'rseq_size' on first thread registration")
    
    Fixes: a0cc649353bb ("selftests/rseq: Fix mm_cid test failure")
    Reported-by: Raghavendra Rao Ananta <rananta@google.com>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Raghavendra Rao Ananta <rananta@google.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: "Paul E. McKenney" <paulmck@kernel.org>
    Cc: Carlos O'Donell <carlos@redhat.com>
    Cc: Florian Weimer <fweimer@redhat.com>
    Cc: Michael Jeanson <mjeanson@efficios.com>
    Cc: linux-kselftest@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82e491e085719068179ff6a5466b7387cc4bbf32
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Jan 28 12:26:33 2025 +0100

    netfilter: nf_tables: reject mismatching sum of field_len with set key length
    
    commit 1b9335a8000fb70742f7db10af314104b6ace220 upstream.
    
    The field length description provides the length of each separated key
    field in the concatenation, each field gets rounded up to 32-bits to
    calculate the pipapo rule width from pipapo_init(). The set key length
    provides the total size of the key aligned to 32-bits.
    
    Register-based arithmetics still allows for combining mismatching set
    key length and field length description, eg. set key length 10 and field
    description [ 5, 4 ] leading to pipapo width of 12.
    
    Cc: stable@vger.kernel.org
    Fixes: 3ce67e3793f4 ("netfilter: nf_tables: do not allow mismatch field size and set key length")
    Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbfb30ae17d45b92bc9e5fb119a4a6a81433c5cb
Author: Parth Pancholi <parth.pancholi@toradex.com>
Date:   Thu Nov 14 15:56:44 2024 +0100

    kbuild: switch from lz4c to lz4 for compression
    
    commit e397a603e49cc7c7c113fad9f55a09637f290c34 upstream.
    
    Replace lz4c with lz4 for kernel image compression.
    Although lz4 and lz4c are functionally similar, lz4c has been deprecated
    upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4
    and lz4c have been packaged together, making it safe to update the
    requirement from lz4c to lz4.
    
    Consequently, some distributions and build systems, such as OpenEmbedded,
    have fully transitioned to using lz4. OpenEmbedded core adopted this
    change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of
    lz4c"), causing compatibility issues when building the mainline kernel
    in the latest OpenEmbedded environment, as seen in the errors below.
    
    This change also updates the LZ4 compression commands to make it backward
    compatible by replacing stdin and stdout with the '-' option, due to some
    unclear reason, the stdout keyword does not work for lz4 and '-' works for
    both. In addition, this modifies the legacy '-c1' with '-9' which is also
    compatible with both. This fixes the mainline kernel build failures with
    the latest master OpenEmbedded builds associated with the mentioned
    compatibility issues.
    
    LZ4     arch/arm/boot/compressed/piggy_data
    /bin/sh: 1: lz4c: not found
    ...
    ...
    ERROR: oe_runmake failed
    
    Link: https://github.com/lz4/lz4/pull/553
    Suggested-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 225b88642aef6558550ccde63e06cc5438bb2b8d
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Jan 2 20:00:01 2025 -0500

    Revert "SUNRPC: Reduce thread wake-up rate when receiving large RPC messages"
    
    commit 966a675da844f1a764bb44557c21561cc3d09840 upstream.
    
    I noticed that a handful of NFSv3 fstests were taking an
    unexpectedly long time to run. Troubleshooting showed that the
    server's TCP window closed and never re-opened, which caused the
    client to trigger an RPC retransmit timeout after 180 seconds.
    
    The client's recovery action was to establish a fresh connection
    and retransmit the timed-out requests. This worked, but it adds a
    long delay.
    
    I tracked the problem to the commit that attempted to reduce the
    rate at which the network layer delivers TCP socket data_ready
    callbacks. Under most circumstances this change worked as expected,
    but for NFSv3, which has no session or other type of throttling, it
    can overwhelm the receiver on occasion.
    
    I'm sure I could tweak the lowat settings, but the small benefit
    doesn't seem worth the bother. Just revert it.
    
    Fixes: 2b877fc53e97 ("SUNRPC: Reduce thread wake-up rate when receiving large RPC messages")
    Cc: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18edc1d03ca0d2bf10054bc3dacad5778f908228
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Jan 26 12:45:17 2024 -0500

    NFSD: Reset cb_seq_status after NFS4ERR_DELAY
    
    commit 961b4b5e86bf56a2e4b567f81682defa5cba957e upstream.
    
    I noticed that once an NFSv4.1 callback operation gets a
    NFS4ERR_DELAY status on CB_SEQUENCE and then the connection is lost,
    the callback client loops, resending it indefinitely.
    
    The switch arm in nfsd4_cb_sequence_done() that handles
    NFS4ERR_DELAY uses rpc_restart_call() to rearm the RPC state machine
    for the retransmit, but that path does not call the rpc_prepare_call
    callback again. Thus cb_seq_status is set to -10008 by the first
    NFS4ERR_DELAY result, but is never set back to 1 for the retransmits.
    
    nfsd4_cb_sequence_done() thinks it's getting nothing but a
    long series of CB_SEQUENCE NFS4ERR_DELAY replies.
    
    Fixes: 7ba6cad6c88f ("nfsd: New helper nfsd4_cb_sequence_done() for processing more cb errors")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bf2adad03e1dee3a923d53bccecef13e3d58902
Author: Daniel Lee <chullee@google.com>
Date:   Fri Dec 20 15:41:31 2024 -0800

    f2fs: Introduce linear search for dentries
    
    commit 91b587ba79e1b68bb718d12b0758dbcdab4e9cb7 upstream.
    
    This patch addresses an issue where some files in case-insensitive
    directories become inaccessible due to changes in how the kernel function,
    utf8_casefold(), generates case-folded strings from the commit 5c26d2f1d3f5
    ("unicode: Don't special case ignorable code points").
    
    F2FS uses these case-folded names to calculate hash values for locating
    dentries and stores them on disk. Since utf8_casefold() can produce
    different output across kernel versions, stored hash values and newly
    calculated hash values may differ. This results in affected files no
    longer being found via the hash-based lookup.
    
    To resolve this, the patch introduces a linear search fallback.
    If the initial hash-based search fails, F2FS will sequentially scan the
    directory entries.
    
    Fixes: 5c26d2f1d3f5 ("unicode: Don't special case ignorable code points")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219586
    Signed-off-by: Daniel Lee <chullee@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Cc: Daniel Rosenberg <drosen@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa420dee339299e04c7edac70f71864c66f05503
Author: Lin Yujun <linyujun809@huawei.com>
Date:   Mon May 22 02:56:08 2023 +0000

    hexagon: Fix unbalanced spinlock in die()
    
    [ Upstream commit 03410e87563a122075c3721acc7d5510e41d8332 ]
    
    die executes holding the spinlock of &die.lock and unlock
    it after printing the oops message.
    However in the code if the notify_die() returns NOTIFY_STOP
    , die() exit with returning 1 but never unlocked the spinlock.
    
    Fix this by adding spin_unlock_irq(&die.lock) before returning.
    
    Fixes: cf9750bae262 ("Hexagon: Provide basic debugging and system trap support.")
    Signed-off-by: Lin Yujun <linyujun809@huawei.com>
    Link: https://lore.kernel.org/r/20230522025608.2515558-1-linyujun809@huawei.com
    Signed-off-by: Brian Cain <bcain@quicinc.com>
    Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97517cba767177cb4b66e1b32010125b01e4a8af
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Dec 3 17:17:34 2024 -0500

    hexagon: fix using plain integer as NULL pointer warning in cmpxchg
    
    [ Upstream commit 8a20030038742b9915c6d811a4e6c14b126cafb4 ]
    
    Sparse reports
    
        net/ipv4/inet_diag.c:1511:17: sparse: sparse: Using plain integer as NULL pointer
    
    Due to this code calling cmpxchg on a non-integer type
    struct inet_diag_handler *
    
        return !cmpxchg((const struct inet_diag_handler**)&inet_diag_table[type],
                        NULL, h) ? 0 : -EEXIST;
    
    While hexagon's cmpxchg assigns an integer value to a variable of this
    type.
    
        __typeof__(*(ptr)) __oldval = 0;
    
    Update this assignment to cast 0 to the correct type.
    
    The original issue is easily reproduced at head with the below block,
    and is absent after this change.
    
        make LLVM=1 ARCH=hexagon defconfig
        make C=1 LLVM=1 ARCH=hexagon net/ipv4/inet_diag.o
    
    Fixes: 99a70aa051d2 ("Hexagon: Add processor and system headers")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202411091538.PGSTqUBi-lkp@intel.com/
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Tested-by: Christian Gmeiner <cgmeiner@igalia.com>
    Link: https://lore.kernel.org/r/20241203221736.282020-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Brian Cain <bcain@quicinc.com>
    Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29f5ee6c9774eccd75583d40b3c9c12c72ef54fc
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jan 20 17:10:31 2025 +0900

    kconfig: fix memory leak in sym_warn_unmet_dep()
    
    [ Upstream commit a409fc1463d664002ea9bf700ae4674df03de111 ]
    
    The string allocated in sym_warn_unmet_dep() is never freed, leading
    to a memory leak when an unmet dependency is detected.
    
    Fixes: f8f69dc0b4e0 ("kconfig: make unmet dependency warnings readable")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 582e70f1eddfaa49c7ccbf4336166e9b6138ead0
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date:   Wed Nov 22 12:47:45 2023 +0900

    kconfig: WERROR unmet symbol dependency
    
    [ Upstream commit 15d3f7664d2776c086f813f1efbfe2ae20a85e89 ]
    
    When KCONFIG_WERROR env variable is set treat unmet direct
    symbol dependency as a terminal condition (error).
    
    Suggested-by: Stefan Reinauer <reinauer@google.com>
    Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 487852a55a4817421907a2957718848efa4b6a85
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Nov 18 16:59:09 2023 +0900

    kconfig: deduplicate code in conf_read_simple()
    
    [ Upstream commit d854b4b21de684a16a7d6163c7b0e9c5ff8a09d3 ]
    
    Kconfig accepts both "# CONFIG_FOO is not set" and "CONFIG_FOO=n" as
    a valid input, but conf_read_simple() duplicates similar code to handle
    them. Factor out the common code.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94d9ee3b85d204ceeb0e7ca1221d1316888328f1
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Nov 18 16:59:08 2023 +0900

    kconfig: remove unused code for S_DEF_AUTO in conf_read_simple()
    
    [ Upstream commit 92d4fe0a48f1ab6cf20143dd0b376f4fe842854b ]
    
    The 'else' arm here is unreachable in practical use cases.
    
    include/config/auto.conf does not include "# CONFIG_... is not set"
    line unless it is manually hacked.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26341c1bb7666c0e09a0f92c91567855e1e7fbe3
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Nov 18 16:59:07 2023 +0900

    kconfig: require a space after '#' for valid input
    
    [ Upstream commit 4d137ab0107ead0f2590fc0314e627431e3b9e3f ]
    
    Currently, when an input line starts with '#', (line + 2) is passed to
    memcmp() without checking line[1].
    
    It means that line[1] can be any arbitrary character. For example,
    "#KCONFIG_FOO is not set" is accepted as valid input, functioning the
    same as "# CONFIG_FOO is not set".
    
    More importantly, this can potentially lead to a buffer overrun if
    line[1] == '\0'. It occurs if the input only contains '#', as
    (line + 2) points to an uninitialized buffer.
    
    Check line[1], and skip the line if it is not a space.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13dc6f1692e002a732b00d13f6b48f354446c4cd
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jan 20 16:59:14 2025 +0900

    kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST
    
    [ Upstream commit a314f52a0210730d0d556de76bb7388e76d4597d ]
    
    Most 'make *config' commands use .config as the base configuration file.
    
    When .config does not exist, Kconfig tries to load a file listed in
    KCONFIG_DEFCONFIG_LIST instead.
    
    However, since commit b75b0a819af9 ("kconfig: change defconfig_list
    option to environment variable"), warning messages have displayed an
    incorrect file name in such cases.
    
    Below is a demonstration using Debian Trixie. While loading
    /boot/config-6.12.9-amd64, the warning messages incorrectly show .config
    as the file name.
    
    With this commit, the correct file name is displayed in warnings.
    
    [Before]
    
      $ rm -f .config
      $ make config
      #
      # using defaults found in /boot/config-6.12.9-amd64
      #
      .config:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT
      .config:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC
    
    [After]
    
      $ rm -f .config
      $ make config
      #
      # using defaults found in /boot/config-6.12.9-amd64
      #
      /boot/config-6.12.9-amd64:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT
      /boot/config-6.12.9-amd64:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC
    
    Fixes: b75b0a819af9 ("kconfig: change defconfig_list option to environment variable")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 089d1c188a5a448776a50f69e3e8fe5dc012f683
Author: Pali Rohár <pali@kernel.org>
Date:   Mon Oct 14 13:43:23 2024 +0200

    cifs: Fix getting and setting SACLs over SMB1
    
    [ Upstream commit 8b19dfb34d17e77a0809d433cc128b779282131b ]
    
    SMB1 callback get_cifs_acl_by_fid() currently ignores its last argument and
    therefore ignores request for SACL_SECINFO. Fix this issue by correctly
    propagating info argument from get_cifs_acl() and get_cifs_acl_by_fid() to
    CIFSSMBGetCIFSACL() function and pass SACL_SECINFO when requested.
    
    For accessing SACLs it is needed to open object with SYSTEM_SECURITY
    access. Pass this flag when trying to get or set SACLs.
    
    Same logic is in the SMB2+ code path.
    
    This change fixes getting and setting of "system.cifs_ntsd_full" and
    "system.smb3_ntsd_full" xattrs over SMB1 as currently it silentely ignored
    SACL part of passed xattr buffer.
    
    Fixes: 3970acf7ddb9 ("SMB3: Add support for getting and setting SACLs")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32cc06a68d3a305efd7833d7307f8845ec19ab71
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Dec 26 15:20:39 2024 +0100

    cifs: Validate EAs for WSL reparse points
    
    [ Upstream commit ef201e8759d20bf82b5943101147072de12bc524 ]
    
    Major and minor numbers for char and block devices are mandatory for stat.
    So check that the WSL EA $LXDEV is present for WSL CHR and BLK reparse
    points.
    
    WSL reparse point tag determinate type of the file. But file type is
    present also in the WSL EA $LXMOD. So check that both file types are same.
    
    Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 563ba1701bc1a87085de2d4d451c8435d061f6db
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Jan 22 17:29:31 2025 -0700

    io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock()
    
    [ Upstream commit d58d82bd0efd6c8edd452fc2f6c6dd052ec57cb2 ]
    
    io_uring_cmd_sock() does a normal read of cmd->sqe->cmd_op, where it
    really should be using a READ_ONCE() as ->sqe may still be pointing to
    the original SQE. Since the prep side already does this READ_ONCE() and
    stores it locally, use that value rather than re-read it.
    
    Fixes: 8e9fad0e70b7b ("io_uring: Add io_uring command support for sockets")
    Link: https://lore.kernel.org/r/20250121-uring-sockcmd-fix-v1-1-add742802a29@google.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 730071ea1ea76ca970eddb0dba9652fbe3dceb0e
Author: Detlev Casanova <detlev.casanova@collabora.com>
Date:   Fri Jan 17 11:31:02 2025 -0500

    ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback
    
    [ Upstream commit 5323186e2e8d33c073fad51e24f18e2d6dbae2da ]
    
    In commit
    9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates"),
    the set_sysclk callback was removed as considered unused as the mclk rate
    can be set in the hw_params callback.
    The difference between hw_params and set_sysclk is that the former is
    called with the audio sampling rate set in the params (e.g.: 48000 Hz)
    while the latter is called with a clock rate already computed with
      sampling_rate * mclk-fs (e.g.: 48000 * 256)
    
    For HDMI audio using the Rockchip I2S TDM driver, the mclk-fs value must
    be set to 128 instead of the default 256, and that value is set in the
    device tree at the machine driver level (like a simple-audio-card
    compatible node).
    Therefore, the i2s_tdm driver has no idea that another mclk-fs value can
    be configured and simply computes the mclk rate in the hw_params callback
    with DEFAULT_MCLK_FS * params_rate(params), which is wrong for HDMI
    audio.
    
    Re-add the set_sysclk callback so that the mclk rate is computed by the
    machine driver which has the correct mclk-fs value set in its device tree
    node.
    
    Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates")
    Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
    Link: https://patch.msgid.link/20250117163102.65807-1-detlev.casanova@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b730c68ea282175b617d762ae2f8fcd778f474ad
Author: Palmer Dabbelt <palmer@rivosinc.com>
Date:   Wed Jan 15 10:02:51 2025 -0800

    RISC-V: Mark riscv_v_init() as __init
    
    [ Upstream commit 9d87cf525fd2e1a5fcbbb40ee3df216d1d266c88 ]
    
    This trips up with Xtheadvector enabled, but as far as I can tell it's
    just been an issue since the original patchset.
    
    Fixes: 7ca7a7b9b635 ("riscv: Add sysctl to set the default vector rule for new processes")
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Tested-by: Charlie Jenkins <charlie@rivosinc.com>
    Link: https://lore.kernel.org/r/20250115180251.31444-1-palmer@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be80de30b347dc2eae35dd5f7905ad9c9167dc08
Author: Hongbo Li <lihongbo22@huawei.com>
Date:   Thu Jul 25 14:51:30 2024 +0800

    hostfs: fix the host directory parse when mounting.
    
    commit ef9ca17ca458ac7253ae71b552e601e49311fc48 upstream.
    
    hostfs not keep the host directory when mounting. When the host
    directory is none (default), fc->source is used as the host root
    directory, and this is wrong. Here we use `parse_monolithic` to
    handle the old mount path for parsing the root directory. For new
    mount path, The `parse_param` is used for the host directory parse.
    
    Reported-and-tested-by: Maciej Żenczykowski <maze@google.com>
    Fixes: cd140ce9f611 ("hostfs: convert hostfs to use the new mount API")
    Link: https://lore.kernel.org/all/CANP3RGceNzwdb7w=vPf5=7BCid5HVQDmz1K5kC9JG42+HVAh_g@mail.gmail.com/
    Cc: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
    Link: https://lore.kernel.org/r/20240725065130.1821964-1-lihongbo22@huawei.com
    [brauner: minor fixes]
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fbe93dd7e6a0dab59a5fce99f16703f7d52ed81
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jun 11 12:58:41 2024 -0700

    hostfs: Add const qualifier to host_root in hostfs_fill_super()
    
    commit 104eef133fd9c17e4dc28bf43f592a86f26d8a59 upstream.
    
    After the recent conversion to the new mount API, there is a warning
    when building hostfs (which may be upgraded to an error via
    CONFIG_WERROR=y):
    
      fs/hostfs/hostfs_kern.c: In function 'hostfs_fill_super':
      fs/hostfs/hostfs_kern.c:942:27: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
        942 |         char *host_root = fc->source;
            |                           ^~
    
    Add the 'const' qualifier, as host_root will not be modified after its
    assignment. Move the assignment to keep the existing reverse Christmas
    tree order intact.
    
    Fixes: cd140ce9f611 ("hostfs: convert hostfs to use the new mount API")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20240611-hostfs-fix-mount-api-conversion-v1-1-ef75bbc77f44@kernel.org
    Acked-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86ec56b25476758f708328b2eeed68918567efd0
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Jan 11 01:37:44 2025 -0500

    hostfs: fix string handling in __dentry_name()
    
    [ Upstream commit 60a6002432448bb3f291d80768ae98d62efc9c77 ]
    
    strcpy() should not be used with destination potentially overlapping
    the source; what's more, strscpy() in there is pointless - we already
    know the amount we want to copy; might as well use memcpy().
    
    Fixes: c278e81b8a02 "hostfs: Remove open coded strcpy()"
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d073828fe0f5cd9531bb918ab0b5a7b920b1bfdb
Author: Hongbo Li <lihongbo22@huawei.com>
Date:   Thu May 30 20:01:11 2024 +0800

    hostfs: convert hostfs to use the new mount API
    
    [ Upstream commit cd140ce9f611a5e9d2a5989a282b75e55c71dab3 ]
    
    Convert the hostfs filesystem to the new internal mount API as the old
    one will be obsoleted and removed.  This allows greater flexibility in
    communication of mount parameters between userspace, the VFS and the
    filesystem.
    
    See Documentation/filesystems/mount_api.txt for more information.
    
    Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
    Link: https://lore.kernel.org/r/20240530120111.3794664-1-lihongbo22@huawei.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: 60a600243244 ("hostfs: fix string handling in __dentry_name()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4517f37bf54e2e790bcff4c4aec25c4f6c5dd8d2
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri Jan 3 16:30:39 2025 +0900

    genksyms: fix memory leak when the same symbol is read from *.symref file
    
    [ Upstream commit be2fa44b5180a1f021efb40c55fdf63c249c3209 ]
    
    When a symbol that is already registered is read again from *.symref
    file, __add_symbol() removes the previous one from the hash table without
    freeing it.
    
    [Test Case]
    
      $ cat foo.c
      #include <linux/export.h>
      void foo(void);
      void foo(void) {}
      EXPORT_SYMBOL(foo);
    
      $ cat foo.symref
      foo void foo ( void )
      foo void foo ( void )
    
    When a symbol is removed from the hash table, it must be freed along
    with its ->name and ->defn members. However, sym->name cannot be freed
    because it is sometimes shared with node->string, but not always. If
    sym->name and node->string share the same memory, free(sym->name) could
    lead to a double-free bug.
    
    To resolve this issue, always assign a strdup'ed string to sym->name.
    
    Fixes: 64e6c1e12372 ("genksyms: track symbol checksum changes")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9dc841e89ae01c362e99fa8287d9b5b75cc37d0a
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri Jan 3 16:30:38 2025 +0900

    genksyms: fix memory leak when the same symbol is added from source
    
    [ Upstream commit 45c9c4101d3d2fdfa00852274bbebba65fcc3cf2 ]
    
    When a symbol that is already registered is added again, __add_symbol()
    returns without freeing the symbol definition, making it unreachable.
    
    The following test cases demonstrate different memory leak points.
    
    [Test Case 1]
    
    Forward declaration with exactly the same definition
    
      $ cat foo.c
      #include <linux/export.h>
      void foo(void);
      void foo(void) {}
      EXPORT_SYMBOL(foo);
    
    [Test Case 2]
    
    Forward declaration with a different definition (e.g. attribute)
    
      $ cat foo.c
      #include <linux/export.h>
      void foo(void);
      __attribute__((__section__(".ref.text"))) void foo(void) {}
      EXPORT_SYMBOL(foo);
    
    [Test Case 3]
    
    Preserving an overridden symbol (compile with KBUILD_PRESERVE=1)
    
      $ cat foo.c
      #include <linux/export.h>
      void foo(void);
      void foo(void) { }
      EXPORT_SYMBOL(foo);
    
      $ cat foo.symref
      override foo void foo ( int )
    
    The memory leaks in Test Case 1 and 2 have existed since the introduction
    of genksyms into the kernel tree. [1]
    
    The memory leak in Test Case 3 was introduced by commit 5dae9a550a74
    ("genksyms: allow to ignore symbol checksum changes").
    
    When multiple init_declarators are reduced to an init_declarator_list,
    the decl_spec must be duplicated. Otherwise, the following Test Case 4
    would result in a double-free bug.
    
    [Test Case 4]
    
      $ cat foo.c
      #include <linux/export.h>
    
      extern int foo, bar;
    
      int foo, bar;
      EXPORT_SYMBOL(foo);
    
    In this case, 'foo' and 'bar' share the same decl_spec, 'int'. It must
    be unshared before being passed to add_symbol().
    
    [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=46bd1da672d66ccd8a639d3c1f8a166048cca608
    
    Fixes: 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62289ebb2554e18de45d57cca23ecd5d27f24c66
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jan 29 13:00:07 2025 +0000

    net: hsr: fix fill_frame_info() regression vs VLAN packets
    
    [ Upstream commit 0f5697f1a3f99bc2b674b8aa3c5da822c5673c11 ]
    
    Stephan Wurm reported that my recent patch broke VLAN support.
    
    Apparently skb->mac_len is not correct for VLAN traffic as
    shown by debug traces [1].
    
    Use instead pskb_may_pull() to make sure the expected header
    is present in skb->head.
    
    Many thanks to Stephan for his help.
    
    [1]
    kernel: skb len=170 headroom=2 headlen=170 tailroom=20
            mac=(2,14) mac_len=14 net=(16,-1) trans=-1
            shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
            csum(0x0 start=0 offset=0 ip_summed=0 complete_sw=0 valid=0 level=0)
            hash(0x0 sw=0 l4=0) proto=0x0000 pkttype=0 iif=0
            priority=0x0 mark=0x0 alloc_cpu=0 vlan_all=0x0
            encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
    kernel: dev name=prp0 feat=0x0000000000007000
    kernel: sk family=17 type=3 proto=0
    kernel: skb headroom: 00000000: 74 00
    kernel: skb linear:   00000000: 01 0c cd 01 00 01 00 d0 93 53 9c cb 81 00 80 00
    kernel: skb linear:   00000010: 88 b8 00 01 00 98 00 00 00 00 61 81 8d 80 16 52
    kernel: skb linear:   00000020: 45 47 44 4e 43 54 52 4c 2f 4c 4c 4e 30 24 47 4f
    kernel: skb linear:   00000030: 24 47 6f 43 62 81 01 14 82 16 52 45 47 44 4e 43
    kernel: skb linear:   00000040: 54 52 4c 2f 4c 4c 4e 30 24 44 73 47 6f 6f 73 65
    kernel: skb linear:   00000050: 83 07 47 6f 49 64 65 6e 74 84 08 67 8d f5 93 7e
    kernel: skb linear:   00000060: 76 c8 00 85 01 01 86 01 00 87 01 00 88 01 01 89
    kernel: skb linear:   00000070: 01 00 8a 01 02 ab 33 a2 15 83 01 00 84 03 03 00
    kernel: skb linear:   00000080: 00 91 08 67 8d f5 92 77 4b c6 1f 83 01 00 a2 1a
    kernel: skb linear:   00000090: a2 06 85 01 00 83 01 00 84 03 03 00 00 91 08 67
    kernel: skb linear:   000000a0: 8d f5 92 77 4b c6 1f 83 01 00
    kernel: skb tailroom: 00000000: 80 18 02 00 fe 4e 00 00 01 01 08 0a 4f fd 5e d1
    kernel: skb tailroom: 00000010: 4f fd 5e cd
    
    Fixes: b9653d19e556 ("net: hsr: avoid potential out-of-bound access in fill_frame_info()")
    Reported-by: Stephan Wurm <stephan.wurm@a-eberle.de>
    Tested-by: Stephan Wurm <stephan.wurm@a-eberle.de>
    Closes: https://lore.kernel.org/netdev/Z4o_UC0HweBHJ_cw@PC-LX-SteWu/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250129130007.644084-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f59acc3f9441ff662d203e6c4e7c1c5298badb37
Author: Kory Maincent <kory.maincent@bootlin.com>
Date:   Wed Jan 29 10:50:47 2025 +0100

    net: sh_eth: Fix missing rtnl lock in suspend/resume path
    
    [ Upstream commit b95102215a8d0987789715ce11c0d4ec031cbfbe ]
    
    Fix the suspend/resume path by ensuring the rtnl lock is held where
    required. Calls to sh_eth_close, sh_eth_open and wol operations must be
    performed under the rtnl lock to prevent conflicts with ongoing ndo
    operations.
    
    Fixes: b71af04676e9 ("sh_eth: add more PM methods")
    Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1bc4a35a04cbeb85b6ef5911ec015baa424989f
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Mon Jan 27 14:13:42 2025 +0100

    net: xdp: Disallow attaching device-bound programs in generic mode
    
    [ Upstream commit 3595599fa8360bb3c7afa7ee50c810b4a64106ea ]
    
    Device-bound programs are used to support RX metadata kfuncs. These
    kfuncs are driver-specific and rely on the driver context to read the
    metadata. This means they can't work in generic XDP mode. However, there
    is no check to disallow such programs from being attached in generic
    mode, in which case the metadata kfuncs will be called in an invalid
    context, leading to crashes.
    
    Fix this by adding a check to disallow attaching device-bound programs
    in generic mode.
    
    Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs")
    Reported-by: Marcus Wichelmann <marcus.wichelmann@hetzner-cloud.de>
    Closes: https://lore.kernel.org/r/dae862ec-43b5-41a0-8edf-46c59071cdda@hetzner-cloud.de
    Tested-by: Marcus Wichelmann <marcus.wichelmann@hetzner-cloud.de>
    Acked-by: Stanislav Fomichev <sdf@fomichev.me>
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://patch.msgid.link/20250127131344.238147-1-toke@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b01e7ceb35dcb7ffad413da657b78c3340a09039
Author: Jon Maloy <jmaloy@redhat.com>
Date:   Mon Jan 27 18:13:04 2025 -0500

    tcp: correct handling of extreme memory squeeze
    
    [ Upstream commit 8c670bdfa58e48abad1d5b6ca1ee843ca91f7303 ]
    
    Testing with iperf3 using the "pasta" protocol splicer has revealed
    a problem in the way tcp handles window advertising in extreme memory
    squeeze situations.
    
    Under memory pressure, a socket endpoint may temporarily advertise
    a zero-sized window, but this is not stored as part of the socket data.
    The reasoning behind this is that it is considered a temporary setting
    which shouldn't influence any further calculations.
    
    However, if we happen to stall at an unfortunate value of the current
    window size, the algorithm selecting a new value will consistently fail
    to advertise a non-zero window once we have freed up enough memory.
    This means that this side's notion of the current window size is
    different from the one last advertised to the peer, causing the latter
    to not send any data to resolve the sitution.
    
    The problem occurs on the iperf3 server side, and the socket in question
    is a completely regular socket with the default settings for the
    fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
    
    The following excerpt of a logging session, with own comments added,
    shows more in detail what is happening:
    
    //              tcp_v4_rcv(->)
    //                tcp_rcv_established(->)
    [5201<->39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
    [5201<->39222]:     tcp_data_queue(->)
    [5201<->39222]:        DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM
                           [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
                           [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0]
                           [OFO queue: gap: 65480, len: 0]
    [5201<->39222]:     tcp_data_queue(<-)
    [5201<->39222]:     __tcp_transmit_skb(->)
                            [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
    [5201<->39222]:       tcp_select_window(->)
    [5201<->39222]:         (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE
                            [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
                            returning 0
    [5201<->39222]:       tcp_select_window(<-)
    [5201<->39222]:       ADVERTISING WIN 0, ACK_SEQ: 265600160
    [5201<->39222]:     [__tcp_transmit_skb(<-)
    [5201<->39222]:   tcp_rcv_established(<-)
    [5201<->39222]: tcp_v4_rcv(<-)
    
    // Receive queue is at 85 buffers and we are out of memory.
    // We drop the incoming buffer, although it is in sequence, and decide
    // to send an advertisement with a window of zero.
    // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means
    // we unconditionally shrink the window.
    
    [5201<->39222]: tcp_recvmsg_locked(->)
    [5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160
    [5201<->39222]:     [new_win = 0, win_now = 131184, 2 * win_now = 262368]
    [5201<->39222]:     [new_win >= (2 * win_now) ? --> time_to_ack = 0]
    [5201<->39222]:     NOT calling tcp_send_ack()
                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
    [5201<->39222]:   __tcp_cleanup_rbuf(<-)
                      [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
                      [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
                      returning 6104 bytes
    [5201<->39222]: tcp_recvmsg_locked(<-)
    
    // After each read, the algorithm for calculating the new receive
    // window in __tcp_cleanup_rbuf() finds it is too small to advertise
    // or to update tp->rcv_wnd.
    // Meanwhile, the peer thinks the window is zero, and will not send
    // any more data to trigger an update from the interrupt mode side.
    
    [5201<->39222]: tcp_recvmsg_locked(->)
    [5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160
    [5201<->39222]:     [new_win = 262144, win_now = 131184, 2 * win_now = 262368]
    [5201<->39222]:     [new_win >= (2 * win_now) ? --> time_to_ack = 0]
    [5201<->39222]:     NOT calling tcp_send_ack()
                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
    [5201<->39222]:   __tcp_cleanup_rbuf(<-)
                      [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
                      [copied_seq 260099840->260171536 (71696), unread 5428624, qlen 83, ofoq 0]
                      returning 131072 bytes
    [5201<->39222]: tcp_recvmsg_locked(<-)
    
    // The above pattern repeats again and again, since nothing changes
    // between the reads.
    
    [...]
    
    [5201<->39222]: tcp_recvmsg_locked(->)
    [5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160
    [5201<->39222]:     [new_win = 262144, win_now = 131184, 2 * win_now = 262368]
    [5201<->39222]:     [new_win >= (2 * win_now) ? --> time_to_ack = 0]
    [5201<->39222]:     NOT calling tcp_send_ack()
                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
    [5201<->39222]:   __tcp_cleanup_rbuf(<-)
                      [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
                      [copied_seq 265600160->265600160 (0), unread 0, qlen 0, ofoq 0]
                      returning 54672 bytes
    [5201<->39222]: tcp_recvmsg_locked(<-)
    
    // The receive queue is empty, but no new advertisement has been sent.
    // The peer still thinks the receive window is zero, and sends nothing.
    // We have ended up in a deadlock situation.
    
    Note that well behaved endpoints will send win0 probes, so the problem
    will not occur.
    
    Furthermore, we have observed that in these situations this side may
    send out an updated 'th->ack_seq´ which is not stored in tp->rcv_wup
    as it should be. Backing ack_seq seems to be harmless, but is of
    course still wrong from a protocol viewpoint.
    
    We fix this by updating the socket state correctly when a packet has
    been dropped because of memory exhaustion and we have to advertize
    a zero window.
    
    Further testing shows that the connection recovers neatly from the
    squeeze situation, and traffic can continue indefinitely.
    
    Fixes: e2142825c120 ("net: tcp: send zero-window ACK when no memory")
    Cc: Menglong Dong <menglong8.dong@gmail.com>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Jon Maloy <jmaloy@redhat.com>
    Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Neal Cardwell <ncardwell@google.com>
    Link: https://patch.msgid.link/20250127231304.1465565-1-jmaloy@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e6e723675e54ced5200bcc367e2526badc4070c
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Mon Jan 27 09:51:59 2025 -0800

    bgmac: reduce max frame size to support just MTU 1500
    
    [ Upstream commit 752e5fcc2e77358936d36ef8e522d6439372e201 ]
    
    bgmac allocates new replacement buffer before handling each received
    frame. Allocating & DMA-preparing 9724 B each time consumes a lot of CPU
    time. Ideally bgmac should just respect currently set MTU but it isn't
    the case right now. For now just revert back to the old limited frame
    size.
    
    This change bumps NAT masquerade speed by ~95%.
    
    Since commit 8218f62c9c9b ("mm: page_frag: use initial zero offset for
    page_frag_alloc_align()"), the bgmac driver fails to open its network
    interface successfully and runs out of memory in the following call
    stack:
    
    bgmac_open
      -> bgmac_dma_init
        -> bgmac_dma_rx_skb_for_slot
          -> netdev_alloc_frag
    
    BGMAC_RX_ALLOC_SIZE = 10048 and PAGE_FRAG_CACHE_MAX_SIZE = 32768.
    
    Eventually we land into __page_frag_alloc_align() with the following
    parameters across multiple successive calls:
    
    __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=0
    __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=10048
    __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=20096
    __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=30144
    
    So in that case we do indeed have offset + fragsz (40192) > size (32768)
    and so we would eventually return NULL. Reverting to the older 1500
    bytes MTU allows the network driver to be usable again.
    
    Fixes: 8c7da63978f1 ("bgmac: configure MTU and add support for frames beyond 8192 byte size")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    [florian: expand commit message about recent commits]
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://patch.msgid.link/20250127175159.1788246-1-florian.fainelli@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77ad90dd18aec27700a69239938eda597ef7d8e7
Author: Michal Luczaj <mhal@rbox.co>
Date:   Tue Jan 28 14:15:28 2025 +0100

    vsock: Allow retrying on connect() failure
    
    [ Upstream commit aa388c72113b7458127b709bdd7d3628af26e9b4 ]
    
    sk_err is set when a (connectible) connect() fails. Effectively, this makes
    an otherwise still healthy SS_UNCONNECTED socket impossible to use for any
    subsequent connection attempts.
    
    Clear sk_err upon trying to establish a connection.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Link: https://patch.msgid.link/20250128-vsock-transport-vs-autobind-v3-2-1cf57065b770@rbox.co
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3924c153761c4dd44f1ef1b5c94a7313f90f8336
Author: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Date:   Mon Jan 20 19:49:46 2025 +0530

    Bluetooth: btnxpuart: Fix glitches seen in dual A2DP streaming
    
    [ Upstream commit 7de119bb79a63f6a1959b83117a98734914fb0b0 ]
    
    This fixes a regression caused by previous commit for fixing truncated
    ACL data, which is causing some intermittent glitches when running two
    A2DP streams.
    
    serdev_device_write_buf() is the root cause of the glitch, which is
    reverted, and the TX work will continue to write until the queue is empty.
    
    This change fixes both issues. No A2DP streaming glitches or truncated
    ACL data issue observed.
    
    Fixes: 8023dd220425 ("Bluetooth: btnxpuart: Fix driver sending truncated data")
    Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets")
    Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2cd915aea83c6e8993ee239492076c36ffba6e1
Author: Howard Chu <howardchu95@gmail.com>
Date:   Tue Jan 21 18:55:19 2025 -0800

    perf trace: Fix runtime error of index out of bounds
    
    [ Upstream commit c7b87ce0dd10b64b68a0b22cb83bbd556e28fe81 ]
    
    libtraceevent parses and returns an array of argument fields, sometimes
    larger than RAW_SYSCALL_ARGS_NUM (6) because it includes "__syscall_nr",
    idx will traverse to index 6 (7th element) whereas sc->fmt->arg holds 6
    elements max, creating an out-of-bounds access. This runtime error is
    found by UBsan. The error message:
    
      $ sudo UBSAN_OPTIONS=print_stacktrace=1 ./perf trace -a --max-events=1
      builtin-trace.c:1966:35: runtime error: index 6 out of bounds for type 'syscall_arg_fmt [6]'
        #0 0x5c04956be5fe in syscall__alloc_arg_fmts /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:1966
        #1 0x5c04956c0510 in trace__read_syscall_info /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:2110
        #2 0x5c04956c372b in trace__syscall_info /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:2436
        #3 0x5c04956d2f39 in trace__init_syscalls_bpf_prog_array_maps /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:3897
        #4 0x5c04956d6d25 in trace__run /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:4335
        #5 0x5c04956e112e in cmd_trace /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:5502
        #6 0x5c04956eda7d in run_builtin /home/howard/hw/linux-perf/tools/perf/perf.c:351
        #7 0x5c04956ee0a8 in handle_internal_command /home/howard/hw/linux-perf/tools/perf/perf.c:404
        #8 0x5c04956ee37f in run_argv /home/howard/hw/linux-perf/tools/perf/perf.c:448
        #9 0x5c04956ee8e9 in main /home/howard/hw/linux-perf/tools/perf/perf.c:556
        #10 0x79eb3622a3b7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #11 0x79eb3622a47a in __libc_start_main_impl ../csu/libc-start.c:360
        #12 0x5c04955422d4 in _start (/home/howard/hw/linux-perf/tools/perf/perf+0x4e02d4) (BuildId: 5b6cab2d59e96a4341741765ad6914a4d784dbc6)
    
         0.000 ( 0.014 ms): Chrome_ChildIO/117244 write(fd: 238, buf: !, count: 1)                                      = 1
    
    Fixes: 5e58fcfaf4c6 ("perf trace: Allow allocating sc->arg_fmt even without the syscall tracepoint")
    Signed-off-by: Howard Chu <howardchu95@gmail.com>
    Link: https://lore.kernel.org/r/20250122025519.361873-1-howardchu95@gmail.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d3693d402a81043d6231fcb31e2bf6acb4cb4ef
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Mon Jan 27 10:38:19 2025 +0900

    net: stmmac: Limit FIFO size by hardware capability
    
    [ Upstream commit 044f2fbaa2725696ecbf1f02ba7ab0a8ccb7e1ae ]
    
    Tx/Rx FIFO size is specified by the parameter "{tx,rx}-fifo-depth" from
    stmmac_platform layer.
    
    However, these values are constrained by upper limits determined by the
    capabilities of each hardware feature. There is a risk that the upper
    bits will be truncated due to the calculation, so it's appropriate to
    limit them to the upper limit values and display a warning message.
    
    This only works if the hardware capability has the upper limit values.
    
    Fixes: e7877f52fd4a ("stmmac: Read tx-fifo-depth and rx-fifo-depth from the devicetree")
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80083bd4c214ae15a5a906330ace6266548610de
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Mon Jan 27 10:38:18 2025 +0900

    net: stmmac: Limit the number of MTL queues to hardware capability
    
    [ Upstream commit f5fb35a3d6b36d378b2e2ecbfb9caa337d5428e6 ]
    
    The number of MTL queues to use is specified by the parameter
    "snps,{tx,rx}-queues-to-use" from stmmac_platform layer.
    
    However, the maximum numbers of queues are constrained by upper limits
    determined by the capability of each hardware feature. It's appropriate
    to limit the values not to exceed the upper limit values and display
    a warning message.
    
    This only works if the hardware capability has the upper limit values.
    
    Fixes: d976a525c371 ("net: stmmac: multiple queues dt configuration")
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a6d1e1d022bf1b3dce34b7d25d3783f59006561
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Sat Jan 25 10:28:38 2025 +0100

    ptp: Properly handle compat ioctls
    
    [ Upstream commit 19ae40f572a9ce1ade9954990af709a03fd37010 ]
    
    Pointer arguments passed to ioctls need to pass through compat_ptr() to
    work correctly on s390; as explained in Documentation/driver-api/ioctl.rst.
    Detect compat mode at runtime and call compat_ptr() for those commands
    which do take pointer arguments.
    
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/lkml/1ba5d3a4-7931-455b-a3ce-85a968a7cb10@app.fastmail.com/
    Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.")
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Link: https://patch.msgid.link/20250125-posix-clock-compat_ioctl-v2-1-11c865c500eb@weissschuh.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c411f9a5fdc9158e8f7c57eac961d3df3eb4d8ca
Author: Chenyuan Yang <chenyuan0y@gmail.com>
Date:   Thu Jan 23 15:42:13 2025 -0600

    net: davicom: fix UAF in dm9000_drv_remove
    
    [ Upstream commit 19e65c45a1507a1a2926649d2db3583ed9d55fd9 ]
    
    dm is netdev private data and it cannot be
    used after free_netdev() call. Using dm after free_netdev()
    can cause UAF bug. Fix it by moving free_netdev() at the end of the
    function.
    
    This is similar to the issue fixed in commit
    ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
    
    This bug is detected by our static analysis tool.
    
    Fixes: cf9e60aa69ae ("net: davicom: Fix regulator not turned off on driver removal")
    Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com>
    CC: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
    Link: https://patch.msgid.link/20250123214213.623518-1-chenyuan0y@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a84d511165d6ba7f331b90ae6b6ce180ec534daa
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Thu Jan 23 23:57:46 2025 +0900

    vxlan: Fix uninit-value in vxlan_vnifilter_dump()
    
    [ Upstream commit 5066293b9b7046a906eff60e3949a887ae185a43 ]
    
    KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].
    
    If the length of the netlink message payload is less than
    sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes
    beyond the message. This can lead to uninit-value access. Fix this by
    returning an error in such situations.
    
    [1]
    BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422
     vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422
     rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786
     netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317
     __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432
     netlink_dump_start include/linux/netlink.h:340 [inline]
     rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]
     rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882
     netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542
     rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944
     netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
     netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347
     netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891
     sock_sendmsg_nosec net/socket.c:711 [inline]
     __sock_sendmsg+0x330/0x3d0 net/socket.c:726
     ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583
     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637
     __sys_sendmsg net/socket.c:2669 [inline]
     __do_sys_sendmsg net/socket.c:2674 [inline]
     __se_sys_sendmsg net/socket.c:2672 [inline]
     __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672
     x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
     slab_post_alloc_hook mm/slub.c:4110 [inline]
     slab_alloc_node mm/slub.c:4153 [inline]
     kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205
     kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587
     __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678
     alloc_skb include/linux/skbuff.h:1323 [inline]
     netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196
     netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866
     sock_sendmsg_nosec net/socket.c:711 [inline]
     __sock_sendmsg+0x330/0x3d0 net/socket.c:726
     ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583
     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637
     __sys_sendmsg net/socket.c:2669 [inline]
     __do_sys_sendmsg net/socket.c:2674 [inline]
     __se_sys_sendmsg net/socket.c:2672 [inline]
     __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672
     x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
    
    Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://patch.msgid.link/20250123145746.785768-1-syoshida@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b91034314ad24a5dcdd4739035e9f787a9030a9e
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Jan 22 14:45:03 2025 -0800

    net: netdevsim: try to close UDP port harness races
    
    [ Upstream commit 50bf398e1ceacb9a7f85bd3bdca065ebe5cb6159 ]
    
    syzbot discovered that we remove the debugfs files after we free
    the netdev. Try to clean up the relevant dir while the device
    is still around.
    
    Reported-by: syzbot+2e5de9e3ab986b71d2bf@syzkaller.appspotmail.com
    Fixes: 424be63ad831 ("netdevsim: add UDP tunnel port offload support")
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Link: https://patch.msgid.link/20250122224503.762705-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51c128ba038cf1b79d605cbee325919b45ab95a5
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jan 22 18:02:44 2025 +0000

    net: rose: fix timer races against user threads
    
    [ Upstream commit 5de7665e0a0746b5ad7943554b34db8f8614a196 ]
    
    Rose timers only acquire the socket spinlock, without
    checking if the socket is owned by one user thread.
    
    Add a check and rearm the timers if needed.
    
    BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
    Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
    
    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
    Call Trace:
     <IRQ>
      __dump_stack lib/dump_stack.c:94 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
      print_address_description mm/kasan/report.c:378 [inline]
      print_report+0x169/0x550 mm/kasan/report.c:489
      kasan_report+0x143/0x180 mm/kasan/report.c:602
      rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
      call_timer_fn+0x187/0x650 kernel/time/timer.c:1793
      expire_timers kernel/time/timer.c:1844 [inline]
      __run_timers kernel/time/timer.c:2418 [inline]
      __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430
      run_timer_base kernel/time/timer.c:2439 [inline]
      run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449
      handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
      __do_softirq kernel/softirq.c:595 [inline]
      invoke_softirq kernel/softirq.c:435 [inline]
      __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662
      irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
      instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
      sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049
     </IRQ>
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20250122180244.1861468-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5385c1d1c08fd79064b613a0658c4235299ddb50
Author: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Date:   Thu Sep 5 11:14:10 2024 +0200

    iavf: allow changing VLAN state without calling PF
    
    [ Upstream commit ee7d79433d783346430ee32f28c9df44a88b3bb6 ]
    
    First case:
    > ip l a l $VF name vlanx type vlan id 100
    > ip l d vlanx
    > ip l a l $VF name vlanx type vlan id 100
    
    As workqueue can be execute after sometime, there is a window to have
    call trace like that:
    - iavf_del_vlan
    - iavf_add_vlan
    - iavf_del_vlans (wq)
    
    It means that our VLAN 100 will change the state from IAVF_VLAN_ACTIVE
    to IAVF_VLAN_REMOVE (iavf_del_vlan). After that in iavf_add_vlan state
    won't be changed because VLAN 100 is on the filter list. The final
    result is that the VLAN 100 filter isn't added in hardware (no
    iavf_add_vlans call).
    
    To fix that change the state if the filter wasn't removed yet directly
    to active. It is save as IAVF_VLAN_REMOVE means that virtchnl message
    wasn't sent yet.
    
    Second case:
    > ip l a l $VF name vlanx type vlan id 100
    Any type of VF reset ex. change trust
    > ip l s $PF vf $VF_NUM trust on
    > ip l d vlanx
    > ip l a l $VF name vlanx type vlan id 100
    
    In case of reset iavf driver is responsible for readding all filters
    that are being used. To do that all VLAN filters state are changed to
    IAVF_VLAN_ADD. Here is even longer window for changing VLAN state from
    kernel side, as workqueue isn't called immediately. We can have call
    trace like that:
    
    - changing to IAVF_VLAN_ADD (after reset)
    - iavf_del_vlan (called from kernel ops)
    - iavf_del_vlans (wq)
    
    Not exsisitng VLAN filters will be removed from hardware. It isn't a
    bug, ice driver will handle it fine. However, we can have call trace
    like that:
    
    - changing to IAVF_VLAN_ADD (after reset)
    - iavf_del_vlan (called from kernel ops)
    - iavf_add_vlan (called from kernel ops)
    - iavf_del_vlans (wq)
    
    With fix for previous case we end up with no VLAN filters in hardware.
    We have to remove VLAN filters if the state is IAVF_VLAN_ADD and delete
    VLAN was called. It is save as IAVF_VLAN_ADD means that virtchnl message
    wasn't sent yet.
    
    Fixes: 0c0da0e95105 ("iavf: refactor VLAN filter states")
    Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02794e35ab0db32ad72d46afb5f02133b46d977b
Author: Wentao Liang <vulab@iscas.ac.cn>
Date:   Sun Jan 19 22:32:05 2025 +0800

    PM: hibernate: Add error handling for syscore_suspend()
    
    [ Upstream commit e20a70c572539a486dbd91b225fa6a194a5e2122 ]
    
    In hibernation_platform_enter(), the code did not check the
    return value of syscore_suspend(), potentially leading to a
    situation where syscore_resume() would be called even if
    syscore_suspend() failed. This could cause unpredictable
    behavior or system instability.
    
    Modify the code sequence in question to properly handle errors returned
    by syscore_suspend(). If an error occurs in the suspend path, the code
    now jumps to label 'Enable_irqs' skipping the syscore_resume() call and
    only enabling interrupts after setting the system state to SYSTEM_RUNNING.
    
    Fixes: 40dc166cb5dd ("PM / Core: Introduce struct syscore_ops for core subsystems PM")
    Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
    Link: https://patch.msgid.link/20250119143205.2103-1-vulab@iscas.ac.cn
    [ rjw: Changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b379b3162ff55a70464c6a934ae9bf0497478a62
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 21 18:12:41 2025 +0000

    ipmr: do not call mr_mfc_uses_dev() for unres entries
    
    [ Upstream commit 15a901361ec3fb1c393f91880e1cbf24ec0a88bd ]
    
    syzbot found that calling mr_mfc_uses_dev() for unres entries
    would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif
    alias to "struct sk_buff_head unresolved", which contain two pointers.
    
    This code never worked, lets remove it.
    
    [1]
    Unable to handle kernel paging request at virtual address ffff5fff2d536613
    KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]
    Modules linked in:
    CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
    pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]
     pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334
     lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]
     lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334
    Call trace:
      mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)
      mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)
      mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382
      ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648
      rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327
      rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791
      netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317
      netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973
      sock_recvmsg_nosec net/socket.c:1033 [inline]
      sock_recvmsg net/socket.c:1055 [inline]
      sock_read_iter+0x2d8/0x40c net/socket.c:1125
      new_sync_read fs/read_write.c:484 [inline]
      vfs_read+0x740/0x970 fs/read_write.c:565
      ksys_read+0x15c/0x26c fs/read_write.c:708
    
    Fixes: cb167893f41e ("net: Plumb support for filtering ipv4 and ipv6 multicast route dumps")
    Reported-by: syzbot+5cfae50c0e5f2c500013@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/678fe2d1.050a0220.15cac.00b3.GAE@google.com/T/#u
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20250121181241.841212-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d063bec046a04c26bcabf90f36289c77ae51413f
Author: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
Date:   Mon Jan 20 14:24:30 2025 +0530

    net: fec: implement TSO descriptor cleanup
    
    [ Upstream commit 61dc1fd9205bc9d9918aa933a847b08e80b4dc20 ]
    
    Implement cleanup of descriptors in the TSO error path of
    fec_enet_txq_submit_tso(). The cleanup
    
    - Unmaps DMA buffers for data descriptors skipping TSO header
    - Clears all buffer descriptors
    - Handles extended descriptors by clearing cbd_esc when enabled
    
    Fixes: 79f339125ea3 ("net: fec: Add software TSO support")
    Signed-off-by: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
    Reviewed-by: Wei Fang <wei.fang@nxp.com>
    Link: https://patch.msgid.link/20250120085430.99318-1-dheeraj.linuxdev@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5a17441bb38ca558fae0a80664cb7b1222787bf
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Mon Jan 13 23:19:11 2025 +0100

    gpio: mxc: remove dead code after switch to DT-only
    
    [ Upstream commit b049e7abe9001a780d58e78e3833dcceee22f396 ]
    
    struct platform_device::id was only set by board code, but since i.MX
    became a devicetree-only platform, this will always be -1
    (PLATFORM_DEVID_NONE).
    
    Note: of_alias_get_id() returns a negative number on error and base
    treats all negative errors the same, so we need not add any additional
    error handling.
    
    Fixes: 0f2c7af45d7e ("gpio: mxc: Convert the driver to DT-only")
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20250113-b4-imx-gpio-base-warning-v1-3-0a28731a5cf6@pengutronix.de
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5a8bc47aa0a4aa8bca5466dfa2d12dbb5b3cd0c
Author: Jian Shen <shenjian15@huawei.com>
Date:   Sat Jan 18 17:47:41 2025 +0800

    net: hns3: fix oops when unload drivers paralleling
    
    [ Upstream commit 92e5995773774a3e70257e9c95ea03518268bea5 ]
    
    When unload hclge driver, it tries to disable sriov first for each
    ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at
    the time, because it removes all the ae_dev nodes, and it may cause
    oops.
    
    But we can't simply use hnae3_common_lock for this. Because in the
    process flow of pci_disable_sriov(), it will trigger the remove flow
    of VF, which will also take hnae3_common_lock.
    
    To fixes it, introduce a new mutex to protect the unload process.
    
    Fixes: 0dd8a25f355b ("net: hns3: disable sriov before unload hclge layer")
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Link: https://patch.msgid.link/20250118094741.3046663-1-shaojijie@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0f6111bb525d86f3a6befb1f29771684b372cad
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Wed Jan 22 08:20:19 2025 +0100

    regulator: core: Add missing newline character
    
    [ Upstream commit 155c569fa4c3b340fbf8571a0e42dd415c025377 ]
    
    dev_err_probe() error messages need newline character.
    
    Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API")
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://patch.msgid.link/20250122072019.1926093-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40e25a3c0063935763717877bb2a814c081509ff
Author: pangliyuan <pangliyuan1@huawei.com>
Date:   Tue Dec 24 16:18:23 2024 +0800

    ubifs: skip dumping tnc tree when zroot is null
    
    [ Upstream commit bdb0ca39e0acccf6771db49c3f94ed787d05f2d7 ]
    
    Clearing slab cache will free all znode in memory and make
    c->zroot.znode = NULL, then dumping tnc tree will access
    c->zroot.znode which cause null pointer dereference.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219624#c0
    Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
    Signed-off-by: pangliyuan <pangliyuan1@huawei.com>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20f0f55e6d686eae7934e28358ea446e36cff77f
Author: Ming Wang <wangming01@loongson.cn>
Date:   Thu Dec 5 19:43:07 2024 +0800

    rtc: loongson: clear TOY_MATCH0_REG in loongson_rtc_isr()
    
    [ Upstream commit 09471d8f5b390883eaf21b917c4bf3ced1b8a1df ]
    
    The TOY_MATCH0_REG should be cleared to 0 in the RTC interrupt handler,
    otherwise the interrupt cannot be cleared, which will cause the
    loongson_rtc_isr() to be triggered multiple times.
    
    The previous code cleared TOY_MATCH0_REG in the loongson_rtc_handler(),
    which is an ACPI interrupt. This did not prevent loongson_rtc_isr()
    from being triggered multiple times.
    
    This commit moves the clearing of TOY_MATCH0_REG to the
    loongson_rtc_isr() to ensure that the interrupt is properly cleared.
    
    Fixes: 1b733a9ebc3d ("rtc: Add rtc driver for the Loongson family chips")
    Signed-off-by: Ming Wang <wangming01@loongson.cn>
    Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
    Reviewed-by: Keguang Zhang <keguang.zhang@gmail.com> # on LS1B
    Tested-by: Keguang Zhang <keguang.zhang@gmail.com>
    Link: https://lore.kernel.org/r/20241205114307.1891418-1-wangming01@loongson.cn
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9adefa7b9559d0f21034a5d5ec1b55840c9348b9
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Wed Dec 18 20:34:58 2024 +0100

    rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
    
    [ Upstream commit 3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c ]
    
    The nvmem interface supports variable buffer sizes, while the regmap
    interface operates with fixed-size storage. If an nvmem client uses a
    buffer size less than 4 bytes, regmap_read will write out of bounds
    as it expects the buffer to point at an unsigned int.
    
    Fix this by using an intermediary unsigned int to hold the value.
    
    Fixes: fadfd092ee91 ("rtc: pcf85063: add nvram support")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Link: https://lore.kernel.org/r/20241218-rtc-pcf85063-stack-corruption-v1-1-12fd0ee0f046@pengutronix.de
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6e1b2cac24b2a4d1dd472071021bf00c26450eb
Author: Alexandre Cassen <acassen@corp.free.fr>
Date:   Thu Jan 2 12:11:11 2025 +0200

    xfrm: delete intermediate secpath entry in packet offload mode
    
    [ Upstream commit 600258d555f0710b9c47fb78d2d80a4aecd608cc ]
    
    Packets handled by hardware have added secpath as a way to inform XFRM
    core code that this path was already handled. That secpath is not needed
    at all after policy is checked and it is removed later in the stack.
    
    However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),
    that secpath is not removed and packets which already were handled are reentered
    to the driver TX path with xfrm_offload set.
    
    The following kernel panic is observed in mlx5 in such case:
    
     mlx5_core 0000:04:00.0 enp4s0f0np0: Link up
     mlx5_core 0000:04:00.1 enp4s0f1np1: Link up
     Initializing XFRM netlink socket
     IPsec XFRM device driver
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor instruction fetch in kernel mode
     #PF: error_code(0x0010) - not-present page
     PGD 0 P4D 0
     Oops: Oops: 0010 [#1] PREEMPT SMP
     CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
     RIP: 0010:0x0
     Code: Unable to access opcode bytes at 0xffffffffffffffd6.
     RSP: 0018:ffffb87380003800 EFLAGS: 00010206
     RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf
     RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00
     RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010
     R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00
     R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e
     FS:  0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0
     Call Trace:
      <IRQ>
      ? show_regs+0x63/0x70
      ? __die_body+0x20/0x60
      ? __die+0x2b/0x40
      ? page_fault_oops+0x15c/0x550
      ? do_user_addr_fault+0x3ed/0x870
      ? exc_page_fault+0x7f/0x190
      ? asm_exc_page_fault+0x27/0x30
      mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]
      mlx5e_xmit+0x58e/0x1980 [mlx5_core]
      ? __fib_lookup+0x6a/0xb0
      dev_hard_start_xmit+0x82/0x1d0
      sch_direct_xmit+0xfe/0x390
      __dev_queue_xmit+0x6d8/0xee0
      ? __fib_lookup+0x6a/0xb0
      ? internal_add_timer+0x48/0x70
      ? mod_timer+0xe2/0x2b0
      neigh_resolve_output+0x115/0x1b0
      __neigh_update+0x26a/0xc50
      neigh_update+0x14/0x20
      arp_process+0x2cb/0x8e0
      ? __napi_build_skb+0x5e/0x70
      arp_rcv+0x11e/0x1c0
      ? dev_gro_receive+0x574/0x820
      __netif_receive_skb_list_core+0x1cf/0x1f0
      netif_receive_skb_list_internal+0x183/0x2a0
      napi_complete_done+0x76/0x1c0
      mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]
      __napi_poll+0x2d/0x1f0
      net_rx_action+0x1a6/0x370
      ? atomic_notifier_call_chain+0x3b/0x50
      ? irq_int_handler+0x15/0x20 [mlx5_core]
      handle_softirqs+0xb9/0x2f0
      ? handle_irq_event+0x44/0x60
      irq_exit_rcu+0xdb/0x100
      common_interrupt+0x98/0xc0
      </IRQ>
      <TASK>
      asm_common_interrupt+0x27/0x40
     RIP: 0010:pv_native_safe_halt+0xb/0x10
     Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22
     0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb
    40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8
     RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202
     RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680
     RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4
     RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70
     R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40
     R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8
      ? default_idle+0x9/0x20
      arch_cpu_idle+0x9/0x10
      default_idle_call+0x29/0xf0
      do_idle+0x1f2/0x240
      cpu_startup_entry+0x2c/0x30
      rest_init+0xe7/0x100
      start_kernel+0x76b/0xb90
      x86_64_start_reservations+0x18/0x30
      x86_64_start_kernel+0xc0/0x110
      ? setup_ghcb+0xe/0x130
      common_startup_64+0x13e/0x141
      </TASK>
     Modules linked in: esp4_offload esp4 xfrm_interface
    xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binfmt_misc
    intel_rapl_msr intel_rapl_common kvm_amd ccp kvm input_leds serio_raw
    qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc
    scsi_dh_alua efi_pstore ip_tables x_tables autofs4 raid10 raid456
    async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx
    libcrc32c raid1 raid0 mlx5_core crct10dif_pclmul crc32_pclmul
    polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3
    sha1_ssse3 ahci mlxfw i2c_i801 libahci i2c_mux i2c_smbus psample
    virtio_rng pci_hyperv_intf aesni_intel crypto_simd cryptd
     CR2: 0000000000000000
     ---[ end trace 0000000000000000 ]---
     RIP: 0010:0x0
     Code: Unable to access opcode bytes at 0xffffffffffffffd6.
     RSP: 0018:ffffb87380003800 EFLAGS: 00010206
     RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf
     RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00
     RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010
     R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00
     R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e
     FS:  0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0
     Kernel panic - not syncing: Fatal exception in interrupt
     Kernel Offset: 0x3b800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
     ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
    
    Fixes: 5958372ddf62 ("xfrm: add RX datapath protection for IPsec packet offload mode")
    Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0f47b08786de5b02cedcadc88dad77ed4b1e671
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Thu Dec 19 11:05:07 2024 +0900

    dmaengine: ti: edma: fix OF node reference leaks in edma_driver
    
    [ Upstream commit e883c64778e5a9905fce955681f8ee38c7197e0f ]
    
    The .probe() of edma_driver calls of_parse_phandle_with_fixed_args() but
    does not release the obtained OF nodes. Thus add a of_node_put() call.
    
    This bug was found by an experimental verification tool that I am
    developing.
    
    Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20241219020507.1983124-3-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68a5e8b9125b672b08b79e15d1089b819c0a9e33
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Tue Nov 12 14:10:31 2024 +0200

    xfrm: replay: Fix the update of replay_esn->oseq_hi for GSO
    
    [ Upstream commit c05c5e5aa163f4682ca97a2f0536575fc7dbdecb ]
    
    When skb needs GSO and wrap around happens, if xo->seq.low (seqno of
    the first skb segment) is before the last seq number but oseq (seqno
    of the last segment) is after it, xo->seq.low is still bigger than
    replay_esn->oseq while oseq is smaller than it, so the update of
    replay_esn->oseq_hi is missed for this case wrap around because of
    the change in the cited commit.
    
    For example, if sending a packet with gso_segs=3 while old
    replay_esn->oseq=0xfffffffe, we calculate:
        xo->seq.low = 0xfffffffe + 1 = 0x0xffffffff
        oseq = 0xfffffffe + 3 = 0x1
    (oseq < replay_esn->oseq) is true, but (xo->seq.low <
    replay_esn->oseq) is false, so replay_esn->oseq_hi is not incremented.
    
    To fix this issue, change the outer checking back for the update of
    replay_esn->oseq_hi. And add new checking inside for the update of
    packet's oseq_hi.
    
    Fixes: 4b549ccce941 ("xfrm: replay: Fix ESN wrap around for GSO")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Reviewed-by: Patrisious Haddad <phaddad@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e0f793ee9616db8f66985fdb98f65f2821d0f85
Author: Luo Yifan <luoyifan@cmss.chinamobile.com>
Date:   Tue Jan 28 23:27:01 2025 +0900

    tools/bootconfig: Fix the wrong format specifier
    
    [ Upstream commit f6ab7384d554ba80ff4793259d75535874b366f5 ]
    
    Use '%u' instead of '%d' for unsigned int.
    
    Link: https://lore.kernel.org/all/20241105011048.201629-1-luoyifan@cmss.chinamobile.com/
    
    Fixes: 973780011106 ("tools/bootconfig: Suppress non-error messages")
    Signed-off-by: Luo Yifan <luoyifan@cmss.chinamobile.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d49ab6857d98266010f3446c9c2063014db5b654
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Sun Jan 26 21:49:59 2025 +0800

    LoongArch: Fix warnings during S3 suspend
    
    [ Upstream commit 26c0a2d93af55d30a46d5f45d3e9c42cde730168 ]
    
    The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),
    and the later one may call the preempt_schedule_common() function,
    resulting in a thread switch and causing the CPU to be in an interrupt
    enabled state after the enable_gpe_wakeup() function returns, leading
    to the warnings as follow.
    
    [ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8
    [ C0]          ...
    [ C0] Call Trace:
    [ C0] [<90000000002243b4>] show_stack+0x64/0x188
    [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88
    [ C0] [<90000000002687e4>] __warn+0x8c/0x148
    [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0
    [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8
    [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000
    [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8
    [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0
    [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378
    [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388
    [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48
    [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8
    [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80
    [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98
    [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48
    [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8
    [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48
    [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0
    [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8
    [ C0] [<900000000164e34c>] __schedule+0x314/0xa48
    [ C0] [<900000000164ead8>] schedule+0x58/0xf0
    [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498
    [ C0] [<900000000029d2f0>] kthread+0xf8/0x108
    [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4
    [ C0]
    [ C0] ---[ end trace 0000000000000000 ]---
    
    The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect
    acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause
    a thread switch. Since there is no longer concurrent execution during
    loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()
    directly in enable_gpe_wakeup().
    
    The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid
    breaking S3 wakeup due to might_sleep()").
    
    Fixes: 366bb35a8e48 ("LoongArch: Add suspend (ACPI S3) support")
    Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34c3ea55d1a7588781776d6e4b7f41d524f75c8d
Author: Olga Kornievskaia <okorniev@redhat.com>
Date:   Fri Dec 13 11:52:01 2024 -0500

    NFSv4.2: mark OFFLOAD_CANCEL MOVEABLE
    
    [ Upstream commit 668135b9348c53fd205f5e07d11e82b10f31b55b ]
    
    OFFLOAD_CANCEL should be marked MOVEABLE for when we need to move
    tasks off a non-functional transport.
    
    Fixes: c975c2092657 ("NFS send OFFLOAD_CANCEL when COPY killed")
    Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
    Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cedab40478283219b01247c1543deb72e3556de6
Author: Olga Kornievskaia <okorniev@redhat.com>
Date:   Fri Dec 13 11:52:00 2024 -0500

    NFSv4.2: fix COPY_NOTIFY xdr buf size calculation
    
    [ Upstream commit e8380c2d06055665b3df6c03964911375d7f9290 ]
    
    We need to include sequence size in the compound.
    
    Fixes: 0491567b51ef ("NFS: add COPY_NOTIFY operation")
    Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
    Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe616b82bc46982f60c2f95fe0f3023d7de6598b
Author: John Ogness <john.ogness@linutronix.de>
Date:   Tue Jan 7 22:32:57 2025 +0106

    serial: 8250: Adjust the timeout for FIFO mode
    
    [ Upstream commit d91f98be26510f5f81ec66425bb0306d1ccd571a ]
    
    After a console has written a record into UART_TX, it uses
    wait_for_xmitr() to wait until the data has been sent out before
    returning. However, wait_for_xmitr() will timeout after 10ms,
    regardless if the data has been transmitted or not.
    
    For single bytes, this timeout is sufficient even at very slow
    baud rates, such as 1200bps. However, when FIFO mode is used,
    there may be 64 bytes pushed into the FIFO at once. At a baud
    rate of 115200bps, the 10ms timeout is still sufficient. But
    when using lower baud rates (such as 57600bps), the timeout
    is _not_ sufficient. This causes longer lines to be cut off,
    resulting in lost and horribly misformatted output on the
    console.
    
    When using FIFO mode, take the number of bytes into account to
    determine an appropriate maximum timeout. Increasing the timeout
    does not affect performance since ideally the timeout never
    occurs.
    
    Fixes: 8f3631f0f6eb ("serial/8250: Use fifo in 8250 console driver")
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Wander Lairson Costa <wander@redhat.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20250107212702.169493-2-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4b9bc823b0cfdebfed479c0e87d6939c7562e87
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Sun Jan 5 16:34:02 2025 +0800

    driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()
    
    [ Upstream commit e128f82f7006991c99a58114f70ef61e937b1ac1 ]
    
    There are a potential wild pointer dereferences issue regarding APIs
    class_dev_iter_(init|next|exit)(), as explained by below typical usage:
    
    // All members of @iter are wild pointers.
    struct class_dev_iter iter;
    
    // class_dev_iter_init(@iter, @class, ...) checks parameter @class for
    // potential class_to_subsys() error, and it returns void type and does
    // not initialize its output parameter @iter, so caller can not detect
    // the error and continues to invoke class_dev_iter_next(@iter) even if
    // @iter still contains wild pointers.
    class_dev_iter_init(&iter, ...);
    
    // Dereference these wild pointers in @iter here once suffer the error.
    while (dev = class_dev_iter_next(&iter)) { ... };
    
    // Also dereference these wild pointers here.
    class_dev_iter_exit(&iter);
    
    Actually, all callers of these APIs have such usage pattern in kernel tree.
    Fix by:
    - Initialize output parameter @iter by memset() in class_dev_iter_init()
      and give callers prompt by pr_crit() for the error.
    - Check if @iter is valid in class_dev_iter_next().
    
    Fixes: 7b884b7f24b4 ("driver core: class.c: convert to only use class_to_subsys")
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20250105-class_fix-v6-1-3a2f1768d4d4@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91c9ec5a208d2760a57a5895edd04ede70f94ade
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Wed Jan 8 10:04:30 2025 +0100

    module: Extend the preempt disabled section in dereference_symbol_descriptor().
    
    [ Upstream commit a145c848d69f9c6f32008d8319edaa133360dd74 ]
    
    dereference_symbol_descriptor() needs to obtain the module pointer
    belonging to pointer in order to resolve that pointer.
    The returned mod pointer is obtained under RCU-sched/ preempt_disable()
    guarantees and needs to be used within this section to ensure that the
    module is not removed in the meantime.
    
    Extend the preempt_disable() section to also cover
    dereference_module_function_descriptor().
    
    Fixes: 04b8eb7a4ccd9 ("symbol lookup: introduce dereference_symbol_descriptor()")
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Naveen N Rao <naveen@kernel.org>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Cc: linux-parisc@vger.kernel.org
    Cc: linuxppc-dev@lists.ozlabs.org
    Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/20250108090457.512198-2-bigeasy@linutronix.de
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e1b9201c9a24638cf09c6e1c9f224157328010b
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Jan 8 05:00:47 2025 +0900

    nilfs2: protect access to buffers with no active references
    
    [ Upstream commit 367a9bffabe08c04f6d725032cce3d891b2b9e1a ]
    
    nilfs_lookup_dirty_data_buffers(), which iterates through the buffers
    attached to dirty data folios/pages, accesses the attached buffers without
    locking the folios/pages.
    
    For data cache, nilfs_clear_folio_dirty() may be called asynchronously
    when the file system degenerates to read only, so
    nilfs_lookup_dirty_data_buffers() still has the potential to cause use
    after free issues when buffers lose the protection of their dirty state
    midway due to this asynchronous clearing and are unintentionally freed by
    try_to_free_buffers().
    
    Eliminate this race issue by adjusting the lock section in this function.
    
    Link: https://lkml.kernel.org/r/20250107200202.6432-3-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption")
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61a8a1917a4b2ca56bb21f78377a4d7c3c6244ca
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon Oct 16 21:11:03 2023 +0100

    nilfs2: convert nilfs_lookup_dirty_data_buffers to use folio_create_empty_buffers
    
    [ Upstream commit 922b12eff0b293fc13ae4045c7d7264e18938878 ]
    
    This function was already using a folio, so this update to the new API
    removes a single folio->page->folio conversion.
    
    Link: https://lkml.kernel.org/r/20231016201114.1928083-17-willy@infradead.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Andreas Gruenbacher <agruenba@redhat.com>
    Cc: Pankaj Raghav <p.raghav@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 367a9bffabe0 ("nilfs2: protect access to buffers with no active references")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 724dc6daebb103ed13c9a7d39026d3524030a1dc
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon Oct 16 21:10:49 2023 +0100

    buffer: make folio_create_empty_buffers() return a buffer_head
    
    [ Upstream commit 3decb8564eff88a2533f83b01cec2cf9259c3eaf ]
    
    Patch series "Finish the create_empty_buffers() transition", v2.
    
    Pankaj recently added folio_create_empty_buffers() as the folio equivalent
    to create_empty_buffers().  This patch set finishes the conversion by
    first converting all remaining filesystems to call
    folio_create_empty_buffers(), then renaming it back to
    create_empty_buffers().  I took the opportunity to make a few
    simplifications like making folio_create_empty_buffers() return the head
    buffer and extracting get_nth_bh() from nilfs2.
    
    A few of the patches in this series aren't directly related to
    create_empty_buffers(), but I saw them while I was working on this and
    thought they'd be easy enough to add to this series.  Compile-tested only,
    other than ext4.
    
    This patch (of 26):
    
    Almost all callers want to know the first BH that was allocated for this
    folio.  We already have that handy, so return it.
    
    Link: https://lkml.kernel.org/r/20231016201114.1928083-1-willy@infradead.org
    Link: https://lkml.kernel.org/r/20231016201114.1928083-3-willy@infradead.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: Pankaj Raghav <p.raghav@samsung.com>
    Cc: Andreas Gruenbacher <agruenba@redhat.com>
    Cc: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 367a9bffabe0 ("nilfs2: protect access to buffers with no active references")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e6e5acf4c7dead000aea3492b01fc7f008c6a04
Author: Su Yue <glass.su@suse.com>
Date:   Mon Jan 6 22:06:53 2025 +0800

    ocfs2: mark dquot as inactive if failed to start trans while releasing dquot
    
    [ Upstream commit 276c61385f6bc3223a5ecd307cf4aba2dfbb9a31 ]
    
    While running fstests generic/329, the kernel workqueue
    quota_release_workfn is dead looping in calling ocfs2_release_dquot().
    The ocfs2 state is already readonly but ocfs2_release_dquot wants to
    start a transaction but fails and returns.
    
    =====================================================================
    [ 2918.123602 ][  T275 ] On-disk corruption discovered. Please run
    fsck.ocfs2 once the filesystem is unmounted.
    [ 2918.124034 ][  T275 ] (kworker/u135:1,275,11):ocfs2_release_dquot:765
    ERROR: status = -30
    [ 2918.124452 ][  T275 ] (kworker/u135:1,275,11):ocfs2_release_dquot:795
    ERROR: status = -30
    [ 2918.124883 ][  T275 ] (kworker/u135:1,275,11):ocfs2_start_trans:357
    ERROR: status = -30
    [ 2918.125276 ][  T275 ] OCFS2: abort (device dm-0): ocfs2_start_trans:
    Detected aborted journal
    [ 2918.125710 ][  T275 ] On-disk corruption discovered. Please run
    fsck.ocfs2 once the filesystem is unmounted.
    =====================================================================
    
    ocfs2_release_dquot() is much like dquot_release(), which is called by
    ext4 to handle similar situation.  So here fix it by marking the dquot as
    inactive like what dquot_release() does.
    
    Link: https://lkml.kernel.org/r/20250106140653.92292-1-glass.su@suse.com
    Fixes: 9e33d69f553a ("ocfs2: Implementation of local and global quota file handling")
    Signed-off-by: Su Yue <glass.su@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5565240c648d28398b4ff952d7ac712074d339d
Author: Guixin Liu <kanie@linux.alibaba.com>
Date:   Wed Dec 18 09:42:13 2024 +0800

    scsi: ufs: bsg: Delete bsg_dev when setting up bsg fails
    
    [ Upstream commit fcf247deb3c3e1c6be5774e3fa03bbd018eff1a9 ]
    
    We should remove the bsg device when bsg_setup_queue() fails to release the
    resources.
    
    Fixes: df032bf27a41 ("scsi: ufs: Add a bsg endpoint that supports UPIUs")
    Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20241218014214.64533-2-kanie@linux.alibaba.com
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 495dcb00d4fec18b6d8873380003c4a94e2e028a
Author: Paul Menzel <pmenzel@molgen.mpg.de>
Date:   Thu Dec 12 23:18:12 2024 +0100

    scsi: mpt3sas: Set ioc->manu_pg11.EEDPTagMode directly to 1
    
    [ Upstream commit ad7c3c0cb8f61d6d5a48b83e62ca4a9fd2f26153 ]
    
    Currently, the code does:
    
        if (x == 0) {
            x &= ~0x3;
            x |= 0x1;
        }
    
    Zeroing bits 0 and 1 of a variable that is 0 is not necessary. So directly
    set the variable to 1.
    
    Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
    Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
    Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Link: https://lore.kernel.org/r/20241212221817.78940-2-pmenzel@molgen.mpg.de
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c994716d33911cf287cb98d15973cdcdf2cfe8ef
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Thu Jan 16 22:46:47 2025 +0530

    PCI: endpoint: pci-epf-test: Fix check for DMA MEMCPY test
    
    [ Upstream commit 235c2b197a8de2887f13990094a3343d2392155b ]
    
    Currently, if DMA MEMCPY test is requested by the host, and if the endpoint
    DMA controller supports DMA_PRIVATE, the test will fail. This is not
    correct since there is no check for DMA_MEMCPY capability and the DMA
    controller can support both DMA_PRIVATE and DMA_MEMCPY.
    
    Fix the check and also reword the error message.
    
    Link: https://lore.kernel.org/r/20250116171650.33585-2-manivannan.sadhasivam@linaro.org
    Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities")
    Reported-by: Niklas Cassel <cassel@kernel.org>
    Closes: https://lore.kernel.org/linux-pci/Z3QtEihbiKIGogWA@ryzen
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Niklas Cassel <cassel@kernel.org>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48349476ae1372e4b389e848de0f4ae5033ae709
Author: Mohamed Khalfella <khalfella@gmail.com>
Date:   Fri Dec 27 08:08:41 2024 -0800

    PCI: endpoint: pci-epf-test: Set dma_chan_rx pointer to NULL on error
    
    [ Upstream commit b1b1f4b12969130c0a6ec0cf0299460cb01e799c ]
    
    If dma_chan_tx allocation fails, set dma_chan_rx to NULL after it is
    freed.
    
    Link: https://lore.kernel.org/r/20241227160841.92382-1-khalfella@gmail.com
    Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities")
    Signed-off-by: Mohamed Khalfella <khalfella@gmail.com>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a12efc567a270a155e3b886258297abd79cdea0
Author: Richard Zhu <hongxing.zhu@nxp.com>
Date:   Tue Nov 26 15:56:56 2024 +0800

    PCI: imx6: Skip controller_id generation logic for i.MX7D
    
    [ Upstream commit f068ffdd034c93f0c768acdc87d4d2d7023c1379 ]
    
    The i.MX7D only has one PCIe controller, so controller_id should always be
    0. The previous code is incorrect although yielding the correct result.
    
    Fix by removing "IMX7D" from the switch case branch.
    
    Fixes: 2d8ed461dbc9 ("PCI: imx6: Add support for i.MX8MQ")
    Link: https://lore.kernel.org/r/20241126075702.4099164-5-hongxing.zhu@nxp.com
    Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c64da8e0ad764e08c724e43a5517df0a1be2d114
Author: Frank Li <Frank.Li@nxp.com>
Date:   Tue Feb 20 11:19:11 2024 -0500

    PCI: imx6: Simplify clock handling by using clk_bulk*() function
    
    [ Upstream commit 6a40185838759cdae728ed79738680d798863ce7 ]
    
    Refactor the clock handling logic. Add 'clk_names' define in drvdata.
    Use clk_bulk*() API to simplify the code.
    
    Link: https://lore.kernel.org/r/20240220161924.3871774-2-Frank.Li@nxp.com
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Stable-dep-of: f068ffdd034c ("PCI: imx6: Skip controller_id generation logic for i.MX7D")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c54b9fca1755e80a343ccfde0652dc5ea4744b2
Author: King Dix <kingdix10@qq.com>
Date:   Thu Jan 9 08:50:18 2025 +0800

    PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
    
    [ Upstream commit 2d2da5a4c1b4509f6f7e5a8db015cd420144beb4 ]
    
    The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()
    macro to request a needed resource. A string variable that lives on the
    stack is then used to store a dynamically computed resource name, which
    is then passed on as one of the macro arguments. This can lead to
    undefined behavior.
    
    Depending on the current contents of the memory, the manifestations of
    errors may vary. One possible output may be as follows:
    
      $ cat /proc/iomem
      30000000-37ffffff :
      38000000-3fffffff :
    
    Sometimes, garbage may appear after the colon.
    
    In very rare cases, if no NULL-terminator is found in memory, the system
    might crash because the string iterator will overrun which can lead to
    access of unmapped memory above the stack.
    
    Thus, fix this by replacing outbound_name with the name of the previously
    requested resource. With the changes applied, the output will be as
    follows:
    
      $ cat /proc/iomem
      30000000-37ffffff : memory2
      38000000-3fffffff : memory3
    
    Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support")
    Link: https://lore.kernel.org/r/tencent_DBDCC19D60F361119E76919ADAB25EC13C06@qq.com
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Signed-off-by: King Dix <kingdix10@qq.com>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d3f69add24e651664b1949ec5482e1fe3f80468
Author: Desnes Nunes <desnesn@redhat.com>
Date:   Thu Sep 19 14:27:55 2024 -0300

    media: dvb-usb-v2: af9035: fix ISO C90 compilation error on af9035_i2c_master_xfer
    
    [ Upstream commit c36b9ad1a8add3c114e25fe167efa217a813b0c7 ]
    
    This fixes a 'ISO C90 forbids mixed declarations and code' compilation
    error on af9035_i2c_master_xfer, which is caused by the sanity check added
    on user controlled msg[i], before declaring the demodulator register.
    
    Fixes: 7bf744f2de0a ("media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer")
    Signed-off-by: Desnes Nunes <desnesn@redhat.com>
    Link: https://lore.kernel.org/r/20240919172755.196907-1-desnesn@redhat.com
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aba54e4583f662c6dc2a0ab263cfd7f192d66300
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Tue Dec 24 12:54:11 2024 +0900

    staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()
    
    [ Upstream commit 094f5c315f756b19198e6c401aa821ac0e868750 ]
    
    imx_media_add_of_subdevs() calls of_parse_phandle() and passes the
    obtained node to imx_media_of_add_csi(). The passed node is used in
    v4l2_async_nf_add_fwnode(), which increments the refcount of the node.
    Therefore, while the current implementation only releases the node when
    imx_media_of_add_csi() fails, but should always release it. Call
    of_node_put() right after imx_media_of_add_csi().
    
    Fixes: dee747f88167 ("media: imx: Don't register IPU subdevs/links if CSI port missing")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09ab93b4b6b2faecf0ed1a0999f92228e19df2a9
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Sun Jan 5 20:17:18 2025 +0900

    watchdog: rti_wdt: Fix an OF node leak in rti_wdt_probe()
    
    [ Upstream commit 143981aa63f33d469a55a55fd9fb81cd90109672 ]
    
    rti_wdt_probe() does not release the OF node reference obtained by
    of_parse_phandle(). Add a of_node_put() call.
    
    This was found by an experimental verification tool that I am
    developing. Due to the lack of the actual device, no runtime test was
    able to be performed.
    
    Fixes: f20ca595ae23 ("watchdog:rit_wdt: Add support for WDIOF_CARDRESET")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20250105111718.4184192-1-joe@pf.is.s.u-tokyo.ac.jp
    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 7f6802ca6d1349928e916cb95386b6a1321e86e6
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Date:   Tue Sep 24 13:33:04 2024 +0300

    media: nxp: imx8-isi: fix v4l2-compliance test errors
    
    [ Upstream commit 7b12ab055edef2f51733d155617a401a05237bcc ]
    
    Running the v4l2-compliance (1.27.0-5208, SHA: af114250d48d) on the m2m
    device fails on the MMAP streaming tests, with the following messages:
    
    fail: v4l2-test-buffers.cpp(240): g_field() == V4L2_FIELD_ANY
    fail: v4l2-test-buffers.cpp(1508): buf.qbuf(node)
    
    Apparently, the driver does not properly set the field member of
    vb2_v4l2_buffer struct, returning the default V4L2_FIELD_ANY value which
    is against the guidelines.
    
    Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
    Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/20240924103304.124085-1-laurentiu.palcu@oss.nxp.com
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ca60562c0d2f39c9ea802f375ac736d0c1ea229
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Fri Dec 6 22:38:09 2024 +0900

    mtd: hyperbus: hbmc-am654: fix an OF node reference leak
    
    [ Upstream commit bf5821909eb9c7f5d07d5c6e852ead2c373c94a0 ]
    
    In am654_hbmc_platform_driver, .remove() and the error path of .probe()
    do not decrement the refcount of an OF node obtained by
      of_get_next_child(). Fix this by adding of_node_put() calls.
    
    Fixes: aca31ce96814 ("mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ec44b69e48f537cd3f1689b64162b95f5c4cbff
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun Oct 8 22:01:32 2023 +0200

    mtd: hyperbus: hbmc-am654: Convert to platform remove callback returning void
    
    [ Upstream commit 59bd56760df17506bc2f828f19b40a2243edd0d0 ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is ignored (apart
    from emitting a warning) and this typically results in resource leaks.
    
    To improve here there is a quest to make the remove callback return
    void. In the first step of this quest all drivers are converted to
    .remove_new(), which already returns void. Eventually after all drivers
    are converted, .remove_new() will be renamed to .remove().
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-10-u.kleine-koenig@pengutronix.de
    Stable-dep-of: bf5821909eb9 ("mtd: hyperbus: hbmc-am654: fix an OF node reference leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d95397b17929227507456afa91e0b38edc2f11d
Author: david regan <dregan@broadcom.com>
Date:   Mon Nov 25 18:39:16 2024 -0800

    mtd: rawnand: brcmnand: fix status read of brcmnand_waitfunc
    
    [ Upstream commit 03271ea36ea7a58d30a4bde182eb2a0d46220467 ]
    
    This change fixes an issue where an error return value may be mistakenly
    used as NAND status.
    
    Fixes: f504551b7f15 ("mtd: rawnand: Propagate error and simplify ternary operators for brcmstb_nand_wait_for_completion()")
    Signed-off-by: david regan <dregan@broadcom.com>
    Reviewed-by: William Zhang <william.zhang@broadcom.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ada9f380e799269f0949919b9b0503feb6daf850
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Wed Dec 18 21:39:08 2024 +0000

    media: uvcvideo: Propagate buf->error to userspace
    
    [ Upstream commit 87ce177654e388451850905a1d376658aebe8699 ]
    
    Now we return VB2_BUF_STATE_DONE for valid and invalid frames. Propagate
    the correct value, so the user can know if the frame is valid or not via
    struct v4l2_buffer->flags.
    
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Closes: https://lore.kernel.org/linux-media/84b0f212-cd88-46bb-8e6f-b94ec3eccba6@redhat.com
    Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc")
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20241218-uvc-deprecate-v2-1-ab814139e983@chromium.org
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6981619d56a6710cefbf403b612a99f1baf698d0
Author: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Date:   Mon Nov 25 19:18:17 2024 +0000

    media: camif-core: Add check for clk_enable()
    
    [ Upstream commit 77ed2470ac09c2b0a33cf3f98cc51d18ba9ed976 ]
    
    Add check for the return value of clk_enable() to gurantee the success.
    
    Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface")
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79bf1c4773ba2280c386799d28a3f2aac4b602c4
Author: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Date:   Mon Nov 25 19:18:18 2024 +0000

    media: mipi-csis: Add check for clk_enable()
    
    [ Upstream commit 125ad1aeec77eb55273b420be6894b284a01e4b6 ]
    
    Add check for the return value of clk_enable() to gurantee the success.
    
    Fixes: b5f1220d587d ("[media] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers")
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11c7649c9ec3dcaf0a7760551ad30747d9e02d81
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Mon Dec 9 14:55:45 2024 +0000

    media: i2c: ov9282: Correct the exposure offset
    
    [ Upstream commit feaf4154d69657af2bf96e6e66cca794f88b1a61 ]
    
    The datasheet lists that "Maximum exposure time is frame
    length -25 row periods, where frame length is set by
    registers {0x380E, 0x380F}".
    However this driver had OV9282_EXPOSURE_OFFSET set to 12
    which allowed that restriction to be violated, and would
    result in very under-exposed images.
    
    Correct the offset.
    
    Fixes: 14ea315bbeb7 ("media: i2c: Add ov9282 camera sensor driver")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4c35f6958de8fa250b99563fdfdd6cf86533a95
Author: Luca Weiss <luca.weiss@fairphone.com>
Date:   Mon Nov 18 22:45:46 2024 +0100

    media: i2c: imx412: Add missing newline to prints
    
    [ Upstream commit 33f4a7fba7229232e294f4794503283e44cd03f2 ]
    
    Add trailing \n to dev_dbg and dev_err prints where missing.
    
    Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
    Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e4300717701eb973697290d28e6dff1abb52c7c
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Wed Nov 20 19:17:04 2024 +0000

    media: i2c: imx290: Register 0x3011 varies between imx327 and imx290
    
    [ Upstream commit f2055c1d62d6dfd25a31d1d1923883f21305aea5 ]
    
    Reviewing the datasheets, register 0x3011 is meant to be 0x02 on imx327
    and 0x00 on imx290.
    
    Move it out of the common registers, and set it appropriately in the
    sensor specific sections. (Included for imx290 to be explicit, rather
    than relying on the default value).
    
    Fixes: 2d41947ec2c0 ("media: i2c: imx290: Add support for imx327 variant")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88d08ca77266872aa1172470e5057a27fc7a1605
Author: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Date:   Tue Dec 3 21:29:02 2024 +0000

    media: marvell: Add check for clk_enable()
    
    [ Upstream commit 11f68d2ba2e1521a608af773bf788e8cfa260f68 ]
    
    Add check for the return value of clk_enable() to guarantee the success.
    
    Fixes: 81a409bfd551 ("media: marvell-ccic: provide a clock for the sensor")
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    [Sakari Ailus: Fix spelling in commit message.]
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0f94441a1de03c5f5740420fbfea2fb494351b7
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Tue Dec 10 22:00:18 2024 +0800

    PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy()
    
    [ Upstream commit d4929755e4d02bd3de3ae5569dab69cb9502c54f ]
    
    The devm_pci_epc_destroy() comment says destroys the EPC device, but it
    does not actually do that since devres_destroy() does not call
    devm_pci_epc_release(), and it also can not fully undo what the API
    devm_pci_epc_create() does, so it is faulty.
    
    Fortunately, the faulty API has not been used by current kernel tree.  Use
    devres_release() instead of devres_destroy() so the EPC device will be
    released.
    
    Link: https://lore.kernel.org/r/20241210-pci-epc-core_fix-v3-1-4d86dd573e4b@quicinc.com
    Fixes: 5e8cb4033807 ("PCI: endpoint: Add EP core layer to enable EP controller and EP functions")
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dfccddd5874fcb2f0715c8e02ce633139425d295
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Tue May 21 17:10:42 2024 +0800

    media: lmedm04: Handle errors for lme2510_int_read
    
    [ Upstream commit a2836d3fe220220ff8c495ca9722f89cea8a67e7 ]
    
    Add check for the return value of usb_pipe_endpoint() and
    usb_submit_urb() in order to catch the errors.
    
    Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20240521091042.1769684-1-nichen@iscas.ac.cn
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb06c7bbf1724306ed322543e5700ea999b55e8b
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Nov 26 14:17:22 2024 +0100

    media: rc: iguanair: handle timeouts
    
    [ Upstream commit b98d5000c50544f14bacb248c34e5219fbe81287 ]
    
    In case of a timeout the IO must be cancelled or
    the next IO using the URB will fail and/or overwrite
    an operational URB.
    
    The automatic bisection fails because it arrives
    at a commit that correctly lets the test case run
    without an error.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Fixes: e99a7cfe93fd ("[media] iguanair: reuse existing urb callback for command responses")
    Reported-by: syzbot+ffba8e636870dac0e0c0@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/66f5cc9a.050a0220.46d20.0004.GAE@google.com/
    Tested-by: syzbot+ffba8e636870dac0e0c0@syzkaller.appspotmail.com
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2d565d93d07c5696b0b7bcaaab7df3aa8572600
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jan 17 16:16:03 2025 +0000

    spi: omap2-mcspi: Correctly handle devm_clk_get_optional() errors
    
    [ Upstream commit a07eb4f67ed085f32002a1af2b6073546d67de3f ]
    
    devm_clk_get_optional() returns NULL for missing clocks and a PTR_ERR()
    if there is a clock but we fail to get it, but currently we only handle
    the latter case and do so as though the clock was missing.  If we get an
    error back we should handle that as an error since the clock exists but
    we failed to get it, if we get NULL then the clock doesn't exist and we
    should handle that.
    
    Fixes: 4c6ac5446d06 ("spi: omap2-mcspi: Fix the IS_ERR() bug for devm_clk_get_optional_enabled()")
    Reported-by: Lars Pedersen <lapeddk@gmail.com>
    Link: https://patch.msgid.link/20250117-spi-fix-omap2-optional-v1-1-e77d4ac6db6e@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Tested-by: Lars Pedersen <lapeddk@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38ac76fc06bc6826a3e4b12a98efbe98432380a9
Author: Qasim Ijaz <qasdev00@gmail.com>
Date:   Mon Jan 13 22:38:20 2025 +0000

    iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()
    
    [ Upstream commit e24c1551059268b37f6f40639883eafb281b8b9c ]
    
    Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()
    where shifting the constant "1" (of type int) by bitmap->mapped.pgshift
    (an unsigned long value) could result in undefined behavior.
    
    The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds
    31 (e.g., pgshift = 63) the shift operation overflows, as the result
    cannot be represented in a 32-bit type.
    
    To resolve this, the constant is updated to "1UL", promoting it to an
    unsigned long type to match the operand's type.
    
    Fixes: 58ccf0190d19 ("vfio: Add an IOVA bitmap support")
    Link: https://patch.msgid.link/r/20250113223820.10713-1-qasdev00@gmail.com
    Reported-by: syzbot <syzbot+85992ace37d5b7b51635@syzkaller.appspotmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=85992ace37d5b7b51635
    Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
    Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45e567800492088bc52c9abac35524b4d332a8f8
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Fri Jan 10 17:09:27 2025 +0100

    RDMA/rxe: Fix the warning "__rxe_cleanup+0x12c/0x170 [rdma_rxe]"
    
    [ Upstream commit edc4ef0e0154096d6c0cf5e06af6fc330dbad9d1 ]
    
    The Call Trace is as below:
    "
      <TASK>
      ? show_regs.cold+0x1a/0x1f
      ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]
      ? __warn+0x84/0xd0
      ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]
      ? report_bug+0x105/0x180
      ? handle_bug+0x46/0x80
      ? exc_invalid_op+0x19/0x70
      ? asm_exc_invalid_op+0x1b/0x20
      ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]
      ? __rxe_cleanup+0x124/0x170 [rdma_rxe]
      rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe]
      ib_destroy_qp_user+0x118/0x190 [ib_core]
      rdma_destroy_qp.cold+0x43/0x5e [rdma_cm]
      rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core]
      rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server]
      process_one_work+0x21d/0x3f0
      worker_thread+0x4a/0x3c0
      ? process_one_work+0x3f0/0x3f0
      kthread+0xf0/0x120
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x22/0x30
      </TASK>
    "
    When too many rdma resources are allocated, rxe needs more time to
    handle these rdma resources. Sometimes with the current timeout, rxe
    can not release the rdma resources correctly.
    
    Compared with other rdma drivers, a bigger timeout is used.
    
    Fixes: 215d0a755e1b ("RDMA/rxe: Stop lookup of partially built objects")
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Link: https://patch.msgid.link/20250110160927.55014-1-yanjun.zhu@linux.dev
    Tested-by: Joe Klein <joe.klein812@gmail.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07f8ce734df7b624fdd04fc0b010260e8918f657
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Jan 7 15:53:09 2025 -0800

    efi: sysfb_efi: fix W=1 warnings when EFI is not set
    
    [ Upstream commit 19fdc68aa7b90b1d3d600e873a3e050a39e7663d ]
    
    A build with W=1 fails because there are code and data that are not
    needed or used when CONFIG_EFI is not set. Move the "#ifdef CONFIG_EFI"
    block to earlier in the source file so that the unused code/data are
    not built.
    
    drivers/firmware/efi/sysfb_efi.c:345:39: warning: ‘efifb_fwnode_ops’ defined but not used [-Wunused-const-variable=]
      345 | static const struct fwnode_operations efifb_fwnode_ops = {
          |                                       ^~~~~~~~~~~~~~~~
    drivers/firmware/efi/sysfb_efi.c:238:35: warning: ‘efifb_dmi_swap_width_height’ defined but not used [-Wunused-const-variable=]
      238 | static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = {
          |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/firmware/efi/sysfb_efi.c:188:35: warning: ‘efifb_dmi_system_table’ defined but not used [-Wunused-const-variable=]
      188 | static const struct dmi_system_id efifb_dmi_system_table[] __initconst = {
          |                                   ^~~~~~~~~~~~~~~~~~~~~~
    
    Fixes: 15d27b15de96 ("efi: sysfb_efi: fix build when EFI is not set")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202501071933.20nlmJJt-lkp@intel.com/
    Cc: David Rheinsberg <david@readahead.eu>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Javier Martinez Canillas <javierm@redhat.com>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Simona Vetter <simona@ffwll.ch>
    Cc: linux-fbdev@vger.kernel.org
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: linux-efi@vger.kernel.org
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c14c6d0a6aa4a14877963cd3e409bd197cb29883
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Thu Jan 9 21:27:01 2025 +0800

    of: reserved-memory: Do not make kmemleak ignore freed address
    
    [ Upstream commit 29091a52562bca4d6e678dd8f0085dac119d6a21 ]
    
    early_init_dt_alloc_reserved_memory_arch() will free address @base when
    suffers memblock_mark_nomap() error, but it still makes kmemleak ignore
    the freed address @base via kmemleak_ignore_phys().
    
    That is unnecessary, besides, also causes unnecessary warning messages:
    
    kmemleak_ignore_phys()
     -> make_black_object()
        -> paint_ptr()
           -> kmemleak_warn() // warning message here.
    
    Fix by avoiding kmemleak_ignore_phys() when suffer the error.
    
    Fixes: 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak")
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-10-db8a72415b8c@quicinc.com
    Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ea9e3895f8c19a4a9c67811930da0d6319b933e
Author: Michael Guralnik <michaelgur@nvidia.com>
Date:   Mon Jan 6 20:27:10 2025 +0200

    RDMA/mlx5: Fix indirect mkey ODP page count
    
    [ Upstream commit 235f238402194a78ac5fb882a46717eac817e5d1 ]
    
    Restrict the check for the number of pages handled during an ODP page
    fault to direct mkeys.
    Perform the check right after handling the page fault and don't
    propagate the number of handled pages to callers.
    
    Indirect mkeys and their associated direct mkeys can have different
    start addresses. As a result, the calculation of the number of pages to
    handle for an indirect mkey may not match the actual page fault
    handling done on the direct mkey.
    
    For example:
    A 4K sized page fault on a KSM mkey that has a start address that is not
    aligned to a page will result a calculation that assumes the number of
    pages required to handle are 2.
    While the underlying MTT might be aligned will require fetching only a
    single page.
    Thus, do the calculation and compare number of pages handled only per
    direct mkey.
    
    Fixes: db570d7deafb ("IB/mlx5: Add ODP support to MW")
    Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
    Reviewed-by: Artemy Kovalyov <artemyko@nvidia.com>
    Link: https://patch.msgid.link/86c483d9e75ce8fe14e9ff85b62df72b779f8ab1.1736187990.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60d2fb033a999bb644f8e8606ff4a1b82de36c6f
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date:   Wed Nov 27 18:35:11 2024 +0800

    i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition
    
    [ Upstream commit b75439c945b94dd8a2b645355bdb56f948052601 ]
    
    In dw_i3c_common_probe, &master->hj_work is bound with
    dw_i3c_hj_work. And dw_i3c_master_irq_handler can call
    dw_i3c_master_irq_handle_ibis function to start the work.
    
    If we remove the module which will call dw_i3c_common_remove to
    make cleanup, it will free master->base through i3c_master_unregister
    while the work mentioned above will be used. The sequence of operations
    that may lead to a UAF bug is as follows:
    
    CPU0                                      CPU1
    
                                         | dw_i3c_hj_work
    dw_i3c_common_remove                 |
    i3c_master_unregister(&master->base) |
    device_unregister(&master->dev)      |
    device_release                       |
    //free master->base                  |
                                         | i3c_master_do_daa(&master->base)
                                         | //use master->base
    
    Fix it by ensuring that the work is canceled before proceeding with
    the cleanup in dw_i3c_common_remove.
    
    Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP")
    Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
    Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
    Link: https://lore.kernel.org/r/bfc49c9527be5b513e7ceafeba314ca40a5be4bc.1732703537.git.xiaopei01@kylinos.cn
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c30508bb0b4b64780dc219190d54cab13cc3f8ef
Author: Billy Tsai <billy_tsai@aspeedtech.com>
Date:   Mon Apr 29 15:36:24 2024 +0800

    i3c: dw: Add hot-join support.
    
    [ Upstream commit 1d08326020fba690cbb7b8f1b38ab4eab6745969 ]
    
    Add hot-join support for dw i3c master controller.
    By default, the hot-join acknowledgment is disabled, and the hardware will
    automatically send the DISEC CCC when it receives the hot-join request.
    Users can use the sys entry to enable it.
    
    Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
    Link: https://lore.kernel.org/r/20240429073624.256830-1-billy_tsai@aspeedtech.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: b75439c945b9 ("i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e713ca2e652696928442c53c36730391ce3dc135
Author: Akhil R <akhilrajeev@nvidia.com>
Date:   Fri Dec 6 16:22:00 2024 +0530

    arm64: tegra: Fix DMA ID for SPI2
    
    [ Upstream commit 346bf459db26325c09ed841fdfd6678de1b1cb3a ]
    
    DMA ID for SPI2 is '16'. Update the incorrect value in the devicetree.
    
    Fixes: bb9667d8187b ("arm64: tegra: Add SPI device tree nodes for Tegra234")
    Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
    Link: https://lore.kernel.org/r/20241206105201.53596-1-akhilrajeev@nvidia.com
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35f444b3104ad0486d13dc7637298a5c7398239b
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Wed Jan 8 10:15:37 2025 +0900

    fbdev: omapfb: Fix an OF node leak in dss_of_port_get_parent_device()
    
    [ Upstream commit de124b61e179e690277116e6be512e4f422b5dd8 ]
    
    dss_of_port_get_parent_device() leaks an OF node reference when i >= 2
    and struct device_node *np is present. Since of_get_next_parent()
    obtains a reference of the returned OF node, call of_node_put() before
    returning NULL.
    
    This was found by an experimental verifier that I am developing, and no
    runtime test was able to be performed due to that lack of actual
    devices.
    
    Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2c5d45b05d26ffa82636af3f431a4daa96fed6c
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Mon Jun 17 11:46:33 2024 +0200

    ARM: dts: mediatek: mt7623: fix IR nodename
    
    [ Upstream commit 90234cf9b37c57201a24b78c217a91a8af774109 ]
    
    Fix following validation error:
    arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: cir@10013000: $nodename:0: 'cir@10013000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$'
            from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml#
    
    Fixes: 91044f38dae7 ("arm: dts: mt7623: add ir nodes to the mt7623.dtsi file")
    Cc: linux-media@vger.kernel.org
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20240617094634.23173-1-zajec5@gmail.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb6f0553f8dcca826f08d352a5020cf95f2a8751
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Wed Nov 27 14:29:50 2024 +0200

    arm64: dts: qcom: sm8250: Fix interrupt types of camss interrupts
    
    [ Upstream commit 6c7bba42ebc3da56e64d4aec4c4a31dd454e05fd ]
    
    Qualcomm IP catalog says that all CAMSS interrupts is edge rising,
    fix it in the CAMSS device tree node for sm8250 SoC.
    
    Fixes: 30325603b910 ("arm64: dts: qcom: sm8250: camss: Add CAMSS block definition")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Link: https://lore.kernel.org/r/20241127122950.885982-7-vladimir.zapolskiy@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad28a017b542b08dfc7aafeaa56d6b5c233a4502
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Wed Nov 27 14:29:49 2024 +0200

    arm64: dts: qcom: sdm845: Fix interrupt types of camss interrupts
    
    [ Upstream commit cb96722b728e81ad97f5b5b20dea64cd294a5452 ]
    
    Qualcomm IP catalog says that all CAMSS interrupts is edge rising,
    fix it in the CAMSS device tree node for sdm845 SoC.
    
    Fixes: d48a6698a6b7 ("arm64: dts: qcom: sdm845: Add CAMSS ISP node")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Link: https://lore.kernel.org/r/20241127122950.885982-6-vladimir.zapolskiy@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7e2f0ee4301d512d73786f815f7f6aea148f19d
Author: Val Packett <val@packett.cool>
Date:   Wed Dec 25 16:26:20 2024 -0300

    arm64: dts: mediatek: add per-SoC compatibles for keypad nodes
    
    [ Upstream commit 6139d9e9e397dc9711cf10f8f548a8f9da3b5323 ]
    
    The mt6779-keypad binding specifies using a compatible for the
    actual SoC before the generic MT6779 one.
    
    Fixes: a8013418d35c ("arm64: dts: mediatek: mt8183: add keyboard node")
    Fixes: 6ff945376556 ("arm64: dts: mediatek: Initial mt8365-evk support")
    Signed-off-by: Val Packett <val@packett.cool>
    Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241225192631.25017-3-val@packett.cool
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64f51b68e296005567e80098b9abc92df5a5890b
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Fri Dec 20 02:15:31 2024 +0800

    dts: arm64: mediatek: mt8195: Remove MT8183 compatible for OVL
    
    [ Upstream commit ce3dbc46d7e30a84b8e99c730e3172dd5efbf094 ]
    
    The OVL hardware capabilities have changed starting from MT8195,
    making the MT8183 compatible no longer applicable.
    Therefore, it is necessary to remove the MT8183 compatible for OVL.
    
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Fixes: b852ee68fd72 ("arm64: dts: mt8195: Add display node for vdosys0")
    Link: https://lore.kernel.org/r/20241219181531.4282-5-jason-jh.lin@mediatek.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30fb7a297f1652a9c1846da6075ab74bc18fb67c
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Date:   Thu Dec 12 23:19:37 2024 +0100

    arm64: dts: qcom: sc8280xp: Fix up remoteproc register space sizes
    
    [ Upstream commit 7ec7e327286182c65d0b5b81dff498d620fe9e8c ]
    
    Make sure the remoteproc reg ranges reflect the entire register space
    they refer to.
    
    Since they're unused by the driver, there's no functional change.
    
    Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Link: https://lore.kernel.org/r/20241212-topic-8280_rproc_reg-v1-1-bd1c696e91b0@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df5c93e0c0a0a114f745eca641698393aa26b43c
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Mon Dec 30 13:44:49 2024 +0100

    arm64: dts: qcom: sm8150-microsoft-surface-duo: fix typos in da7280 properties
    
    [ Upstream commit 9875adffb87da5c40f4013e55104f5e2fc071c2a ]
    
    The dlg,const-op-mode & dlg,periodic-op-mode were mis-names with twice
    the "dlg," prefix, drop one to match the bindings.
    
    This fixes:
    sm8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,const-op-mode' is a required property
            from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
    m8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,periodic-op-mode' is a required property
            from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
    sm8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,dlg,const-op-mode', 'dlg,dlg,periodic-op-mode' do not match any of the regexes: 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
    
    With the dlg,da7280.yaml converted from dlg,da7280.txt at [1].
    
    [1] https://lore.kernel.org/all/20241206-topic-misc-da7280-convert-v2-1-1c3539f75604@linaro.org/
    
    Fixes: d1f781db47a8 ("arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20241230-topic-misc-dt-fixes-v4-6-1e6880e9dda3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3ec2298c34eadbf05b92e588baa92b16898991b
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Mon Dec 30 13:44:48 2024 +0100

    arm64: dts: qcom: sc7180: fix psci power domain node names
    
    [ Upstream commit 092febd32a99800902f865ed86b83314faa9c7e4 ]
    
    Rename the psci power domain node names to match the bindings.
    
    This Fixes:
    sc7180-acer-aspire1.dts: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6', 'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
    
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20241230-topic-misc-dt-fixes-v4-5-1e6880e9dda3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f11e59d464cce3041f016fd56fa6a6e08a230f0
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Oct 22 17:47:29 2024 +0200

    arm64: dts: qcom: sc7180: change labels to lower-case
    
    [ Upstream commit e5f90735136562c0653714b43ff1aeb331600d24 ]
    
    DTS coding style expects labels to be lowercase.  No functional impact.
    Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20241022-dts-qcom-label-v3-4-0505bc7d2c56@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 092febd32a99 ("arm64: dts: qcom: sc7180: fix psci power domain node names")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78e69e507f8974ee3fb5fbca75680c2001cab4c9
Author: David Wronek <davidwronek@gmail.com>
Date:   Thu Aug 24 11:15:06 2023 +0200

    arm64: dts: qcom: Add SM7125 device tree
    
    [ Upstream commit 72fbf05149bd451e7222c2ed1e3823972f19df9c ]
    
    The Snapdragon 720G (sm7125) is software-wise very similar to the
    Snapdragon 7c with minor differences in clock speeds and as added here,
    it uses the Kryo 465 instead of Kryo 468.
    
    Signed-off-by: David Wronek <davidwronek@gmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230824091737.75813-4-davidwronek@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 092febd32a99 ("arm64: dts: qcom: sc7180: fix psci power domain node names")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0789f1224758c47d7d6ae76b737f16b5d6142901
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Mon Dec 30 13:44:47 2024 +0100

    arm64: dts: qcom: sc7180-trogdor-pompom: rename 5v-choke thermal zone
    
    [ Upstream commit 9180b38d706c29ed212181a77999c35ae9ff6879 ]
    
    Rename the 5v-choke thermal zone to satisfy the bindings.
    
    This fixes:
    sc7180-trogdor-pompom-r2-lte.dts: thermal-zones: '5v-choke-thermal' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$', 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
    
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20241230-topic-misc-dt-fixes-v4-4-1e6880e9dda3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0da37d9875809e40d859305822569a9d96a4e275
Author: Konrad Dybcio <konradybcio@kernel.org>
Date:   Fri May 10 13:59:39 2024 +0200

    arm64: dts: qcom: sc7180-*: Remove thermal zone polling delays
    
    [ Upstream commit 7cd2d9080a6eb281701f7303b1699719640380d0 ]
    
    All of the thermal zone suppliers are interrupt-driven, remove the
    bogus and unnecessary polling that only wastes CPU time.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-16-436ca4218da2@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 9180b38d706c ("arm64: dts: qcom: sc7180-trogdor-pompom: rename 5v-choke thermal zone")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d92cbcfb10cf77a5524656b0879502fab27b4cfb
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Mon Dec 30 13:44:46 2024 +0100

    arm64: dts: qcom: sc7180-trogdor-quackingstick: add missing avee-supply
    
    [ Upstream commit aa09de104d421e7ff8d8cde9af98568ce62a002c ]
    
    The bindings requires the avee-supply, use the same regulator as
    the avdd (positive voltage) which would also provide the negative
    voltage by definition.
    
    The fixes:
    sc7180-trogdor-quackingstick-r0.dts: panel@0: 'avee-supply' is a required property
            from schema $id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
    
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20241230-topic-misc-dt-fixes-v4-3-1e6880e9dda3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d1dccadf21ba6f8856798d4f4b36ba21d0b6ff8
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Mon Dec 30 13:44:45 2024 +0100

    arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: remove disabled ov7251 camera
    
    [ Upstream commit 80b47f14d5433068dd6738c9e6e17ff6648bae41 ]
    
    The ov7251node has bindings check errors in the endpoint, and the
    camera node was disabled since the beginning. Even when switching the
    node to okay, the endpoint description to the csiphy is missing along
    with the csiphy parameters.
    
    Drop the ov7251 camera entirely until it's properly described.
    
    This obviously fixes:
    sdm845-db845c-navigation-mezzanine.dtso: camera@60: port:endpoint:data-lanes: [0, 1] is too long
            from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov7251.yaml#
    
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20241230-topic-misc-dt-fixes-v4-2-1e6880e9dda3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fa6d6e521ed0aea092c554b0a0722f049457572
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Fri Oct 25 16:43:24 2024 +0100

    arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: Convert mezzanine riser to dtso
    
    [ Upstream commit 30df676a31b7a4881352097d8ae7c2bb83515a17 ]
    
    Convert the navigation / camera mezzanine from its own dts to a dtso. A
    small amount of additional includes / address / cell size change needs to
    be applied to convert.
    
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # rb3
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20241025-b4-linux-next-24-10-25-camss-dts-fixups-v1-2-cdff2f1a5792@linaro.org
    [bjorn: Corrected up makefile syntax, added missing cells for cci_i2c1]
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 80b47f14d543 ("arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: remove disabled ov7251 camera")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c59ba194002a4b482a40f01c3debee5c0dd619d
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Wed Jan 1 14:12:15 2025 +0200

    ARM: omap1: Fix up the Retu IRQ on Nokia 770
    
    [ Upstream commit ad455e48bba7f21bb5108406da0854cf8dede8ea ]
    
    The Retu IRQ is off by one, as a result the power button does not work.
    Fix it.
    
    Fixes: 084b6f216778 ("ARM: omap1: Fix up the Nokia 770 board device IRQs")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/Z3UxH_fOzuftjnuX@darkstar.musicnaut.iki.fi
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e746da4b0cd6541f1aefe57cb24cc0d51e61dbe3
Author: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Date:   Sat Jan 4 11:45:19 2025 +0530

    RDMA/bnxt_re: Fix to drop reference to the mmap entry in case of error
    
    [ Upstream commit c84f0f4f49d81645f49c3269fdcc3b84ce61e795 ]
    
    In the error handling path of bnxt_re_mmap(), driver should invoke
    rdma_user_mmap_entry_put() to free the reference of mmap entry in case
    the error happens after rdma_user_mmap_entry_get was called.
    
    Fixes: ea2224857882 ("RDMA/bnxt_re: Update alloc_page uapi for pacing")
    Reviewed-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
    Reviewed-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://patch.msgid.link/20250104061519.2540178-1-kalesh-anakkur.purayil@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94526fbf58c4d54b111ef79dca9bd40113aa5af6
Author: Vasily Khoruzhick <anarsoul@gmail.com>
Date:   Fri Jan 3 23:36:59 2025 -0800

    arm64: dts: allwinner: a64: explicitly assign clock parent for TCON0
    
    [ Upstream commit 8715c91a836502929c637c76a26335ede8818acf ]
    
    TCON0 seems to need a different clock parent depending on output type.
    For RGB it has to be PLL-VIDEO0-2X, while for DSI it has to be PLL-MIPI,
    so select it explicitly.
    
    Video output doesn't work if incorrect clock is assigned.
    
    On my Pinebook I manually configured PLL-VIDEO0-2X and PLL-MIPI to the same
    rate, and while video output works fine with PLL-VIDEO0-2X, it doesn't
    work at all (as in no picture) with PLL-MIPI.
    
    Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
    Reviewed-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Tested-by: Frank Oltmanns <frank@oltmanns.dev> # on PinePhone
    Tested-by: Stuart Gathman <stuart@gathman.org> # on OG Pinebook
    Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Link: https://patch.msgid.link/20250104074035.1611136-4-anarsoul@gmail.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5e386065e5a67273ab5de5d4809a3bfe5e707ff
Author: Bryan Brattlof <bb@ti.com>
Date:   Tue Dec 10 14:59:25 2024 -0600

    arm64: dts: ti: k3-am62a: Remove duplicate GICR reg
    
    [ Upstream commit 6f0232577e260cdbc25508e27bb0b75ade7e7ebc ]
    
    The GIC Redistributor control range is mapped twice. Remove the extra
    entry from the reg range.
    
    Fixes: 5fc6b1b62639 ("arm64: dts: ti: Introduce AM62A7 family of SoCs")
    Reported-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Bryan Brattlof <bb@ti.com>
    Link: https://lore.kernel.org/r/20241210-am62-gic-fixup-v1-2-758b4d5b4a0a@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64100cdc3df3152db09e2b4ea376b03c5502db26
Author: Bryan Brattlof <bb@ti.com>
Date:   Tue Dec 10 14:59:24 2024 -0600

    arm64: dts: ti: k3-am62: Remove duplicate GICR reg
    
    [ Upstream commit 72c691d77ea5d0c4636fd3e9f0ad80d813c7d1a7 ]
    
    The GIC Redistributor control register range is mapped twice. Remove
    the extra entry from the reg range.
    
    Fixes: f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC")
    Reported-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Bryan Brattlof <bb@ti.com>
    Link: https://lore.kernel.org/r/20241210-am62-gic-fixup-v1-1-758b4d5b4a0a@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3b30a524c46d1b8b35e99d83cd9396840b9fd1c
Author: Cristian Birsan <cristian.birsan@microchip.com>
Date:   Tue Nov 19 18:01:07 2024 +0200

    ARM: dts: microchip: sama5d27_wlsom1_ek: Add no-1-8-v property to sdmmc0 node
    
    [ Upstream commit 4d9e5965df04c0adf260c3009c55d5fe240f7286 ]
    
    Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V.
    This property will stop the LDO regulator from switching to 1.8V when the
    MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the
    SDMMC interface pins in GPIO mode (PA0 - PA13).
    
    On this board, PA10 is used as GPIO to enable the power switch controlling
    USB Vbus for the USB Host. The change is needed to fix the PA10 voltage
    level to 3.3V instead of 1.8V.
    
    Fixes: 5d4c3cfb63fe ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek")
    Suggested-by: Mihai Sain <mihai.sain@microchip.com>
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
    Tested-by: Andrei Simion <andrei.simion@microchip.com>
    Link: https://lore.kernel.org/r/20241119160107.598411-3-cristian.birsan@microchip.com
    Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e16a59c767231dd6b4c05b3e2716c11fc6a408a
Author: Mihai Sain <mihai.sain@microchip.com>
Date:   Mon Dec 4 09:25:37 2023 +0200

    ARM: dts: microchip: sama5d27_wlsom1_ek: Remove mmc-ddr-3_3v property from sdmmc0 node
    
    [ Upstream commit 2a7f1848d9d65a4deb366726ff8f33c9c64ac43b ]
    
    On board the sdmmc0 interface is wired to a SD Card socket.
    According with mmc-controller bindings, the mmc-ddr-3_3v property
    is used for eMMC devices to enable high-speed DDR mode (3.3V I/O).
    Remove the mmc-ddr-3_3v property from sdmmc0 node.
    
    Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
    Link: https://lore.kernel.org/r/20231204072537.2991-1-mihai.sain@microchip.com
    Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Stable-dep-of: 4d9e5965df04 ("ARM: dts: microchip: sama5d27_wlsom1_ek: Add no-1-8-v property to sdmmc0 node")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6919d6d65c712651e26bb661c78507d7bab1a9f1
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:14 2024 +0200

    arm64: dts: qcom: sm8450: correct sleep clock frequency
    
    [ Upstream commit c375ff3b887abf376607d4769c1114c5e3b6ea72 ]
    
    The SM8450 platform uses PMK8350 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-15-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3bc622b2046620b7d594e7e072ad4e38d9c5a8f
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:13 2024 +0200

    arm64: dts: qcom: sm8350: correct sleep clock frequency
    
    [ Upstream commit f4cc8c75cfc5d06084a31da2ff67e477565f0cae ]
    
    The SM8350 platform uses PMK8350 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-14-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1574f607d83f9750215b5900e592cd8be432dec
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:12 2024 +0200

    arm64: dts: qcom: sm8250: correct sleep clock frequency
    
    [ Upstream commit 75420e437eed69fa95d1d7c339dad86dea35319a ]
    
    The SM8250 platform uses PM8150 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 9ff8b0591fcf ("arm64: dts: qcom: sm8250: use the right clock-freqency for sleep-clk")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-13-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fed5d47fe8da123a1f518cfbea7ae642a47d889
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:11 2024 +0200

    arm64: dts: qcom: sm6375: correct sleep clock frequency
    
    [ Upstream commit 223382c94f1f07c475d39713e4c058401480b441 ]
    
    The SM6375 platform uses PM6125 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 59d34ca97f91 ("arm64: dts: qcom: Add initial device tree for SM6375")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-12-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78b611083305d726e418059a908eaa90ed5604b8
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:10 2024 +0200

    arm64: dts: qcom: sm6125: correct sleep clock frequency
    
    [ Upstream commit b3c547e1507862f0e4d46432b665c5c6e61e14d6 ]
    
    The SM6125 platform uses PM6125 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-11-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd951e7b04bc44941888764b442babb81e563723
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:09 2024 +0200

    arm64: dts: qcom: sm4450: correct sleep clock frequency
    
    [ Upstream commit 158e67cf3619dbb5b9914bb364889041f4b90eea ]
    
    The SM4450 platform uses PM4450 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 7a1fd03e7410 ("arm64: dts: qcom: Adds base SM4450 DTSI")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-10-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36cded5e139dfda81ca227a5901ef40bbc3506d9
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:08 2024 +0200

    arm64: dts: qcom: sdx75: correct sleep clock frequency
    
    [ Upstream commit b8021da9ddc65fa041e12ea1e0ff2dfce5c926eb ]
    
    The SDX75 platform uses PMK8550 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 9181bb939984 ("arm64: dts: qcom: Add SDX75 platform and IDP board support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-9-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ba4d5c19ea9a0ebca0d3b6e4459ba3e6adfb9de
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:07 2024 +0200

    arm64: dts: qcom: sc7280: correct sleep clock frequency
    
    [ Upstream commit f6ccdca14eac545320ab03d6ca91ca343e7372e5 ]
    
    The SC7280 platform uses PMK8350 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 7a1f4e7f740d ("arm64: dts: qcom: sc7280: Add basic dts/dtsi files for sc7280 soc")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-8-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c38070e3b8a3371d90538e5e87eb40e321feafd7
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:05 2024 +0200

    arm64: dts: qcom: qrb4210-rb2: correct sleep clock frequency
    
    [ Upstream commit 298192f365a343d84e9d2755e47bebebf0cfb82e ]
    
    Qualcomm RB2 board uses PM6125 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 8d58a8c0d930 ("arm64: dts: qcom: Add base qrb4210-rb2 board dts")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-6-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29bb336761ed36bf356c03d6e262e0822f302056
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:04 2024 +0200

    arm64: dts: qcom: q[dr]u1000: correct sleep clock frequency
    
    [ Upstream commit 5546604e034b6c383b65676ff8615b346897eccd ]
    
    The Q[DR]U1000 platforms use PM8150 to provide sleep clock. According to
    the documentation, that clock has 32.7645 kHz frequency. Correct the
    sleep clock definition.
    
    Fixes: d1f2cfe2f669 ("arm64: dts: qcom: Add base QDU1000/QRU1000 IDP DTs")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-5-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2e31fadc52ec63162c87c748a6113bbf62337a6
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:03 2024 +0200

    arm64: dts: qcom: qcs404: correct sleep clock frequency
    
    [ Upstream commit 1473ff0b69de68b23ce9874548cdabc64d72725e ]
    
    The QCS40x platforms use PMS405 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 9181bb939984 ("arm64: dts: qcom: Add SDX75 platform and IDP board support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-4-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d68ef84ca10d3b3d8332981af5bfe0265d7e33b7
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:02 2024 +0200

    arm64: dts: qcom: msm8994: correct sleep clock frequency
    
    [ Upstream commit a4148d869d47d8c86da0291dd95d411a5ebe90c8 ]
    
    The MSM8994 platform uses PM8994/6 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: feeaf56ac78d ("arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-3-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7c8c08640d1985cac694ab8db0d47c8f54429b8
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:01 2024 +0200

    arm64: dts: qcom: msm8939: correct sleep clock frequency
    
    [ Upstream commit 5c775f586cde4fca3c5591c43b6dc8b243bc304c ]
    
    The MSM8939 platform uses PM8916 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-2-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db975f5e7cb26e3490ac192299fe064c4cd99733
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Dec 24 12:17:00 2024 +0200

    arm64: dts: qcom: msm8916: correct sleep clock frequency
    
    [ Upstream commit f088b921890cef28862913e5627bb2e2b5f82125 ]
    
    The MSM8916 platform uses PM8916 to provide sleep clock. According to the
    documentation, that clock has 32.7645 kHz frequency. Correct the sleep
    clock definition.
    
    Fixes: f4fb6aeafaaa ("arm64: dts: qcom: msm8916: Add fixed rate on-board oscillators")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241224-fix-board-clocks-v3-1-e9b08fbeadd3@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f23f69f0f22480e6ad51b75ad2e5cbaba676cc08
Author: Luca Weiss <luca.weiss@fairphone.com>
Date:   Fri Dec 20 09:55:01 2024 +0100

    arm64: dts: qcom: sm7225-fairphone-fp4: Drop extra qcom,msm-id value
    
    [ Upstream commit 7fb88e0d4dc1a40a29d49b603faa1484334c60f3 ]
    
    The ID 434 is for SM6350 while 459 is for SM7225. Fairphone 4 is only
    SM7225, so drop the unused 434 entry.
    
    Fixes: 4cbea668767d ("arm64: dts: qcom: sm7225: Add device tree for Fairphone 4")
    Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20241220-fp4-msm-id-v1-1-2b75af02032a@fairphone.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e466bb7f544e58979ba81d8f5edc0ec58f73a78
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Date:   Fri Nov 29 23:12:48 2024 +0100

    arm64: dts: qcom: msm8994: Describe USB interrupts
    
    [ Upstream commit c910544d2234709660d60f80345c285616e73b1c ]
    
    Previously the interrupt lanes were not described, fix that.
    
    Fixes: d9be0bc95f25 ("arm64: dts: qcom: msm8994: Add USB support")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Tested-by: Petr Vorel <petr.vorel@gmail.com>
    Link: https://lore.kernel.org/r/20241129-topic-qcom_usb_dtb_fixup-v1-4-cba24120c058@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 585081791387d001b61146028408a9de7ccd48fe
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Date:   Fri Nov 29 23:12:47 2024 +0100

    arm64: dts: qcom: msm8996: Fix up USB3 interrupts
    
    [ Upstream commit 9cb9c9f4e1380da317a056afd26d66a835c5796c ]
    
    Add the missing interrupt lines and fix qusb2_phy being an impostor
    of hs_phy_irq.
    
    This happens to also fix warnings such as:
    
    usb@6af8800: interrupt-names: ['hs_phy_irq', 'ss_phy_irq'] is too short
    
    Fixes: 4753492de9df ("arm64: dts: qcom: msm8996: Add usb3 interrupts")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20241129-topic-qcom_usb_dtb_fixup-v1-3-cba24120c058@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0753f8993cfe2fd0757dd56e52f949d1779eb6b
Author: Taniya Das <quic_tdas@quicinc.com>
Date:   Fri Oct 25 14:22:53 2024 +0530

    arm64: dts: qcom: sa8775p: Update sleep_clk frequency
    
    [ Upstream commit 30f7dfd2c4899630becf477447e8bbe92683d2c6 ]
    
    Fix the sleep_clk frequency is 32000 on SA8775P.
    
    Fixes: 603f96d4c9d0 ("arm64: dts: qcom: add initial support for qcom sa8775p-ride")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
    Link: https://lore.kernel.org/r/20241025-sa8775p-mm-v4-resend-patches-v6-1-329a2cac09ae@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74f3061e03303a3dae258132de6851e2ad6203e4
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Thu Jun 27 13:42:11 2024 +0200

    arm64: dts: qcom: move common parts for sa8775p-ride variants into a .dtsi
    
    [ Upstream commit fe15631117f8d85b1bc4e0c3b434c78be483a43d ]
    
    In order to support multiple revisions of the sa8775p-ride board, create
    a .dtsi containing the common parts and split out the ethernet bits into
    the actual board file as they will change in revision 3.
    
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Link: https://lore.kernel.org/r/20240627114212.25400-3-brgl@bgdev.pl
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 30f7dfd2c489 ("arm64: dts: qcom: sa8775p: Update sleep_clk frequency")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 823536e1128b92d1ff9979f734ac8dee28fc5745
Author: Shazad Hussain <quic_shazhuss@quicinc.com>
Date:   Tue Nov 7 17:35:02 2023 +0530

    arm64: dts: qcom: sa8775p-ride: enable pmm8654au_0_pon_resin
    
    [ Upstream commit 81c8ec77b86fde629d5beea1ebe42caeea57c5a4 ]
    
    The volume down key is controlled by PMIC via the PON hardware on
    sa8775p platform, so enable the same for sa8775p-ride.
    
    Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
    Link: https://lore.kernel.org/r/20231107120503.28917-1-quic_shazhuss@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 30f7dfd2c489 ("arm64: dts: qcom: sa8775p: Update sleep_clk frequency")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9316d15e7d4e69717f04c4dc8bd05f537ee49183
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Thu Aug 17 16:37:17 2023 -0500

    arm64: dts: qcom: sa8775p-ride: Describe sgmii_phy1 irq
    
    [ Upstream commit 454557d0032d088b4f467f0c541f98edb01fe431 ]
    
    There's an irq hooked up, so let's describe it.
    
    Prior to commit 9757300d2750
    ("pinctrl: qcom: Add intr_target_width field to support increased number of interrupt targets")
    one would not see the IRQ fire, despite some (invasive) debugging
    showing that the GPIO was in fact asserted, resulting in the interface
    staying down.
    
    Now that the IRQ is properly routed we can describe it.
    
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230817213815.638189-3-ahalaney@redhat.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 30f7dfd2c489 ("arm64: dts: qcom: sa8775p: Update sleep_clk frequency")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0aff49ed0d2acf47e14c8a809db95bff336bdce8
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Thu Aug 17 16:37:16 2023 -0500

    arm64: dts: qcom: sa8775p-ride: Describe sgmii_phy0 irq
    
    [ Upstream commit 1ff6569b0ffe7a2e311104cb3cd841983e484ac9 ]
    
    There's an irq hooked up, so let's describe it.
    
    Prior to commit 9757300d2750
    ("pinctrl: qcom: Add intr_target_width field to support increased number of interrupt targets")
    one would not see the IRQ fire, despite some (invasive) debugging
    showing that the GPIO was in fact asserted, resulting in the interface
    staying down.
    
    Now that the IRQ is properly routed we can describe it.
    
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230817213815.638189-2-ahalaney@redhat.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 30f7dfd2c489 ("arm64: dts: qcom: sa8775p: Update sleep_clk frequency")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 367e43d89b9103f3819794d006fb8c6486ea99fe
Author: Marek Vasut <marex@denx.de>
Date:   Sun Oct 6 04:19:48 2024 +0200

    arm64: dts: qcom: msm8996-xiaomi-gemini: Fix LP5562 LED1 reg property
    
    [ Upstream commit 02e784c5023232c48c6ec79b52ac8929d4e4db34 ]
    
    The LP5562 led@1 reg property should likely be set to 1 to match
    the unit. Fix it.
    
    Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241006022012.366601-1-marex@denx.de
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d13b39e072f888b5d802b82c78a01e3ba8dd16b7
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Oct 30 15:02:20 2024 +0800

    arm64: dts: mediatek: mt8183-kukui-jacuzzi: Drop pp3300_panel voltage settings
    
    [ Upstream commit 0b5b1c881a909f17c05ef4b1ccb421e077f6e466 ]
    
    The pp3300_panel fixed regulator is just a load switch. It does not have
    any regulating capabilities. Thus having voltage constraints on it is
    wrong.
    
    Remove the voltage constraints.
    
    Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20241030070224.1006331-2-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c144423cb07e4e227a8572d5742ca2b36ada770d
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Tue Dec 17 18:14:34 2024 +0900

    memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
    
    [ Upstream commit b9784e5cde1f9fb83661a70e580e381ae1264d12 ]
    
    As of_find_node_by_name() release the reference of the argument device
    node, tegra_emc_find_node_by_ram_code() releases some device nodes while
    still in use, resulting in possible UAFs. According to the bindings and
    the in-tree DTS files, the "emc-tables" node is always device's child
    node with the property "nvidia,use-ram-code", and the "lpddr2" node is a
    child of the "emc-tables" node. Thus utilize the
    for_each_child_of_node() macro and of_get_child_by_name() instead of
    of_find_node_by_name() to simplify the code.
    
    This bug was found by an experimental verification tool that I am
    developing.
    
    Fixes: 96e5da7c8424 ("memory: tegra: Introduce Tegra20 EMC driver")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://lore.kernel.org/r/20241217091434.1993597-1-joe@pf.is.s.u-tokyo.ac.jp
    Link: https://lore.kernel.org/r/20241218024415.2494267-3-joe@pf.is.s.u-tokyo.ac.jp
    [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5607d1e7944f6b0a6978d6b0b62c0eeb2c1aa3c5
Author: Marek Vasut <marex@denx.de>
Date:   Fri Dec 13 23:36:25 2024 +0100

    ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoM
    
    [ Upstream commit 479b8227ffc433929ba49200182b6383569f9615 ]
    
    Swap USART3 and UART8 aliases on STM32MP15xx DHCOM SoM,
    make sure UART8 is listed first, USART3 second, because
    the UART8 is labeled as UART2 on the SoM pinout, while
    USART3 is labeled as UART3 on the SoM pinout.
    
    Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cac3340a2fe449be739954cab6c80b565c77fe61
Author: Marek Vasut <marex@denx.de>
Date:   Wed Nov 6 00:29:44 2024 +0100

    ARM: dts: stm32: Deduplicate serial aliases and chosen node for STM32MP15xx DHCOM SoM
    
    [ Upstream commit 73317d327123472cb70e9ecbe050310f1d235e93 ]
    
    Deduplicate /aliases { serialN = ... } and /chosen node into
    stm32mp15xx-dhcom-som.dtsi , since the content is identical
    on all carrier boards using the STM32MP15xx DHCOM SoM. No
    functional change.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Stable-dep-of: 479b8227ffc4 ("ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoM")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fbfacbbf6ee9237464556a439b059b279118f6e
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed Dec 18 19:01:08 2024 -0300

    arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie1
    
    [ Upstream commit 3d7fdd8e38aafd4858935df2392762c1ab8fb40f ]
    
    The MAC reset for PCIe port 1 on MT8195 when asserted during suspend
    causes the system to hang during resume with the following error (with
    no_console_suspend enabled):
    
      mtk-pcie-gen3 112f8000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x0)
      mtk-pcie-gen3 112f8000.pcie: PM: dpm_run_callback(): genpd_resume_noirq+0x0/0x24 returns -110
      mtk-pcie-gen3 112f8000.pcie: PM: failed to resume noirq: error -110
    
    This issue is specific to MT8195. On MT8192 with the PCIe reset,
    MT8192_INFRA_RST4_PCIE_TOP_SWRST, added to the DT node, the issue is not
    observed.
    
    Since without the reset, the PCIe controller and WiFi card connected to
    it, work just as well, remove the reset to allow the system to suspend
    and resume properly.
    
    Fixes: ecc0af6a3fe6 ("arm64: dts: mt8195: Add pcie and pcie phy nodes")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20241218-mt8195-pcie1-reset-suspend-fix-v1-1-1c021dda42a6@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb9a5a953b64ba455eaf5b04e969603cfb48baa0
Author: Ma Ke <make_ruc2021@163.com>
Date:   Tue Dec 17 15:55:38 2024 +0800

    RDMA/srp: Fix error handling in srp_add_port
    
    [ Upstream commit a3cbf68c69611188cd304229e346bffdabfd4277 ]
    
    As comment of device_add() says, if device_add() succeeds, you should
    call device_del() when you want to get rid of it. If device_add() has
    not succeeded, use only put_device() to drop the reference count.
    
    Add a put_device() call before returning from the function to decrement
    reference count for cleanup.
    
    Found by code review.
    
    Fixes: c8e4c2397655 ("RDMA/srp: Rework the srp_add_port() error path")
    Signed-off-by: Ma Ke <make_ruc2021@163.com>
    Link: https://patch.msgid.link/20241217075538.2909996-1-make_ruc2021@163.com
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3013bcfc0c2bc043e0e009536002c74f522aaa68
Author: Hsin-Te Yuan <yuanhsinte@chromium.org>
Date:   Fri Dec 13 05:27:48 2024 +0000

    arm64: dts: mediatek: mt8183: willow: Support second source touchscreen
    
    [ Upstream commit 9594935260d76bffe200bea6cfab6ba0752e70d9 ]
    
    Some willow devices use second source touchscreen.
    
    Fixes: f006bcf1c972 ("arm64: dts: mt8183: Add kukui-jacuzzi-willow board")
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Link: https://lore.kernel.org/r/20241213-touchscreen-v3-2-7c1f670913f9@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90cc73be437ca6adc24e9040a8f610e5a59cedc8
Author: Hsin-Te Yuan <yuanhsinte@chromium.org>
Date:   Fri Dec 13 05:27:47 2024 +0000

    arm64: dts: mediatek: mt8183: kenzo: Support second source touchscreen
    
    [ Upstream commit 5ec5dc73c5ac0c6e06803dc3b5aea4493e856568 ]
    
    Some kenzo devices use second source touchscreen.
    
    Fixes: 0a9cefe21aec ("arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board")
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Link: https://lore.kernel.org/r/20241213-touchscreen-v3-1-7c1f670913f9@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a01e2dc9f010051a536c97a6235405ba311e4e0
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Mon Dec 16 20:19:53 2024 +0800

    RDMA/rxe: Fix mismatched max_msg_sz
    
    [ Upstream commit db03b70969aab4ef111a3369cfd90ea4da3a6aa0 ]
    
    User mode queries max_msg_sz as 0x800000 by command 'ibv_devinfo -v',
    however ibv_post_send/ibv_post_recv has a limit of 2^31. Fix this
    mismatched information.
    
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Fixes: f605f26ea196 ("RDMA/rxe: Protect QP state with qp->state_lock")
    Fixes: 5bf944f24129 ("RDMA/rxe: Add error messages")
    Link: https://patch.msgid.link/20241216121953.765331-1-pizhenwei@bytedance.com
    Review-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5dfd5a88823cfab94226697ed8f78ddc8edb81d9
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Tue Jan 9 16:32:52 2024 +0800

    RDMA/rxe: Improve newline in printing messages
    
    [ Upstream commit 6482718086bf69f9616d0b86d03514b17afaeb08 ]
    
    Previously rxe_{dbg,info,err}() macros are appended built-in newline,
    but some users will add redundant newline sometimes. So remove the
    built-in newline for these macros.
    
    In terms of rxe_{dbg,info,err}_xxx() macros, because they don't have
    built-in newline, append newline when using them.
    
    CC: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
    Reviewed-by: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
    Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com>
    Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
    Link: https://lore.kernel.org/r/20240109083253.3629967-1-lizhijian@fujitsu.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: db03b70969aa ("RDMA/rxe: Fix mismatched max_msg_sz")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a332e101fcbfe141728bdfe5e3f052f199cc1a07
Author: Mamta Shukla <mamta.shukla@leica-geosystems.com>
Date:   Mon Oct 28 15:59:07 2024 +0100

    arm: dts: socfpga: use reset-name "stmmaceth-ocp" instead of "ahb"
    
    [ Upstream commit 62a40a0d5634834790f7166ab592be247390d857 ]
    
    The ahb reset is deasserted in probe before first register access, while the
    stmmacheth-ocp reset needs to be asserted every time before changing the phy
    mode in Arria10[1].
    
    Changed in Upstream to "ahb"(331085a423b  arm64: dts: socfpga: change the
    reset-name of "stmmaceth-ocp" to "ahb" ).This change was intended for arm64
    socfpga and it is not applicable to Arria10.
    
    Further with STMMAC-SELFTEST Driver enabled, ethtool test also FAILS.
    $ ethtool -t eth0
    [  322.946709] socfpga-dwmac ff800000.ethernet eth0: entered promiscuous mode
    [  323.374558] socfpga-dwmac ff800000.ethernet eth0: left promiscuous mode
    The test result is FAIL
    The test extra info:
     1. MAC Loopback                 0
     2. PHY Loopback                 -110
     3. MMC Counters                 -110
     4. EEE                          -95
     5. Hash Filter MC               0
     6. Perfect Filter UC            -110
     7. MC Filter                    -110
     8. UC Filter                    0
     9. Flow Control                 -110
    10. RSS                          -95
    11. VLAN Filtering               -95
    12. VLAN Filtering (perf)        -95
    13. Double VLAN Filter           -95
    14. Double VLAN Filter (perf)    -95
    15. Flexible RX Parser           -95
    16. SA Insertion (desc)          -95
    17. SA Replacement (desc)        -95
    18. SA Insertion (reg)           -95
    19. SA Replacement (reg)         -95
    20. VLAN TX Insertion            -95
    21. SVLAN TX Insertion           -95
    22. L3 DA Filtering              -95
    23. L3 SA Filtering              -95
    24. L4 DA TCP Filtering          -95
    25. L4 SA TCP Filtering          -95
    26. L4 DA UDP Filtering          -95
    27. L4 SA UDP Filtering          -95
    28. ARP Offload                  -95
    29. Jumbo Frame                  -110
    30. Multichannel Jumbo           -95
    31. Split Header                 -95
    32. TBS (ETF Scheduler)          -95
    
    [  324.881327] socfpga-dwmac ff800000.ethernet eth0: Link is Down
    [  327.995360] socfpga-dwmac ff800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
    
    Link:[1] https://www.intel.com/content/www/us/en/docs/programmable/683711/21-2/functional-description-of-the-emac.html
    Fixes: 331085a423b ("arm64: dts: socfpga: change the reset-name of "stmmaceth-ocp" to "ahb")
    Signed-off-by: Mamta Shukla <mamta.shukla@leica-geosystems.com>
    Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c62ceade98a0f453f3a1a542c5702a069bdc778d
Author: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com>
Date:   Thu Oct 3 15:42:46 2024 +0800

    ARM: dts: aspeed: yosemite4: correct the compatible string for max31790
    
    [ Upstream commit b1a1ecb669bfa763ee5e86a038d7c9363eee7548 ]
    
    Fix the compatible string for max31790 to match the binding document.
    
    Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC")
    Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com>
    Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
    Link: https://patch.msgid.link/20241003074251.3818101-6-Delphine_CC_Chiu@wiwynn.com
    Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4064a22702d37de6d4f88e3e2482ad6e28c7ea2f
Author: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com>
Date:   Thu Oct 3 15:42:45 2024 +0800

    ARM: dts: aspeed: yosemite4: Add required properties for IOE on fan boards
    
    [ Upstream commit c64ac96f8f8d957cdc6ec3c93dd9a6c4e6d78506 ]
    
    Add the required properties for IO expander on fan boards.
    
    Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC")
    Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com>
    Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
    Link: https://patch.msgid.link/20241003074251.3818101-5-Delphine_CC_Chiu@wiwynn.com
    Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b94b27e715cb94451be2571342ec206839866d19
Author: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com>
Date:   Fri Sep 27 16:52:13 2024 +0800

    ARM: dts: aspeed: yosemite4: correct the compatible string of adm1272
    
    [ Upstream commit ece3e20e3389ec8a32944ad44746ee379bf1d3eb ]
    
    Remove the space in the compatible string of adm1272 to match the
    pattern of compatible.
    
    Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC")
    Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com>
    Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
    Fixes: 2b8d94f4b4a4765d ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC")
    Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Link: https://patch.msgid.link/20240927085213.331127-1-Delphine_CC_Chiu@wiwynn.com
    Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b14695a7bdaf09d9ec015f28ea197746aaab866
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Tue Dec 10 17:26:13 2024 +0800

    arm64: dts: mediatek: mt8173-evb: Fix MT6397 PMIC sub-node names
    
    [ Upstream commit 9545ba142865b9099d43c972b9ebcf463606499a ]
    
    The MT6397 PMIC bindings specify exact names for its sub-nodes. The
    names used in the current dts don't match, causing a validation error.
    
    Fix up the names. Also drop the label for the regulators node, since
    any reference should be against the individual regulator sub-nodes.
    
    Fixes: 16ea61fc5614 ("arm64: dts: mt8173-evb: Add PMIC support")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20241210092614.3951748-2-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08f2d1bcc0227c3940ec1d3a6ac8e900c4f1ba87
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Tue Dec 10 17:26:12 2024 +0800

    arm64: dts: mediatek: mt8173-elm: Fix MT6397 PMIC sub-node names
    
    [ Upstream commit beb06b727194f68b0a4b5183e50c88265ce185af ]
    
    The MT6397 PMIC bindings specify exact names for its sub-nodes. The
    names used in the current dts don't match, causing a validation error.
    
    Fix up the names. Also drop the label for the regulators node, since
    any reference should be against the individual regulator sub-nodes.
    
    Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20241210092614.3951748-1-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2495b1f85dd9423a3b68d9164beb587ac17d4671
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Dec 11 13:24:24 2024 +0800

    arm64: dts: mediatek: mt8195-demo: Drop regulator-compatible property
    
    [ Upstream commit 2a8af9b95f504260a6d8200a11f0ae5c90e9f787 ]
    
    The "regulator-compatible" property has been deprecated since 2012 in
    commit 13511def87b9 ("regulator: deprecate regulator-compatible DT
    property"), which is so old it's not even mentioned in the converted
    regulator bindings YAML file. It is also not listed in the MT6360
    regulator and charger bindings.
    
    Drop the "regulator-compatible" property from the board dts. The MT6360
    bindings actually require the lowercase name, so with the property
    present the regulators were likely not actually working.
    
    Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241211052427.4178367-7-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fad7737a92e7d9d6bf14252020f21e34defba3e
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Dec 11 13:24:23 2024 +0800

    arm64: dts: mediatek: mt8195-cherry: Drop regulator-compatible property
    
    [ Upstream commit 4dbaa5d5def2c49e44efaa5e796c23d9b904be09 ]
    
    The "regulator-compatible" property has been deprecated since 2012 in
    commit 13511def87b9 ("regulator: deprecate regulator-compatible DT
    property"), which is so old it's not even mentioned in the converted
    regulator bindings YAML file. It should not have been used for new
    submissions such as the MT6315.
    
    Drop the "regulator-compatible" property from the board dts. The
    property values are the same as the node name, so everything should
    continue to work.
    
    Fixes: 260c04d425eb ("arm64: dts: mediatek: cherry: Enable MT6315 regulators on SPMI bus")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241211052427.4178367-6-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4a7aea0c4fb10400d0088f4484b3a4c0304c45e
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Dec 11 13:24:22 2024 +0800

    arm64: dts: mediatek: mt8192-asurada: Drop regulator-compatible property
    
    [ Upstream commit d1fb968551c8688652b8b817bb081fdc9c25cd48 ]
    
    The "regulator-compatible" property has been deprecated since 2012 in
    commit 13511def87b9 ("regulator: deprecate regulator-compatible DT
    property"), which is so old it's not even mentioned in the converted
    regulator bindings YAML file. It should not have been used for new
    submissions such as the MT6315.
    
    Drop the "regulator-compatible" property from the board dts. The
    property values are the same as the node name, so everything should
    continue to work.
    
    Fixes: 3183cb62b033 ("arm64: dts: mediatek: asurada: Add SPMI regulators")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241211052427.4178367-5-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32ddffac4201ffd49c6ae6deaf9bb8826f92f2c0
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Dec 11 13:24:21 2024 +0800

    arm64: dts: mediatek: mt8173-elm: Drop regulator-compatible property
    
    [ Upstream commit 4b907b3ea5fba240808136cc5599d14b52230b39 ]
    
    The "regulator-compatible" property has been deprecated since 2012 in
    commit 13511def87b9 ("regulator: deprecate regulator-compatible DT
    property"), which is so old it's not even mentioned in the converted
    regulator bindings YAML file. It is also not listed in the MT6397
    regulator bindings. Having them present produces a whole bunch of
    validation errors:
    
        Unevaluated properties are not allowed ('regulator-compatible' was unexpected)
    
    Drop the "regulator-compatible" property from the board dts. The
    property values are the same as the node name, so everything should
    continue to work.
    
    Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241211052427.4178367-4-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 206d385b1237f8e436f431b50942891323905970
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Dec 11 13:24:20 2024 +0800

    arm64: dts: mediatek: mt8173-evb: Drop regulator-compatible property
    
    [ Upstream commit a6d5983e40f5d5b219337569cdd269727f5a3e2e ]
    
    The "regulator-compatible" property has been deprecated since 2012 in
    commit 13511def87b9 ("regulator: deprecate regulator-compatible DT
    property"), which is so old it's not even mentioned in the converted
    regulator bindings YAML file. It is also not listed in the MT6397
    regulator bindings. Having them present produces a whole bunch of
    validation errors:
    
        Unevaluated properties are not allowed ('regulator-compatible' was unexpected)
    
    Drop the "regulator-compatible" property from the board dts. The
    property values are the same as the node name, so everything should
    continue to work.
    
    Fixes: 16ea61fc5614 ("arm64: dts: mt8173-evb: Add PMIC support")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241211052427.4178367-3-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de8d88b68d0cfd41152a7a63d6aec0ed3e1b837a
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Nov 30 13:01:37 2024 +0300

    rdma/cxgb4: Prevent potential integer overflow on 32bit
    
    [ Upstream commit bd96a3935e89486304461a21752f824fc25e0f0b ]
    
    The "gl->tot_len" variable is controlled by the user.  It comes from
    process_responses().  On 32bit systems, the "gl->tot_len + sizeof(struct
    cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an
    integer wrapping bug.  Use size_add() to prevent this.
    
    Fixes: 1cab775c3e75 ("RDMA/cxgb4: Fix LE hash collision bug for passive open connection")
    Link: https://patch.msgid.link/r/86b404e1-4a75-4a35-a34e-e3054fa554c7@stanley.mountain
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47b3acbf31e01e1e74c15db503e97571eca16185
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Dec 3 15:44:25 2024 +0200

    RDMA/mlx4: Avoid false error about access to uninitialized gids array
    
    [ Upstream commit 1f53d88cbb0dcc7df235bf6611ae632b254fccd8 ]
    
    Smatch generates the following false error report:
    drivers/infiniband/hw/mlx4/main.c:393 mlx4_ib_del_gid() error: uninitialized symbol 'gids'.
    
    Traditionally, we are not changing kernel code and asking people to fix
    the tools. However in this case, the fix can be done by simply rearranging
    the code to be more clear.
    
    Fixes: e26be1bfef81 ("IB/mlx4: Implement ib_device callbacks")
    Link: https://patch.msgid.link/6a3a1577463da16962463fcf62883a87506e9b62.1733233426.git.leonro@nvidia.com
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 410b99a3d062a8b78d66daba83d92e0728a12f88
Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Date:   Fri Dec 6 18:17:59 2024 +0100

    ARM: dts: stm32: Fix IPCC EXTI declaration on stm32mp151
    
    [ Upstream commit 4ea654242e0c75bdf6b45d3c619c5fdcb2e9312a ]
    
    The GIC IRQ type used for IPCC RX should be IRQ_TYPE_LEVEL_HIGH.
    Replacing the interrupt with the EXTI event changes the type to
    the numeric value 1, meaning IRQ_TYPE_EDGE_RISING.
    
    The issue is that EXTI event 61 is a direct event.The IRQ type of
    direct events is not used by EXTI and is propagated to the parent
    IRQ controller of EXTI, the GIC.
    
    Align the IRQ type to the value expected by the GIC by replacing
    the second parameter "1" with IRQ_TYPE_LEVEL_HIGH.
    
    Fixes: 7d9802bb0e34 ("ARM: dts: stm32: remove the IPCC "wakeup" IRQ on stm32mp151")
    Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 434b724ce471135bcc8eff1eb6d98db7e66866a2
Author: Val Packett <val@packett.cool>
Date:   Wed Dec 4 16:05:07 2024 -0300

    arm64: dts: mediatek: mt8516: reserve 192 KiB for TF-A
    
    [ Upstream commit 2561c7d5d497b988deccc36fe5eac7fd50b937f8 ]
    
    The Android DTB for the related MT8167 reserves 0x30000. This is likely
    correct for MT8516 Android devices as well, and there's never any harm
    in reserving 64KiB more.
    
    Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516")
    Signed-off-by: Val Packett <val@packett.cool>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241204190524.21862-5-val@packett.cool
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a17b2390322ae0bde42000ff659050bb80ca0081
Author: Val Packett <val@packett.cool>
Date:   Wed Dec 4 16:05:06 2024 -0300

    arm64: dts: mediatek: mt8516: add i2c clock-div property
    
    [ Upstream commit eb72341fd92b7af510d236e5a8554d855ed38d3c ]
    
    Move the clock-div property from the pumpkin board dtsi to the SoC's
    since it belongs to the SoC itself and is required on other devices.
    
    Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516")
    Signed-off-by: Val Packett <val@packett.cool>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241204190524.21862-4-val@packett.cool
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c9cda5a2074af0b55846b97de42ab1cb56809a8
Author: Val Packett <val@packett.cool>
Date:   Wed Dec 4 16:05:05 2024 -0300

    arm64: dts: mediatek: mt8516: fix wdt irq type
    
    [ Upstream commit 03a80442030e7147391738fb6cbe5fa0b3b91bb1 ]
    
    The GICv2 does not support EDGE_FALLING interrupts, so the watchdog
    would refuse to attach due to a failing check coming from the GIC driver.
    
    Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516")
    Signed-off-by: Val Packett <val@packett.cool>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241204190524.21862-3-val@packett.cool
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a10685c816f66af44f0fcc3b98742c8c5f54531
Author: Val Packett <val@packett.cool>
Date:   Wed Dec 4 16:05:04 2024 -0300

    arm64: dts: mediatek: mt8516: fix GICv2 range
    
    [ Upstream commit e3ee31e4409f051c021a30122f3c470f093a7386 ]
    
    On the MT8167 which is based on the MT8516 DTS, the following error
    was appearing on boot, breaking interrupt operation:
    
    GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
    
    Similar to what's been proposed for MT7622 which has the same issue,
    fix by using the range reported by force_probe.
    
    Link: https://lore.kernel.org/all/YmhNSLgp%2Fyg8Vr1F@makrotopia.org/
    Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516")
    Signed-off-by: Val Packett <val@packett.cool>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241204190524.21862-2-val@packett.cool
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8bea7ece086b1e0f9c8518a0fcb9b5779ce83f45
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Wed Nov 13 16:16:53 2024 +0800

    arm64: dts: mt8183: set DMIC one-wire mode on Damu
    
    [ Upstream commit 6c379e8b984815fc8f876e4bc78c4d563f13ddae ]
    
    Sets DMIC one-wire mode on Damu.
    
    Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board")
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Link: https://lore.kernel.org/r/20241113-damu-v4-1-6911b69610dd@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac8f8cc0b2b236cec56d3b5c2947b01e2a30c1cd
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed Nov 6 16:01:45 2024 -0500

    arm64: dts: mediatek: mt8186: Move wakeup to MTU3 to get working suspend
    
    [ Upstream commit 253b4e96f5783fddede1b82274a7b4e0aa57d761 ]
    
    The current DT has the wakeup-source and mediatek,syscon-wakeup
    properties in the XHCI nodes, which configures USB wakeup after powering
    down the XHCI hardware block. However, since the XHCI controller is
    behind an MTU3 (USB3 DRD controller), the MTU3 only gets powered down
    after USB wakeup has been configured, causing the system to detect a
    wakeup, and results in broken suspend support as the system resumes
    immediately.
    
    Move the wakeup properties to the MTU3 nodes so that USB wakeup is only
    enabled after the MTU3 has powered down.
    
    With this change in place, it is possible to suspend and resume, and
    also to wakeup through USB, as tested on the Google Steelix (Lenovo 300e
    Yoga Chromebook Gen 4).
    
    Fixes: f6c3e61c5486 ("arm64: dts: mediatek: mt8186: Add MTU3 nodes")
    Reported-by: Wojciech Macek <wmacek@google.com>
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241106-mt8186-suspend-with-usb-wakeup-v1-1-07734a4c8236@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4aa4a0045753fb3ec7291487a255e2c594cfe0bc
Author: Nicolas Ferre <nicolas.ferre@microchip.com>
Date:   Mon Nov 25 17:56:48 2024 +0100

    ARM: at91: pm: change BU Power Switch to automatic mode
    
    [ Upstream commit 6fc5bdfa872b7da51b5507a1327a17c3db2fcf95 ]
    
    Change how the Backup Unit Power is configured and force the
    automatic/hardware mode.
    This change eliminates the need for software management of the power
    switch, ensuring it transitions to the backup power source before
    entering low power modes.
    
    This is done in the only location where this switch was configured. It's
    usually done in the bootloader.
    
    Previously, the loss of the VDDANA (or VDDIN33) power source was not
    automatically compensated by an alternative power source. This resulted
    in the loss of Backup Unit content, including Backup Self-refresh low
    power mode information, OTP emulation configuration, and boot
    configuration, for instance.
    
    Fixes: ac809e7879b1 ("ARM: at91: pm: switch backup area to vbat in backup mode")
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Link: https://lore.kernel.org/r/20241125165648.509162-1-nicolas.ferre@microchip.com
    Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5908e04d73883484168c62a6da660a64a8a58bcd
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Thu Oct 31 13:33:36 2024 +0100

    soc: atmel: fix device_node release in atmel_soc_device_init()
    
    [ Upstream commit d3455ab798100f40af77123e7c2443ec979c546b ]
    
    A device_node acquired via of_find_node_by_path() requires explicit
    calls to of_node_put() when it is no longer needed to avoid leaking the
    resource.
    
    Instead of adding the missing calls to of_node_put() in all execution
    paths, use the cleanup attribute for 'np' by means of the __free()
    macro, which automatically calls of_node_put() when the variable goes
    out of scope.
    
    Fixes: 960ddf70cc11 ("drivers: soc: atmel: Avoid calling at91_soc_init on non AT91 SoCs")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20241031-soc-atmel-soc-cleanup-v2-1-73f2d235fd98@gmail.com
    Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f298125b3651ccb5c3267980667ae58f8f49fe8
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Jan 2 21:38:48 2025 +0100

    cifs: Use cifs_autodisable_serverino() for disabling CIFS_MOUNT_SERVER_INUM in readdir.c
    
    [ Upstream commit 015683d4ed0d23698c71f2194f09bd17dbfad044 ]
    
    In all other places is used function cifs_autodisable_serverino() for
    disabling CIFS_MOUNT_SERVER_INUM mount flag. So use is also in readir.c
    _initiate_cifs_search() function. Benefit of cifs_autodisable_serverino()
    is that it also prints dmesg message that server inode numbers are being
    disabled.
    
    Fixes: ec06aedd4454 ("cifs: clean up handling when server doesn't consistently support inode numbers")
    Fixes: f534dc994397 ("cifs: clear server inode number flag while autodisabling")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f901c35e1a1b3ed1b528a17ffdb941aa0294458
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Thu Jan 16 14:29:03 2025 -0300

    smb: client: fix oops due to unset link speed
    
    [ Upstream commit be7a6a77669588bfa5022a470989702bbbb11e7f ]
    
    It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always
    be set by the server, so the client must handle any values and then
    prevent oopses like below from happening:
    
    Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
    CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41
    04/01/2014
    RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48
    89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8
    e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89
    c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24
    RSP: 0018:ffffc90001817be0 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99
    RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228
    RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac
    R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200
    R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58
    FS: 00007fe27119e740(0000) GS:ffff888148600000(0000)
    knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? __die_body.cold+0x19/0x27
     ? die+0x2e/0x50
     ? do_trap+0x159/0x1b0
     ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
     ? do_error_trap+0x90/0x130
     ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
     ? exc_divide_error+0x39/0x50
     ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
     ? asm_exc_divide_error+0x1a/0x20
     ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]
     ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
     ? seq_read_iter+0x42e/0x790
     seq_read_iter+0x19a/0x790
     proc_reg_read_iter+0xbe/0x110
     ? __pfx_proc_reg_read_iter+0x10/0x10
     vfs_read+0x469/0x570
     ? do_user_addr_fault+0x398/0x760
     ? __pfx_vfs_read+0x10/0x10
     ? find_held_lock+0x8a/0xa0
     ? __pfx_lock_release+0x10/0x10
     ksys_read+0xd3/0x170
     ? __pfx_ksys_read+0x10/0x10
     ? __rcu_read_unlock+0x50/0x270
     ? mark_held_locks+0x1a/0x90
     do_syscall_64+0xbb/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fe271288911
    Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8
    20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d
    00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec
    RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
    RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911
    RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003
    RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380
    R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000
    R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000
     </TASK>
    
    Fix this by setting cifs_server_iface::speed to a sane value (1Gbps)
    by default when link speed is unset.
    
    Cc: Shyam Prasad N <nspmangalore@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Fixes: a6d8fb54a515 ("cifs: distribute channels across interfaces based on speed")
    Reported-by: Frank Sorenson <sorenson@redhat.com>
    Reported-by: Jay Shin <jaeshin@redhat.com>
    Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f45ef616775b0ce7889b0f6077fc8d681ab30bc
Author: Chen Ridong <chenridong@huawei.com>
Date:   Fri Jan 10 06:16:39 2025 +0000

    padata: avoid UAF for reorder_work
    
    [ Upstream commit dd7d37ccf6b11f3d95e797ebe4e9e886d0332600 ]
    
    Although the previous patch can avoid ps and ps UAF for _do_serial, it
    can not avoid potential UAF issue for reorder_work. This issue can
    happen just as below:
    
    crypto_request                  crypto_request          crypto_del_alg
    padata_do_serial
      ...
      padata_reorder
        // processes all remaining
        // requests then breaks
        while (1) {
          if (!padata)
            break;
          ...
        }
    
                                    padata_do_serial
                                      // new request added
                                      list_add
        // sees the new request
        queue_work(reorder_work)
                                      padata_reorder
                                        queue_work_on(squeue->work)
    ...
    
                                    <kworker context>
                                    padata_serial_worker
                                    // completes new request,
                                    // no more outstanding
                                    // requests
    
                                                            crypto_del_alg
                                                              // free pd
    
    <kworker context>
    invoke_padata_reorder
      // UAF of pd
    
    To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work'
    into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.
    
    Fixes: bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock by using per-instance padata queues")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5981c99467121792a70a3dd2eddf84cb3fafa08
Author: Chen Ridong <chenridong@huawei.com>
Date:   Fri Jan 10 06:16:37 2025 +0000

    padata: add pd get/put refcnt helper
    
    [ Upstream commit ae154202cc6a189b035359f3c4e143d5c24d5352 ]
    
    Add helpers for pd to get/put refcnt to make code consice.
    
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: dd7d37ccf6b1 ("padata: avoid UAF for reorder_work")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de
Author: Chen Ridong <chenridong@huawei.com>
Date:   Fri Jan 10 06:16:38 2025 +0000

    padata: fix UAF in padata_reorder
    
    [ Upstream commit e01780ea4661172734118d2a5f41bc9720765668 ]
    
    A bug was found when run ltp test:
    
    BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0
    Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
    
    CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+
    Workqueue: pdecrypt_parallel padata_parallel_worker
    Call Trace:
    <TASK>
    dump_stack_lvl+0x32/0x50
    print_address_description.constprop.0+0x6b/0x3d0
    print_report+0xdd/0x2c0
    kasan_report+0xa5/0xd0
    padata_find_next+0x29/0x1a0
    padata_reorder+0x131/0x220
    padata_parallel_worker+0x3d/0xc0
    process_one_work+0x2ec/0x5a0
    
    If 'mdelay(10)' is added before calling 'padata_find_next' in the
    'padata_reorder' function, this issue could be reproduced easily with
    ltp test (pcrypt_aead01).
    
    This can be explained as bellow:
    
    pcrypt_aead_encrypt
    ...
    padata_do_parallel
    refcount_inc(&pd->refcnt); // add refcnt
    ...
    padata_do_serial
    padata_reorder // pd
    while (1) {
    padata_find_next(pd, true); // using pd
    queue_work_on
    ...
    padata_serial_worker                            crypto_del_alg
    padata_put_pd_cnt // sub refcnt
                                                    padata_free_shell
                                                    padata_put_pd(ps->pd);
                                                    // pd is freed
    // loop again, but pd is freed
    // call padata_find_next, UAF
    }
    
    In the padata_reorder function, when it loops in 'while', if the alg is
    deleted, the refcnt may be decreased to 0 before entering
    'padata_find_next', which leads to UAF.
    
    As mentioned in [1], do_serial is supposed to be called with BHs disabled
    and always happen under RCU protection, to address this issue, add
    synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls
    to finish.
    
    [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/
    [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/
    Fixes: b128a3040935 ("padata: allocate workqueue internally")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Qu Zicheng <quzicheng@huawei.com>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55f75ce472aece6a3899563ce035129db81fe3a8
Author: Chun-Tse Shao <ctshao@google.com>
Date:   Thu Jan 16 15:58:14 2025 -0800

    perf lock: Fix parse_lock_type which only retrieve one lock flag
    
    [ Upstream commit 1be9264158ef4818393e5d8144887a1a5d3cc480 ]
    
    `parse_lock_type` can only add the first lock flag in `lock_type_table`
    given input `str`. For example, for `Y rwlock`, it only adds `rwlock:R`
    into this perf session. Another example is for `-Y mutex`, it only adds
    the mutex without `LCB_F_SPIN` flag. The patch fixes this issue, makes
    sure both `rwlock:R` and `rwlock:W` will be added with `-Y rwlock`, and
    so on.
    
    Testing:
      $ ./perf lock con -ab -Y mutex,rwlock -- perf bench sched pipe
      # Running 'sched/pipe' benchmark:
      # Executed 1000000 pipe operations between two processes
    
           Total time: 9.313 [sec]
    
             9.313976 usecs/op
               107365 ops/sec
       contended   total wait     max wait     avg wait         type   caller
    
             176      1.65 ms     19.43 us      9.38 us        mutex   pipe_read+0x57
              34    180.14 us     10.93 us      5.30 us        mutex   pipe_write+0x50
               7     77.48 us     16.09 us     11.07 us        mutex   do_epoll_wait+0x24d
               7     74.70 us     13.50 us     10.67 us        mutex   do_epoll_wait+0x24d
               3     35.97 us     14.44 us     11.99 us     rwlock:W   ep_done_scan+0x2d
               3     35.00 us     12.23 us     11.66 us     rwlock:W   do_epoll_wait+0x255
               2     15.88 us     11.96 us      7.94 us     rwlock:W   do_epoll_wait+0x47c
               1     15.23 us     15.23 us     15.23 us     rwlock:W   do_epoll_wait+0x4d0
               1     14.26 us     14.26 us     14.26 us     rwlock:W   ep_done_scan+0x2d
               2     14.00 us      7.99 us      7.00 us        mutex   pipe_read+0x282
               1     12.29 us     12.29 us     12.29 us     rwlock:R   ep_poll_callback+0x35
               1     12.02 us     12.02 us     12.02 us     rwlock:W   do_epoll_ctl+0xb65
               1     10.25 us     10.25 us     10.25 us     rwlock:R   ep_poll_callback+0x35
               1      7.86 us      7.86 us      7.86 us        mutex   do_epoll_ctl+0x6c1
               1      5.04 us      5.04 us      5.04 us        mutex   do_epoll_ctl+0x3d4
    
    [namhyung: Add a comment and rename to 'mutex:spin' for consistency
    
    Fixes: d783ea8f62c4 ("perf lock contention: Simplify parse_lock_type()")
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Chun-Tse Shao <ctshao@google.com>
    Cc: nick.forrington@arm.com
    Link: https://lore.kernel.org/r/20250116235838.2769691-1-ctshao@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40f8b565d595aab0bd19536060b4335821086265
Author: Kailang Yang <kailang@realtek.com>
Date:   Mon Dec 30 14:44:01 2024 +0800

    ALSA: hda/realtek - Fixed headphone distorted sound on Acer Aspire A115-31 laptop
    
    [ Upstream commit 5cb4e5b056772e341b590755a976081776422053 ]
    
    Sound played through headphones is distorted.
    
    Fixes: 34ab5bbc6e82 ("ALSA: hda/realtek - Add Headset Mic supported Acer NB platform")
    Closes: https://lore.kernel.org/linux-sound/e142749b-7714-4733-9452-918fbe328c8f@gmail.com/
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/0a89b6c18ed94378a105fa61e9f290e4@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 670ef7b2900b38792c357b2db0fadf2881d3d239
Author: Daniel Xu <dxu@dxuuu.xyz>
Date:   Tue Jan 14 13:28:43 2025 -0700

    bpf: tcp: Mark bpf_load_hdr_opt() arg2 as read-write
    
    [ Upstream commit 8ac412a3361173e3000b16167af3d1f6f90af613 ]
    
    MEM_WRITE attribute is defined as: "Non-presence of MEM_WRITE means that
    MEM is only being read". bpf_load_hdr_opt() both reads and writes from
    its arg2 - void *search_res.
    
    This matters a lot for the next commit where we more precisely track
    stack accesses. Without this annotation, the verifier will make false
    assumptions about the contents of memory written to by helpers and
    possibly prune valid branches.
    
    Fixes: 6fad274f06f0 ("bpf: Add MEM_WRITE attribute")
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
    Link: https://lore.kernel.org/r/730e45f8c39be2a5f3d8c4406cceca9d574cbf14.1736886479.git.dxu@dxuuu.xyz
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eeef8e65041a031bd8a747a392c14b76a123a12c
Author: Puranjay Mohan <puranjay@kernel.org>
Date:   Wed Jan 15 10:36:47 2025 +0000

    bpf: Send signals asynchronously if !preemptible
    
    [ Upstream commit 87c544108b612512b254c8f79aa5c0a8546e2cc4 ]
    
    BPF programs can execute in all kinds of contexts and when a program
    running in a non-preemptible context uses the bpf_send_signal() kfunc,
    it will cause issues because this kfunc can sleep.
    Change `irqs_disabled()` to `!preemptible()`.
    
    Reported-by: syzbot+97da3d7e0112d59971de@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/67486b09.050a0220.253251.0084.GAE@google.com/
    Fixes: 1bc7896e9ef4 ("bpf: Fix deadlock with rq_lock in bpf_send_signal()")
    Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/r/20250115103647.38487-1-puranjay@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01220c10a7f48014381b3d9879ce5732744f25fc
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Mon Jan 6 18:41:15 2025 +0100

    pinctrl: amd: Take suspend type into consideration which pins are non-wake
    
    [ Upstream commit f31f33dbb3bab572bad9fe7b849ab0dcbe6fd279 ]
    
    Some laptops have pins which are a wake source for S0i3/S3 but which
    aren't a wake source for S4/S5 and which cause issues when left unmasked
    during hibernation (S4).
    
    For example HP EliteBook 855 G7 has pin #24 that causes instant wakeup
    (hibernation failure) if left unmasked (it is a wake source only for
    S0i3/S3).
    GPIO pin #24 on this platform is likely dedicated to WWAN XMM7360
    modem since this pin triggers wake notify to WWAN modem's parent PCIe
    port.
    
    Fix this by considering a pin a wake source only if it is marked as one
    for the current suspend type (S0i3/S3 vs S4/S5).
    
    Since Z-wake pins only make sense at runtime these were excluded from
    both of suspend categories, so pins with only the Z-wake flag set are
    effectively treated as non-wake pins.
    
    Fixes: 2fff0b5e1a6b ("pinctrl: amd: Mask non-wake source pins with interrupt enabled at suspend")
    Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/d4b2d076366fdd08a0c1cd9b7ecd91dc95e07269.1736184752.git.mail@maciej.szmigiero.name
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3872b4eec88a61874a488ffd5e5fcd865ae01eb6
Author: Mingwei Zheng <zmw12306@gmail.com>
Date:   Mon Jan 6 17:06:59 2025 -0500

    pinctrl: stm32: Add check for clk_enable()
    
    [ Upstream commit 451bc9aea9a1a6fe53969e81a5cb1bd785c0d989 ]
    
    Convert the driver to clk_bulk*() API.
    Add check for the return value of clk_bulk_enable() to catch
    the potential error.
    
    Fixes: 05d8af449d93 ("pinctrl: stm32: Keep pinctrl block clock enabled when LEVEL IRQ requested")
    Signed-off-by: Mingwei Zheng <zmw12306@gmail.com>
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Reviewed-by: Antonio Borneo <antonio.borneo@foss.st.com>
    Link: https://lore.kernel.org/20250106220659.2640365-1-zmw12306@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e09336f352f8c233379427b8610f7b85da82d0a
Author: Jiachen Zhang <me@jcix.top>
Date:   Thu Jan 9 23:22:19 2025 +0800

    perf report: Fix misleading help message about --demangle
    
    [ Upstream commit ac0ac75189a4d6a29a2765a7adbb62bc6cc650c7 ]
    
    The wrong help message may mislead users. This commit fixes it.
    
    Fixes: 328ccdace8855289 ("perf report: Add --no-demangle option")
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Jiachen Zhang <me@jcix.top>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20250109152220.1869581-1-me@jcix.top
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49bc44a51d72e0837086e8080426198fac0841ba
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Thu Jan 9 13:22:06 2025 +0100

    ASoC: Intel: avs: Fix theoretical infinite loop
    
    [ Upstream commit cf4d74256fe103ece7b2647550e6c063048e5682 ]
    
    While 'stack_dump_size' is a u32 bitfield of 16 bits, u32 has a bigger
    upper bound than the type u16 of loop counter 'offset' what in theory
    may lead to infinite loop condition.
    
    Found out by Coverity static analyzer.
    
    Fixes: c8c960c10971 ("ASoC: Intel: avs: APL-based platforms support")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://patch.msgid.link/20250109122216.3667847-4-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e6f12d554ae3491644501685d20e14403f40b67
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Thu Jan 9 13:22:04 2025 +0100

    ASoC: Intel: avs: Do not readq() u32 registers
    
    [ Upstream commit bca0fa5f6b5e96c03daac1ed62b1e5c5057a2048 ]
    
    Register reporting ROM status is 4-bytes wide.
    
    Fixes: 092cf7b26a48 ("ASoC: Intel: avs: Code loading over HDA")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://patch.msgid.link/20250109122216.3667847-2-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9db15cf2d690ab2aeac3de8867078ad35092fbd
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Tue Feb 20 12:50:29 2024 +0100

    ASoC: Intel: avs: Abstract IPC handling
    
    [ Upstream commit 7576e2f4d99df6efabb77f52b9539fd345233aee ]
    
    Servicing IPCs on CNL platforms and onward differs from the existing
    one. To make room for these, enrich platform descriptor with fields
    representing crucial IPC registers and utilize them throughout the code.
    
    While cleaning up device descriptors, reduce the number of code lines by
    assigning 'min_fw_version' within a single line.
    
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240220115035.770402-5-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: bca0fa5f6b5e ("ASoC: Intel: avs: Do not readq() u32 registers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5a41d42396ea9a7245dfe88e149f68c9887209f
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Tue Feb 20 12:50:28 2024 +0100

    ASoC: Intel: avs: Prefix SKL/APL-specific members
    
    [ Upstream commit a8f858d98f016a0209edaf1518fd45a5e5c62d47 ]
    
    Prefix members that are platform-specific with 'avs_' to improve code
    cohesiveness and reduce the chance for naming-conflics with other
    drivers.
    
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240220115035.770402-4-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: bca0fa5f6b5e ("ASoC: Intel: avs: Do not readq() u32 registers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 125066c32953855c24882b235e5e74447aa643ba
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Dec 6 17:48:28 2024 -0300

    perf namespaces: Fixup the nsinfo__in_pidns() return type, its bool
    
    [ Upstream commit 64a7617efd5ae1d57a75e464d7134eec947c3fe3 ]
    
    When adding support for refconunt checking a cut'n'paste made this
    function, that is just an accessor to a bool member of 'struct nsinfo',
    return a pid_t, when that member is a boolean, fix it.
    
    Fixes: bcaf0a97858de7ab ("perf namespaces: Add functions to access nsinfo")
    Reported-by: Francesco Nigro <fnigro@redhat.com>
    Reported-by: Ilan Green <igreen@redhat.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: James Clark <james.clark@linaro.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Yonatan Goldschmidt <yonatan.goldschmidt@granulate.io>
    Link: https://lore.kernel.org/r/20241206204828.507527-6-acme@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d43c2447032c02fe2263567933dee2a39163b474
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Dec 6 17:48:26 2024 -0300

    perf namespaces: Introduce nsinfo__set_in_pidns()
    
    [ Upstream commit 9c6a585d257f6845731f4e36b45fe42b5c3162f5 ]
    
    When we're processing a perf.data file we will, for every thread in that
    file do a machine__findnew_thread(machine, pid, tid) that when that pid
    is seen for the first time will create a 'struct thread' representing
    it.
    
    That in turn will call nsinfo__new() -> nsinfo__init() and there it will
    assume we're running live, which is wrong and will need to be addressed
    in a followup patch.
    
    The nsinfo__new() assumes that if we can't access that thread it has
    already finished and will ignore the -1 return from nsinfo__init(), just
    taking notes to avoid trying to enter in that namespace, since it isn't
    there anymore, a race.
    
    When doing this from 'perf inject', tho, we can fill in parts of that
    nsinfo from what we get from the PERF_RECORD_MMAP2 (pid, tid) and in the
    jitdump file name, that has the form of jit-<PID>.dump.
    
    So if the pid in the jitdump file name is not the one in the
    PERF_RECORD_MMAP2, we can assume that its the pid of the process
    _inside_ the namespace, and that perf was runing outside that namespace.
    
    This will be done in the following patch.
    
    Reported-by: Francesco Nigro <fnigro@redhat.com>
    Reported-by: Ilan Green <igreen@redhat.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: James Clark <james.clark@linaro.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Yonatan Goldschmidt <yonatan.goldschmidt@granulate.io>
    Link: https://lore.kernel.org/r/20241206204828.507527-4-acme@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 64a7617efd5a ("perf namespaces: Fixup the nsinfo__in_pidns() return type, its bool")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4318e26fe4f43542bb10b9f79a259a3342e2a2f4
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Jan 8 10:15:24 2025 +0100

    perf machine: Don't ignore _etext when not a text symbol
    
    [ Upstream commit 7a93786c306296f15e728b1dbd949a319e4e3d19 ]
    
    Depending on how vmlinux.lds is written, _etext might be the very first
    data symbol instead of the very last text symbol.
    
    Don't require it to be a text symbol, accept any symbol type.
    
    Comitter notes:
    
    See the first Link for further discussion, but it all boils down to
    this:
    
     ---
      # grep -e _stext -e _etext -e _edata /proc/kallsyms
      c0000000 T _stext
      c08b8000 D _etext
    
      So there is no _edata and _etext is not text
    
      $ ppc-linux-objdump -x vmlinux | grep -e _stext -e _etext -e _edata
      c0000000 g       .head.text   00000000 _stext
      c08b8000 g       .rodata      00000000 _etext
      c1378000 g       .sbss        00000000 _edata
     ---
    
    Fixes: ed9adb2035b5be58 ("perf machine: Read also the end of the kernel")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/r/b3ee1994d95257cb7f2de037c5030ba7d1bed404.1736327613.git.christophe.leroy@csgroup.eu
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8487f93db8550af32c9b612ee83008100ca5cf67
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Jan 2 16:50:39 2025 -0300

    perf top: Don't complain about lack of vmlinux when not resolving some kernel samples
    
    [ Upstream commit 058b38ccd2af9e5c95590b018e8425fa148d7aca ]
    
    Recently we got a case where a kernel sample wasn't being resolved due
    to a bug that was not setting the end address on kernel functions
    implemented in assembly (see Link: tag), and then those were not being
    found by machine__resolve() -> map__find_symbol().
    
    So we ended up with:
    
      # perf top --stdio
      PerfTop: 0 irqs/s  kernel: 0%  exact: 0% lost: 0/0 drop: 0/0 [cycles/P]
      -----------------------------------------------------------------------
    
      Warning:
      A vmlinux file was not found.
      Kernel samples will not be resolved.
      ^Z
      [1]+  Stopped                 perf top --stdio
      #
    
    But then resolving all other kernel symbols.
    
    So just fixup the logic to only print that warning when there are no
    symbols in the kernel map.
    
    Fixes: d88205db9caa0e9d ("perf dso: Add dso__has_symbols() method")
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: James Clark <james.clark@linaro.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Link: https://lore.kernel.org/lkml/Z3buKhcCsZi3_aGb@x1
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6e97a24de83b381e23e0cc488a0f314451d8916
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Fri Dec 27 23:32:01 2024 +0100

    padata: fix sysfs store callback check
    
    [ Upstream commit 9ff6e943bce67d125781fe4780a5d6f072dc44c0 ]
    
    padata_sysfs_store() was copied from padata_sysfs_show() but this check
    was not adapted. Today there is no attribute which can fail this
    check, but if there is one it may as well be correct.
    
    Fixes: 5e017dc3f8bc ("padata: Added sysfs primitives to padata subsystem")
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19f17a762ebda04e1bf9265f30b1b63fe8103683
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 1 13:55:47 2025 +0100

    ALSA: seq: Make dependency on UMP clearer
    
    [ Upstream commit 9001d515443518d72222ba4d58e247696b625071 ]
    
    CONFIG_SND_SEQ_UMP_CLIENT is a Kconfig for a sequencer client
    corresponding to the UMP rawmidi, while we have another major knob
    CONFIG_SND_SEQ_UMP that specifies whether the sequencer core supports
    UMP packets or not.  Strictly speaking both of them are independent,
    but practically seen, it makes no sense to enable
    CONFIG_SND_SEQ_UMP_CLIENT without UMP support itself.
    
    This patch makes such an implicit dependency clearer.  Now
    CONFIG_SND_SEQ_UMP_CLIENT depends on both CONFIG_SND_UMP and
    CONFIG_SND_SEQ_UMP.  Meanwhile, CONFIG_SND_SEQ_UMP is enabled as
    default when CONFIG_SND_UMP is set.
    
    Fixes: 81fd444aa371 ("ALSA: seq: Bind UMP device")
    Link: https://patch.msgid.link/20250101125548.25961-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bd0bb51bd92930769a349d35bcc459c29aeaddf
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Feb 15 22:53:04 2024 +0900

    ALSA: seq: remove redundant 'tristate' for SND_SEQ_UMP_CLIENT
    
    [ Upstream commit 8e8bc5000328a1ba8f93d43faf427e8ac31fb416 ]
    
    'def_tristate' is a shorthand for 'default' + 'tristate'.
    
    Another 'tristate' is redundant.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Link: https://lore.kernel.org/r/20240215135304.1909431-1-masahiroy@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Stable-dep-of: 9001d5154435 ("ALSA: seq: Make dependency on UMP clearer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78f2ac97823cb88cfb4d388b2eceb9f9eda53124
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Sun Dec 15 16:27:20 2024 +0900

    crypto: ixp4xx - fix OF node reference leaks in init_ixp_crypto()
    
    [ Upstream commit 472a989029aac2b78ef2f0b18b27c568bf76d104 ]
    
    init_ixp_crypto() calls of_parse_phandle_with_fixed_args() multiple
    times, but does not release all the obtained refcounts. Fix it by adding
    of_node_put() calls.
    
    This bug was found by an experimental static analysis tool that I am
    developing.
    
    Fixes: 76f24b4f46b8 ("crypto: ixp4xx - Add device tree support")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfb531141bda4be3b20fe8886cc8eec94a641355
Author: Wenkai Lin <linwenkai6@hisilicon.com>
Date:   Fri Dec 13 17:13:35 2024 +0800

    crypto: hisilicon/sec2 - fix for aead invalid authsize
    
    [ Upstream commit a5a9d959936499a3106a1bf3b9070875d0d3dec4 ]
    
    When the digest alg is HMAC-SHAx or another, the authsize may be less
    than 4 bytes and mac_len of the BD is set to zero, the hardware considers
    it a BD configuration error and reports a ras error, so the sec driver
    needs to switch to software calculation in this case, this patch add a
    check for it and remove unnecessary check that has been done by crypto.
    
    Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2")
    Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
    Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2309cf3f5e9dcf24f6313cbae5d7dd8230223a5e
Author: Wenkai Lin <linwenkai6@hisilicon.com>
Date:   Fri Dec 13 17:13:34 2024 +0800

    crypto: hisilicon/sec2 - fix for aead icv error
    
    [ Upstream commit fd337f852b2677b53d0859a47b58e6e6bd189f30 ]
    
    When the AEAD algorithm is used for encryption or decryption,
    the input authentication length varies, the hardware needs to
    obtain the input length to pass the integrity check verification.
    Currently, the driver uses a fixed authentication length,which
    causes decryption failure, so the length configuration is modified.
    In addition, the step of setting the auth length is unnecessary,
    so it was deleted from the setkey function.
    
    Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2")
    Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
    Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4cc472ea0d810b0f158b11ec9a2774149cba29b
Author: Chenghai Huang <huangchenghai2@huawei.com>
Date:   Sat Dec 9 15:01:35 2023 +0800

    crypto: hisilicon/sec2 - optimize the error return process
    
    [ Upstream commit 1bed82257b1881b689ee41f14ecb4c20a273cac0 ]
    
    Add the printf of an error message and optimized the handling
    process of ret.
    
    Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: fd337f852b26 ("crypto: hisilicon/sec2 - fix for aead icv error")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3392fa605d7c5708c5fbe02e4fbdac547c3b7352
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Wed Dec 18 11:30:00 2024 -0800

    bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT
    
    [ Upstream commit 8eef6ac4d70eb1f0099fff93321d90ce8fa49ee1 ]
    
    In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible
    context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is
    to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT
    is enabled.
    
    [   35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    [   35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs
    [   35.118569] preempt_count: 1, expected: 0
    [   35.118571] RCU nest depth: 1, expected: 1
    [   35.118577] INFO: lockdep is turned off.
        ...
    [   35.118647]  __might_resched+0x433/0x5b0
    [   35.118677]  rt_spin_lock+0xc3/0x290
    [   35.118700]  ___slab_alloc+0x72/0xc40
    [   35.118723]  __kmalloc_noprof+0x13f/0x4e0
    [   35.118732]  bpf_map_kzalloc+0xe5/0x220
    [   35.118740]  bpf_selem_alloc+0x1d2/0x7b0
    [   35.118755]  bpf_local_storage_update+0x2fa/0x8b0
    [   35.118784]  bpf_sk_storage_get_tracing+0x15a/0x1d0
    [   35.118791]  bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66
    [   35.118795]  bpf_trace_run3+0x222/0x400
    [   35.118820]  __bpf_trace_inet_sock_set_state+0x11/0x20
    [   35.118824]  trace_inet_sock_set_state+0x112/0x130
    [   35.118830]  inet_sk_state_store+0x41/0x90
    [   35.118836]  tcp_set_state+0x3b3/0x640
    
    There is no need to adjust the gfp_flags passing to the
    bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.
    The verifier has ensured GFP_KERNEL is passed only in sleepable context.
    
    It has been an old issue since the first introduction of the
    bpf_local_storage ~5 years ago, so this patch targets the bpf-next.
    
    bpf_mem_alloc is needed to solve it, so the Fixes tag is set
    to the commit when bpf_mem_alloc was first used in the bpf_local_storage.
    
    Fixes: 08a7ce384e33 ("bpf: Use bpf_mem_cache_alloc/free in bpf_local_storage_elem")
    Reported-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20241218193000.2084281-1-martin.lau@linux.dev
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c7f63d94087a4c363e398d160e0a7e388700bfb
Author: Ba Jing <bajing@cmss.chinamobile.com>
Date:   Mon Sep 2 21:07:35 2024 +0800

    ktest.pl: Remove unused declarations in run_bisect_test function
    
    [ Upstream commit 776735b954f49f85fd19e1198efa421fae2ad77c ]
    
    Since $output and $ret are not used in the subsequent code, the declarations
    should be removed.
    
    Fixes: a75fececff3c ("ktest: Added sample.conf, new %default option format")
    Link: https://lore.kernel.org/20240902130735.6034-1-bajing@cmss.chinamobile.com
    Signed-off-by: Ba Jing <bajing@cmss.chinamobile.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ee00cc23cc855a53f5c16a0561edbf3be0f5e73
Author: Levi Yun <yeoreum.yun@arm.com>
Date:   Fri Nov 8 14:34:25 2024 +0000

    perf expr: Initialize is_test value in expr__ctx_new()
    
    [ Upstream commit 1d18ebcfd302a2005b83ae5f13df223894d19902 ]
    
    When expr_parse_ctx is allocated by expr_ctx_new(),
    expr_scanner_ctx->is_test isn't initialize, so it has garbage value.
    this can affects the result of expr__parse() return when it parses
    non-exist event literal according to garbage value.
    
    Use calloc instead of malloc in expr_ctx_new() to fix this.
    
    Fixes: 3340a08354ac286e ("perf pmu-events: Fix testing with JEVENTS_ARCH=all")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Reviewed-by: James Clark <james.clark@linaro.org>
    Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20241108143424.819126-1-yeoreum.yun@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd95e117530e6784131a4cecae2073a79a107dd4
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Tue Dec 10 19:09:34 2024 +0200

    ASoC: renesas: rz-ssi: Use only the proper amount of dividers
    
    [ Upstream commit 55c209cd4318c701e6e88e0b2512a0f12dd02a7d ]
    
    There is no need to populate the ckdv[] with invalid dividers as that
    part will not be indexed anyway. The ssi->audio_mck/bclk_rate should
    always be >= 0. While at it, change the ckdv type as u8, as the divider
    128 was previously using the s8 sign bit.
    
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Fixes: 03e786bd43410fa9 ("ASoC: sh: Add RZ/G2L SSIF-2 driver")
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://patch.msgid.link/20241210170953.2936724-6-claudiu.beznea.uj@bp.renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7d067a47bf811548143522b6b2b2d1ff9e4357c
Author: Zhongqiu Han <quic_zhonhan@quicinc.com>
Date:   Thu Dec 5 16:45:00 2024 +0800

    perf bpf: Fix two memory leakages when calling perf_env__insert_bpf_prog_info()
    
    [ Upstream commit 03edb7020bb920f1935c3f30acad0bb27fdb99af ]
    
    If perf_env__insert_bpf_prog_info() returns false due to a duplicate bpf
    prog info node insertion, the temporary info_node and info_linear memory
    will leak. Add a check to ensure the memory is freed if the function
    returns false.
    
    Fixes: d56354dc49091e33 ("perf tools: Save bpf_prog_info and BTF of new BPF programs")
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@linaro.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <song@kernel.org>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20241205084500.823660-4-quic_zhonhan@quicinc.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bce9da3aca14dc6ab85ef1a55a40281d5b9c8702
Author: Zhongqiu Han <quic_zhonhan@quicinc.com>
Date:   Thu Dec 5 16:44:59 2024 +0800

    perf header: Fix one memory leakage in process_bpf_prog_info()
    
    [ Upstream commit a7da6c7030e1aec32f0a41c7b4fa70ec96042019 ]
    
    Function __perf_env__insert_bpf_prog_info() will return without inserting
    bpf prog info node into perf env again due to a duplicate bpf prog info
    node insertion, causing the temporary info_linear and info_node memory to
    leak. Modify the return type of this function to bool and add a check to
    ensure the memory is freed if the function returns false.
    
    Fixes: 606f972b1361f477 ("perf bpf: Save bpf_prog_info information as headers to perf.data")
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@linaro.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <song@kernel.org>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20241205084500.823660-3-quic_zhonhan@quicinc.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f2582dacad498beb2759f4755d51860b862563a
Author: Zhongqiu Han <quic_zhonhan@quicinc.com>
Date:   Thu Dec 5 16:44:58 2024 +0800

    perf header: Fix one memory leakage in process_bpf_btf()
    
    [ Upstream commit 875d22980a062521beed7b5df71fb13a1af15d83 ]
    
    If __perf_env__insert_btf() returns false due to a duplicate btf node
    insertion, the temporary node will leak. Add a check to ensure the memory
    is freed if the function returns false.
    
    Fixes: a70a1123174ab592 ("perf bpf: Save BTF information as headers to perf.data")
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@linaro.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <song@kernel.org>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20241205084500.823660-2-quic_zhonhan@quicinc.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3885a4d4a5195a6519fc8db5fc47f889503e2cfd
Author: Gaurav Jain <gaurav.jain@nxp.com>
Date:   Tue Nov 26 12:16:07 2024 +0530

    crypto: caam - use JobR's space to access page 0 regs
    
    [ Upstream commit 73a7496c218b7ca19ba276f54758e7f0adf269c5 ]
    
    On iMX8DXL/QM/QXP(SECO) & iMX8ULP(ELE) SoCs, access to controller
    region(CAAM page 0) is not permitted from non secure world.
    use JobR's register space to access page 0 registers.
    
    Fixes: 6a83830f649a ("crypto: caam - warn if blob_gen key is insecure")
    Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
    Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2a5487487bd91c06c2cf90d9783b025bc192b44
Author: Saket Kumar Bhaskar <skb99@linux.ibm.com>
Date:   Mon Dec 9 12:27:20 2024 +0530

    selftests/bpf: Fix fill_link_info selftest on powerpc
    
    [ Upstream commit 4d33dc1bc31df80356c49e40dbd3ddff19500bcb ]
    
    With CONFIG_KPROBES_ON_FTRACE enabled on powerpc, ftrace_location_range
    returns ftrace location for bpf_fentry_test1 at offset of 4 bytes from
    function entry. This is because branch to _mcount function is at offset
    of 4 bytes in function profile sequence.
    
    To fix this, add entry_offset of 4 bytes while verifying the address for
    kprobe entry address of bpf_fentry_test1 in verify_perf_link_info in
    selftest, when CONFIG_KPROBES_ON_FTRACE is enabled.
    
    Disassemble of bpf_fentry_test1:
    
    c000000000e4b080 <bpf_fentry_test1>:
    c000000000e4b080:       a6 02 08 7c     mflr    r0
    c000000000e4b084:       b9 e2 22 4b     bl      c00000000007933c <_mcount>
    c000000000e4b088:       01 00 63 38     addi    r3,r3,1
    c000000000e4b08c:       b4 07 63 7c     extsw   r3,r3
    c000000000e4b090:       20 00 80 4e     blr
    
    When CONFIG_PPC_FTRACE_OUT_OF_LINE [1] is enabled, these function profile
    sequence is moved out of line with an unconditional branch at offset 0.
    So, the test works without altering the offset for
    'CONFIG_KPROBES_ON_FTRACE && CONFIG_PPC_FTRACE_OUT_OF_LINE' case.
    
    Disassemble of bpf_fentry_test1:
    
    c000000000f95190 <bpf_fentry_test1>:
    c000000000f95190:       00 00 00 60     nop
    c000000000f95194:       01 00 63 38     addi    r3,r3,1
    c000000000f95198:       b4 07 63 7c     extsw   r3,r3
    c000000000f9519c:       20 00 80 4e     blr
    
    [1] https://lore.kernel.org/all/20241030070850.1361304-13-hbathini@linux.ibm.com/
    
    Fixes: 23cf7aa539dc ("selftests/bpf: Add selftest for fill_link_info")
    Signed-off-by: Saket Kumar Bhaskar <skb99@linux.ibm.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20241209065720.234344-1-skb99@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 557065f0a493aeab7ecbe1e818229d628bcad201
Author: George Lander <lander@jagmn.com>
Date:   Mon Nov 11 17:55:29 2024 +0100

    ASoC: sun4i-spdif: Add clock multiplier settings
    
    [ Upstream commit 0a2319308de88b9e819c0b43d0fccd857123eb31 ]
    
    There have been intermittent issues with the SPDIF output on H3
    and H2+ devices which has been fixed by setting the s_clk to 4
    times the audio pll.
    Add a quirk for the clock multiplier as not every supported SoC
    requires it. Without the multiplier, the audio at normal sampling
    rates was distorted and did not play at higher sampling rates.
    
    Fixes: 1bd92af877ab ("ASoC: sun4i-spdif: Add support for the H3 SoC")
    Signed-off-by: George Lander <lander@jagmn.com>
    Signed-off-by: Marcus Cooper <codekipper@gmail.com>
    Link: https://patch.msgid.link/20241111165600.57219-2-codekipper@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccb01198f01d9d085689f7e66d402877b6d49d31
Author: Quentin Monnet <qmo@kernel.org>
Date:   Thu Dec 5 13:59:42 2024 +0000

    libbpf: Fix segfault due to libelf functions not setting errno
    
    [ Upstream commit e10500b69c3f3378f3dcfc8c2fe4cdb74fc844f5 ]
    
    Libelf functions do not set errno on failure. Instead, it relies on its
    internal _elf_errno value, that can be retrieved via elf_errno (or the
    corresponding message via elf_errmsg()). From "man libelf":
    
        If a libelf function encounters an error it will set an internal
        error code that can be retrieved with elf_errno. Each thread
        maintains its own separate error code. The meaning of each error
        code can be determined with elf_errmsg, which returns a string
        describing the error.
    
    As a consequence, libbpf should not return -errno when a function from
    libelf fails, because an empty value will not be interpreted as an error
    and won't prevent the program to stop. This is visible in
    bpf_linker__add_file(), for example, where we call a succession of
    functions that rely on libelf:
    
        err = err ?: linker_load_obj_file(linker, filename, opts, &obj);
        err = err ?: linker_append_sec_data(linker, &obj);
        err = err ?: linker_append_elf_syms(linker, &obj);
        err = err ?: linker_append_elf_relos(linker, &obj);
        err = err ?: linker_append_btf(linker, &obj);
        err = err ?: linker_append_btf_ext(linker, &obj);
    
    If the object file that we try to process is not, in fact, a correct
    object file, linker_load_obj_file() may fail with errno not being set,
    and return 0. In this case we attempt to run linker_append_elf_sysms()
    and may segfault.
    
    This can happen (and was discovered) with bpftool:
    
        $ bpftool gen object output.o sample_ret0.bpf.c
        libbpf: failed to get ELF header for sample_ret0.bpf.c: invalid `Elf' handle
        zsh: segmentation fault (core dumped)  bpftool gen object output.o sample_ret0.bpf.c
    
    Fix the issue by returning a non-null error code (-EINVAL) when libelf
    functions fail.
    
    Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs")
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20241205135942.65262-1-qmo@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d0c37831e28d7d322124043c31df2a300b584f6
Author: Marco Leogrande <leogrande@google.com>
Date:   Mon Dec 2 12:45:30 2024 -0800

    tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind
    
    [ Upstream commit e2f0791124a1b6ca8d570110cbd487969d9d41ef ]
    
    Commit f803bcf9208a ("selftests/bpf: Prevent client connect before
    server bind in test_tc_tunnel.sh") added code that waits for the
    netcat server to start before the netcat client attempts to connect to
    it. However, not all calls to 'server_listen' were guarded.
    
    This patch adds the existing 'wait_for_port' guard after the remaining
    call to 'server_listen'.
    
    Fixes: f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh")
    Signed-off-by: Marco Leogrande <leogrande@google.com>
    Acked-by: Stanislav Fomichev <sdf@fomichev.me>
    Link: https://lore.kernel.org/r/20241202204530.1143448-1-leogrande@google.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3676e57417390c2facae30407f4b71fe68c7abc1
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Nov 21 14:45:58 2024 -0800

    libbpf: don't adjust USDT semaphore address if .stapsdt.base addr is missing
    
    [ Upstream commit 98ebe5ef6f5c4517ba92fb3e56f95827ebea83fd ]
    
    USDT ELF note optionally can record an offset of .stapsdt.base, which is
    used to make adjustments to USDT target attach address. Currently,
    libbpf will do this address adjustment unconditionally if it finds
    .stapsdt.base ELF section in target binary. But there is a corner case
    where .stapsdt.base ELF section is present, but specific USDT note
    doesn't reference it. In such case, libbpf will basically just add base
    address and end up with absolutely incorrect USDT target address.
    
    This adjustment has to be done only if both .stapsdt.sema section is
    present and USDT note is recording a reference to it.
    
    Fixes: 74cc6311cec9 ("libbpf: Add USDT notes parsing and resolution logic")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20241121224558.796110-1-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 352daa50946c3bbb662432e8daf54d6760796589
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Wed Jan 15 08:42:20 2025 -0800

    net/rose: prevent integer overflows in rose_setsockopt()
    
    [ Upstream commit d640627663bfe7d8963c7615316d7d4ef60f3b0b ]
    
    In case of possible unpredictably large arguments passed to
    rose_setsockopt() and multiplied by extra values on top of that,
    integer overflows may occur.
    
    Do the safest minimum and fix these issues by checking the
    contents of 'opt' and returning -EINVAL if they are too large. Also,
    switch to unsigned int and remove useless check for negative 'opt'
    in ROSE_IDLE case.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://patch.msgid.link/20250115164220.19954-1-n.zhandarovich@fintech.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 617d7308bd3865545291624924cf6caa3d51aeb0
Author: Mahdi Arghavani <ma.arghavani@yahoo.com>
Date:   Fri Jan 17 21:37:51 2025 +0000

    tcp_cubic: fix incorrect HyStart round start detection
    
    [ Upstream commit 25c1a9ca53db5780757e7f53e688b8f916821baa ]
    
    I noticed that HyStart incorrectly marks the start of rounds,
    leading to inaccurate measurements of ACK train lengths and
    resetting the `ca->sample_cnt` variable. This inaccuracy can impact
    HyStart's functionality in terminating exponential cwnd growth during
    Slow-Start, potentially degrading TCP performance.
    
    The issue arises because the changes introduced in commit 4e1fddc98d25
    ("tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows")
    moved the caller of the `bictcp_hystart_reset` function inside the `hystart_update` function.
    This modification added an additional condition for triggering the caller,
    requiring that (tcp_snd_cwnd(tp) >= hystart_low_window) must also
    be satisfied before invoking `bictcp_hystart_reset`.
    
    This fix ensures that `bictcp_hystart_reset` is correctly called
    at the start of a new round, regardless of the congestion window size.
    This is achieved by moving the condition
    (tcp_snd_cwnd(tp) >= hystart_low_window)
    from before calling `bictcp_hystart_reset` to after it.
    
    I tested with a client and a server connected through two Linux software routers.
    In this setup, the minimum RTT was 150 ms, the bottleneck bandwidth was 50 Mbps,
    and the bottleneck buffer size was 1 BDP, calculated as (50M / 1514 / 8) * 0.150 = 619 packets.
    I conducted the test twice, transferring data from the server to the client for 1.5 seconds.
    Before the patch was applied, HYSTART-DELAY stopped the exponential growth of cwnd when
    cwnd = 516, and the bottleneck link was not yet saturated (516 < 619).
    After the patch was applied, HYSTART-ACK-TRAIN stopped the exponential growth of cwnd when
    cwnd = 632, and the bottleneck link was saturated (632 > 619).
    In this test, applying the patch resulted in 300 KB more data delivered.
    
    Fixes: 4e1fddc98d25 ("tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows")
    Signed-off-by: Mahdi Arghavani <ma.arghavani@yahoo.com>
    Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Haibo Zhang <haibo.zhang@otago.ac.nz>
    Cc: David Eyers <david.eyers@otago.ac.nz>
    Cc: Abbas Arghavani <abbas.arghavani@mdu.se>
    Reviewed-by: Neal Cardwell <ncardwell@google.com>
    Tested-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88fd5db8c0073bd91d18391feb5741aeb0a2b475
Author: Roger Quadros <rogerq@kernel.org>
Date:   Thu Jan 16 15:54:49 2025 +0200

    net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()
    
    [ Upstream commit 4395a44acb15850e492dd1de9ec4b6479d96bc80 ]
    
    When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns
    negative error value on error. So not NULL check is not sufficient
    to deteremine if IRQ is valid. Check that IRQ is greater then zero
    to ensure it is valid.
    
    There is no issue at probe time but at runtime user can invoke
    .set_channels which results in the following call chain.
    am65_cpsw_set_channels()
     am65_cpsw_nuss_update_tx_rx_chns()
      am65_cpsw_nuss_remove_tx_chns()
      am65_cpsw_nuss_init_tx_chns()
    
    At this point if am65_cpsw_nuss_init_tx_chns() fails due to
    k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a
    negative value.
    
    Then, at subsequent .set_channels with higher channel count we
    will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()
    leading to a kernel warning.
    
    The issue is present in the original commit that introduced this driver,
    although there, am65_cpsw_nuss_update_tx_rx_chns() existed as
    am65_cpsw_nuss_update_tx_chns().
    
    Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
    Signed-off-by: Roger Quadros <rogerq@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3c1a0e4ba0a0b56adbf743748bb70ba8dd76096
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jan 14 00:50:34 2025 +0100

    netfilter: nft_flow_offload: update tcp state flags under lock
    
    [ Upstream commit 7a4b61406395291ffb7220a10e8951a9a8684819 ]
    
    The conntrack entry is already public, there is a small chance that another
    CPU is handling a packet in reply direction and racing with the tcp state
    update.
    
    Move this under ct spinlock.
    
    This is done once, when ct is about to be offloaded, so this should
    not result in a noticeable performance hit.
    
    Fixes: 8437a6209f76 ("netfilter: nft_flow_offload: set liberal tracking mode for tcp")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9aaae892d467a15c5eca7ef40f9f93075b5c9fc
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jan 6 23:40:50 2025 +0100

    netfilter: nf_tables: fix set size with rbtree backend
    
    [ Upstream commit 8d738c1869f611955d91d8d0fd0012d9ef207201 ]
    
    The existing rbtree implementation uses singleton elements to represent
    ranges, however, userspace provides a set size according to the number
    of ranges in the set.
    
    Adjust provided userspace set size to the number of singleton elements
    in the kernel by multiplying the range by two.
    
    Check if the no-match all-zero element is already in the set, in such
    case release one slot in the set size.
    
    Fixes: 0ed6389c483d ("netfilter: nf_tables: rename set implementations")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c80fcb6caa9bfca2486e2b66b54786089f203afc
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Oct 13 14:18:16 2023 +0200

    netfilter: nft_set_rbtree: prefer sync gc to async worker
    
    [ Upstream commit 7d259f021aaa78904b6c836d975e8e00d83a182a ]
    
    There is no need for asynchronous garbage collection, rbtree inserts
    can only happen from the netlink control plane.
    
    We already perform on-demand gc on insertion, in the area of the
    tree where the insertion takes place, but we don't do a full tree
    walk there for performance reasons.
    
    Do a full gc walk at the end of the transaction instead and
    remove the async worker.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: 8d738c1869f6 ("netfilter: nf_tables: fix set size with rbtree backend")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7e81ae38643490b1775385cd200ede088ad463a
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Oct 13 14:18:15 2023 +0200

    netfilter: nft_set_rbtree: rename gc deactivate+erase function
    
    [ Upstream commit 8079fc30f79799e59d9602e7e080d434936a482d ]
    
    Next patch adds a cllaer that doesn't hold the priv->write lock and
    will need a similar function.
    
    Rename the existing function to make it clear that it can only
    be used for opportunistic gc during insertion.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: 8d738c1869f6 ("netfilter: nf_tables: fix set size with rbtree backend")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f8277b97ad4caca66c3cd879987c5b178217cb9
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Oct 13 14:18:14 2023 +0200

    netfilter: nf_tables: de-constify set commit ops function argument
    
    [ Upstream commit 256001672153af5786c6ca148114693d7d76d836 ]
    
    The set backend using this already has to work around this via ugly
    cast, don't spread this pattern.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Stable-dep-of: 8d738c1869f6 ("netfilter: nf_tables: fix set size with rbtree backend")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e2bd8c13b07e29a247c023c7444df23f9a79fd8
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Wed Jan 15 17:37:13 2025 -0800

    net: sched: Disallow replacing of child qdisc from one parent to another
    
    [ Upstream commit bc50835e83f60f56e9bec2b392fb5544f250fb6f ]
    
    Lion Ackermann was able to create a UAF which can be abused for privilege
    escalation with the following script
    
    Step 1. create root qdisc
    tc qdisc add dev lo root handle 1:0 drr
    
    step2. a class for packet aggregation do demonstrate uaf
    tc class add dev lo classid 1:1 drr
    
    step3. a class for nesting
    tc class add dev lo classid 1:2 drr
    
    step4. a class to graft qdisc to
    tc class add dev lo classid 1:3 drr
    
    step5.
    tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024
    
    step6.
    tc qdisc add dev lo parent 1:2 handle 3:0 drr
    
    step7.
    tc class add dev lo classid 3:1 drr
    
    step 8.
    tc qdisc add dev lo parent 3:1 handle 4:0 pfifo
    
    step 9. Display the class/qdisc layout
    
    tc class ls dev lo
     class drr 1:1 root leaf 2: quantum 64Kb
     class drr 1:2 root leaf 3: quantum 64Kb
     class drr 3:1 root leaf 4: quantum 64Kb
    
    tc qdisc ls
     qdisc drr 1: dev lo root refcnt 2
     qdisc plug 2: dev lo parent 1:1
     qdisc pfifo 4: dev lo parent 3:1 limit 1000p
     qdisc drr 3: dev lo parent 1:2
    
    step10. trigger the bug <=== prevented by this patch
    tc qdisc replace dev lo parent 1:3 handle 4:0
    
    step 11. Redisplay again the qdiscs/classes
    
    tc class ls dev lo
     class drr 1:1 root leaf 2: quantum 64Kb
     class drr 1:2 root leaf 3: quantum 64Kb
     class drr 1:3 root leaf 4: quantum 64Kb
     class drr 3:1 root leaf 4: quantum 64Kb
    
    tc qdisc ls
     qdisc drr 1: dev lo root refcnt 2
     qdisc plug 2: dev lo parent 1:1
     qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p
     qdisc drr 3: dev lo parent 1:2
    
    Observe that a) parent for 4:0 does not change despite the replace request.
    There can only be one parent.  b) refcount has gone up by two for 4:0 and
    c) both class 1:3 and 3:1 are pointing to it.
    
    Step 12.  send one packet to plug
    echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))
    step13.  send one packet to the grafted fifo
    echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))
    
    step14. lets trigger the uaf
    tc class delete dev lo classid 1:3
    tc class delete dev lo classid 1:1
    
    The semantics of "replace" is for a del/add _on the same node_ and not
    a delete from one node(3:1) and add to another node (1:3) as in step10.
    While we could "fix" with a more complex approach there could be
    consequences to expectations so the patch takes the preventive approach of
    "disallow such config".
    
    Joint work with Lion Ackermann <nnamrec@gmail.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250116013713.900000-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f29127e94ae9fdc7497331003d6860e9551cdf3
Author: Antoine Tenart <atenart@kernel.org>
Date:   Thu Jan 16 10:21:57 2025 +0100

    net: avoid race between device unregistration and ethnl ops
    
    [ Upstream commit 12e070eb6964b341b41677fd260af5a305316a1f ]
    
    The following trace can be seen if a device is being unregistered while
    its number of channels are being modified.
    
      DEBUG_LOCKS_WARN_ON(lock->magic != lock)
      WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
      CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
      RIP: 0010:__mutex_lock+0xc8a/0x1120
      Call Trace:
       <TASK>
       ethtool_check_max_channel+0x1ea/0x880
       ethnl_set_channels+0x3c3/0xb10
       ethnl_default_set_doit+0x306/0x650
       genl_family_rcv_msg_doit+0x1e3/0x2c0
       genl_rcv_msg+0x432/0x6f0
       netlink_rcv_skb+0x13d/0x3b0
       genl_rcv+0x28/0x40
       netlink_unicast+0x42e/0x720
       netlink_sendmsg+0x765/0xc20
       __sys_sendto+0x3ac/0x420
       __x64_sys_sendto+0xe0/0x1c0
       do_syscall_64+0x95/0x180
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    This is because unregister_netdevice_many_notify might run before the
    rtnl lock section of ethnl operations, eg. set_channels in the above
    example. In this example the rss lock would be destroyed by the device
    unregistration path before being used again, but in general running
    ethnl operations while dismantle has started is not a good idea.
    
    Fix this by denying any operation on devices being unregistered. A check
    was already there in ethnl_ops_begin, but not wide enough.
    
    Note that the same issue cannot be seen on the ioctl version
    (__dev_ethtool) because the device reference is retrieved from within
    the rtnl lock section there. Once dismantle started, the net device is
    unlisted and no reference will be found.
    
    Fixes: dde91ccfa25f ("ethtool: do not perform operations on net devices being unregistered")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
    Link: https://patch.msgid.link/20250116092159.50890-1-atenart@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9ad8c9289219d0966688141938772566c91cd52
Author: Shinas Rasheed <srasheed@marvell.com>
Date:   Fri Jan 17 01:46:50 2025 -0800

    octeon_ep: remove firmware stats fetch in ndo_get_stats64
    
    [ Upstream commit 1f64255bb76c11d0c41a7d81d7cec68e49d5362d ]
    
    The firmware stats fetch call that happens in ndo_get_stats64()
    is currently not required, and causes a warning to issue.
    
    The warn log is given below:
    
    [  123.316837] ------------[ cut here ]------------
    [  123.316840] Voluntary context switch within RCU read-side critical section!
    [  123.316917] pc : rcu_note_context_switch+0x2e4/0x300
    [  123.316919] lr : rcu_note_context_switch+0x2e4/0x300
    [  123.316947] Call trace:
    [  123.316949]  rcu_note_context_switch+0x2e4/0x300
    [  123.316952]  __schedule+0x84/0x584
    [  123.316955]  schedule+0x38/0x90
    [  123.316956]  schedule_timeout+0xa0/0x1d4
    [  123.316959]  octep_send_mbox_req+0x190/0x230 [octeon_ep]
    [  123.316966]  octep_ctrl_net_get_if_stats+0x78/0x100 [octeon_ep]
    [  123.316970]  octep_get_stats64+0xd4/0xf0 [octeon_ep]
    [  123.316975]  dev_get_stats+0x4c/0x114
    [  123.316977]  dev_seq_printf_stats+0x3c/0x11c
    [  123.316980]  dev_seq_show+0x1c/0x40
    [  123.316982]  seq_read_iter+0x3cc/0x4e0
    [  123.316985]  seq_read+0xc8/0x110
    [  123.316987]  proc_reg_read+0x9c/0xec
    [  123.316990]  vfs_read+0xc8/0x2ec
    [  123.316993]  ksys_read+0x70/0x100
    [  123.316995]  __arm64_sys_read+0x20/0x30
    [  123.316997]  invoke_syscall.constprop.0+0x7c/0xd0
    [  123.317000]  do_el0_svc+0xb4/0xd0
    [  123.317002]  el0_svc+0xe8/0x1f4
    [  123.317005]  el0t_64_sync_handler+0x134/0x150
    [  123.317006]  el0t_64_sync+0x17c/0x180
    [  123.317008] ---[ end trace 63399811432ab69b ]---
    
    Fixes: 6a610a46bad1 ("octeon_ep: add support for ndo ops")
    Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
    Link: https://patch.msgid.link/20250117094653.2588578-2-srasheed@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf7d4b9ca534cad4a86c774a5b97193be5526394
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Thu Jan 16 14:33:16 2025 +0200

    net/mlxfw: Drop hard coded max FW flash image size
    
    [ Upstream commit 70d81f25cc92cc4e914516c9935ae752f27d78ad ]
    
    Currently, mlxfw kernel module limits FW flash image size to be
    10MB at most, preventing the ability to burn recent BlueField-3
    FW that exceeds the said size limit.
    
    Thus, drop the hard coded limit. Instead, rely on FW's
    max_component_size threshold that is reported in MCQI register
    as the size limit for FW image.
    
    Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process")
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Link: https://patch.msgid.link/1737030796-1441634-1-git-send-email-moshe@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ce38b5a6a49e65bad163162a54cb3f104c40b48
Author: Liu Jian <liujian56@huawei.com>
Date:   Thu Jan 16 22:30:53 2025 +0800

    net: let net.core.dev_weight always be non-zero
    
    [ Upstream commit d1f9f79fa2af8e3b45cffdeef66e05833480148a ]
    
    The following problem was encountered during stability test:
    
    (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \
            returned 1, exceeding its budget of 0.
    ------------[ cut here ]------------
    list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \
            next=ffff88905f746e40.
    WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \
            __list_add_valid_or_report+0xf3/0x130
    CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+
    RIP: 0010:__list_add_valid_or_report+0xf3/0x130
    Call Trace:
    ? __warn+0xcd/0x250
    ? __list_add_valid_or_report+0xf3/0x130
    enqueue_to_backlog+0x923/0x1070
    netif_rx_internal+0x92/0x2b0
    __netif_rx+0x15/0x170
    loopback_xmit+0x2ef/0x450
    dev_hard_start_xmit+0x103/0x490
    __dev_queue_xmit+0xeac/0x1950
    ip_finish_output2+0x6cc/0x1620
    ip_output+0x161/0x270
    ip_push_pending_frames+0x155/0x1a0
    raw_sendmsg+0xe13/0x1550
    __sys_sendto+0x3bf/0x4e0
    __x64_sys_sendto+0xdc/0x1b0
    do_syscall_64+0x5b/0x170
    entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    The reproduction command is as follows:
      sysctl -w net.core.dev_weight=0
      ping 127.0.0.1
    
    This is because when the napi's weight is set to 0, process_backlog() may
    return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this
    napi to be re-polled in net_rx_action() until __do_softirq() times out.
    Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can
    be retriggered in enqueue_to_backlog(), causing this issue.
    
    Making the napi's weight always non-zero solves this problem.
    
    Triggering this issue requires system-wide admin (setting is
    not namespaced).
    
    Fixes: e38766054509 ("[NET]: Fix sysctl net.core.dev_weight")
    Fixes: 3d48b53fb2ae ("net: dev_weight: TX/RX orthogonality")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Link: https://patch.msgid.link/20250116143053.4146855-1-liujian56@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 627f67b6d0999361abcfd5514f731070da93f6fd
Author: Mickaël Salaün <mic@digikod.net>
Date:   Wed Jan 8 16:43:28 2025 +0100

    selftests/landlock: Fix error message
    
    [ Upstream commit 2107c35128ad751b201eb92fe91443450d9e5c37 ]
    
    The global variable errno may not be set in test_execute().  Do not use
    it in related error message.
    
    Cc: Günther Noack <gnoack@google.com>
    Fixes: e1199815b47b ("selftests/landlock: Add user space tests")
    Link: https://lore.kernel.org/r/20250108154338.1129069-21-mic@digikod.net
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7efca80bdecaff7aac710a0cd508670181e0366
Author: Mingwei Zheng <zmw12306@gmail.com>
Date:   Sun Dec 15 17:47:52 2024 -0500

    pwm: stm32: Add check for clk_enable()
    
    [ Upstream commit e8c59791ebb60790c74b2c3ab520f04a8a57219a ]
    
    Add check for the return value of clk_enable() to catch the potential
    error.
    
    Fixes: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()")
    Signed-off-by: Mingwei Zheng <zmw12306@gmail.com>
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Link: https://lore.kernel.org/r/20241215224752.220318-1-zmw12306@gmail.com
    Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8e33f0a3c86795f6d7542df953616d9c6da4581
Author: Bo Gan <ganboing@gmail.com>
Date:   Thu Aug 29 23:16:39 2024 -0700

    clk: analogbits: Fix incorrect calculation of vco rate delta
    
    [ Upstream commit d7f12857f095ef38523399d47e68787b357232f6 ]
    
    In wrpll_configure_for_rate() we try to determine the best PLL
    configuration for a target rate. However, in the loop where we try
    values of R, we should compare the derived `vco` with `target_vco_rate`.
    However, we were in fact comparing it with `target_rate`, which is
    actually after Q shift. This is incorrect, and sometimes can result in
    suboptimal clock rates. Fix it.
    
    Fixes: 7b9487a9a5c4 ("clk: analogbits: add Wide-Range PLL library")
    Signed-off-by: Bo Gan <ganboing@gmail.com>
    Link: https://lore.kernel.org/r/20240830061639.2316-1-ganboing@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5960f4d87398e4683b701f1c5cd1d767dc61a9e9
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 14 22:10:49 2025 +0000

    inet: ipmr: fix data-races
    
    [ Upstream commit 3440fa34ad99d471f1085bc2f4dedeaebc310261 ]
    
    Following fields of 'struct mr_mfc' can be updated
    concurrently (no lock protection) from ip_mr_forward()
    and ip6_mr_forward()
    
    - bytes
    - pkt
    - wrong_if
    - lastuse
    
    They also can be read from other functions.
    
    Convert bytes, pkt and wrong_if to atomic_long_t,
    and use READ_ONCE()/WRITE_ONCE() for lastuse.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20250114221049.1190631-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c73ffb62422415c8b9d5e51349ed5bbd0f60636
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Mon Jan 13 18:54:17 2025 +0300

    wifi: cfg80211: adjust allocation of colocated AP data
    
    [ Upstream commit 1a0d24775cdee2b8dc14bfa4f4418c930ab1ac57 ]
    
    In 'cfg80211_scan_6ghz()', an instances of 'struct cfg80211_colocated_ap'
    are allocated as if they would have 'ssid' as trailing VLA member. Since
    this is not so, extra IEEE80211_MAX_SSID_LEN bytes are not needed.
    Briefly tested with KUnit.
    
    Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Link: https://patch.msgid.link/20250113155417.552587-1-dmantipov@yandex.ru
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1138cf80bbbf42efce1066381bab2b15f6517c28
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Thu Sep 28 17:35:30 2023 +0300

    wifi: cfg80211: Handle specific BSSID in 6GHz scanning
    
    [ Upstream commit 0fca7784b7a14d4ede64f479662afb98876ec7f8 ]
    
    When the scan parameters for a 6GHz scan specify a unicast
    BSSID address, and the corresponding AP is found in the scan
    list, add a corresponding entry in the collocated AP list,
    so this AP would be directly probed even if it was not
    advertised as a collocated AP.
    
    This is needed for handling a scan request that is intended
    for a ML probe flow, where user space can requests a scan
    to retrieve information for other links in the AP MLD.
    
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230928172905.54b954bc02ad.I1c072793d3d77a4c8fbbc64b4db5cce1bbb00382@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: 1a0d24775cde ("wifi: cfg80211: adjust allocation of colocated AP data")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c23036b53a0feb47e08d13c971e71055f8e4f20
Author: Dmitry V. Levin <ldv@strace.io>
Date:   Wed Jan 8 19:07:57 2025 +0200

    selftests: harness: fix printing of mismatch values in __EXPECT()
    
    [ Upstream commit 02bc220dc6dc7c56edc4859bc5dd2c08b95d5fb5 ]
    
    intptr_t and uintptr_t are not big enough types on 32-bit architectures
    when printing 64-bit values, resulting to the following incorrect
    diagnostic output:
    
      # get_syscall_info.c:209:get_syscall_info:Expected exp_args[2] (3134324433) == info.entry.args[1] (3134324433)
    
    Replace intptr_t and uintptr_t with intmax_t and uintmax_t, respectively.
    With this fix, the same test produces more usable diagnostic output:
    
      # get_syscall_info.c:209:get_syscall_info:Expected exp_args[2] (3134324433) == info.entry.args[1] (18446744072548908753)
    
    Link: https://lore.kernel.org/r/20250108170757.GA6723@strace.io
    Fixes: b5bb6d3068ea ("selftests/seccomp: fix 32-bit build warnings")
    Signed-off-by: Dmitry V. Levin <ldv@strace.io>
    Reviewed-by: Kees Cook <kees@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e75ae3db46b552dd04f54b29c53290b140b78690
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Dec 12 10:02:56 2024 +0100

    selftests: timers: clocksource-switch: Adapt progress to kselftest framework
    
    [ Upstream commit 8694e6a7f7dba23d3abd9f5a96f64d161704c7b1 ]
    
    When adapting the test to the kselftest framework, a few printf() calls
    indicating test progress were not updated.
    
    Fix this by replacing these printf() calls by ksft_print_msg() calls.
    
    Link: https://lore.kernel.org/r/7dd4b9ab6e43268846e250878ebf25ae6d3d01ce.1733994134.git.geert+renesas@glider.be
    Fixes: ce7d101750ff ("selftests: timers: clocksource-switch: adapt to kselftest framework")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc343336b7c06340f6c7532bf3d94ffcd3bbed7a
Author: Gautham R. Shenoy <gautham.shenoy@amd.com>
Date:   Mon Jan 13 10:11:07 2025 +0530

    cpufreq: ACPI: Fix max-frequency computation
    
    [ Upstream commit 0834667545962ef1c5e8684ed32b45d9c574acd3 ]
    
    Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover
    boost frequencies") introduced an assumption in acpi_cpufreq_cpu_init()
    that the first entry in the P-state table was the nominal frequency.
    This assumption is incorrect. The frequency corresponding to the P0
    P-State need not be the same as the nominal frequency advertised via
    CPPC.
    
    Since the driver is using the CPPC.highest_perf and CPPC.nominal_perf
    to compute the boost-ratio, it makes sense to use CPPC.nominal_freq to
    compute the max-frequency. CPPC.nominal_freq is advertised on
    platforms supporting CPPC revisions 3 or higher.
    
    Hence, fallback to using the first entry in the P-State table only on
    platforms that do not advertise CPPC.nominal_freq.
    
    Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
    Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
    Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://patch.msgid.link/20250113044107.566-1-gautham.shenoy@amd.com
    [ rjw: Retain reverse X-mas tree ordering of local variable declarations ]
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f97a0b96e14da5b9774e0e46282624c8b548800
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Tue Jan 14 18:10:24 2025 +0800

    wifi: mt76: mt7996: fix ldpc setting
    
    [ Upstream commit da8352da1e4f476fdbf549a4efce4f3c618fde3b ]
    
    The non-AP interfaces would not use conf->vht_ldpc so they never set
    STA_CAP_VHT_LDPC even if peer-station support LDPC.
    Check conf->vht_ldpc only for AP interface.
    
    Without this patch, station only uses BCC to transmit packet in VHT mode.
    
    Fixes: dda423dd65c3 ("wifi: mt76: mt7996: remove mt7996_mcu_beacon_check_caps()")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Link: https://patch.msgid.link/20250114101026.3587702-7-shayne.chen@mediatek.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fd26afa1da98a4e5f5d21d388a2d19723bede04
Author: Benjamin Lin <benjamin-jw.lin@mediatek.com>
Date:   Tue Jan 14 18:10:21 2025 +0800

    wifi: mt76: mt7996: fix incorrect indexing of MIB FW event
    
    [ Upstream commit 5c2a25a1ab76a2976dddc5ffd58498866f3ef7c2 ]
    
    Fix wrong calculation of the channel times due to incorrect
    interpretation from the FW event.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Benjamin Lin <benjamin-jw.lin@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Link: https://patch.msgid.link/20250114101026.3587702-4-shayne.chen@mediatek.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9288a136a0a713c8de298da75a59c1ef6e90483
Author: Howard Hsu <howard-yh.hsu@mediatek.com>
Date:   Tue Jan 14 18:10:20 2025 +0800

    wifi: mt76: mt7996: fix HE Phy capability
    
    [ Upstream commit 7e3aef59a403ade5dd4ea02edc2d7138a66d74b6 ]
    
    Set HE SU PPDU And HE MU PPDU With 4x HE-LTF And 0.8 us GI within HE PHY
    Capabilities element as 1 since hardware can support.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Link: https://patch.msgid.link/20250114101026.3587702-3-shayne.chen@mediatek.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b20cda1df8ba6a266bbf6afea20ab02353b5cdba
Author: Howard Hsu <howard-yh.hsu@mediatek.com>
Date:   Tue Jan 14 18:10:19 2025 +0800

    wifi: mt76: mt7996: fix the capability of reception of EHT MU PPDU
    
    [ Upstream commit 2ffbdfc1bd78ba944c5754791c84f32232b513c6 ]
    
    This commit includes two changes. First, enable "EHT MU PPDU With 4x
    EHT-LTF And 0.8us GI" in EHT Phy capabilities element since hardware
    can support. Second, fix the value of "Maximum number of supported
    EHT LTFs" in the same element, where the previous setting of 3 in
    Bit 3-4 was incorrect.
    
    Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init")
    Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Link: https://patch.msgid.link/20250114101026.3587702-2-shayne.chen@mediatek.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 566b749f0d64543b8ab530c756e7dae555b0ed07
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Tue Jan 14 18:10:18 2025 +0800

    wifi: mt76: mt7996: add max mpdu len capability
    
    [ Upstream commit 1816ad9381e0c150e4c44ce6dd6ee2c52008a052 ]
    
    Set max mpdu len to 11454 according to hardware capability.
    Without this patch, the max ampdu length would be 3895 and count not get
    expected performance.
    
    Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Link: https://patch.msgid.link/20250114101026.3587702-1-shayne.chen@mediatek.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d6961b573655d1632c9124cdc7f8cddbc240149
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Thu Jan 9 19:04:36 2025 +0800

    wifi: mt76: mt7996: fix register mapping
    
    [ Upstream commit d07ecb4f7070e84de49e8fa4e5a83dd52716d805 ]
    
    Bypass the entry when ofs is equal to dev->reg.map[i].size.
    Without this patch, it would get incorrect register mapping when the CR
    address is located at the boundary of an entry.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
    Link: https://patch.msgid.link/OSZPR01MB84344FEFF53004B5CF40BCC198132@OSZPR01MB8434.jpnprd01.prod.outlook.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59e4ebeb43f2814135d7ab8f83e3148e36bb61b6
Author: Peter Chiu <chui-hao.chiu@mediatek.com>
Date:   Thu Jan 9 19:04:35 2025 +0800

    wifi: mt76: mt7915: fix register mapping
    
    [ Upstream commit dd1649ef966bb87053c17385ea2cfd1758f5385b ]
    
    Bypass the entry when ofs is equal to dev->reg.map[i].size.
    Without this patch, it would get incorrect register mapping when the CR
    address is located at the boundary of an entry.
    
    Fixes: cd4c314a65d3 ("mt76: mt7915: refine register definition")
    Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
    Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
    Link: https://patch.msgid.link/OSZPR01MB843401EAA1DA6BD7AEF356F298132@OSZPR01MB8434.jpnprd01.prod.outlook.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e474cbe5db60793ef6628e3191db9e48c6c4f48
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Dec 30 20:42:00 2024 +0100

    wifi: mt76: mt7915: fix omac index assignment after hardware reset
    
    [ Upstream commit cd043bbba6f9b71ebe0781d1bd2107565363c4b9 ]
    
    Reset per-phy mac address slot mask in order to avoid leaking entries.
    
    Fixes: 8a55712d124f ("wifi: mt76: mt7915: enable full system reset support")
    Link: https://patch.msgid.link/20241230194202.95065-12-nbd@nbd.name
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c71d2db21f1532128b6ee110bcfad8fe6ef47dc3
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue Aug 27 11:30:06 2024 +0200

    wifi: mt76: mt7915: improve hardware restart reliability
    
    [ Upstream commit 328e35c7bfc673cde5a3a453318d044f8f83b505 ]
    
    - use reconfig_complete to restart mac_work / queues
    - reset full wtbl after firmware init
    - clear wcid and vif mask to avoid leak
    - fix sta poll list corruption
    
    Link: https://patch.msgid.link/20240827093011.18621-19-nbd@nbd.name
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Stable-dep-of: cd043bbba6f9 ("wifi: mt76: mt7915: fix omac index assignment after hardware reset")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d19f26ecf26c079ea4dad6aecd5c052b1ed2f9b
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue Aug 27 11:30:05 2024 +0200

    wifi: mt76: connac: move mt7615_mcu_del_wtbl_all to connac
    
    [ Upstream commit b2141eadf8be6285ff8980cab153079231cab4fd ]
    
    Preparation for reusing it in mt7915
    
    Link: https://patch.msgid.link/20240827093011.18621-18-nbd@nbd.name
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Stable-dep-of: cd043bbba6f9 ("wifi: mt76: mt7915: fix omac index assignment after hardware reset")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72eabd4c1986ba4fffd165fa75711bf4f23acd99
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Dec 30 20:41:59 2024 +0100

    wifi: mt76: mt7915: firmware restart on devices with a second pcie link
    
    [ Upstream commit 9b60e2ae511c959024ecf6578b3fbe85cd06d7cc ]
    
    It seems that the firmware checks the register used for detecting matching
    PCIe links in order to figure out if a secondary PCIe link is enabled.
    Write the register again just before starting the firmware on hw reset,
    in order to fix an issue that left the second band unusable after restart.
    
    Fixes: 9093cfff72e3 ("mt76: mt7915: add support for using a secondary PCIe link for gen1")
    Link: https://patch.msgid.link/20241230194202.95065-11-nbd@nbd.name
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a249ebfc80e0adc611bbb0da4fee992b76230c8
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Dec 30 20:41:53 2024 +0100

    wifi: mt76: mt7996: fix rx filter setting for bfee functionality
    
    [ Upstream commit 858fd2a53877b2e8b1d991a5a861ac34a0f55ef8 ]
    
    Fix rx filter setting to prevent dropping NDPA frames. Without this
    change, bfee functionality may behave abnormally.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Link: https://patch.msgid.link/20241230194202.95065-5-nbd@nbd.name
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 987e8224da662fbfaccdee158ba8cb2c6cb306f2
Author: xueqin Luo <luoxueqin@kylinos.cn>
Date:   Mon Dec 2 11:19:17 2024 +0800

    wifi: mt76: mt7915: fix overflows seen when writing limit attributes
    
    [ Upstream commit 64d571742b0ae44eee5efd51e2d4a09d7f6782fc ]
    
    DIV_ROUND_CLOSEST() after kstrtoul() results in an overflow if a large
    number such as 18446744073709551615 is provided by the user.
    Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
    This commit was inspired by commit: 57ee12b6c514.
    
    Fixes: 02ee68b95d81 ("mt76: mt7915: add control knobs for thermal throttling")
    Signed-off-by: xueqin Luo <luoxueqin@kylinos.cn>
    Link: https://patch.msgid.link/20241202031917.23741-3-luoxueqin@kylinos.cn
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b823e541dcc1776f39960ac4b7e0536ca1e92cba
Author: Michael Lo <michael.lo@mediatek.com>
Date:   Thu Aug 1 10:43:35 2024 +0800

    wifi: mt76: mt7921: fix using incorrect group cipher after disconnection.
    
    [ Upstream commit aa566ac6b7272e7ea5359cb682bdca36d2fc7e73 ]
    
    To avoid incorrect cipher after disconnection, we should
    do the key deletion process in this case.
    
    Fixes: e6db67fa871d ("wifi: mt76: ignore key disable commands")
    Signed-off-by: Michael Lo <michael.lo@mediatek.com>
    Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
    Tested-by: David Ruth <druth@chromium.org>
    Reviewed-by: David Ruth <druth@chromium.org>
    Link: https://patch.msgid.link/20240801024335.12981-1-mingyen.hsieh@mediatek.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 824813ea30a5e096b0f2f1b1432c5e518aec1e1d
Author: WangYuli <wangyuli@uniontech.com>
Date:   Mon Jan 13 15:02:41 2025 +0800

    wifi: mt76: mt76u_vendor_request: Do not print error messages when -EPROTO
    
    [ Upstream commit f1b1e133a770fcdbd89551651232b034d2f7a27a ]
    
    When initializing the network card, unplugging the device will
    trigger an -EPROTO error, resulting in a flood of error messages
    being printed frantically.
    
    The exception is printed as follows:
    
             mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71
             mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71
             ...
    
    It will continue to print more than 2000 times for about 5 minutes,
    causing the usb device to be unable to be disconnected. During this
    period, the usb port cannot recognize the new device because the old
    device has not disconnected.
    
    There may be other operating methods that cause -EPROTO, but -EPROTO is
    a low-level hardware error. It is unwise to repeat vendor requests
    expecting to read correct data. It is a better choice to treat -EPROTO
    and -ENODEV the same way.
    
    Similar to commit 9b0f100c1970 ("mt76: usb: process URBs with status
    EPROTO properly") do no schedule rx_worker for urb marked with status
    set  -EPROTO. I also reproduced this situation when plugging and
    unplugging the device, and this patch is effective.
    
    Just do not vendor request again for urb marked with status set -EPROTO.
    
    Link: https://lore.kernel.org/all/531681bd-30f5-4a70-a156-bf8754b8e072@intel.com/
    Link: https://lore.kernel.org/all/D4B9CC1FFC0CBAC3+20250105040607.154706-1-wangyuli@uniontech.com/
    Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
    Co-developed-by: Xu Rao <raoxu@uniontech.com>
    Signed-off-by: Xu Rao <raoxu@uniontech.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Link: https://patch.msgid.link/9DD7DE7AAB497CB7+20250113070241.63590-1-wangyuli@uniontech.com
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39bb3d56f1c351e76bb18895d0e73796e653d5c1
Author: Mickaël Salaün <mic@digikod.net>
Date:   Fri Jan 10 16:39:13 2025 +0100

    landlock: Handle weird files
    
    [ Upstream commit 49440290a0935f428a1e43a5ac8dc275a647ff80 ]
    
    A corrupted filesystem (e.g. bcachefs) might return weird files.
    Instead of throwing a warning and allowing access to such file, treat
    them as regular files.
    
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: Paul Moore <paul@paul-moore.com>
    Reported-by: syzbot+34b68f850391452207df@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/r/000000000000a65b35061cffca61@google.com
    Reported-by: syzbot+360866a59e3c80510a62@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/r/67379b3f.050a0220.85a0.0001.GAE@google.com
    Reported-by: Ubisectech Sirius <bugreport@ubisectech.com>
    Closes: https://lore.kernel.org/r/c426821d-8380-46c4-a494-7008bbd7dd13.bugreport@ubisectech.com
    Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control")
    Reviewed-by: Günther Noack <gnoack3000@gmail.com>
    Link: https://lore.kernel.org/r/20250110153918.241810-1-mic@digikod.net
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d433ccd98736fefeeac03ed961acad5543481953
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Date:   Sat Jan 4 22:32:01 2025 +0800

    net/smc: fix data error when recvmsg with MSG_PEEK flag
    
    [ Upstream commit a4b6539038c1aa1ae871aacf6e41b566c3613993 ]
    
    When recvmsg with MSG_PEEK flag, the data will be copied to
    user's buffer without advancing consume cursor and without
    reducing the length of rx available data. Once the expected
    peek length is larger than the value of bytes_to_rcv, in the
    loop of do while in smc_rx_recvmsg, the first loop will copy
    bytes_to_rcv bytes of data from the position local_tx_ctrl.cons,
    the second loop will copy the min(bytes_to_rcv, read_remaining)
    bytes from the position local_tx_ctrl.cons again because of the
    lacking of process with advancing consume cursor and reducing
    the length of available data. So do the subsequent loops. The
    data copied in the second loop and the subsequent loops will
    result in data error, as it should not be copied if no more data
    arrives and it should be copied from the position advancing
    bytes_to_rcv bytes from the local_tx_ctrl.cons if more data arrives.
    
    This issue can be reproduce by the following python script:
    server.py:
    import socket
    import time
    server_ip = '0.0.0.0'
    server_port = 12346
    server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_socket.bind((server_ip, server_port))
    server_socket.listen(1)
    print('Server is running and listening for connections...')
    conn, addr = server_socket.accept()
    print('Connected by', addr)
    while True:
        data = conn.recv(1024)
        if not data:
            break
        print('Received request:', data.decode())
        conn.sendall(b'Hello, client!\n')
        time.sleep(5)
        conn.sendall(b'Hello, again!\n')
    conn.close()
    
    client.py:
    import socket
    server_ip = '<server ip>'
    server_port = 12346
    resp=b'Hello, client!\nHello, again!\n'
    client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client_socket.connect((server_ip, server_port))
    request = 'Hello, server!'
    client_socket.sendall(request.encode())
    peek_data = client_socket.recv(len(resp),
        socket.MSG_PEEK | socket.MSG_WAITALL)
    print('Peeked data:', peek_data.decode())
    client_socket.close()
    
    Fixes: 952310ccf2d8 ("smc: receive data from RMBE")
    Reported-by: D. Wythe <alibuda@linux.alibaba.com>
    Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
    Link: https://patch.msgid.link/20250104143201.35529-1-guangguan.wang@linux.alibaba.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0edcd0d18d700d76c61c091a24568b8b8c3b387
Author: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Date:   Wed Jan 8 10:36:36 2025 +0100

    clk: ralink: mtmips: remove duplicated 'xtal' clock for Ralink SoC RT3883
    
    [ Upstream commit 830d8062d25581cf0beaa334486eea06834044da ]
    
    Ralink SoC RT3883 has already 'xtal' defined as a base clock so there is no
    need to redefine it again in fixed clocks section. Hence, remove the duplicate
    one from there.
    
    Fixes: d34db686a3d7 ("clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs")
    Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
    Link: https://lore.kernel.org/r/20250108093636.265033-1-sergio.paracuellos@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf21ef3d430847ba864bbc9b2774fffcc03ce321
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jan 2 16:20:06 2025 +0200

    wifi: mac80211: don't flush non-uploaded STAs
    
    [ Upstream commit aa3ce3f8fafa0b8fb062f28024855ea8cb3f3450 ]
    
    If STA state is pre-moved to AUTHORIZED (such as in IBSS
    scenarios) and insertion fails, the station is freed.
    In this case, the driver never knew about the station,
    so trying to flush it is unexpected and may crash.
    
    Check if the sta was uploaded to the driver before and
    fix this.
    
    Fixes: d00800a289c9 ("wifi: mac80211: add flush_sta method")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://patch.msgid.link/20250102161730.e3d10970a7c7.I491bbcccc46f835ade07df0640a75f6ed92f20a3@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43b67fb2fea350a6c5549ecb9561b012522049d6
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Thu Jan 2 16:20:00 2025 +0200

    wifi: mac80211: Fix common size calculation for ML element
    
    [ Upstream commit 19aa842dcbb5860509b7e1b7745dbae0b791f6c4 ]
    
    When the ML type is EPCS the control bitmap is reserved, the length
    is always 7 and is captured by the 1st octet after the control.
    
    Fixes: 0f48b8b88aa9 ("wifi: ieee80211: add definitions for multi-link element")
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://patch.msgid.link/20250102161730.5790376754a7.I381208cbb72b1be2a88239509294099e9337e254@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69226421a5bcfed211442354311e90d43237c19c
Author: Andy Strohman <andrew@andrewstrohman.com>
Date:   Tue Jan 7 10:44:31 2025 +0000

    wifi: mac80211: fix tid removal during mesh forwarding
    
    [ Upstream commit 3aaa1a5a9a2ceeb32afa6ea4110a92338a863c33 ]
    
    With change (wifi: mac80211: fix receiving A-MSDU
    frames on mesh interfaces), a non-zero TID assignment
    is lost during slow path mesh forwarding.
    
    Prior to this change, ieee80211_rx_h_mesh_fwding()
    left the TID intact in the header.
    
    As a result of this header corruption, packets belonging
    to non-zero TIDs will get treating as belonging
    TID 0 by functions such as ieee80211_get_tid().
    While this miscategorization by itself is an
    issue, there are additional ramifications
    due to the fact that skb->priority still reflects
    the mesh forwarded packet's ingress (correct) TID.
    
    The mt7915 driver inspects the TID recorded within
    skb->priority and relays this to the
    hardware/radio during TX. The radio firmware appears to
    react to this by changing the sequence control
    header, but it does not also ensure/correct the TID in
    the QoS control header. As a result, the receiver
    will see packets with sequence numbers corresponding
    to the wrong TID. The receiver of the forwarded
    packet will see TID 0 in QoS control but a sequence number
    corresponding to the correct (different) TID in sequence
    control. This causes data stalls for TID 0 until
    the TID 0 sequence number advances past what the receiver
    believes it should be due to this bug.
    
    Mesh routing mpath changes cause a brief transition
    from fast path forwarding to slow path forwarding.
    Since this bug only affects the slow path forwarding,
    mpath changes bring opportunity for the bug to be triggered.
    In the author's case, he was experiencing TID 0 data stalls
    after mpath changes on an intermediate mesh node.
    
    These observed stalls may be specific
    to mediatek radios. But the inconsistency between
    the packet header and skb->priority may cause problems
    for other drivers as well. Regardless if this causes
    connectivity issues on other radios, this change is
    necessary in order transmit (forward) the packet on the
    correct TID and to have a consistent view a packet's TID
    within mac80211.
    
    Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces")
    Signed-off-by: Andy Strohman <andrew@andrewstrohman.com>
    Link: https://patch.msgid.link/20250107104431.446775-1-andrew@andrewstrohman.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d36e48a4d81c647df8a76cc58fd4d2442ba10744
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 30 09:14:07 2024 +0100

    wifi: mac80211: prohibit deactivating all links
    
    [ Upstream commit 7553477cbfd784b128297f9ed43751688415bbaa ]
    
    In the internal API this calls this is a WARN_ON, but that
    should remain since internally we want to know about bugs
    that may cause this. Prevent deactivating all links in the
    debugfs write directly.
    
    Reported-by: syzbot+0c5d8e65f23569a8ffec@syzkaller.appspotmail.com
    Fixes: 3d9011029227 ("wifi: mac80211: implement link switching")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://patch.msgid.link/20241230091408.505bd125c35a.Ic3c1f9572b980a952a444cad62b09b9c6721732b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4ba608bd4277d95640697c771771c8b5efb919f
Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date:   Fri Sep 27 10:53:17 2024 +0200

    wifi: mt76: mt7915: Fix mesh scan on MT7916 DBDC
    
    [ Upstream commit f21b77cb556296116b1cce1d62295d13e35da574 ]
    
    commit c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop
    period") changes the behavior of mt7915_bss_info_changed() in mesh mode
    when enable_beacon becomes false: it calls mt7915_mcu_add_bss_info(...,
    false) and mt7915_mcu_add_sta(..., false) while the previous code
    didn't.  These sends mcu commands that apparently confuse the firmware.
    
    This breaks scanning while in mesh mode on AsiaRF MT7916 DBDC-based cards:
    scanning works but no mesh frames get sent afterwards and the firmware
    seems to be hosed.  It breaks on MT7916 DBDC but not on MT7915 DBDC.
    
    Fixes: c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period")
    Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
    Link: https://patch.msgid.link/20240927085350.4594-1-nicolas.cavallari@green-communications.fr
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 849fb90ccc3d6669b0d7701c216d86208442fa9d
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Sat Jan 4 20:55:07 2025 +0100

    wifi: wlcore: fix unbalanced pm_runtime calls
    
    [ Upstream commit 996c934c8c196144af386c4385f61fcd5349af28 ]
    
    If firmware boot failes, runtime pm is put too often:
    [12092.708099] wlcore: ERROR firmware boot failed despite 3 retries
    [12092.708099] wl18xx_driver wl18xx.1.auto: Runtime PM usage count underflow!
    Fix that by redirecting all error gotos before runtime_get so that runtime is
    not put.
    
    Fixes: c40aad28a3cf ("wlcore: Make sure firmware is initialized in wl1271_op_add_interface()")
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    Reviewed-by: Michael Nemanov <michael.nemanov@ti.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20250104195507.402673-1-akemnade@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9450b3c3c4ff26e03090d95dc653246cce9cddfc
Author: Zichen Xie <zichenxie0106@gmail.com>
Date:   Wed Nov 27 21:29:56 2024 -0600

    samples/landlock: Fix possible NULL dereference in parse_path()
    
    [ Upstream commit 078bf9438a31567e2c0587159ccefde835fb1ced ]
    
    malloc() may return NULL, leading to NULL dereference.  Add a NULL
    check.
    
    Fixes: ba84b0bf5a16 ("samples/landlock: Add a sandbox manager example")
    Signed-off-by: Zichen Xie <zichenxie0106@gmail.com>
    Link: https://lore.kernel.org/r/20241128032955.11711-1-zichenxie0106@gmail.com
    [mic: Simplify fix]
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e30d21ed451d615296b6b53e57c2eb50852d06ce
Author: Rob Herring (Arm) <robh@kernel.org>
Date:   Tue Dec 17 12:11:40 2024 -0600

    mfd: syscon: Fix race in device_node_get_regmap()
    
    [ Upstream commit 805f7aaf7fee14a57b56af01d270edf6c10765e8 ]
    
    It is possible for multiple, simultaneous callers calling
    device_node_get_regmap() with the same node to fail to find an entry in
    the syscon_list. There is a period of time while the first caller is
    calling of_syscon_register() that subsequent callers also fail to find
    an entry in the syscon_list and then call of_syscon_register() a second
    time.
    
    Fix this by keeping the lock held until after of_syscon_register()
    completes and adds the node to syscon_list. Convert the spinlock to a
    mutex as many of the functions called in of_syscon_register() such as
    kzalloc() and of_clk_get() may sleep.
    
    Fixes: bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices")
    Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Will McVicker <willmcvicker@google.com>
    Tested-by: Pankaj Dubey <pankaj.dubey@samsung.com>
    Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
    Link: https://lore.kernel.org/r/20241217-syscon-fixes-v2-1-4f56d750541d@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bbe56ed428d07861ce419ee2999573393287611
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Jul 7 13:48:23 2024 +0200

    mfd: syscon: Use scoped variables with memory allocators to simplify error paths
    
    [ Upstream commit 82f898f47112bc7b787cb9ce8803c4e2f9f60c89 ]
    
    Allocate the memory with scoped/cleanup.h to reduce error handling and
    make the code a bit simpler.
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240707114823.9175-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Stable-dep-of: 805f7aaf7fee ("mfd: syscon: Fix race in device_node_get_regmap()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b45fd493da1870fbdacf1271b0f81a4aa7c79a3c
Author: Peter Griffin <peter.griffin@linaro.org>
Date:   Fri Jun 21 12:55:43 2024 +0100

    mfd: syscon: Add of_syscon_register_regmap() API
    
    [ Upstream commit 769cb63166d90f1fadafa4352f180cbd96b6cb77 ]
    
    The of_syscon_register_regmap() API allows an externally created regmap
    to be registered with syscon. This regmap can then be returned to client
    drivers using the syscon_regmap_lookup_by_phandle() APIs.
    
    The API is used by platforms where mmio access to the syscon registers is
    not possible, and a underlying soc driver like exynos-pmu provides a SoC
    specific regmap that can issue a SMC or hypervisor call to write the
    register.
    
    This approach keeps the SoC complexities out of syscon, but allows common
    drivers such as  syscon-poweroff, syscon-reboot and friends that are used
    by many SoCs already to be re-used.
    
    Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
    Tested-by: Will McVicker <willmcvicker@google.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240621115544.1655458-2-peter.griffin@linaro.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Stable-dep-of: 805f7aaf7fee ("mfd: syscon: Fix race in device_node_get_regmap()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6c5f73c31f04aef01119cbc962452c106d4a091
Author: Peter Griffin <peter.griffin@linaro.org>
Date:   Tue Feb 20 11:50:11 2024 +0000

    mfd: syscon: Remove extern from function prototypes
    
    [ Upstream commit 0db017f8edd9b9af818bc1d68ba578df1b4c4628 ]
    
    The kernel coding style does not require 'extern' in function prototypes
    in .h files, so remove them as they are not needed.
    
    To avoid checkpatch warnings such as
    CHECK: Lines should not end with a '('
    +struct regmap *syscon_regmap_lookup_by_phandle(
    
    The indentation is also updated. No functional changes in this patch.
    
    Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
    Link: https://lore.kernel.org/r/20240220115012.471689-3-peter.griffin@linaro.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Stable-dep-of: 805f7aaf7fee ("mfd: syscon: Fix race in device_node_get_regmap()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2c3949cebef39064f7d82db7d26442cbc7974e5
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Fri Dec 20 17:53:46 2024 +0900

    leds: cht-wcove: Use devm_led_classdev_register() to avoid memory leak
    
    [ Upstream commit 417cad5dc782096350e6a967ee5dd3417a19a24e ]
    
    cht_wc_leds_probe() leaks memory when the second led_classdev_register()
    call in the for-loop fails as it does not call the cleanup function
    led_classdev_unregister() on the first device. Avoid this leak by
    calling devm_led_classdev_register().
    
    Fixes: 047da762b9a9 ("leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driver")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://lore.kernel.org/r/20241220085346.533675-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68834217baaf5b102f07b2516cf9b286028ddaa6
Author: Terry Tritton <terry.tritton@linaro.org>
Date:   Fri Dec 20 19:23:18 2024 +0000

    HID: fix generic desktop D-Pad controls
    
    [ Upstream commit 80818fdc068eaab729bb793d790ae9fd053f7053 ]
    
    The addition of the "System Do Not Disturb" event code caused the Generic
    Desktop D-Pad configuration to be skipped. This commit allows both to be
    configured without conflicting with each other.
    
    Fixes: 22d6d060ac77 ("input: Add support for "Do Not Disturb"")
    Signed-off-by: Terry Tritton <terry.tritton@linaro.org>
    Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
    Reviewed-by: Carlos Llamas <cmllamas@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae730deded66150204c494282969bfa98dc3ae67
Author: Karol Przybylski <karprzy7@gmail.com>
Date:   Thu Dec 5 23:22:21 2024 +0100

    HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check
    
    [ Upstream commit 50420d7c79c37a3efe4010ff9b1bb14bc61ebccf ]
    
    syzbot has found a type mismatch between a USB pipe and the transfer
    endpoint, which is triggered by the hid-thrustmaster driver[1].
    There is a number of similar, already fixed issues [2].
    In this case as in others, implementing check for endpoint type fixes the issue.
    
    [1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470
    [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
    
    Fixes: c49c33637802 ("HID: support for initialization of some Thrustmaster wheels")
    Reported-by: syzbot+040e8b3db6a96908d470@syzkaller.appspotmail.com
    Tested-by: syzbot+040e8b3db6a96908d470@syzkaller.appspotmail.com
    Signed-off-by: Karol Przybylski <karprzy7@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1efa37f8b5480f39db6f5f774f6c9fcc453a3185
Author: Amit Pundir <amit.pundir@linaro.org>
Date:   Mon Dec 9 23:19:12 2024 +0530

    clk: qcom: gcc-sdm845: Do not use shared clk_ops for QUPs
    
    [ Upstream commit f760a4bb5e927a133dcd75f7b69ccae2a331e42c ]
    
    Similar to the earlier fixes meant for sm8x50 and x1e platforms,
    we have to stop using the shared clk ops for sdm845 QUPs as well.
    
    As Stephen Boyd pointed out in earlier fixes, there wasn't a problem
    to mark QUP clks shared until we started parking shared RCGs at clk
    registration time in commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs
    upon registration"). Parking at init is actually harmful to the UART
    when earlycon is used. If the device is pumping out data while the
    frequency changes and we see garbage on the serial console until the
    driver can probe and actually set a proper frequency.
    
    This patch reverts the QUP clk sharing ops part of commit 06391eddb60a
    ("clk: qcom: Add Global Clock controller (GCC) driver for SDM845"), so
    that the QUPs on sdm845 don't get parked during clk registration and
    break UART operations.
    
    Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration")
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Link: https://lore.kernel.org/r/20241209174912.2526928-1-amit.pundir@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb47144d9111cfb544d8210f2c81eeb9440b1f0a
Author: Sathishkumar Muruganandam <quic_murugana@quicinc.com>
Date:   Mon Sep 9 13:00:49 2024 +0530

    wifi: ath12k: fix tx power, max reg power update to firmware
    
    [ Upstream commit 3540bba855b4b422e8b977d11aa8173ccb4f089d ]
    
    Currently, when the vdev start WMI cmd is sent from host, vdev related
    parameters such as max_reg_power, max_power, and max_antenna_gain are
    multiplied by 2 before being sent to the firmware. This is incorrect
    because the firmware uses 1 dBm steps for power calculations.
    
    This leads to incorrect power values being used in the firmware and
    radio, potentially causing incorrect behavior.
    
    Fix the update of max_reg_power, max_power, and max_antenna_gain values
    in the ath12k_mac_vdev_start_restart function, ensuring accurate
    power settings in the firmware by sending these values as-is,
    without multiplication.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
    
    Signed-off-by: Sathishkumar Muruganandam <quic_murugana@quicinc.com>
    Signed-off-by: Santhosh Ramesh <quic_santrame@quicinc.com>
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Acked-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240909073049.3423035-1-quic_santrame@quicinc.com
    Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2851acb600d66ba3ebba209864367c8025a5326c
Author: Quan Nguyen <quan@os.amperecomputing.com>
Date:   Tue Jan 7 10:47:34 2025 +0700

    ipmi: ssif_bmc: Fix new request loss when bmc ready for a response
    
    [ Upstream commit 83d8c79aa958e37724ed9c14dc7d0f66a48ad864 ]
    
    Cosmo found that when there is a new request comes in while BMC is
    ready for a response, the complete_response(), which is called to
    complete the pending response, would accidentally clear out that new
    request and force ssif_bmc to move back to abort state again.
    
    This commit is to address that issue.
    
    Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver")
    Reported-by: Cosmo Chou <chou.cosmo@gmail.com>
    Closes: https://lore.kernel.org/lkml/20250101165431.2113407-1-chou.cosmo@gmail.com/
    Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
    Message-ID: <20250107034734.1842247-1-quan@os.amperecomputing.com>
    Signed-off-by: Corey Minyard <corey@minyard.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ec98ebb38dc612f4692d1041db072f72da30832
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Tue Jan 7 14:44:53 2025 +0900

    OPP: OF: Fix an OF node leak in _opp_add_static_v2()
    
    [ Upstream commit 1d38eb7f7b26261a0b642f6e0923269c7c000a97 ]
    
    _opp_add_static_v2() leaks the obtained OF node reference when
    _of_opp_alloc_required_opps() fails. Add an of_node_put() call in the
    error path.
    
    Fixes: 3466ea2cd6b6 ("OPP: Don't drop opp->np reference while it is still in use")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7705d8a7f2c26c80973c81093db07c6022b2b30e
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 3 21:05:14 2025 +0000

    ax25: rcu protect dev->ax25_ptr
    
    [ Upstream commit 95fc45d1dea8e1253f8ec58abc5befb71553d666 ]
    
    syzbot found a lockdep issue [1].
    
    We should remove ax25 RTNL dependency in ax25_setsockopt()
    
    This should also fix a variety of possible UAF in ax25.
    
    [1]
    
    WARNING: possible circular locking dependency detected
    6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted
    ------------------------------------------------------
    syz.5.1818/12806 is trying to acquire lock:
     ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
    
    but task is already holding lock:
     ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]
     ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}:
            lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
            lock_sock_nested+0x48/0x100 net/core/sock.c:3642
            lock_sock include/net/sock.h:1618 [inline]
            ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]
            ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146
            notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
           __dev_notify_flags+0x207/0x400
            dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026
            dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563
            dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820
            sock_do_ioctl+0x240/0x460 net/socket.c:1234
            sock_ioctl+0x626/0x8e0 net/socket.c:1339
            vfs_ioctl fs/ioctl.c:51 [inline]
            __do_sys_ioctl fs/ioctl.c:906 [inline]
            __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    -> #0 (rtnl_mutex){+.+.}-{4:4}:
            check_prev_add kernel/locking/lockdep.c:3161 [inline]
            check_prevs_add kernel/locking/lockdep.c:3280 [inline]
            validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904
            __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226
            lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
            __mutex_lock_common kernel/locking/mutex.c:585 [inline]
            __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735
            ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
            do_sock_setsockopt+0x3af/0x720 net/socket.c:2324
            __sys_setsockopt net/socket.c:2349 [inline]
            __do_sys_setsockopt net/socket.c:2355 [inline]
            __se_sys_setsockopt net/socket.c:2352 [inline]
            __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(sk_lock-AF_AX25);
                                   lock(rtnl_mutex);
                                   lock(sk_lock-AF_AX25);
      lock(rtnl_mutex);
    
     *** DEADLOCK ***
    
    1 lock held by syz.5.1818/12806:
      #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]
      #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
    
    stack backtrace:
    CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:94 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
      print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074
      check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206
      check_prev_add kernel/locking/lockdep.c:3161 [inline]
      check_prevs_add kernel/locking/lockdep.c:3280 [inline]
      validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904
      __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226
      lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
      __mutex_lock_common kernel/locking/mutex.c:585 [inline]
      __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735
      ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
      do_sock_setsockopt+0x3af/0x720 net/socket.c:2324
      __sys_setsockopt net/socket.c:2349 [inline]
      __do_sys_setsockopt net/socket.c:2355 [inline]
      __se_sys_setsockopt net/socket.c:2352 [inline]
      __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f7b62385d29
    
    Fixes: c433570458e4 ("ax25: fix a use-after-free in ax25_fillin_cb()")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/20250103210514.87290-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d54308079d0513f2a884bacae1b1a8fa4c0a1834
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Sat Jan 4 17:04:53 2025 +0900

    regulator: of: Implement the unwind path of of_regulator_match()
    
    [ Upstream commit dddca3b2fc676113c58b04aaefe84bfb958ac83e ]
    
    of_regulator_match() does not release the OF node reference in the error
    path, resulting in an OF node leak. Therefore, call of_node_put() on the
    obtained nodes before returning the EINVAL error.
    
    Since it is possible that some drivers call this function and do not
    exit on failure, such as s2mps11_pmic_driver, clear the init_data and
    of_node in the error path.
    
    This was reported by an experimental verification tool that I am
    developing. As I do not have access to actual devices nor the QEMU board
    configuration to test drivers that call this function, no runtime test
    was able to be performed.
    
    Fixes: 1c8fa58f4750 ("regulator: Add generic DT parsing for regulators")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://patch.msgid.link/20250104080453.2153592-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32d90424651b9d41fb55ce821c729de74f3bdcaa
Author: Vasily Khoruzhick <anarsoul@gmail.com>
Date:   Fri Jan 3 23:37:00 2025 -0800

    clk: sunxi-ng: a64: stop force-selecting PLL-MIPI as TCON0 parent
    
    [ Upstream commit 383ca7bee8a93be9ff5a072936981c2710d2856b ]
    
    Stop force-selecting PLL-MIPI as TCON0 parent, since it breaks video
    output on Pinebook that uses RGB to eDP bridge.
    
    Partially revert commit ca1170b69968 ("clk: sunxi-ng: a64: force
    select PLL_MIPI in TCON0 mux"), while still leaving
    CLK_SET_RATE_NO_REPARENT flag set, since we do not want the clock to
    be reparented.
    
    The issue is that apparently different TCON0 outputs require a different
    clock, or the mux might be selecting the output type.
    
    I did an experiment: I manually configured PLL_MIPI and PLL_VIDEO0_2X
    to the same clock rate and flipped the switch with devmem. Experiment
    clearly showed that whenever PLL_MIPI is selected as TCON0 clock parent,
    the video output stops working.
    
    Therefore, TCON0 clock parent corresponding to the output type must be
    assigned in the device tree.
    
    Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
    Reviewed-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Tested-by: Frank Oltmanns <frank@oltmanns.dev> # on PinePhone
    Tested-by: Stuart Gathman <stuart@gathman.org> # on OG Pinebook
    Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Link: https://patch.msgid.link/20250104074035.1611136-5-anarsoul@gmail.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e121a4f42b4d70001eb97935e540a8d8793a6459
Author: Vasily Khoruzhick <anarsoul@gmail.com>
Date:   Fri Jan 3 23:36:58 2025 -0800

    clk: sunxi-ng: a64: drop redundant CLK_PLL_VIDEO0_2X and CLK_PLL_MIPI
    
    [ Upstream commit 0f368cb7ef103f284f75e962c4c89da5aa8ccec7 ]
    
    Drop redundant CLK_PLL_VIDEO0_2X and CLK_PLL.MIPI. These are now
    defined in dt-bindings/clock/sun50i-a64-ccu.h
    
    Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
    Reviewed-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Tested-by: Frank Oltmanns <frank@oltmanns.dev> # on pinephone
    Tested-by: Stuart Gathman <stuart@gathman.org> # on OG pinebook
    Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Link: https://patch.msgid.link/20250104074035.1611136-3-anarsoul@gmail.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11f5bdeff93e7a1da338c0531d51b196742b84ae
Author: Vasily Khoruzhick <anarsoul@gmail.com>
Date:   Fri Jan 3 23:36:57 2025 -0800

    dt-bindings: clock: sunxi: Export PLL_VIDEO_2X and PLL_MIPI
    
    [ Upstream commit 9897831de614f1d8d5184547f0e7bf7665eed436 ]
    
    Export PLL_VIDEO_2X and PLL_MIPI, these will be used to explicitly
    select TCON0 clock parent in dts
    
    Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
    Reviewed-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Tested-by: Frank Oltmanns <frank@oltmanns.dev> # on PinePhone
    Tested-by: Stuart Gathman <stuart@gathman.org> # on OG Pinebook
    Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://patch.msgid.link/20250104074035.1611136-2-anarsoul@gmail.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Stable-dep-of: 0f368cb7ef10 ("clk: sunxi-ng: a64: drop redundant CLK_PLL_VIDEO0_2X and CLK_PLL_MIPI")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 184a564e6000b41582f160a5be9a9b5aabe22ac1
Author: Octavian Purdila <tavip@google.com>
Date:   Mon Dec 30 12:56:47 2024 -0800

    team: prevent adding a device which is already a team device lower
    
    [ Upstream commit 3fff5da4ca2164bb4d0f1e6cd33f6eb8a0e73e50 ]
    
    Prevent adding a device which is already a team device lower,
    e.g. adding veth0 if vlan1 was already added and veth0 is a lower of
    vlan1.
    
    This is not useful in practice and can lead to recursive locking:
    
    $ ip link add veth0 type veth peer name veth1
    $ ip link set veth0 up
    $ ip link set veth1 up
    $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1
    $ ip link add team0 type team
    $ ip link set veth0.1 down
    $ ip link set veth0.1 master team0
    team0: Port device veth0.1 added
    $ ip link set veth0 down
    $ ip link set veth0 master team0
    
    ============================================
    WARNING: possible recursive locking detected
    6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
    --------------------------------------------
    ip/7684 is trying to acquire lock:
    ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    
    but task is already holding lock:
    ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
    
    other info that might help us debug this:
    Possible unsafe locking scenario:
    
    CPU0
    ----
    lock(team->team_lock_key);
    lock(team->team_lock_key);
    
    *** DEADLOCK ***
    
    May be due to missing lock nesting notation
    
    2 locks held by ip/7684:
    
    stack backtrace:
    CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    Call Trace:
    <TASK>
    dump_stack_lvl (lib/dump_stack.c:122)
    print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)
    __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)
    ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)
    lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)
    ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))
    ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    ? lock_acquire (kernel/locking/lockdep.c:5822)
    ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)
    ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    ? fib_sync_up (net/ipv4/fib_semantics.c:2167)
    ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
    notifier_call_chain (kernel/notifier.c:85)
    call_netdevice_notifiers_info (net/core/dev.c:1996)
    __dev_notify_flags (net/core/dev.c:8993)
    ? __dev_change_flags (net/core/dev.c:8975)
    dev_change_flags (net/core/dev.c:9027)
    vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)
    ? br_device_event (net/bridge/br.c:143)
    notifier_call_chain (kernel/notifier.c:85)
    call_netdevice_notifiers_info (net/core/dev.c:1996)
    dev_open (net/core/dev.c:1519 net/core/dev.c:1505)
    team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)
    ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)
    do_set_master (net/core/rtnetlink.c:2917)
    do_setlink.isra.0 (net/core/rtnetlink.c:3117)
    
    Reported-by: syzbot+3c47b5843403a45aef57@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=3c47b5843403a45aef57
    Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
    Signed-off-by: Octavian Purdila <tavip@google.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a32da24ef8cccf4b390d16574fef9dbdd23eca8e
Author: Marek Vasut <marex@denx.de>
Date:   Tue Nov 12 02:36:54 2024 +0100

    clk: imx8mp: Fix clkout1/2 support
    
    [ Upstream commit a9b7c84d22fb1687d63ca2a386773015cf59436b ]
    
    The CLKOUTn may be fed from PLL1/2/3, but the PLL1/2/3 has to be enabled
    first by setting PLL_CLKE bit 11 in CCM_ANALOG_SYS_PLLn_GEN_CTRL register.
    The CCM_ANALOG_SYS_PLLn_GEN_CTRL bit 11 is modeled by plln_out clock. Fix
    the clock tree and place the clkout1/2 under plln_sel instead of plain plln
    to let the clock subsystem correctly control the bit 11 and enable the PLL
    in case the CLKOUTn is supplied by PLL1/2/3.
    
    Fixes: 43896f56b59e ("clk: imx8mp: add clkout1/2 support")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20241112013718.333771-1-marex@denx.de
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3319bebda6df3ec2bc664972c0a8d4796ecf1875
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Thu Dec 5 22:20:29 2024 +0530

    cpufreq: qcom: Implement clk_ops::determine_rate() for qcom_cpufreq* clocks
    
    [ Upstream commit a9ba290d0b829012574b6821ba08815046e60c94 ]
    
    determine_rate() callback is used by the clk_set_rate() API to get the
    closest rate of the target rate supported by the clock. If this callback
    is not implemented (nor round_rate() callback), then the API will assume
    that the clock cannot set the requested rate. And since there is no parent,
    it will return -EINVAL.
    
    This is not an issue right now as clk_set_rate() mistakenly compares the
    target rate with cached rate and bails out early. But once that is fixed
    to compare the target rate with the actual rate of the clock (returned by
    recalc_rate()), then clk_set_rate() for this clock will start to fail as
    below:
    
    cpu cpu0: _opp_config_clk_single: failed to set clock rate: -22
    
    So implement the determine_rate() callback that just returns the actual
    rate at which the clock is passed to the CPUs in a domain.
    
    Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support")
    Reported-by: Johan Hovold <johan+linaro@kernel.org>
    Suggested-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f757327c4ce69f9d654aa43889c8c14035090d14
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Thu Dec 5 22:20:28 2024 +0530

    cpufreq: qcom: Fix qcom_cpufreq_hw_recalc_rate() to query LUT if LMh IRQ is not available
    
    [ Upstream commit 85d8b11351a8f15d6ec7a5e97909861cb3b6bcec ]
    
    Currently, qcom_cpufreq_hw_recalc_rate() returns the LMh throttled
    frequency for the domain even if LMh IRQ is not available. But as per
    qcom_cpufreq_hw_get(), the driver has to query LUT entries to get the
    actual frequency of the domain. So do the same in
    qcom_cpufreq_hw_recalc_rate().
    
    While doing so, refactor the existing qcom_cpufreq_hw_get() function so
    that qcom_cpufreq_hw_recalc_rate() can make use of the existing code and
    avoid code duplication. This also requires setting the
    qcom_cpufreq_data::policy even if LMh IRQ is not available.
    
    Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support")
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b38f66273f89b5851fb8b667d0503f7a0eb7392d
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
Date:   Thu Dec 19 10:39:46 2024 +0100

    gpio: pca953x: log an error when failing to get the reset GPIO
    
    [ Upstream commit 7cef813a91c468253c80633891393478b9f2c966 ]
    
    When the dirver fails getting this GPIO, it fails silently. Log an error
    message to make debugging a lot easier by just reading dmesg.
    
    Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Fixes: 054ccdef8b28 ("gpio: pca953x: Add optional reset gpio control")
    Link: https://lore.kernel.org/r/20241219-pca953x-log-no-reset-gpio-v1-1-9aa7bcc45ead@bootlin.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f66aed661bf2c9600ab644fa7bca9addbd53db92
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Sep 1 16:40:33 2023 +0300

    gpio: pca953x: Fully convert to device managed resources
    
    [ Upstream commit 53c59d66c44c5eb98b34da9967f937e5387f8624 ]
    
    Curtrently the error path is unsynchronised with removal due to
    regulator being disabled before other device managed resources
    are handled. Correct that by wrapping regulator enablement in
    the respective call.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Stable-dep-of: 7cef813a91c4 ("gpio: pca953x: log an error when failing to get the reset GPIO")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e657dc10c4d4877f7d514019d9f4a3a07b74b778
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Sep 1 16:40:32 2023 +0300

    gpio: pca953x: Drop unused fields in struct pca953x_platform_data
    
    [ Upstream commit 2f4d3e293392571e02b106c8b431b638bd029276 ]
    
    New code should solely use firmware nodes for the specifics and
    not any callbacks.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Stable-dep-of: 7cef813a91c4 ("gpio: pca953x: log an error when failing to get the reset GPIO")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50bcea7af9240b678caf37c5f68087f42924ff9c
Author: Sultan Alsawaf (unemployed) <sultan@kerneltoast.com>
Date:   Wed Dec 11 17:57:32 2024 -0800

    cpufreq: schedutil: Fix superfluous updates caused by need_freq_update
    
    [ Upstream commit 8e461a1cb43d69d2fc8a97e61916dce571e6bb31 ]
    
    A redundant frequency update is only truly needed when there is a policy
    limits change with a driver that specifies CPUFREQ_NEED_UPDATE_LIMITS.
    
    In spite of that, drivers specifying CPUFREQ_NEED_UPDATE_LIMITS receive a
    frequency update _all the time_, not just for a policy limits change,
    because need_freq_update is never cleared.
    
    Furthermore, ignore_dl_rate_limit()'s usage of need_freq_update also leads
    to a redundant frequency update, regardless of whether or not the driver
    specifies CPUFREQ_NEED_UPDATE_LIMITS, when the next chosen frequency is the
    same as the current one.
    
    Fix the superfluous updates by only honoring CPUFREQ_NEED_UPDATE_LIMITS
    when there's a policy limits change, and clearing need_freq_update when a
    requisite redundant update occurs.
    
    This is neatly achieved by moving up the CPUFREQ_NEED_UPDATE_LIMITS test
    and instead setting need_freq_update to false in sugov_update_next_freq().
    
    Fixes: 600f5badb78c ("cpufreq: schedutil: Don't skip freq update when limits change")
    Signed-off-by: Sultan Alsawaf (unemployed) <sultan@kerneltoast.com>
    Reviewed-by: Christian Loehle <christian.loehle@arm.com>
    Link: https://patch.msgid.link/20241212015734.41241-2-sultan@kerneltoast.com
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f06dd950d045241ef59254bf0640ab1ca5bbd14
Author: Mingwei Zheng <zmw12306@gmail.com>
Date:   Fri Dec 6 16:53:18 2024 -0500

    pwm: stm32-lp: Add check for clk_enable()
    
    [ Upstream commit cce16e7f6216227964cda25f5f23634bce2c500f ]
    
    Add check for the return value of clk_enable() to catch the potential
    error.
    We used APP-Miner to find it.
    
    Fixes: e70a540b4e02 ("pwm: Add STM32 LPTimer PWM driver")
    Signed-off-by: Mingwei Zheng <zmw12306@gmail.com>
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Link: https://lore.kernel.org/r/20241206215318.3402860-1-zmw12306@gmail.com
    Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 280fb099c1ddef78c13d248cb55e9ad099d2661c
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Dec 15 17:56:29 2024 +0000

    inetpeer: do not get a refcount in inet_getpeer()
    
    [ Upstream commit a853c609504e2d1d83e71285e3622fda1f1451d8 ]
    
    All inet_getpeer() callers except ip4_frag_init() don't need
    to acquire a permanent refcount on the inetpeer.
    
    They can switch to full RCU protection.
    
    Move the refcount_inc_not_zero() into ip4_frag_init(),
    so that all the other callers no longer have to
    perform a pair of expensive atomic operations on
    a possibly contended cache line.
    
    inet_putpeer() no longer needs to be exported.
    
    After this patch, my DUT can receive 8,400,000 UDP packets
    per second targeting closed ports, using 50% less cpu cycles
    than before.
    
    Also change two calls to l3mdev_master_ifindex() by
    l3mdev_master_ifindex_rcu() (Ido ideas)
    
    Fixes: 8c2bd38b95f7 ("icmp: change the order of rate limits")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241215175629.1248773-5-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e22c073471b5ed89d817ffb47e0cb322d282ef0d
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Dec 15 17:56:28 2024 +0000

    inetpeer: update inetpeer timestamp in inet_getpeer()
    
    [ Upstream commit 50b362f21d6c10b0f7939c1482c6a1b43da82f1a ]
    
    inet_putpeer() will be removed in the following patch,
    because we will no longer use refcounts.
    
    Update inetpeer timestamp (p->dtime) at lookup time.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241215175629.1248773-4-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a853c609504e ("inetpeer: do not get a refcount in inet_getpeer()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb8449c34910a73dcdfd089bbb42b76f9fdd1ccc
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Dec 15 17:56:27 2024 +0000

    inetpeer: remove create argument of inet_getpeer()
    
    [ Upstream commit 7a596a50c4a4eab946aec149171c72321b4934aa ]
    
    All callers of inet_getpeer() want to create an inetpeer.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241215175629.1248773-3-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a853c609504e ("inetpeer: do not get a refcount in inet_getpeer()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdaa6b3c7e365f242fa919c0ccdcfae922208946
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Dec 15 17:56:26 2024 +0000

    inetpeer: remove create argument of inet_getpeer_v[46]()
    
    [ Upstream commit 661cd8fc8e9039819ca0c22e0add52b632240a9e ]
    
    All callers of inet_getpeer_v4() and inet_getpeer_v6()
    want to create an inetpeer.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241215175629.1248773-2-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a853c609504e ("inetpeer: do not get a refcount in inet_getpeer()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d01e6a67595068741373f71759d5ff5e30faa116
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Mon Dec 16 16:49:23 2024 +0900

    leds: netxbig: Fix an OF node reference leak in netxbig_leds_get_of_pdata()
    
    [ Upstream commit 0508316be63bb735f59bdc8fe4527cadb62210ca ]
    
    netxbig_leds_get_of_pdata() does not release the OF node obtained by
    of_parse_phandle() when of_find_device_by_node() fails. Add an
    of_node_put() call to fix the leak.
    
    This bug was found by an experimental static analysis tool that I am
    developing.
    
    Fixes: 9af512e81964 ("leds: netxbig: Convert to use GPIO descriptors")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://lore.kernel.org/r/20241216074923.628509-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fd7fd629a3314e84e051b7c26b6a6952ffc3299
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Tue Nov 12 19:01:06 2024 +0200

    dt-bindings: mfd: bd71815: Fix rsense and typos
    
    [ Upstream commit 6856edf7ead8c54803216a38a7b227bcb3dadff7 ]
    
    The sense resistor used for measuring currents is typically some tens of
    milli Ohms. It has accidentally been documented to be tens of mega Ohms.
    Fix the size of this resistor and a few copy-paste errors while at it.
    
    Drop the unsuitable 'rohm,charger-sense-resistor-ohms' property (which
    can't represent resistors smaller than one Ohm), and introduce a new
    'rohm,charger-sense-resistor-micro-ohms' property with appropriate
    minimum, maximum and default values instead.
    
    Fixes: 4238dc1e6490 ("dt_bindings: mfd: Add ROHM BD71815 PMIC")
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/0efd8e9de0ae8d62ee4c6b78cc565b04007a245d.1731430700.git.mazziesaccount@gmail.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97294d480d4bab765179047458a9c12d5c984223
Author: He Rongguang <herongguang@linux.alibaba.com>
Date:   Thu Dec 12 10:14:59 2024 +0800

    cpupower: fix TSC MHz calculation
    
    [ Upstream commit 9d6c0e58514f8b57cd9c2c755e41623d6a966025 ]
    
    Commit 'cpupower: Make TSC read per CPU for Mperf monitor' (c2adb1877b7)
    changes TSC counter reads per cpu, but left time diff global (from start
    of all cpus to end of all cpus), thus diff(time) is too large for a
    cpu's tsc counting, resulting in far less than acutal TSC_Mhz and thus
    `cpupower monitor` showing far less than actual cpu realtime frequency.
    
    /proc/cpuinfo shows frequency:
    cat /proc/cpuinfo | egrep -e 'processor' -e 'MHz'
    ...
    processor : 171
    cpu MHz   : 4108.498
    ...
    
    before fix (System 100% busy):
        | Mperf              || Idle_Stats
     CPU| C0   | Cx   | Freq  || POLL | C1   | C2
     171|  0.77| 99.23|  2279||  0.00|  0.00|  0.00
    
    after fix (System 100% busy):
        | Mperf              || Idle_Stats
     CPU| C0   | Cx   | Freq  || POLL | C1   | C2
     171|  0.46| 99.54|  4095||  0.00|  0.00|  0.00
    
    Fixes: c2adb1877b76 ("cpupower: Make TSC read per CPU for Mperf monitor")
    Signed-off-by: He Rongguang <herongguang@linux.alibaba.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45f1432e74d1be60a15e692b272db062e756a073
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Wed Dec 11 12:28:12 2024 +0900

    ACPI: fan: cleanup resources in the error path of .probe()
    
    [ Upstream commit c759bc8e9046f9812238f506d70f07d3ea4206d4 ]
    
    Call thermal_cooling_device_unregister() and sysfs_remove_link() in the
    error path of acpi_fan_probe() to fix possible memory leak.
    
    This bug was found by an experimental static analysis tool that I am
    developing.
    
    Fixes: 05a83d972293 ("ACPI: register ACPI Fan as generic thermal cooling device")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://patch.msgid.link/20241211032812.210164-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19958067c4be4e9ce7b9acc0b30102a4b33a106e
Author: Marcel Hamer <marcel.hamer@windriver.com>
Date:   Wed Dec 11 14:36:18 2024 +0100

    wifi: brcmfmac: add missing header include for brcmf_dbg
    
    [ Upstream commit b05d30c2b6df7e2172b18bf1baee9b202f9c6b53 ]
    
    Including the fwil.h header file can lead to a build error:
    
    drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h: \
            In function ‘brcmf_fil_cmd_int_set’:
    drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h:90:9: error: implicit \
            declaration of function ‘brcmf_dbg’ [-Werror=implicit-function-declaration]
       90 |         brcmf_dbg(FIL, "ifidx=%d, cmd=%d, value=%d\n", ifp->ifidx, cmd, data);
          |         ^~~~~~~~~
    
    The error is often avoided because the debug.h header file is included
    before the fwil.h header file.
    
    This makes sure the header include order is irrelevant by explicitly adding the
    debug.h header.
    
    Fixes: 31343230abb1 ("wifi: brcmfmac: export firmware interface functions")
    Signed-off-by: Marcel Hamer <marcel.hamer@windriver.com>
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241211133618.2014083-1-marcel.hamer@windriver.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3afc51492ad9c8353b8af8529f121c3406979618
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Dec 11 13:24:19 2024 +0800

    regulator: dt-bindings: mt6315: Drop regulator-compatible property
    
    [ Upstream commit 08242719a8af603db54a2a79234a8fe600680105 ]
    
    The "regulator-compatible" property has been deprecated since 2012 in
    commit 13511def87b9 ("regulator: deprecate regulator-compatible DT
    property"), which is so old it's not even mentioned in the converted
    regulator bindings YAML file. It should not have been used for new
    submissions such as the MT6315.
    
    Drop the property from the MT6315 regulator binding and its examples.
    
    Fixes: 977fb5b58469 ("regulator: document binding for MT6315 regulator")
    Fixes: 6d435a94ba5b ("regulator: mt6315: Enforce regulator-compatible, not name")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://patch.msgid.link/20241211052427.4178367-2-wenst@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d259ac7e0c5149f4c3a783e19fb0333c9a52cc4
Author: Jiri Kosina <jikos@kernel.org>
Date:   Thu Dec 12 10:19:32 2024 +0100

    HID: multitouch: fix support for Goodix PID 0x01e9
    
    [ Upstream commit 8ade5e05bd094485ce370fad66a6a3fb6f50bfbc ]
    
    Commit c8000deb68365b ("HID: multitouch: Add support for GT7868Q") added
    support for 0x01e8 and 0x01e9, but the mt_device[] entries were added
    twice for 0x01e8 and there was none added for 0x01e9. Fix that.
    
    Fixes: c8000deb68365b ("HID: multitouch: Add support for GT7868Q")
    Reported-by: He Lugang <helugang@uniontech.com>
    Reported-by: WangYuli <wangyuli@uniontech.com>
    Reported-by: Ulrich Müller <ulm@gentoo.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2fe1678e04dc3cb6efcb7575d3cd79b4c3d3fe2
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Fri Dec 6 14:37:13 2024 -0300

    wifi: rtlwifi: pci: wait for firmware loading before releasing memory
    
    [ Upstream commit b59b86c5d08be7d761c04affcbcec8184738c200 ]
    
    At probe error path, the firmware loading work may have already been
    queued. In such a case, it will try to access memory allocated by the probe
    function, which is about to be released. In such paths, wait for the
    firmware worker to finish before releasing memory.
    
    Fixes: 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241206173713.3222187-5-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 624cea89a0865a2bc3e00182a6b0f954a94328b4
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Fri Dec 6 14:37:12 2024 -0300

    wifi: rtlwifi: fix memory leaks and invalid access at probe error path
    
    [ Upstream commit e7ceefbfd8d447abc8aca8ab993a942803522c06 ]
    
    Deinitialize at reverse order when probe fails.
    
    When init_sw_vars fails, rtl_deinit_core should not be called, specially
    now that it destroys the rtl_wq workqueue.
    
    And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be
    leaked.
    
    Remove pci_set_drvdata call as it will already be cleaned up by the core
    driver code and could lead to memory leaks too. cf. commit 8d450935ae7f
    ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and
    commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").
    
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241206173713.3222187-4-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c37901c0c8eb5eeadcc3ee7b98c2d6e5df31f561
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Fri Dec 6 14:37:11 2024 -0300

    wifi: rtlwifi: destroy workqueue at rtl_deinit_core
    
    [ Upstream commit d8ece6fc3694657e4886191b32ca1690af11adda ]
    
    rtl_wq is allocated at rtl_init_core, so it makes more sense to destroy it
    at rtl_deinit_core. In the case of USB, where _rtl_usb_init does not
    require anything to be undone, that is fine. But for PCI, rtl_pci_init,
    which is called after rtl_init_core, needs to deallocate data, but only if
    it has been called.
    
    That means that destroying the workqueue needs to be done whether
    rtl_pci_init has been called or not. And since rtl_pci_deinit was doing it,
    it has to be moved out of there.
    
    It makes more sense to move it to rtl_deinit_core and have it done in both
    cases, USB and PCI.
    
    Since this is a requirement for a followup memory leak fix, mark this as
    fixing such memory leak.
    
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241206173713.3222187-3-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 465d01ef6962b82b1f0ad1f3e58b398dbd35c1c1
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Fri Dec 6 14:37:10 2024 -0300

    wifi: rtlwifi: remove unused check_buddy_priv
    
    [ Upstream commit 2fdac64c3c35858aa8ac5caa70b232e03456e120 ]
    
    Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global
    list of private data structures.
    
    Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match
    vendor version 2013.02.07") started adding the private data to that list at
    probe time and added a hook, check_buddy_priv to find the private data from
    a similar device.
    
    However, that function was never used.
    
    Besides, though there is a lock for that list, it is never used. And when
    the probe fails, the private data is never removed from the list. This
    would cause a second probe to access freed memory.
    
    Remove the unused hook, structures and members, which will prevent the
    potential race condition on the list and its corruption during a second
    probe when probe fails.
    
    Fixes: 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241206173713.3222187-2-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43c47210dae3f6680ee50d1368c9f2870d83bfaa
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Nov 14 13:44:29 2024 +0100

    dt-bindings: leds: class-multicolor: Fix path to color definitions
    
    [ Upstream commit 609bc99a4452ffbce82d10f024a85d911c42e6cd ]
    
    The LED color definitions have always been in
    include/dt-bindings/leds/common.h in upstream.
    
    Fixes: 5c7f8ffe741daae7 ("dt: bindings: Add multicolor class dt bindings documention")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/a3c7ea92e90b77032f2e480d46418b087709286d.1731588129.git.geert+renesas@glider.be
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ffbe3a0b816f67bdbe6b33c1f9efaa92cd04d45
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Tue Dec 10 22:09:12 2024 +0900

    clk: fix an OF node reference leak in of_clk_get_parent_name()
    
    [ Upstream commit 28fa3291cad1c201967ef93edc6e7f8ccc9afbc0 ]
    
    Current implementation of of_clk_get_parent_name() leaks an OF node
    reference on error path. Add a of_node_put() call before returning an
    error.
    
    This bug was found by an experimental static analysis tool that I am
    developing.
    
    Fixes: 8da411cc1964 ("clk: let of_clk_get_parent_name() fail for invalid clock-indices")
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Link: https://lore.kernel.org/r/20241210130913.3615205-1-joe@pf.is.s.u-tokyo.ac.jp
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 914ef7d1a702c510d0b59151a9623f9d20c69d2a
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
Date:   Wed Jul 24 18:33:06 2024 +0200

    of: remove internal arguments from of_property_for_each_u32()
    
    [ Upstream commit 9722c3b66e21ff08aec570d02a97d331087fd70f ]
    
    The of_property_for_each_u32() macro needs five parameters, two of which
    are primarily meant as internal variables for the macro itself (in the
    for() clause). Yet these two parameters are used by a few drivers, and this
    can be considered misuse or at least bad practice.
    
    Now that the kernel uses C11 to build, these two parameters can be avoided
    by declaring them internally, thus changing this pattern:
    
      struct property *prop;
      const __be32 *p;
      u32 val;
    
      of_property_for_each_u32(np, "xyz", prop, p, val) { ... }
    
    to this:
    
      u32 val;
    
      of_property_for_each_u32(np, "xyz", val) { ... }
    
    However two variables cannot be declared in the for clause even with C11,
    so declare one struct that contain the two variables we actually need. As
    the variables inside this struct are not meant to be used by users of this
    macro, give the struct instance the noticeable name "_it" so it is visible
    during code reviews, helping to avoid new code to use it directly.
    
    Most usages are trivially converted as they do not use those two
    parameters, as expected. The non-trivial cases are:
    
     - drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway
     - drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the
       checks had to be replicated in a different way, making code more verbose
       and somewhat uglier, but I refrained from a full rework to keep as much
       of the original code untouched having no hardware to test my changes
    
    All the changes have been build tested. The few for which I have the
    hardware have been runtime-tested too.
    
    Reviewed-by: Andre Przywara <andre.przywara@arm.com> # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c
    Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # drivers/gpio/gpio-brcmstb.c
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # drivers/irqchip/irq-atmel-aic-common.c
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # drivers/iio/adc/ti_am335x_adc.c
    Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> # drivers/pwm/pwm-samsung.c
    Acked-by: Richard Leitner <richard.leitner@linux.dev> # drivers/usb/misc/usb251xb.c
    Acked-by: Mark Brown <broonie@kernel.org> # sound/soc/codecs/arizona.c
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> # sound/soc/codecs/arizona.c
    Acked-by: Michael Ellerman <mpe@ellerman.id.au> # arch/powerpc/sysdev/xive/spapr.c
    Acked-by: Stephen Boyd <sboyd@kernel.org> # clk
    Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Acked-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com
    Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
    Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b84c2cee295d4c0a683382ae7c1c10beef731d1
Author: Alvin Å ipraga <alsi@bang-olufsen.dk>
Date:   Fri Nov 24 14:17:44 2023 +0100

    clk: si5351: allow PLLs to be adjusted without reset
    
    [ Upstream commit b2adbc9cea752539f6421e9d4642408f666c1251 ]
    
    Introduce a new PLL reset mode flag which controls whether or not to
    reset a PLL after adjusting its rate. The mode can be configured through
    platform data or device tree.
    
    Since commit 6dc669a22c77 ("clk: si5351: Add PLL soft reset"), the
    driver unconditionally resets a PLL whenever its rate is adjusted.
    The rationale was that a PLL reset was required to get three outputs
    working at the same time. Before this change, the driver never reset the
    PLLs.
    
    Commit b26ff127c52c ("clk: si5351: Apply PLL soft reset before enabling
    the outputs") subsequently introduced an option to reset the PLL when
    enabling a clock output that sourced it. Here, the rationale was that
    this is required to get a deterministic phase relationship between
    multiple output clocks.
    
    This clearly shows that it is useful to reset the PLLs in applications
    where multiple clock outputs are used. However, the Si5351 also allows
    for glitch-free rate adjustment of its PLLs if one avoids resetting the
    PLL. In our audio application where a single Si5351 clock output is used
    to supply a runtime adjustable bit clock, this unconditional PLL reset
    behaviour introduces unwanted glitches in the clock output.
    
    It would appear that the problem being solved in the former commit
    may be solved by using the optional device tree property introduced in
    the latter commit, obviating the need for an unconditional PLL reset
    after rate adjustment. But it's not OK to break the default behaviour of
    the driver, and it cannot be assumed that all device trees are using the
    property introduced in the latter commit. Hence, the new behaviour is
    made opt-in.
    
    Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
    Cc: Rabeeh Khoury <rabeeh@solid-run.com>
    Cc: Jacob Siverskog <jacob@teenage.engineering>
    Cc: Sergej Sawazki <sergej@taudac.com>
    Signed-off-by: Alvin Å ipraga <alsi@bang-olufsen.dk>
    Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
    Link: https://lore.kernel.org/r/20231124-alvin-clk-si5351-no-pll-reset-v6-3-69b82311cb90@bang-olufsen.dk
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2321288c43570296bed35457159942d986edd18b
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Wed Sep 27 12:01:52 2023 -0400

    serial: sc16is7xx: use device_property APIs when configuring irda mode
    
    [ Upstream commit 1a0a2a1e57aa8dcdae25229f6e95cf6bd4817faf ]
    
    Convert driver to be property provider agnostic and allow it to be
    used on non-OF platforms.
    
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20230927160153.2717788-2-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0523ac72a8d8944424a8e0dcd0a0e48f1ad7be31
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Thu Nov 28 16:16:41 2024 +0100

    dt-bindings: mmc: controller: clarify the address-cells description
    
    [ Upstream commit b2b8e93ec00b8110cb37cbde5400d5abfdaed6a7 ]
    
    The term "slot ID" has nothing to do with the SDIO function number
    which is specified in the reg property of the subnodes, rephrase
    the description to be more accurate.
    
    Fixes: f9b7989859dd ("dt-bindings: mmc: Add YAML schemas for the generic MMC options")
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Acked-by: Rob Herring (Arm) <robh@kernel.org>
    Message-ID: <20241128-topic-amlogic-arm32-upstream-bindings-fixes-convert-meson-mx-sdio-v4-1-11d9f9200a59@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c6702260557c0183d8417c79a37777a3d3e58e8
Author: David Howells <dhowells@redhat.com>
Date:   Wed Dec 4 07:46:30 2024 +0000

    rxrpc: Fix handling of received connection abort
    
    [ Upstream commit 0e56ebde245e4799ce74d38419426f2a80d39950 ]
    
    Fix the handling of a connection abort that we've received.  Though the
    abort is at the connection level, it needs propagating to the calls on that
    connection.  Whilst the propagation bit is performed, the calls aren't then
    woken up to go and process their termination, and as no further input is
    forthcoming, they just hang.
    
    Also add some tracing for the logging of connection aborts.
    
    Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://patch.msgid.link/20241204074710.990092-3-dhowells@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bb87d8823d4f2271c49dd7aca8b5f91c0d10851
Author: Mingwei Zheng <zmw12306@gmail.com>
Date:   Fri Dec 6 20:52:06 2024 -0500

    spi: zynq-qspi: Add check for clk_enable()
    
    [ Upstream commit 8332e667099712e05ec87ba2058af394b51ebdc9 ]
    
    Add check for the return value of clk_enable() to catch the potential
    error.
    
    Fixes: c618a90dcaf3 ("spi: zynq-qspi: Drop GPIO header")
    Signed-off-by: Mingwei Zheng <zmw12306@gmail.com>
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Link: https://patch.msgid.link/20241207015206.3689364-1-zmw12306@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 833e9a1c27b82024db7ff5038a51651f48f05e5e
Author: Octavian Purdila <tavip@google.com>
Date:   Tue Dec 3 19:05:19 2024 -0800

    net_sched: sch_sfq: don't allow 1 packet limit
    
    [ Upstream commit 10685681bafce6febb39770f3387621bf5d67d0b ]
    
    The current implementation does not work correctly with a limit of
    1. iproute2 actually checks for this and this patch adds the check in
    kernel as well.
    
    This fixes the following syzkaller reported crash:
    
    UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6
    index 65535 is out of range for type 'struct sfq_head[128]'
    CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
    Call Trace:
      __dump_stack lib/dump_stack.c:79 [inline]
      dump_stack+0x125/0x19f lib/dump_stack.c:120
      ubsan_epilogue lib/ubsan.c:148 [inline]
      __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347
      sfq_link net/sched/sch_sfq.c:210 [inline]
      sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238
      sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500
      sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525
      qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
      tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319
      qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
      dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296
      netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]
      dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362
      __dev_close_many+0x214/0x350 net/core/dev.c:1468
      dev_close_many+0x207/0x510 net/core/dev.c:1506
      unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738
      unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695
      unregister_netdevice include/linux/netdevice.h:2893 [inline]
      __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689
      tun_detach drivers/net/tun.c:705 [inline]
      tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640
      __fput+0x203/0x840 fs/file_table.c:280
      task_work_run+0x129/0x1b0 kernel/task_work.c:185
      exit_task_work include/linux/task_work.h:33 [inline]
      do_exit+0x5ce/0x2200 kernel/exit.c:931
      do_group_exit+0x144/0x310 kernel/exit.c:1046
      __do_sys_exit_group kernel/exit.c:1057 [inline]
      __se_sys_exit_group kernel/exit.c:1055 [inline]
      __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055
     do_syscall_64+0x6c/0xd0
     entry_SYSCALL_64_after_hwframe+0x61/0xcb
    RIP: 0033:0x7fe5e7b52479
    Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.
    RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479
    RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
    RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0
    R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270
    
    The crash can be also be reproduced with the following (with a tc
    recompiled to allow for sfq limits of 1):
    
    tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s
    ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1
    ifconfig dummy0 up
    ping -I dummy0 -f -c2 -W0.1 8.8.8.8
    sleep 1
    
    Scenario that triggers the crash:
    
    * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1
    
    * TBF dequeues: it peeks from SFQ which moves the packet to the
      gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so
      it schedules itself for later.
    
    * the second packet is sent and TBF tries to queues it to SFQ. qdisc
      qlen is now 2 and because the SFQ limit is 1 the packet is dropped
      by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,
      however q->tail is not NULL.
    
    At this point, assuming no more packets are queued, when sch_dequeue
    runs again it will decrement the qlen for the current empty slot
    causing an underflow and the subsequent out of bounds access.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Octavian Purdila <tavip@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241204030520.2084663-2-tavip@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58ae7465f0e7113d45aa88a66bf2d203c71c195e
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 8 11:16:03 2024 +0000

    net_sched: sch_sfq: handle bigger packets
    
    [ Upstream commit e4650d7ae4252f67e997a632adfae0dd74d3a99a ]
    
    SFQ has an assumption on dealing with packets smaller than 64KB.
    
    Even before BIG TCP, TCA_STAB can provide arbitrary big values
    in qdisc_pkt_len(skb)
    
    It is time to switch (struct sfq_slot)->allot to a 32bit field.
    
    sizeof(struct sfq_slot) is now 64 bytes, giving better cache locality.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://patch.msgid.link/20241008111603.653140-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 10685681bafc ("net_sched: sch_sfq: don't allow 1 packet limit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab18d76f7852c590d5c97a786b1c7e2bbedaccd5
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 30 18:00:15 2024 +0000

    net_sched: sch_sfq: annotate data-races around q->perturb_period
    
    [ Upstream commit a17ef9e6c2c1cf0fc6cd6ca6a9ce525c67d1da7f ]
    
    sfq_perturbation() reads q->perturb_period locklessly.
    Add annotations to fix potential issues.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240430180015.3111398-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 10685681bafc ("net_sched: sch_sfq: don't allow 1 packet limit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e95f9c408ff8311f75eeabc8acf34a66670d8815
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>
Date:   Mon Nov 4 21:00:35 2024 +0100

    wifi: wcn36xx: fix channel survey memory allocation size
    
    [ Upstream commit 6200d947f050efdba4090dfefd8a01981363d954 ]
    
    KASAN reported a memory allocation issue in wcn->chan_survey
    due to incorrect size calculation.
    This commit uses kcalloc to allocate memory for wcn->chan_survey,
    ensuring proper initialization and preventing the use of uninitialized
    values when there are no frames on the channel.
    
    Fixes: 29696e0aa413 ("wcn36xx: Track SNR and RSSI for each RX frame")
    Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
    Acked-by: Loic Poulain <loic.poulain@linaro.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Link: https://patch.msgid.link/20241104-wcn36xx-memory-allocation-v1-1-5ec901cf37b6@mainlining.org
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 568460c3c935ee51a85e0a8b2d448224df50289a
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu Nov 7 10:33:22 2024 -0300

    wifi: rtlwifi: usb: fix workqueue leak when probe fails
    
    [ Upstream commit f79bc5c67867c19ce2762e7934c20dbb835ed82c ]
    
    rtl_init_core creates a workqueue that is then assigned to rtl_wq.
    rtl_deinit_core does not destroy it. It is left to rtl_usb_deinit, which
    must be called in the probe error path.
    
    Fixes: 2ca20f79e0d8 ("rtlwifi: Add usb driver")
    Fixes: 851639fdaeac ("rtlwifi: Modify some USB de-initialize code.")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241107133322.855112-6-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82a843e949f7fa7da1494c9bf93baf3596363212
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu Nov 7 10:33:21 2024 -0300

    wifi: rtlwifi: fix init_sw_vars leak when probe fails
    
    [ Upstream commit 00260350aed80c002df270c805ca443ec9a719a6 ]
    
    If ieee80211_register_hw fails, the memory allocated for the firmware will
    not be released. Call deinit_sw_vars as the function that undoes the
    allocationes done by init_sw_vars.
    
    Fixes: cefe3dfdb9f5 ("rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241107133322.855112-5-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20893ffe7a48dccc41a0715a9c401b9f65fc5f7f
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu Nov 7 10:33:20 2024 -0300

    wifi: rtlwifi: wait for firmware loading before releasing memory
    
    [ Upstream commit b4b26642b31ef282df6ff7ea8531985edfdef12a ]
    
    At probe error path, the firmware loading work may have already been
    queued. In such a case, it will try to access memory allocated by the probe
    function, which is about to be released. In such paths, wait for the
    firmware worker to finish before releasing memory.
    
    Fixes: a7f7c15e945a ("rtlwifi: rtl8192cu: Free ieee80211_hw if probing fails")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241107133322.855112-4-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8a376b7b5f599472920620fc7b84bcda6c92aa8
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu Nov 7 10:33:19 2024 -0300

    wifi: rtlwifi: rtl8192se: rise completion of firmware loading as last step
    
    [ Upstream commit 8559a9e0c457729fe3edb3176bbf7c7874f482b0 ]
    
    Just like in commit 4dfde294b979 ("rtlwifi: rise completion at the last
    step of firmware callback"), only signal completion once the function is
    finished. Otherwise, the module removal waiting for the completion could
    free the memory that the callback will still use before returning.
    
    Fixes: b0302aba812b ("rtlwifi: Convert to asynchronous firmware load")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241107133322.855112-3-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b304e1f7edc5b0a34260564b37904127e570d284
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu Nov 7 10:33:18 2024 -0300

    wifi: rtlwifi: do not complete firmware loading needlessly
    
    [ Upstream commit e73e11d303940119e41850a0452a0deda2cc4eb5 ]
    
    The only code waiting for completion is driver removal, which will not be
    called when probe returns a failure. So this completion is unnecessary.
    
    Fixes: b0302aba812b ("rtlwifi: Convert to asynchronous firmware load")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241107133322.855112-2-cascardo@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4b764d99183e5e1bb3b3448a14cd805978f4f9f
Author: Balaji Pothunoori <quic_bpothuno@quicinc.com>
Date:   Wed Oct 30 17:16:25 2024 +0530

    wifi: ath11k: Fix unexpected return buffer manager error for WCN6750/WCN6855
    
    [ Upstream commit 78e154d42f2c72905fe66a400847e1b2b101b7b2 ]
    
    The following error messages were encountered while parsing fragmented RX
    packets for WCN6750/WCN6855:
    
    ath11k 17a10040.wifi: invalid return buffer manager 4
    
    This issue arose due to a hardcoded check for HAL_RX_BUF_RBM_SW3_BM
    introduced in 'commit 71c748b5e01e ("ath11k: Fix unexpected return buffer
    manager error for QCA6390")'
    
    For WCN6750 and WCN6855, the return buffer manager ID should be
    HAL_RX_BUF_RBM_SW1_BM. The incorrect conditional check caused fragmented
    packets to be dropped, resulting in the above error log.
    
    Fix this by adding a check for HAL_RX_BUF_RBM_SW1_BM.
    
    Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00258-QCAMSLSWPL-1
    Tested-on: WCN6855 hw2.1 WLAN.HSP.1.1-04479-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
    
    Fixes: 71c748b5e01e ("ath11k: Fix unexpected return buffer manager error for QCA6390")
    Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Acked-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241030114625.2416942-1-quic_bpothuno@quicinc.com
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c9caf86d04dcb10e9fd8cd9db8eb79b5bfcc4d8
Author: Charles Han <hanchunchao@inspur.com>
Date:   Thu Sep 26 17:44:19 2024 +0800

    ipmi: ipmb: Add check devm_kasprintf() returned value
    
    [ Upstream commit 2378bd0b264ad3a1f76bd957caf33ee0c7945351 ]
    
    devm_kasprintf() can return a NULL pointer on failure but this
    returned value is not checked.
    
    Fixes: 51bd6f291583 ("Add support for IPMB driver")
    Signed-off-by: Charles Han <hanchunchao@inspur.com>
    Message-ID: <20240926094419.25900-1-hanchunchao@inspur.com>
    Signed-off-by: Corey Minyard <corey@minyard.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20412f04bce862e4912c456b0d5f106aeea3bc55
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Dec 10 11:20:43 2024 +0100

    genirq: Make handle_enforce_irqctx() unconditionally available
    
    [ Upstream commit 8d187a77f04c14fb459a5301d69f733a5a1396bc ]
    
    Commit 1b57d91b969c ("irqchip/gic-v2, v3: Prevent SW resends entirely")
    sett the flag which enforces interrupt handling in interrupt context and
    prevents software base resends for ARM GIC v2/v3.
    
    But it missed that the helper function which checks the flag was hidden
    behind CONFIG_GENERIC_PENDING_IRQ, which is not set by ARM[64].
    
    Make the helper unconditionally available so that the enforcement actually
    works.
    
    Fixes: 1b57d91b969c ("irqchip/gic-v2, v3: Prevent SW resends entirely")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/all/20241210101811.497716609@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9d24e47419bd27383311ee9f927bd4fa4398716
Author: Jiang Liu <gerry@linux.alibaba.com>
Date:   Mon Dec 23 00:27:21 2024 +0800

    drm/amdgpu: tear down ttm range manager for doorbell in amdgpu_ttm_fini()
    
    [ Upstream commit 60a2c0c12b644450e420ffc42291d1eb248bacb7 ]
    
    Tear down ttm range manager for doorbell in function amdgpu_ttm_fini(),
    to avoid memory leakage.
    
    Fixes: 792b84fb9038 ("drm/amdgpu: initialize ttm for doorbells")
    Signed-off-by: Jiang Liu <gerry@linux.alibaba.com>
    Signed-off-by: Kent Russell <kent.russell@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e576f132cb423d218e8bed44315252be0325aff9
Author: Hermes Wu <hermes.wu@ite.com.tw>
Date:   Mon Dec 30 18:51:19 2024 +0800

    drm/bridge: it6505: Change definition of AUX_FIFO_MAX_SIZE
    
    [ Upstream commit c14870218c14532b0f0a7805b96a4d3c92d06fb2 ]
    
    The hardware AUX FIFO is 16 bytes
    Change definition of AUX_FIFO_MAX_SIZE to 16
    
    Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Hermes Wu <hermes.wu@ite.com.tw>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-1-e0fdd4844703@ite.corp-partner.google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41b72c3401a3d476704b418fee35cf378124f515
Author: Sui Jingfeng <sui.jingfeng@linux.dev>
Date:   Mon Nov 4 17:07:38 2024 +0800

    drm/msm: Check return value of of_dma_configure()
    
    [ Upstream commit b34a7401ffaee45354e81b38a4d072794079cfd6 ]
    
    Because the of_dma_configure() will returns '-EPROBE_DEFER' if the probe
    procedure of the specific platform IOMMU driver is not finished yet. It
    can also return other error code for various reasons.
    
    Stop pretending that it will always suceess, quit if it fail.
    
    Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Fixes: 29ac8979cdf7 ("drm/msm/a6xx: use msm_gem for GMU memory objects")
    Fixes: 5a903a44a984 ("drm/msm/a6xx: Introduce GMU wrapper support")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/622782/
    Link: https://lore.kernel.org/r/20241104090738.529848-1-sui.jingfeng@linux.dev
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d69ded4b4fd391132c60c3bb6fb9869a11024971
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Dec 20 03:28:34 2024 +0200

    drm/msm/dpu: link DSPP_2/_3 blocks on SM8550
    
    [ Upstream commit e21f9d85b05361bc343b11ecf84ac12c9cccbc3e ]
    
    Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows
    using colour transformation matrix (aka night mode) with more outputs at
    the same time.
    
    Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/629961/
    Link: https://lore.kernel.org/r/20241220-dpu-fix-catalog-v2-6-38fa961ea992@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d44b7452a58dccb9dea31ffbda6e5956510cd6cb
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Dec 20 03:28:33 2024 +0200

    drm/msm/dpu: link DSPP_2/_3 blocks on SM8350
    
    [ Upstream commit 42323d3c9e04c725d27606c31663b80a7cc30218 ]
    
    Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows
    using colour transformation matrix (aka night mode) with more outputs at
    the same time.
    
    Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/629959/
    Link: https://lore.kernel.org/r/20241220-dpu-fix-catalog-v2-5-38fa961ea992@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab3077fe61b8b2c66f0f0ca1d695d8f83219deda
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Dec 20 03:28:32 2024 +0200

    drm/msm/dpu: link DSPP_2/_3 blocks on SM8250
    
    [ Upstream commit 8252028092f86d413b3a83e5e76a9615073a0c7f ]
    
    Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows
    using colour transformation matrix (aka night mode) with more outputs at
    the same time.
    
    Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/629956/
    Link: https://lore.kernel.org/r/20241220-dpu-fix-catalog-v2-4-38fa961ea992@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ec5e1495ffe04ce655f5664fa13ddb441e68e53
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Dec 20 03:28:31 2024 +0200

    drm/msm/dpu: link DSPP_2/_3 blocks on SC8180X
    
    [ Upstream commit 0986163245df6bece47113e506143a7e87b0097d ]
    
    Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows
    using colour transformation matrix (aka night mode) with more outputs at
    the same time.
    
    Fixes: f5abecfe339e ("drm/msm/dpu: enable DSPP and DSC on sc8180x")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/629954/
    Link: https://lore.kernel.org/r/20241220-dpu-fix-catalog-v2-3-38fa961ea992@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 396c05f170da851e14ac2f2d70fdc96893190d1b
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Dec 20 03:28:30 2024 +0200

    drm/msm/dpu: link DSPP_2/_3 blocks on SM8150
    
    [ Upstream commit ac440a31e523805939215b24d2f0c451b48d5891 ]
    
    Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows
    using colour transformation matrix (aka night mode) with more outputs at
    the same time.
    
    Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/629952/
    Link: https://lore.kernel.org/r/20241220-dpu-fix-catalog-v2-2-38fa961ea992@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84ff05c9bd577157baed711a4f0b41206593978b
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Tue Dec 3 09:13:00 2024 +0100

    OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized
    
    [ Upstream commit b44b9bc7cab2967c3d6a791b1cd542c89fc07f0e ]
    
    If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth
    from the OPP table but the bandwidth table was not created because the
    interconnect properties were missing in the OPP consumer node, the
    kernel will crash with:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
    ...
    pc : _read_bw+0x8/0x10
    lr : _opp_table_find_key+0x9c/0x174
    ...
    Call trace:
      _read_bw+0x8/0x10 (P)
      _opp_table_find_key+0x9c/0x174 (L)
      _find_key+0x98/0x168
      dev_pm_opp_find_bw_ceil+0x50/0x88
    ...
    
    In order to fix the crash, create an assert function to check
    if the bandwidth table was created before trying to get a
    bandwidth with _read_bw().
    
    Fixes: add1dc094a74 ("OPP: Use generic key finding helpers for bandwidth key")
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb6ffa0192ba83ece1a318b956265519c5c7dcec
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Tue Dec 3 09:12:59 2024 +0100

    OPP: add index check to assert to avoid buffer overflow in _read_freq()
    
    [ Upstream commit d659bc68ed489022ea33342cfbda2911a81e7a0d ]
    
    Pass the freq index to the assert function to make sure
    we do not read a freq out of the opp->rates[] table when called
    from the indexed variants:
    dev_pm_opp_find_freq_exact_indexed() or
    dev_pm_opp_find_freq_ceil/floor_indexed().
    
    Add a secondary parameter to the assert function, unused
    for assert_single_clk() then add assert_clk_index() which
    will check for the clock index when called from the _indexed()
    find functions.
    
    Fixes: 142e17c1c2b4 ("OPP: Introduce dev_pm_opp_find_freq_{ceil/floor}_indexed() APIs")
    Fixes: a5893928bb17 ("OPP: Add dev_pm_opp_find_freq_exact_indexed()")
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 753c018fce5a3da194b988cc6e47021dbf33d01c
Author: Bokun Zhang <bokun.zhang@amd.com>
Date:   Wed Dec 11 15:42:56 2024 -0600

    drm/amdgpu/vcn: reset fw_shared under SRIOV
    
    [ Upstream commit 3676f37a88432132bcff55a17dc48911239b6d98 ]
    
    - The previous patch only considered the case for baremetal
      and is not applicable for SRIOV code path. We also need to
      init fw_share for SRIOV VF
    
    Fixes: 928cd772e18f ("drm/amdgpu/vcn: reset fw_shared when VCPU buffers corrupted on vcn v4.0.3")
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Bokun Zhang <bokun.zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26862f0223ef656cd49b2f30a71bb9de98258e6b
Author: Min-Hua Chen <minhuadotchen@gmail.com>
Date:   Sat Dec 14 16:17:06 2024 +0800

    drm/rockchip: vop2: include rockchip_drm_drv.h
    
    [ Upstream commit 77b1ccb2a27c7b3b118a03bf1730def92070d31b ]
    
    Move rockchip_drm_drv.h in rockchip_drm_vop2.h to fix the follow
    sparse warning:
    
    ARCH=arm64 LLVM=1 make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
    mrproper defconfig all  -j12
    
    drivers/gpu/drm/rockchip/rockchip_vop2_reg.c:502:24: sparse:
    warning: symbol 'vop2_platform_driver' was not declared. Should it
    be static?
    
    It is also beneficial for the upcoming support for rk3576.
    
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com>
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Reviewed-by: Min-Hua Chen <minhuadotchen@gmail.com>
    Tested-by: Detlev Casanova <detlev.casanova@collabora.com>
    Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-8-andyshrk@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7a2cc4952d14e57c12552ecc487e25654d4a9dc
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Mon Dec 11 19:56:27 2023 +0800

    drm/rockchip: move output interface related definition to rockchip_drm_drv.h
    
    [ Upstream commit 8c8546546f256f834e9c7cab48e5946df340d1a8 ]
    
    The output interface related definition can shared between
    vop and vop2, move them to rockchip_drm_drv.h can avoid duplicated
    definition.
    
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231211115627.1784735-1-andyshrk@163.com
    Stable-dep-of: 77b1ccb2a27c ("drm/rockchip: vop2: include rockchip_drm_drv.h")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b126c585fa3a3efd9bda089355d3b3ac6f19019b
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Sat Dec 14 16:17:04 2024 +0800

    drm/rockchip: vop2: Check linear format for Cluster windows on rk3566/8
    
    [ Upstream commit df063c0b8ffbdca486ab2f802e716973985d8f86 ]
    
    The Cluster windows on rk3566/8 only support afbc mode.
    
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-6-andyshrk@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 674bb131f70b4439224423cab433f746a922c4cc
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Sat Dec 14 16:17:01 2024 +0800

    drm/rockchip: vop2: Fix the windows switch between different layers
    
    [ Upstream commit 0ca953ac226eaffbe1a795f5e517095a8d494921 ]
    
    Every layer of vop2 should bind a window, and we also need to make
    sure that this window is not used by other layer.
    
    0x5 is a reserved layer sel value on rk3568, but it will select
    Cluster3 on rk3588, configure unused layers to 0x5  will lead
    alpha blending error on rk3588.
    
    When we bind a window from layerM to layerN, we move the old window
    on layerN to layerM.
    
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Tested-by: Derek Foreman <derek.foreman@collabora.com>
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-3-andyshrk@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66eeb05b7f7db9c9c42773c47408c8b9cc7efe07
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Mon Dec 11 19:58:15 2023 +0800

    drm/rockchip: vop2: set bg dly and prescan dly at vop2_post_config
    
    [ Upstream commit 075a5b3969becb1ebc2f1d4fa1a1fe9163679273 ]
    
    We need to setup background delay cycle and prescan
    delay cycle when a mode is enable to avoid trigger
    POST_BUF_EMPTY irq on rk3588.
    
    Note: RK356x has no such requirement.
    
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231211115815.1785131-1-andyshrk@163.com
    Stable-dep-of: 0ca953ac226e ("drm/rockchip: vop2: Fix the windows switch between different layers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a56ec21a29725daecc8f41df4ff32ee4273f10eb
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Mon Dec 11 19:58:05 2023 +0800

    drm/rockchip: vop2: Set YUV/RGB overlay mode
    
    [ Upstream commit dd49ee4614cfb0b1f627c4353b60cecfe998a374 ]
    
    Set overlay mode register according to the
    output mode is yuv or rgb.
    
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231211115805.1785073-1-andyshrk@163.com
    Stable-dep-of: 0ca953ac226e ("drm/rockchip: vop2: Fix the windows switch between different layers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b12c1f8c557ce383dbe8b801ef014fff2041a8e
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Mon Dec 9 20:29:16 2024 +0800

    drm/rockchip: vop2: Fix the mixer alpha setup for layer 0
    
    [ Upstream commit 6b4dfdcde3573a12b72d2869dabd4ca37ad7e9c7 ]
    
    The alpha setup should start from the second layer, the current calculation
    starts incorrectly from the first layer, a negative offset will be obtained
    in the following formula:
    
    offset = (mixer_id + zpos - 1) * 0x10
    
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Tested-by: Derek Foreman <derek.foreman@collabora.com>
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241209122943.2781431-7-andyshrk@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 556178977bfe9f5ad76d64cbe20b16ba0fa82881
Author: Andy Yan <andy.yan@rock-chips.com>
Date:   Mon Dec 9 20:29:15 2024 +0800

    drm/rockchip: vop2: Fix cluster windows alpha ctrl regsiters offset
    
    [ Upstream commit 17b4b10a0df1a1421d5fbdc03bad0bd3799bc966 ]
    
    The phy_id of cluster windws are not increase one for each window.
    
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Tested-by: Derek Foreman <derek.foreman@collabora.com>
    Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241209122943.2781431-6-andyshrk@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a30634a2e0f1dd3c6b39fd0f114c32893a9907a
Author: Ivan Stepchenko <sid@itb.spb.ru>
Date:   Mon Dec 2 11:00:43 2024 +0300

    drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table
    
    [ Upstream commit 357445e28ff004d7f10967aa93ddb4bffa5c3688 ]
    
    The function atomctrl_get_smc_sclk_range_table() does not check the return
    value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to
    retrieve SMU_Info table, it returns NULL which is later dereferenced.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    In practice this should never happen as this code only gets called
    on polaris chips and the vbios data table will always be present on
    those chips.
    
    Fixes: a23eefa2f461 ("drm/amd/powerplay: enable dpm for baffin.")
    Signed-off-by: Ivan Stepchenko <sid@itb.spb.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0c34936c3bb34e1bdbff7f5bc5e4af839fb45ca
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Nov 19 21:23:18 2024 +0100

    drm/amd/pm: Fix an error handling path in vega10_enable_se_edc_force_stall_config()
    
    [ Upstream commit a3300782d5375e280ba7040f323d01960bfe3396 ]
    
    In case of error after a amdgpu_gfx_rlc_enter_safe_mode() call, it is not
    balanced by a corresponding amdgpu_gfx_rlc_exit_safe_mode() call.
    
    Add the missing call.
    
    Fixes: 9b7b8154cdb8 ("drm/amd/powerplay: added didt support for vega10")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed3d3883476423f337aac0f22c521819b3f1e970
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Dec 31 14:23:12 2024 -0500

    HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections
    
    commit 64f2657b579343cf923aa933f08074e6258eb07b upstream.
    
    A report in 2019 by the syzbot fuzzer was found to be connected to two
    errors in the HID core associated with Resolution Multipliers.  One of
    the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop
    in hid_apply_multiplier."), but the other has not been fixed.
    
    This error arises because hid_apply_multipler() assumes that every
    Resolution Multiplier control is contained in a Logical Collection,
    i.e., there's no way the routine can ever set multiplier_collection to
    NULL.  This is in spite of the fact that the function starts with a
    big comment saying:
    
             * "The Resolution Multiplier control must be contained in the same
             * Logical Collection as the control(s) to which it is to be applied.
               ...
             *  If no Logical Collection is
             * defined, the Resolution Multiplier is associated with all
             * controls in the report."
             * HID Usage Table, v1.12, Section 4.3.1, p30
             *
             * Thus, search from the current collection upwards until we find a
             * logical collection...
    
    The comment and the code overlook the possibility that none of the
    collections found may be a Logical Collection.
    
    The fix is to set the multiplier_collection pointer to NULL if the
    collection found isn't a Logical Collection.
    
    Reported-by: syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/000000000000109c040597dc5843@google.com/
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: Peter Hutterer <peter.hutterer@who-t.net>
    Fixes: 5a4abb36f312 ("HID: core: process the Resolution Multiplier")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f029961b2d4782f60290677eb9433c5b9ded0e1b
Author: Sui Jingfeng <sui.jingfeng@linux.dev>
Date:   Mon Nov 4 08:41:56 2024 +0800

    drm/etnaviv: Fix page property being used for non writecombine buffers
    
    [ Upstream commit 834f304192834d6f0941954f3277ae0ba11a9a86 ]
    
    In the etnaviv_gem_vmap_impl() function, the driver vmap whatever buffers
    with write combine(WC) page property, this is incorrect. Cached buffers
    should be mapped with the cached page property and uncached buffers should
    be mapped with the uncached page property.
    
    Fixes: a0a5ab3e99b8 ("drm/etnaviv: call correct function when trying to vmap a DMABUF")
    Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d453d03a5e717ae476cd36ac15bbe53fbd53dc2a
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Dec 2 12:06:31 2024 +0200

    drm/msm/dp: set safe_to_exit_level before printing it
    
    [ Upstream commit 7dee35d79bb046bfd425aa9e58a82414f67c1cec ]
    
    Rather than printing random garbage from stack and pretending that it is
    the default safe_to_exit_level, set the variable beforehand.
    
    Fixes: d13e36d7d222 ("drm/msm/dp: add audio support for Display Port on MSM")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202411081748.0PPL9MIj-lkp@intel.com/
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/626804/
    Link: https://lore.kernel.org/r/20241202-fd-dp-audio-fixup-v2-1-d9187ea96dad@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccfdd3e19c790c90e4928a11ff38c6c2be383d26
Author: K Prateek Nayak <kprateek.nayak@amd.com>
Date:   Mon Dec 23 04:34:04 2024 +0000

    x86/topology: Use x86_sched_itmt_flags for PKG domain unconditionally
    
    [ Upstream commit e1bc02646527fc1ed74f00eb599b2b74d49671c7 ]
    
    x86_sched_itmt_flags() returns SD_ASYM_PACKING if ITMT support is
    enabled by the system. Without ITMT support being enabled, it returns 0
    similar to current x86_die_flags() on non-Hybrid systems
    (!X86_HYBRID_CPU and !X86_FEATURE_AMD_HETEROGENEOUS_CORES)
    
    On Intel systems that enable ITMT support, either the MC domain
    coincides with the PKG domain, or in case of multiple MC groups
    within a PKG domain, either Sub-NUMA Cluster (SNC) is enabled or the
    processor features Hybrid core layout (X86_HYBRID_CPU) which leads to
    three distinct possibilities:
    
    o If PKG and MC domains coincide, PKG domain is degenerated by
      sd_parent_degenerate() when building sched domain topology.
    
    o If SNC is enabled, PKG domain is never added since
      "x86_has_numa_in_package" is set and the topology will instead contain
      NODE and NUMA domains.
    
    o On X86_HYBRID_CPU which contains multiple MC groups within the PKG,
      the PKG domain requires x86_sched_itmt_flags().
    
    Thus, on Intel systems that contains multiple MC groups within the PKG
    and enables ITMT support, the PKG domain requires
    x86_sched_itmt_flags(). In all other cases PKG domain is either never
    added or is degenerated. Thus, returning x86_sched_itmt_flags()
    unconditionally at PKG domain on Intel systems should not lead to any
    functional changes.
    
    On AMD systems with multiple LLCs (MC groups) within a PKG domain,
    enabling ITMT support requires setting SD_ASYM_PACKING to the PKG domain
    since the core rankings are assigned PKG-wide.
    
    Core rankings on AMD processors is currently set by the amd-pstate
    driver when Preferred Core feature is supported. A subset of systems that
    support Preferred Core feature can be detected using
    X86_FEATURE_AMD_HETEROGENEOUS_CORES however, this does not cover all the
    systems that support Preferred Core ranking.
    
    Detecting Preferred Core support on AMD systems requires inspecting CPPC
    Highest Perf on all present CPUs and checking if it differs on at least
    one CPU. Previous suggestion to use a synthetic feature to detect
    Preferred Core support [1] was found to be non-trivial to implement
    since BSP alone cannot detect if Preferred Core is supported and by the
    time AP comes up, alternatives are patched and setting a X86_FEATURE_*
    then is not possible.
    
    Since x86 processors enabling ITMT support that consists multiple
    non-NUMA MC groups within a PKG requires SD_ASYM_PACKING flag set at the
    PKG domain, return x86_sched_itmt_flags unconditionally for the PKG
    domain.
    
    Since x86_die_flags() would have just returned x86_sched_itmt_flags()
    after the change, remove the unnecessary wrapper and pass
    x86_sched_itmt_flags() directly as the flags function.
    
    Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support")
    Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
    Link: https://lore.kernel.org/r/20241223043407.1611-6-kprateek.nayak@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 046cf2bacea6b47f4289bc73dfbcb35d47308da3
Author: Perry Yuan <perry.yuan@amd.com>
Date:   Fri Oct 25 12:14:57 2024 -0500

    x86/cpu: Enable SD_ASYM_PACKING for PKG domain on AMD
    
    [ Upstream commit b0979e53645825a38f814ca5d3d09aed2745911d ]
    
    Enable the SD_ASYM_PACKING domain flag for the PKG domain on AMD heterogeneous
    processors.  This flag is beneficial for processors with one or more CCDs and
    relies on x86_sched_itmt_flags().
    
    Signed-off-by: Perry Yuan <perry.yuan@amd.com>
    Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Link: https://lore.kernel.org/r/20241025171459.1093-4-mario.limonciello@amd.com
    Stable-dep-of: e1bc02646527 ("x86/topology: Use x86_sched_itmt_flags for PKG domain unconditionally")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbef443cab0e677097bdacf0ca0acf9e60a53c19
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Jul 12 16:10:56 2023 +0200

    sched/topology: Rename 'DIE' domain to 'PKG'
    
    [ Upstream commit f577cd57bfaa889cf0718e30e92c08c7f78c9d85 ]
    
    While reworking the x86 topology code Thomas tripped over creating a 'DIE' domain
    for the package mask. :-)
    
    Since these names are CONFIG_SCHED_DEBUG=y only, rename them to make the
    name less ambiguous.
    
    [ Shrikanth Hegde: rename on s390 as well. ]
    [ Valentin Schneider: also rename it in the comments. ]
    [ mingo: port to recent kernels & find all remaining occurances. ]
    
    Reported-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Valentin Schneider <vschneid@redhat.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Acked-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Acked-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20230712141056.GI3100107@hirez.programming.kicks-ass.net
    Stable-dep-of: e1bc02646527 ("x86/topology: Use x86_sched_itmt_flags for PKG domain unconditionally")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32fe5c4c3e553ae83f6c45242b50c79cfd74cd5a
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Dec 20 06:32:19 2024 +0000

    sched/fair: Fix value reported by hot tasks pulled in /proc/schedstat
    
    [ Upstream commit a430d99e349026d53e2557b7b22bd2ebd61fe12a ]
    
    In /proc/schedstat, lb_hot_gained reports the number hot tasks pulled
    during load balance. This value is incremented in can_migrate_task()
    if the task is migratable and hot. After incrementing the value,
    load balancer can still decide not to migrate this task leading to wrong
    accounting. Fix this by incrementing stats when hot tasks are detached.
    This issue only exists in detach_tasks() where we can decide to not
    migrate hot task even if it is migratable. However, in detach_one_task(),
    we migrate it unconditionally.
    
    [Swapnil: Handled the case where nr_failed_migrations_hot was not accounted properly and wrote commit log]
    
    Fixes: d31980846f96 ("sched: Move up affinity check to mitigate useless redoing overhead")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reported-by: "Gautham R. Shenoy" <gautham.shenoy@amd.com>
    Not-yet-signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241220063224.17767-2-swapnil.sapkal@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0dbecb204cfb91999d0b785048be4a95bbc8c9c
Author: Yabin Cui <yabinc@google.com>
Date:   Wed May 15 12:36:07 2024 -0700

    perf/core: Save raw sample data conditionally based on sample type
    
    [ Upstream commit b9c44b91476b67327a521568a854babecc4070ab ]
    
    Currently, space for raw sample data is always allocated within sample
    records for both BPF output and tracepoint events. This leads to unused
    space in sample records when raw sample data is not requested.
    
    This patch enforces checking sample type of an event in
    perf_sample_save_raw_data(). So raw sample data will only be saved if
    explicitly requested, reducing overhead when it is not needed.
    
    Fixes: 0a9081cf0a11 ("perf/core: Add perf_sample_save_raw_data() helper")
    Signed-off-by: Yabin Cui <yabinc@google.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20240515193610.2350456-2-yabinc@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c89b19e9628164fc6681744c9637bcf971a10b02
Author: David Howells <dhowells@redhat.com>
Date:   Tue Jan 14 14:46:03 2025 +0000

    afs: Fix the fallback handling for the YFS.RemoveFile2 RPC call
    
    [ Upstream commit e30458d690f35abb01de8b3cbc09285deb725d00 ]
    
    Fix a pair of bugs in the fallback handling for the YFS.RemoveFile2 RPC
    call:
    
     (1) Fix the abort code check to also look for RXGEN_OPCODE.  The lack of
         this masks the second bug.
    
     (2) call->server is now not used for ordinary filesystem RPC calls that
         have an operation descriptor.  Fix to use call->op->server instead.
    
    Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/109541.1736865963@warthog.procyon.org.uk
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db996ed1990153f8af88fae216dae550a2623044
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 13 10:27:54 2025 -0700

    nvme: fix bogus kzalloc() return check in nvme_init_effects_log()
    
    [ Upstream commit 170e086ad3997f816d1f551f178a03a626a130b7 ]
    
    nvme_init_effects_log() returns failure when kzalloc() is successful,
    which is obviously wrong and causes failures to boot. Correct the
    check.
    
    Fixes: d4a95adeabc6 ("nvme: Add error path for xa_store in nvme_init_effects")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1951c169377afb398aa3da294f26e2693a67e9c
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Jan 13 09:37:24 2025 +0100

    select: Fix unbalanced user_access_end()
    
    [ Upstream commit 344af27715ddbf357cf76978d674428b88f8e92d ]
    
    While working on implementing user access validation on powerpc
    I got the following warnings on a pmac32_defconfig build:
    
              CC      fs/select.o
            fs/select.o: warning: objtool: sys_pselect6+0x1bc: redundant UACCESS disable
            fs/select.o: warning: objtool: sys_pselect6_time32+0x1bc: redundant UACCESS disable
    
    On powerpc/32s, user_read_access_begin/end() are no-ops, but the
    failure path has a user_access_end() instead of user_read_access_end()
    which means an access end without any prior access begin.
    
    Replace that user_access_end() by user_read_access_end().
    
    Fixes: 7e71609f64ec ("pselect6() and friends: take handling the combined 6th/7th args into helper")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Link: https://lore.kernel.org/r/a7139e28d767a13e667ee3c79599a8047222ef36.1736751221.git.christophe.leroy@csgroup.eu
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6cfeb1c28502039af07d66364f031856c095cb9
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Jan 10 22:27:58 2025 -0800

    partitions: ldm: remove the initial kernel-doc notation
    
    [ Upstream commit e494e451611a3de6ae95f99e8339210c157d70fb ]
    
    Remove the file's first comment describing what the file is.
    This comment is not in kernel-doc format so it causes a kernel-doc
    warning.
    
    ldm.h:13: warning: expecting prototype for ldm(). Prototype was for _FS_PT_LDM_H_() instead
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Richard Russon (FlatCap) <ldm@flatcap.org>
    Cc: linux-ntfs-dev@lists.sourceforge.net
    Cc: Jens Axboe <axboe@kernel.dk>
    Link: https://lore.kernel.org/r/20250111062758.910458-1-rdunlap@infradead.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 525dc0f60469fb315d900d7ebcc30a01384e9ad9
Author: Keisuke Nishimura <keisuke.nishimura@inria.fr>
Date:   Mon Dec 16 16:27:20 2024 +0100

    nvme: Add error path for xa_store in nvme_init_effects
    
    [ Upstream commit d4a95adeabc6b5a39405e49c6d5ed14dd83682c4 ]
    
    The xa_store() may fail due to memory allocation failure because there
    is no guarantee that the index NVME_CSI_NVM is already used. This fix
    introduces a new function to handle the error path.
    
    Fixes: cc115cbe12d9 ("nvme: always initialize known command effects")
    Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 136f70dc96b8424a928dc50a0d7429d87a8aef6b
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Dec 18 22:43:47 2024 +1100

    selftests/powerpc: Fix argument order to timer_sub()
    
    [ Upstream commit 2bf66e66d2e6feece6175ec09ec590a0a8563bdd ]
    
    Commit c814bf958926 ("powerpc/selftests: Use timersub() for
    gettimeofday()"), got the order of arguments to timersub() wrong,
    leading to a negative time delta being reported, eg:
    
      test: gettimeofday
      tags: git_version:v6.12-rc5-409-gdddf291c3030
      time = -3.297781
      success: gettimeofday
    
    The correct order is minuend, subtrahend, which in this case is end,
    start. Which gives:
    
      test: gettimeofday
      tags: git_version:v6.12-rc5-409-gdddf291c3030-dirty
      time = 3.300650
      success: gettimeofday
    
    Fixes: c814bf958926 ("powerpc/selftests: Use timersub() for gettimeofday()")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20241218114347.428108-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48ef61d25e7998873bac69de1152daf84bfe4226
Author: Keisuke Nishimura <keisuke.nishimura@inria.fr>
Date:   Fri Dec 20 13:00:47 2024 +0100

    nvme: Add error check for xa_store in nvme_get_effects_log
    
    [ Upstream commit ac32057acc7f3d7a238dafaa9b2aa2bc9750080e ]
    
    The xa_store() may fail due to memory allocation failure because there
    is no guarantee that the index csi is already used. This fix adds an
    error check of the return value of xa_store() in nvme_get_effects_log().
    
    Fixes: 1cf7a12e09aa ("nvme: use an xarray to lookup the Commands Supported and Effects log")
    Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df62fac30c060c350f62793bfd20118abe75e4c2
Author: Eugen Hristev <eugen.hristev@linaro.org>
Date:   Wed Jan 1 13:19:21 2025 +0200

    pstore/blk: trivial typo fixes
    
    [ Upstream commit 542243af7182efaeaf6d0f4643f7de437541a9af ]
    
    Fix trivial typos in comments.
    
    Fixes: 2a03ddbde1e1 ("pstore/blk: Move verify_size() macro out of function")
    Fixes: 17639f67c1d6 ("pstore/blk: Introduce backend for block devices")
    Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org>
    Link: https://lore.kernel.org/r/20250101111921.850406-1-eugen.hristev@linaro.org
    Signed-off-by: Kees Cook <kees@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d208d2c52b652913b5eefc8ca434b0d6b757f68f
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Jan 3 17:28:59 2025 +0800

    nbd: don't allow reconnect after disconnect
    
    [ Upstream commit 844b8cdc681612ff24df62cdefddeab5772fadf1 ]
    
    Following process can cause nbd_config UAF:
    
    1) grab nbd_config temporarily;
    
    2) nbd_genl_disconnect() flush all recv_work() and release the
    initial reference:
    
      nbd_genl_disconnect
       nbd_disconnect_and_put
        nbd_disconnect
         flush_workqueue(nbd->recv_workq)
        if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))
         nbd_config_put
         -> due to step 1), reference is still not zero
    
    3) nbd_genl_reconfigure() queue recv_work() again;
    
      nbd_genl_reconfigure
       config = nbd_get_config_unlocked(nbd)
       if (!config)
       -> succeed
       if (!test_bit(NBD_RT_BOUND, ...))
       -> succeed
       nbd_reconnect_socket
        queue_work(nbd->recv_workq, &args->work)
    
    4) step 1) release the reference;
    
    5) Finially, recv_work() will trigger UAF:
    
      recv_work
       nbd_config_put(nbd)
       -> nbd_config is freed
       atomic_dec(&config->recv_threads)
       -> UAF
    
    Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so
    that nbd_genl_reconfigure() will fail.
    
    Fixes: b7aa3d39385d ("nbd: add a reconfigure netlink command")
    Reported-by: syzbot+6b0df248918b92c33e6a@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/675bfb65.050a0220.1a2d0d.0006.GAE@google.com/
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20250103092859.3574648-1-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1e537fa23079c85efcd55b721c84d60a2752f39
Author: Yang Erkun <yangerkun@huawei.com>
Date:   Mon Dec 9 19:04:35 2024 +0800

    block: retry call probe after request_module in blk_request_module
    
    [ Upstream commit 457ef47c08d2979f3e59ce66267485c3faed70c8 ]
    
    Set kernel config:
    
     CONFIG_BLK_DEV_LOOP=m
     CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
    
    Do latter:
    
     mknod loop0 b 7 0
     exec 4<> loop0
    
    Before commit e418de3abcda ("block: switch gendisk lookup to a simple
    xarray"), lookup_gendisk will first use base_probe to load module loop,
    and then the retry will call loop_probe to prepare the loop disk. Finally
    open for this disk will success. However, after this commit, we lose the
    retry logic, and open will fail with ENXIO. Block device autoloading is
    deprecated and will be removed soon, but maybe we should keep open success
    until we really remove it. So, give a retry to fix it.
    
    Fixes: e418de3abcda ("block: switch gendisk lookup to a simple xarray")
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Yang Erkun <yangerkun@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20241209110435.3670985-1-yangerkun@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5aa2d3a8872673793a84405a18132bf68efdb04c
Author: Jinliang Zheng <alexjlzheng@gmail.com>
Date:   Sun Nov 24 11:46:36 2024 +0800

    fs: fix proc_handler for sysctl_nr_open
    
    [ Upstream commit d727935cad9f6f52c8d184968f9720fdc966c669 ]
    
    Use proc_douintvec_minmax() instead of proc_dointvec_minmax() to handle
    sysctl_nr_open, because its data type is unsigned int, not int.
    
    Fixes: 9b80a184eaad ("fs/file: more unsigned file descriptors")
    Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>
    Link: https://lore.kernel.org/r/20241124034636.325337-1-alexjlzheng@tencent.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5e157074798181699bf858e80871229aad21292
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 16 20:41:14 2024 +0000

    afs: Fix cleanup of immediately failed async calls
    
    [ Upstream commit 9750be93b2be12b6d92323b97d7c055099d279e6 ]
    
    If we manage to begin an async call, but fail to transmit any data on it
    due to a signal, we then abort it which causes a race between the
    notification of call completion from rxrpc and our attempt to cancel the
    notification.  The notification will be necessary, however, for async
    FetchData to terminate the netfs subrequest.
    
    However, since we get a notification from rxrpc upon completion of a call
    (aborted or otherwise), we can just leave it to that.
    
    This leads to calls not getting cleaned up, but appearing in
    /proc/net/rxrpc/calls as being aborted with code 6.
    
    Fix this by making the "error_do_abort:" case of afs_make_call() abort the
    call and then abandon it to the notification handler.
    
    Fixes: 34fa47612bfe ("afs: Fix race in async call refcounting")
    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20241216204124.3752367-25-dhowells@redhat.com
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e8ea8e80a469742993b1aa006b44ef8911001a0
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 16 20:41:03 2024 +0000

    afs: Fix directory format encoding struct
    
    [ Upstream commit 07a10767853adcbdbf436dc91393b729b52c4e81 ]
    
    The AFS directory format structure, union afs_xdr_dir_block::meta, has too
    many alloc counter slots declared and so pushes the hash table along and
    over the data.  This doesn't cause a problem at the moment because I'm
    currently ignoring the hash table and only using the correct number of
    alloc_ctrs in the code anyway.  In future, however, I should start using
    the hash table to try and speed up afs_lookup().
    
    Fix this by using the correct constant to declare the counter array.
    
    Fixes: 4ea219a839bf ("afs: Split the directory content defs into a header")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20241216204124.3752367-14-dhowells@redhat.com
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 684ce13e3f1a45b9ba0af0946b90ad568010d7ae
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 16 20:41:02 2024 +0000

    afs: Fix EEXIST error returned from afs_rmdir() to be ENOTEMPTY
    
    [ Upstream commit b49194da2aff2c879dec9c59ef8dec0f2b0809ef ]
    
    AFS servers pass back a code indicating EEXIST when they're asked to remove
    a directory that is not empty rather than ENOTEMPTY because not all the
    systems that an AFS server can run on have the latter error available and
    AFS preexisted the addition of that error in general.
    
    Fix afs_rmdir() to translate EEXIST to ENOTEMPTY.
    
    Fixes: 260a980317da ("[AFS]: Add "directory write" support.")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20241216204124.3752367-13-dhowells@redhat.com
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ee9c048089ff64d9ec8642b2513de172ecc145d
Author: Alexander Aring <aahringo@redhat.com>
Date:   Mon Dec 2 10:26:37 2024 -0500

    dlm: fix srcu_read_lock() return type to int
    
    [ Upstream commit 57cdd1a1cf1464199678f9338049b63fb5d5b41c ]
    
    The return type of srcu_read_lock() is int and not bool. Whereas we
    using the ret variable only to evaluate a bool type of
    dlm_lowcomms_con_has_addr() to check if an address is already being set.
    
    Fixes: 6f0b0b5d7ae7 ("fs: dlm: remove dlm_node_addrs lookup list")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9055078501709ae008e4a1ccf0c978d99541c70b
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Tue Dec 17 13:16:40 2024 +0530

    powerpc/book3s64/hugetlb: Fix disabling hugetlb when fadump is active
    
    [ Upstream commit d629d7a8efc33d05d62f4805c0ffb44727e3d99f ]
    
    Commit 8597538712eb ("powerpc/fadump: Do not use hugepages when fadump
    is active") disabled hugetlb support when fadump is active by returning
    early from hugetlbpage_init():arch/powerpc/mm/hugetlbpage.c and not
    populating hpage_shift/HPAGE_SHIFT.
    
    Later, commit 2354ad252b66 ("powerpc/mm: Update default hugetlb size
    early") moved the allocation of hpage_shift/HPAGE_SHIFT to early boot,
    which inadvertently re-enabled hugetlb support when fadump is active.
    
    Fix this by implementing hugepages_supported() on powerpc. This ensures
    that disabling hugetlb for the fadump kernel is independent of
    hpage_shift/HPAGE_SHIFT.
    
    Fixes: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early")
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20241217074640.1064510-1-sourabhjain@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>