Changelog in Linux kernel 6.15.2

 
acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio() [+ + +]
Author: Gautham R. Shenoy <[email protected]>
Date:   Thu May 29 14:21:43 2025 +0530

    acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio()
    
    commit cb6a85f38f456b086c366e346ebb67ffa70c7243 upstream.
    
    commit 083466754596 ("cpufreq: ACPI: Fix max-frequency computation")
    modified get_max_boost_ratio() to return the nominal_freq advertised
    in the _CPC object. This was for the purposes of computing the maximum
    frequency. The frequencies advertised in _CPC objects are in
    MHz. However, cpufreq expects the frequency to be in KHz. Since the
    nominal_freq returned by get_max_boost_ratio() was not in KHz but
    instead in MHz,the cpuinfo_max_frequency that was computed using this
    nominal_freq was incorrect and an invalid value which resulted in
    cpufreq reporting the P0 frequency as the cpuinfo_max_freq.
    
    Fix this by converting the nominal_freq to KHz before returning the
    same from get_max_boost_ratio().
    
    Reported-by: Manu Bretelle <[email protected]>
    Closes: https://lore.kernel.org/lkml/aDaB63tDvbdcV0cg@HQ-GR2X1W2P57/
    Fixes: 083466754596 ("cpufreq: ACPI: Fix max-frequency computation")
    Signed-off-by: Gautham R. Shenoy <[email protected]>
    Cc: 6.14+ <[email protected]> # 6.14+
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ACPICA: Apply ACPI_NONSTRING [+ + +]
Author: Kees Cook <[email protected]>
Date:   Fri Apr 25 21:28:34 2025 +0200

    ACPICA: Apply ACPI_NONSTRING
    
    commit 2b82118845e04c7adf4ece797150c19809bab29b upstream.
    
    ACPICA commit ed68cb8e082e3bfbba02814af4fd5a61247f491b
    
    Add ACPI_NONSTRING annotations for places found that are using char
    arrays without a terminating NUL character. These were found during
    Linux kernel builds and after looking for instances of arrays of size
    ACPI_NAMESEG_SIZE.
    
    Link: https://github.com/acpica/acpica/commit/ed68cb8e
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: Jiri Slaby <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPICA: Apply ACPI_NONSTRING in more places [+ + +]
Author: Ahmed Salem <[email protected]>
Date:   Fri Apr 25 21:31:05 2025 +0200

    ACPICA: Apply ACPI_NONSTRING in more places
    
    commit 70662db73d5455ebc8a1da29973fa70237b18cd2 upstream.
    
    ACPICA commit 1035a3d453f7dd49a235a59ee84ebda9d2d2f41b
    
    Add ACPI_NONSTRING for destination char arrays without a terminating NUL
    character. This is a follow-up to commit 35ad99236f3a ("ACPICA: Apply
    ACPI_NONSTRING") where not all instances received the same treatment, in
    preparation for replacing strncpy() calls with memcpy()
    
    Link: https://github.com/acpica/acpica/commit/1035a3d4
    Signed-off-by: Ahmed Salem <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: Jiri Slaby <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPICA: Introduce ACPI_NONSTRING [+ + +]
Author: Kees Cook <[email protected]>
Date:   Fri Apr 25 21:27:58 2025 +0200

    ACPICA: Introduce ACPI_NONSTRING
    
    commit 6da5e6f3028d46e4fee7849e85eda681939c630b upstream.
    
    ACPICA commit 878823ca20f1987cba0c9d4c1056be0d117ea4fe
    
    In order to distinguish character arrays from C Strings (i.e. strings with
    a terminating NUL character), add support for the "nonstring" attribute
    provided by GCC. (A better name might be "ACPI_NONCSTRING", but that's
    the attribute name, so stick to the existing naming convention.)
    
    GCC 15's -Wunterminated-string-initialization will warn about truncation
    of the NUL byte for string initializers unless the destination is marked
    with "nonstring". Prepare for applying this attribute to the project.
    
    Link: https://github.com/acpica/acpica/commit/878823ca
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    [ rjw: Pick up the tag from Kees ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Cc: Jiri Slaby <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bcachefs: delete dead code from may_delete_deleted_inode() [+ + +]
Author: Kent Overstreet <[email protected]>
Date:   Mon Jun 2 18:26:44 2025 -0400

    bcachefs: delete dead code from may_delete_deleted_inode()
    
    commit bb6689bbeebc6fb51f0f120b486bdcc9a38ffcf6 upstream.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bcachefs: Fix subvol to missing root repair [+ + +]
Author: Kent Overstreet <[email protected]>
Date:   Mon Jun 2 19:48:27 2025 -0400

    bcachefs: Fix subvol to missing root repair
    
    commit 29cc6fb7c068c773049d3bde14b939033893eff4 upstream.
    
    We had a bug where the root inode of a subvolume was erronously deleted:
    bch2_evict_inode() called bch2_inode_rm(), meaning the VFS inode's
    i_nlink was somehow set to 0 when it shouldn't have - the inode in the
    btree indicated it clearly was not unlinked.
    
    This has been addressed with additional safety checks in
    bch2_inode_rm() - pulling in the safety checks we already were doing
    when deleting unlinked inodes in recovery - but the really disastrous
    bug was in check_subvols(), which on finding a dangling subvol (subvol
    with a missing root inode) would delete the subvolume.
    
    I assume this bug dates from early check_directory_structure() code,
    which originally handled subvolumes and normal paths - the idea being
    that still live contents of the subvolume would get reattached
    somewhere.
    
    But that's incorrect, and disastrously so; deleting a subvolume triggers
    deleting the snapshot ID it points to, deleting the entire contents.
    
    The correct way to repair is to recreate the root inode if it's missing;
    then any contents will get reattached under that subvolume's lost+found.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bcachefs: Kill un-reverted directory i_size code [+ + +]
Author: Kent Overstreet <[email protected]>
Date:   Sat May 31 18:32:37 2025 -0400

    bcachefs: Kill un-reverted directory i_size code
    
    commit 95fafc0f3407a6446082c11849df585bd3246571 upstream.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bcachefs: Repair code for directory i_size [+ + +]
Author: Kent Overstreet <[email protected]>
Date:   Sat May 31 11:58:11 2025 -0400

    bcachefs: Repair code for directory i_size
    
    commit 36a2fdf7c5c1ccae6ca16cd14067567096cebe17 upstream.
    
    We had a bug due due to an incomplete revert of the patch implementing
    directory i_size (summing up the size of the dirents), leading to
    completely screwy i_size values that underflow.
    
    Most userspace programs don't seem to care (e.g. du ignores it), but it
    turns out this broke sshfs, so needs to be repaired.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bcachefs: Run may_delete_deleted_inode() checks in bch2_inode_rm() [+ + +]
Author: Kent Overstreet <[email protected]>
Date:   Mon Jun 2 17:43:36 2025 -0400

    bcachefs: Run may_delete_deleted_inode() checks in bch2_inode_rm()
    
    commit 09fb85ae565645b982e9030dbb2ff6707f2cdddc upstream.
    
    We had a bug where bch2_evict_inode() incorrectly called bch2_inode_rm()
    - the journal clearly showed the inode was not unlinked.
    
    We've got checks that we use in recovery when cleaning up deleted
    inodes, lift them to bch2_inode_rm() as well.
    
    Signed-off-by: Kent Overstreet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
binder: fix use-after-free in binderfs_evict_inode() [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Sat May 17 17:09:56 2025 +0000

    binder: fix use-after-free in binderfs_evict_inode()
    
    commit 8c0a559825281764061a127632e5ad273f0466ad upstream.
    
    Running 'stress-ng --binderfs 16 --timeout 300' under KASAN-enabled
    kernel, I've noticed the following:
    
    BUG: KASAN: slab-use-after-free in binderfs_evict_inode+0x1de/0x2d0
    Write of size 8 at addr ffff88807379bc08 by task stress-ng-binde/1699
    
    CPU: 0 UID: 0 PID: 1699 Comm: stress-ng-binde Not tainted 6.14.0-rc7-g586de92313fc-dirty #13
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x1c2/0x2a0
     ? __pfx_dump_stack_lvl+0x10/0x10
     ? __pfx__printk+0x10/0x10
     ? __pfx_lock_release+0x10/0x10
     ? __virt_addr_valid+0x18c/0x540
     ? __virt_addr_valid+0x469/0x540
     print_report+0x155/0x840
     ? __virt_addr_valid+0x18c/0x540
     ? __virt_addr_valid+0x469/0x540
     ? __phys_addr+0xba/0x170
     ? binderfs_evict_inode+0x1de/0x2d0
     kasan_report+0x147/0x180
     ? binderfs_evict_inode+0x1de/0x2d0
     binderfs_evict_inode+0x1de/0x2d0
     ? __pfx_binderfs_evict_inode+0x10/0x10
     evict+0x524/0x9f0
     ? __pfx_lock_release+0x10/0x10
     ? __pfx_evict+0x10/0x10
     ? do_raw_spin_unlock+0x4d/0x210
     ? _raw_spin_unlock+0x28/0x50
     ? iput+0x697/0x9b0
     __dentry_kill+0x209/0x660
     ? shrink_kill+0x8d/0x2c0
     shrink_kill+0xa9/0x2c0
     shrink_dentry_list+0x2e0/0x5e0
     shrink_dcache_parent+0xa2/0x2c0
     ? __pfx_shrink_dcache_parent+0x10/0x10
     ? __pfx_lock_release+0x10/0x10
     ? __pfx_do_raw_spin_lock+0x10/0x10
     do_one_tree+0x23/0xe0
     shrink_dcache_for_umount+0xa0/0x170
     generic_shutdown_super+0x67/0x390
     kill_litter_super+0x76/0xb0
     binderfs_kill_super+0x44/0x90
     deactivate_locked_super+0xb9/0x130
     cleanup_mnt+0x422/0x4c0
     ? lockdep_hardirqs_on+0x9d/0x150
     task_work_run+0x1d2/0x260
     ? __pfx_task_work_run+0x10/0x10
     resume_user_mode_work+0x52/0x60
     syscall_exit_to_user_mode+0x9a/0x120
     do_syscall_64+0x103/0x210
     ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0xcac57b
    Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8
    RSP: 002b:00007ffecf4226a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
    RAX: 0000000000000000 RBX: 00007ffecf422720 RCX: 0000000000cac57b
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850
    RBP: 00007ffecf422850 R08: 0000000028d06ab1 R09: 7fffffffffffffff
    R10: 3fffffffffffffff R11: 0000000000000246 R12: 00007ffecf422718
    R13: 00007ffecf422710 R14: 00007f478f87b658 R15: 00007ffecf422830
     </TASK>
    
    Allocated by task 1705:
     kasan_save_track+0x3e/0x80
     __kasan_kmalloc+0x8f/0xa0
     __kmalloc_cache_noprof+0x213/0x3e0
     binderfs_binder_device_create+0x183/0xa80
     binder_ctl_ioctl+0x138/0x190
     __x64_sys_ioctl+0x120/0x1b0
     do_syscall_64+0xf6/0x210
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 1705:
     kasan_save_track+0x3e/0x80
     kasan_save_free_info+0x46/0x50
     __kasan_slab_free+0x62/0x70
     kfree+0x194/0x440
     evict+0x524/0x9f0
     do_unlinkat+0x390/0x5b0
     __x64_sys_unlink+0x47/0x50
     do_syscall_64+0xf6/0x210
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    This 'stress-ng' workload causes the concurrent deletions from
    'binder_devices' and so requires full-featured synchronization
    to prevent list corruption.
    
    I've found this issue independently but pretty sure that syzbot did
    the same, so Reported-by: and Closes: should be applicable here as well.
    
    Cc: [email protected]
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=353d7b75658a95aa955a
    Fixes: e77aff5528a18 ("binderfs: fix use-after-free in binder_devices")
    Signed-off-by: Dmitry Antipov <[email protected]>
    Acked-by: Carlos Llamas <[email protected]>
    Signed-off-by: Carlos Llamas <[email protected]>
    Reviewed-by: Alice Ryhl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

binder: fix yet another UAF in binder_devices [+ + +]
Author: Carlos Llamas <[email protected]>
Date:   Sat May 24 22:07:58 2025 +0000

    binder: fix yet another UAF in binder_devices
    
    commit 9857af0fcff385c75433f2162c30c62eb912ef6d upstream.
    
    Commit e77aff5528a18 ("binderfs: fix use-after-free in binder_devices")
    addressed a use-after-free where devices could be released without first
    being removed from the binder_devices list. However, there is a similar
    path in binder_free_proc() that was missed:
    
      ==================================================================
      BUG: KASAN: slab-use-after-free in binder_remove_device+0xd4/0x100
      Write of size 8 at addr ffff0000c773b900 by task umount/467
      CPU: 12 UID: 0 PID: 467 Comm: umount Not tainted 6.15.0-rc7-00138-g57483a362741 #9 PREEMPT
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       binder_remove_device+0xd4/0x100
       binderfs_evict_inode+0x230/0x2f0
       evict+0x25c/0x5dc
       iput+0x304/0x480
       dentry_unlink_inode+0x208/0x46c
       __dentry_kill+0x154/0x530
       [...]
    
      Allocated by task 463:
       __kmalloc_cache_noprof+0x13c/0x324
       binderfs_binder_device_create.isra.0+0x138/0xa60
       binder_ctl_ioctl+0x1ac/0x230
      [...]
    
      Freed by task 215:
       kfree+0x184/0x31c
       binder_proc_dec_tmpref+0x33c/0x4ac
       binder_deferred_func+0xc10/0x1108
       process_one_work+0x520/0xba4
      [...]
      ==================================================================
    
    Call binder_remove_device() within binder_free_proc() to ensure the
    device is removed from the binder_devices list before being kfreed.
    
    Cc: [email protected]
    Fixes: 12d909cac1e1 ("binderfs: add new binder devices to binder_devices")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=4af454407ec393de51d6
    Tested-by: [email protected]
    Signed-off-by: Carlos Llamas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: hci_qca: move the SoC type check to the right place [+ + +]
Author: Bartosz Golaszewski <[email protected]>
Date:   Tue May 27 09:47:37 2025 +0200

    Bluetooth: hci_qca: move the SoC type check to the right place
    
    commit 0fb410c914eb03c7e9d821e26d03bac0a239e5db upstream.
    
    Commit 3d05fc82237a ("Bluetooth: qca: set power_ctrl_enabled on NULL
    returned by gpiod_get_optional()") accidentally changed the prevous
    behavior where power control would be disabled without the BT_EN GPIO
    only on QCA_WCN6750 and QCA_WCN6855 while also getting the error check
    wrong. We should treat every IS_ERR() return value from
    devm_gpiod_get_optional() as a reason to bail-out while we should only
    set power_ctrl_enabled to false on the two models mentioned above. While
    at it: use dev_err_probe() to save a LOC.
    
    Cc: [email protected]
    Fixes: 3d05fc82237a ("Bluetooth: qca: set power_ctrl_enabled on NULL returned by gpiod_get_optional()")
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Tested-by: Hsin-chen Chuang <[email protected]>
    Reviewed-by: Hsin-chen Chuang <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clk: samsung: correct clock summary for hsi1 block [+ + +]
Author: Pritam Manohar Sutar <[email protected]>
Date:   Tue May 6 13:31:54 2025 +0530

    clk: samsung: correct clock summary for hsi1 block
    
    commit 81214185e7e1fc6dfc8661a574c457accaf9a5a4 upstream.
    
    clk_summary shows wrong value for "mout_hsi1_usbdrd_user".
    It shows 400Mhz instead of 40Mhz as below.
    
    dout_shared2_div4           1 1 0 400000000 0 0 50000 Y ...
      mout_hsi1_usbdrd_user     0 0 0 400000000 0 0 50000 Y ...
        dout_clkcmu_hsi1_usbdrd 0 0 0 40000000  0 0 50000 Y ...
    
    Correct the clk_tree by adding correct clock parent for
    "mout_hsi1_usbdrd_user".
    
    Post this change, clk_summary shows correct value.
    
    dout_shared2_div4           1 1 0 400000000 0 0 50000 Y ...
      mout_clkcmu_hsi1_usbdrd   0 0 0 400000000 0 0 50000 Y ...
        dout_clkcmu_hsi1_usbdrd 0 0 0 40000000  0 0 50000 Y ...
          mout_hsi1_usbdrd_user 0 0 0 40000000  0 0 50000 Y ...
    
    Fixes: 485e13fe2fb6 ("clk: samsung: add top clock support for ExynosAuto v920 SoC")
    Cc: <[email protected]>
    Signed-off-by: Pritam Manohar Sutar <[email protected]>
    Reviewed-by: Alim Akhtar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Documentation: ACPI: Use all-string data node references [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Wed Apr 9 11:47:38 2025 +0300

    Documentation: ACPI: Use all-string data node references
    
    commit 6db0261f3776bde01ae916ad8e1cb2ded3ba1a2b upstream.
    
    Document that references to data nodes shall use string-only references
    instead of a device reference and a succession of the first package
    entries of hierarchical data node references.
    
    Fixes: 9880702d123f ("ACPI: property: Support using strings in reference properties")
    Cc: 6.8+ <[email protected]> # 6.8+
    Signed-off-by: Sakari Ailus <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Clarifying edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt property [+ + +]
Author: Xu Yang <[email protected]>
Date:   Wed Apr 30 17:44:59 2025 +0800

    dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt property
    
    commit 5b3a91b207c00a8d27f75ce8aaa9860844da72c8 upstream.
    
    The ticket TKT0676370 shows the description of TX_VBOOST_LVL is wrong in
    register PHY_CTRL3 bit[31:29].
    
      011: Corresponds to a launch amplitude of 1.12 V.
      010: Corresponds to a launch amplitude of 1.04 V.
      000: Corresponds to a launch amplitude of 0.88 V.
    
    After updated:
    
      011: Corresponds to a launch amplitude of 0.844 V.
      100: Corresponds to a launch amplitude of 1.008 V.
      101: Corresponds to a launch amplitude of 1.156 V.
    
    This will correct it accordingly.
    
    Fixes: b2e75563dc39 ("dt-bindings: phy: imx8mq-usb: add phy tuning properties")
    Cc: [email protected]
    Reviewed-by: Jun Li <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dt-bindings: pwm: adi,axi-pwmgen: Fix clocks [+ + +]
Author: David Lechner <[email protected]>
Date:   Thu May 29 11:53:19 2025 -0500

    dt-bindings: pwm: adi,axi-pwmgen: Fix clocks
    
    commit e683131e64f71e957ca77743cb3d313646157329 upstream.
    
    Fix a shortcoming in the bindings that doesn't allow for a separate
    external clock.
    
    The AXI PWMGEN IP block has a compile option ASYNC_CLK_EN that allows
    the use of an external clock for the PWM output separate from the AXI
    clock that runs the peripheral.
    
    This was missed in the original bindings and so users were writing dts
    files where the one and only clock specified would be the external
    clock, if there was one, incorrectly missing the separate AXI clock.
    
    The correct bindings are that the AXI clock is always required and the
    external clock is optional (must be given only when HDL compile option
    ASYNC_CLK_EN=1).
    
    Fixes: 1edf2c2a2841 ("dt-bindings: pwm: Add AXI PWM generator")
    Cc: [email protected]
    Signed-off-by: David Lechner <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/20250529-pwm-axi-pwmgen-add-external-clock-v3-2-5d8809a7da91@baylibre.com
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dt-bindings: remoteproc: qcom,sm8150-pas: Add missing SC8180X compatible [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Apr 28 09:52:44 2025 +0200

    dt-bindings: remoteproc: qcom,sm8150-pas: Add missing SC8180X compatible
    
    commit b278981b5ac109e6f6986b20a5cb19654aba8f68 upstream.
    
    Commit 4b4ab93ddc5f ("dt-bindings: remoteproc: Consolidate SC8180X and
    SM8150 PAS files") moved SC8180X bindings from separate file into this
    one, but it forgot to add actual compatibles in top-level properties
    section making the entire binding un-selectable (no-op) for SC8180X PAS.
    
    Fixes: 4b4ab93ddc5f ("dt-bindings: remoteproc: Consolidate SC8180X and SM8150 PAS files")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Rob Herring (Arm) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dt-bindings: usb: cypress,hx3: Add support for all variants [+ + +]
Author: Lukasz Czechowski <[email protected]>
Date:   Fri Apr 25 17:18:07 2025 +0200

    dt-bindings: usb: cypress,hx3: Add support for all variants
    
    commit 1ad4b5a7de16806afc1aeaf012337e62af04e001 upstream.
    
    The Cypress HX3 hubs use different default PID value depending
    on the variant. Update compatibles list.
    Becasuse all hub variants use the same driver data, allow the
    dt node to have two compatibles: leftmost which matches the HW
    exactly, and the second one as fallback.
    
    Fixes: 1eca51f58a10 ("dt-bindings: usb: Add binding for Cypress HX3 USB 3.0 family")
    Cc: [email protected] # 6.6
    Cc: [email protected] # Backport of the patch ("dt-bindings: usb: usb-device: relax compatible pattern to a contains") from list: https://lore.kernel.org/linux-usb/20250418-dt-binding-usb-device-compatibles-v2-1-b3029f14e800@cherry.de/
    Cc: [email protected] # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver
    Signed-off-by: Lukasz Czechowski <[email protected]>
    Reviewed-by: "Rob Herring (Arm)" <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [taken with Greg's blessing]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.15.2 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Jun 10 07:17:11 2025 -0400

    Linux 6.15.2
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Christian Heusel <[email protected]>
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Takeshi Ogasawara <[email protected]>
    Tested-by: Luna Jernberg <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvmem: rmem: select CONFIG_CRC32 [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri May 9 13:24:06 2025 +0100

    nvmem: rmem: select CONFIG_CRC32
    
    commit 7a93add1d31f14e0b7e937163904dee1e864a9a8 upstream.
    
    The newly added crc checking leads to a link failure if CRC32
    itself is disabled:
    
    x86_64-linux-ld: vmlinux.o: in function `rmem_eyeq5_checksum':
    rmem.c:(.text+0x52341b): undefined reference to `crc32_le_arch'
    
    Fixes: 7e606c311f70 ("nvmem: rmem: add CRC validation for Mobileye EyeQ5 NVMEM")
    Cc: stable <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
pinctrl: armada-37xx: set GPIO output value before setting direction [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Wed May 14 21:18:33 2025 +0200

    pinctrl: armada-37xx: set GPIO output value before setting direction
    
    commit e6ebd4942981f8ad37189bbb36a3c8495e21ef4c upstream.
    
    Changing the direction before updating the output value in the
    OUTPUT_VAL register may result in a glitch on the output line
    if the previous value in the OUTPUT_VAL register is different
    from the one we want to set.
    
    In order to avoid that, update the output value before changing
    the direction.
    
    Cc: [email protected]
    Fixes: 6702abb3bf23 ("pinctrl: armada-37xx: Fix direction_output() callback behavior")
    Signed-off-by: Imre Kaloz <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Gabor Juhos <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31 [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Wed May 14 21:18:32 2025 +0200

    pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31
    
    commit 947c93eb29c2a581c0b0b6d5f21af3c2b7ff6d25 upstream.
    
    The controller has two consecutive OUTPUT_VAL registers and both
    holds output value for 32 GPIOs. Due to a missing adjustment, the
    current code always uses the first register while setting the
    output value whereas it should use the second one for GPIOs > 31.
    
    Add the missing armada_37xx_update_reg() call to adjust the register
    according to the 'offset' parameter of the function to fix the issue.
    
    Cc: [email protected]
    Fixes: 6702abb3bf23 ("pinctrl: armada-37xx: Fix direction_output() callback behavior")
    Signed-off-by: Imre Kaloz <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Gabor Juhos <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

pinctrl: mediatek: eint: Fix invalid pointer dereference for v1 platforms [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Tue May 20 17:15:58 2025 -0400

    pinctrl: mediatek: eint: Fix invalid pointer dereference for v1 platforms
    
    commit 1c9977b263475373b31bbf86af94a5c9ae2be42c upstream.
    
    Commit 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple
    addresses") introduced an access to the 'soc' field of struct
    mtk_pinctrl in mtk_eint_do_init() and for that an include of
    pinctrl-mtk-common-v2.h.
    
    However, pinctrl drivers relying on the v1 common driver include
    pinctrl-mtk-common.h instead, which provides another definition of
    struct mtk_pinctrl that does not contain an 'soc' field.
    
    Since mtk_eint_do_init() can be called both by v1 and v2 drivers, it
    will now try to dereference an invalid pointer when called on v1
    platforms. This has been observed on Genio 350 EVK (MT8365), which
    crashes very early in boot (the kernel trace can only be seen with
    earlycon).
    
    In order to fix this, since 'struct mtk_pinctrl' was only needed to get
    a 'struct mtk_eint_pin', make 'struct mtk_eint_pin' a parameter
    of mtk_eint_do_init() so that callers need to supply it, removing
    mtk_eint_do_init()'s dependency on any particular 'struct mtk_pinctrl'.
    
    Fixes: 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple addresses")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/20250520-genio-350-eint-null-ptr-deref-fix-v2-1-6a3ca966a7ba@collabora.com
    Signed-off-by: Linus Walleij <[email protected]>
    [ukleinek: backport to 6.15.y]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/amd/display: more liberal vmin/vmax update for freesync" [+ + +]
Author: Aurabindo Pillai <[email protected]>
Date:   Wed May 21 16:05:39 2025 -0400

    Revert "drm/amd/display: more liberal vmin/vmax update for freesync"
    
    commit 1b824eef269db44d068bbc0de74c94a8e8f9ce02 upstream.
    
    This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d since it
    causes regressions on certain configs. Revert until the issue can be
    isolated and debugged.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "x86/smp: Eliminate mwait_play_dead_cpuid_hint()" [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu May 29 15:40:43 2025 +0200

    Revert "x86/smp: Eliminate mwait_play_dead_cpuid_hint()"
    
    commit 70523f335734b0b42f97647556d331edf684c7dc upstream.
    
    Revert commit 96040f7273e2 ("x86/smp: Eliminate mwait_play_dead_cpuid_hint()")
    because it introduced a significant power regression on systems that
    start with "nosmt" in the kernel command line.
    
    Namely, on such systems, SMT siblings permanently go offline early,
    when cpuidle has not been initialized yet, so after the above commit,
    hlt_play_dead() is called for them.  Later on, when the processor
    attempts to enter a deep package C-state, including PC10 which is
    requisite for reaching minimum power in suspend-to-idle, it is not
    able to do that because of the SMT siblings staying in C1 (which
    they have been put into by HLT).
    
    As a result, the idle power (including power in suspend-to-idle)
    rises quite dramatically on those systems with all of the possible
    consequences, which (needless to say) may not be expected by their
    users.
    
    This issue is hard to debug and potentially dangerous, so it needs to
    be addressed as soon as possible in a way that will work for 6.15.y,
    hence the revert.
    
    Of course, after this revert, the issue that commit 96040f7273e2
    attempted to address will be back and it will need to be fixed again
    later.
    
    Fixes: 96040f7273e2 ("x86/smp: Eliminate mwait_play_dead_cpuid_hint()")
    Reported-by: Todd Brandt <[email protected]>
    Tested-by: Todd Brandt <[email protected]>
    Cc: 6.15+ <[email protected]> # 6.15+
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Dave Hansen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rtc: Fix offset calculation for .start_secs < 0 [+ + +]
Author: Alexandre Mergnat <[email protected]>
Date:   Mon Apr 28 12:06:48 2025 +0200

    rtc: Fix offset calculation for .start_secs < 0
    
    commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream.
    
    The comparison
    
            rtc->start_secs > rtc->range_max
    
    has a signed left-hand side and an unsigned right-hand side.
    So the comparison might become true for negative start_secs which is
    interpreted as a (possibly very large) positive value.
    
    As a negative value can never be bigger than an unsigned value
    the correct representation of the (mathematical) comparison
    
            rtc->start_secs > rtc->range_max
    
    in C is:
    
            rtc->start_secs >= 0 && rtc->start_secs > rtc->range_max
    
    Use that to fix the offset calculation currently used in the
    rtc-mt6397 driver.
    
    Fixes: 989515647e783 ("rtc: Add one offset seconds to expand RTC range")
    Signed-off-by: Alexandre Mergnat <[email protected]>
    Reviewed-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rtc: Make rtc_time64_to_tm() support dates before 1970 [+ + +]
Author: Alexandre Mergnat <[email protected]>
Date:   Mon Apr 28 12:06:47 2025 +0200

    rtc: Make rtc_time64_to_tm() support dates before 1970
    
    commit 7df4cfef8b351fec3156160bedfc7d6d29de4cce upstream.
    
    Conversion of dates before 1970 is still relevant today because these
    dates are reused on some hardwares to store dates bigger than the
    maximal date that is representable in the device's native format.
    This prominently and very soon affects the hardware covered by the
    rtc-mt6397 driver that can only natively store dates in the interval
    1900-01-01 up to 2027-12-31. So to store the date 2028-01-01 00:00:00
    to such a device, rtc_time64_to_tm() must do the right thing for
    time=-2208988800.
    
    Signed-off-by: Alexandre Mergnat <[email protected]>
    Reviewed-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
serial: jsm: fix NPE during jsm_uart_port_init [+ + +]
Author: Dustin Lundquist <[email protected]>
Date:   Tue May 6 11:18:45 2025 -0700

    serial: jsm: fix NPE during jsm_uart_port_init
    
    commit e3975aa899c0a3bbc10d035e699b142cd1373a71 upstream.
    
    No device was set which caused serial_base_ctrl_add to crash.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000050
     Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
     CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1  Debian 6.12.25-1
     RIP: 0010:serial_base_ctrl_add+0x96/0x120
     Call Trace:
      <TASK>
      serial_core_register_port+0x1a0/0x580
      ? __setup_irq+0x39c/0x660
      ? __kmalloc_cache_noprof+0x111/0x310
      jsm_uart_port_init+0xe8/0x180 [jsm]
      jsm_probe_one+0x1f4/0x410 [jsm]
      local_pci_probe+0x42/0x90
      pci_device_probe+0x22f/0x270
      really_probe+0xdb/0x340
      ? pm_runtime_barrier+0x54/0x90
      ? __pfx___driver_attach+0x10/0x10
      __driver_probe_device+0x78/0x110
      driver_probe_device+0x1f/0xa0
      __driver_attach+0xba/0x1c0
      bus_for_each_dev+0x8c/0xe0
      bus_add_driver+0x112/0x1f0
      driver_register+0x72/0xd0
      jsm_init_module+0x36/0xff0 [jsm]
      ? __pfx_jsm_init_module+0x10/0x10 [jsm]
      do_one_initcall+0x58/0x310
      do_init_module+0x60/0x230
    
    Tested with Digi Neo PCIe 8 port card.
    
    Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
    Cc: stable <[email protected]>
    Signed-off-by: Dustin Lundquist <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
thunderbolt: Do not double dequeue a configuration request [+ + +]
Author: Sergey Senozhatsky <[email protected]>
Date:   Fri Mar 28 00:03:50 2025 +0900

    thunderbolt: Do not double dequeue a configuration request
    
    commit 0f73628e9da1ee39daf5f188190cdbaee5e0c98c upstream.
    
    Some of our devices crash in tb_cfg_request_dequeue():
    
     general protection fault, probably for non-canonical address 0xdead000000000122
    
     CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65
     RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0
     Call Trace:
     <TASK>
     ? tb_cfg_request_dequeue+0x2d/0xa0
     tb_cfg_request_work+0x33/0x80
     worker_thread+0x386/0x8f0
     kthread+0xed/0x110
     ret_from_fork+0x38/0x50
     ret_from_fork_asm+0x1b/0x30
    
    The circumstances are unclear, however, the theory is that
    tb_cfg_request_work() can be scheduled twice for a request:
    first time via frame.callback from ring_work() and second
    time from tb_cfg_request().  Both times kworkers will execute
    tb_cfg_request_dequeue(), which results in double list_del()
    from the ctl->request_queue (the list poison deference hints
    at it: 0xdead000000000122).
    
    Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE
    bit set.
    
    Signed-off-by: Sergey Senozhatsky <[email protected]>
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tracing: Fix compilation warning on arm32 [+ + +]
Author: Pan Taixi <[email protected]>
Date:   Mon May 26 09:37:31 2025 +0800

    tracing: Fix compilation warning on arm32
    
    commit 2fbdb6d8e03b70668c0876e635506540ae92ab05 upstream.
    
    On arm32, size_t is defined to be unsigned int, while PAGE_SIZE is
    unsigned long. This hence triggers a compilation warning as min()
    asserts the type of two operands to be equal. Casting PAGE_SIZE to size_t
    solves this issue and works on other target architectures as well.
    
    Compilation warning details:
    
    kernel/trace/trace.c: In function 'tracing_splice_read_pipe':
    ./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types lacks a cast
      (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
                                ^
    ./include/linux/minmax.h:26:4: note: in expansion of macro '__typecheck'
       (__typecheck(x, y) && __no_side_effects(x, y))
        ^~~~~~~~~~~
    
    ...
    
    kernel/trace/trace.c:6771:8: note: in expansion of macro 'min'
            min((size_t)trace_seq_used(&iter->seq),
            ^~~
    
    Cc: [email protected]
    Link: https://lore.kernel.org/[email protected]
    Fixes: f5178c41bb43 ("tracing: Fix oob write in trace_seq_to_buffer()")
    Reviewed-by: Jeongjun Park <[email protected]>
    Signed-off-by: Pan Taixi <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE [+ + +]
Author: Jiayi Li <[email protected]>
Date:   Thu May 8 13:59:47 2025 +0800

    usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE
    
    commit 19f795591947596b5b9efa86fd4b9058e45786e9 upstream.
    
    This device exhibits I/O errors during file transfers due to unstable
    link power management (LPM) behavior. The kernel logs show repeated
    warm resets and eventual disconnection when LPM is enabled:
    
    [ 3467.810740] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0020
    [ 3467.810740] usb usb2-port5: do warm reset
    [ 3467.866444] usb usb2-port5: not warm reset yet, waiting 50ms
    [ 3467.907407] sd 0:0:0:0: [sda] tag#12 sense submit err -19
    [ 3467.994423] usb usb2-port5: status 02c0, change 0001, 10.0 Gb/s
    [ 3467.994453] usb 2-5: USB disconnect, device number 4
    
    The error -19 (ENODEV) occurs when the device disappears during write
    operations. Adding USB_QUIRK_NO_LPM disables link power management
    for this specific device, resolving the stability issues.
    
    Signed-off-by: Jiayi Li <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB [+ + +]
Author: Charles Yeh <[email protected]>
Date:   Wed May 21 21:23:54 2025 +0800

    USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB
    
    commit d3a889482bd5abf2bbdc1ec3d2d49575aa160c9c upstream.
    
    Add new bcd (0x905) to support PL2303GT-2AB (TYPE_HXN).
    Add new bcd (0x1005) to support PL2303GC-Q20 (TYPE_HXN).
    
    Signed-off-by: Charles Yeh <[email protected]>
    Cc: [email protected]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device [+ + +]
Author: Hongyu Xie <[email protected]>
Date:   Mon May 19 10:33:28 2025 +0800

    usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device
    
    commit a541acceedf4f639f928f41fbb676b75946dc295 upstream.
    
    SanDisk 3.2 Gen2 storage device(0781:55e8) doesn't work well with UAS.
    Log says,
    [    6.507865][ 3] [  T159] usb 2-1.4: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
    [    6.540314][ 3] [  T159] usb 2-1.4: New USB device found, idVendor=0781, idProduct=55e8, bcdDevice= 0.01
    [    6.576304][ 3] [  T159] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [    6.584727][ 3] [  T159] usb 2-1.4: Product: SanDisk 3.2 Gen2
    [    6.590459][ 3] [  T159] usb 2-1.4: Manufacturer: SanDisk
    [    6.595845][ 3] [  T159] usb 2-1.4: SerialNumber: 03021707022525140940
    [    7.230852][ 0] [  T265] usbcore: registered new interface driver usb-storage
    [    7.251247][ 0] [  T265] scsi host3: uas
    [    7.255280][ 0] [  T265] usbcore: registered new interface driver uas
    [    7.270498][ 1] [  T192] scsi 3:0:0:0: Direct-Access     SanDisk  Extreme Pro DDE1 0110 PQ: 0 ANSI: 6
    [    7.299588][ 3] [  T192] scsi 3:0:0:1: Enclosure         SanDisk  SES Device       0110 PQ: 0 ANSI: 6
    [    7.321681][ 3] [  T192] sd 3:0:0:0: Attached scsi generic sg1 type 0
    [    7.328185][ 3] [  T192] scsi 3:0:0:1: Attached scsi generic sg2 type 13
    [    7.328804][ 0] [  T191] sd 3:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
    [    7.343486][ 0] [  T191] sd 3:0:0:0: [sda] 4096-byte physical blocks
    [    7.364611][ 0] [  T191] sd 3:0:0:0: [sda] Write Protect is off
    [    7.370524][ 0] [  T191] sd 3:0:0:0: [sda] Mode Sense: 3d 00 10 00
    [    7.390655][ 0] [  T191] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
    [    7.401363][ 0] [  T191] sd 3:0:0:0: [sda] Optimal transfer size 1048576 bytes
    [    7.436010][ 0] [  T191]  sda: sda1
    [    7.450850][ 0] [  T191] sd 3:0:0:0: [sda] Attached SCSI disk
    [    7.470218][ 4] [  T262] scsi 3:0:0:1: Failed to get diagnostic page 0x1
    [    7.474869][ 0] [    C0] sd 3:0:0:0: [sda] tag#0 data cmplt err -75 uas-tag 2 inflight: CMD
    [    7.476911][ 4] [  T262] scsi 3:0:0:1: Failed to bind enclosure -19
    [    7.485330][ 0] [    C0] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00
    [    7.491593][ 4] [  T262] ses 3:0:0:1: Attached Enclosure device
    [   38.066980][ 4] [  T192] sd 3:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN
    [   38.076012][ 4] [  T192] sd 3:0:0:0: [sda] tag#4 CDB: Read(10) 28 00 00 00 01 08 00 00 f8 00
    [   38.086485][ 4] [  T192] sd 3:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
    [   38.095515][ 4] [  T192] sd 3:0:0:0: [sda] tag#3 CDB: Read(10) 28 00 00 00 00 10 00 00 08 00
    [   38.104122][ 4] [  T192] sd 3:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
    [   38.113152][ 4] [  T192] sd 3:0:0:0: [sda] tag#2 CDB: Read(10) 28 00 00 00 00 88 00 00 78 00
    [   38.121761][ 4] [  T192] sd 3:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN
    [   38.130791][ 4] [  T192] sd 3:0:0:0: [sda] tag#1 CDB: Read(10) 28 00 00 00 00 48 00 00 30 00
    [   38.139401][ 4] [  T192] sd 3:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
    [   38.148170][ 4] [  T192] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00
    [   38.178980][ 2] [  T304] scsi host3: uas_eh_device_reset_handler start
    [   38.901540][ 2] [  T304] usb 2-1.4: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd
    [   38.936791][ 2] [  T304] scsi host3: uas_eh_device_reset_handler success
    
    Device decriptor is below,
    Bus 002 Device 006: ID 0781:55e8 SanDisk Corp. SanDisk 3.2 Gen2
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               3.20
      bDeviceClass            0
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0         9
      idVendor           0x0781 SanDisk Corp.
      idProduct          0x55e8
      bcdDevice            0.01
      iManufacturer           1 SanDisk
      iProduct                2 SanDisk 3.2 Gen2
      iSerial                 3 03021707022525140940
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength       0x0079
        bNumInterfaces          1
        bConfigurationValue     1
        iConfiguration          0
        bmAttributes         0x80
          (Bus Powered)
        MaxPower              896mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     80 Bulk-Only
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               0
            bMaxBurst              15
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               0
            bMaxBurst              15
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       1
          bNumEndpoints           4
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     98
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               0
            bMaxBurst               0
            Command pipe (0x01)
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x84  EP 4 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               0
            bMaxBurst              15
            MaxStreams             32
            Status pipe (0x02)
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               0
            bMaxBurst              15
            MaxStreams             32
            Data-in pipe (0x03)
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x03  EP 3 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               0
            bMaxBurst              15
            MaxStreams             32
            Data-out pipe (0x04)
    Binary Object Store Descriptor:
      bLength                 5
      bDescriptorType        15
      wTotalLength       0x002a
      bNumDeviceCaps          3
      USB 2.0 Extension Device Capability:
        bLength                 7
        bDescriptorType        16
        bDevCapabilityType      2
        bmAttributes   0x0000f41e
          BESL Link Power Management (LPM) Supported
        BESL value     1024 us
        Deep BESL value    61440 us
      SuperSpeed USB Device Capability:
        bLength                10
        bDescriptorType        16
        bDevCapabilityType      3
        bmAttributes         0x00
        wSpeedsSupported   0x000e
          Device can operate at Full Speed (12Mbps)
          Device can operate at High Speed (480Mbps)
          Device can operate at SuperSpeed (5Gbps)
        bFunctionalitySupport   1
          Lowest fully-functional device speed is Full Speed (12Mbps)
        bU1DevExitLat          10 micro seconds
        bU2DevExitLat        2047 micro seconds
      SuperSpeedPlus USB Device Capability:
        bLength                20
        bDescriptorType        16
        bDevCapabilityType     10
        bmAttributes         0x00000001
          Sublink Speed Attribute count 1
          Sublink Speed ID count 0
        wFunctionalitySupport   0x1100
        bmSublinkSpeedAttr[0]   0x000a4030
          Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus
        bmSublinkSpeedAttr[1]   0x000a40b0
          Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus
    Device Status:     0x0000
      (Bus Powered)
    
    So ignore UAS driver for this device.
    
    Signed-off-by: Hongyu Xie <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: ucsi: fix Clang -Wsign-conversion warning [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Tue Apr 22 14:47:17 2025 +0100

    usb: typec: ucsi: fix Clang -Wsign-conversion warning
    
    commit f4239ace2dd8606f6824757f192965a95746da05 upstream.
    
    debugfs.c emits the following warnings when compiling with the -Wsign-conversion flag with clang 15:
    
    drivers/usb/typec/ucsi/debugfs.c:58:27: warning: implicit conversion changes signedness: 'int' to 'u32' (aka 'unsigned int') [-Wsign-conversion]
                    ucsi->debugfs->status = ret;
                                          ~ ^~~
    drivers/usb/typec/ucsi/debugfs.c:71:25: warning: implicit conversion changes signedness: 'u32' (aka 'unsigned int') to 'int' [-Wsign-conversion]
                    return ucsi->debugfs->status;
                    ~~~~~~ ~~~~~~~~~~~~~~~^~~~~~
    
    During ucsi_cmd() we see:
    
            if (ret < 0) {
                    ucsi->debugfs->status = ret;
                    return ret;
            }
    
    But "status" is u32 meaning unsigned wrap-around occurs when assigning a value which is < 0 to it, this obscures the real status.
    
    To fix this make the "status" of type int since ret is also of type int.
    
    Fixes: df0383ffad64 ("usb: typec: ucsi: Add debugfs for ucsi commands")
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: usbtmc: Fix timeout value in get_stb [+ + +]
Author: Dave Penkler <[email protected]>
Date:   Wed May 21 14:16:56 2025 +0200

    usb: usbtmc: Fix timeout value in get_stb
    
    commit 342e4955a1f1ce28c70a589999b76365082dbf10 upstream.
    
    wait_event_interruptible_timeout requires a timeout argument
    in units of jiffies. It was being called in usbtmc_get_stb
    with the usb timeout value which is in units of milliseconds.
    
    Pass the timeout argument converted to jiffies.
    
    Fixes: 048c6d88a021 ("usb: usbtmc: Add ioctls to set/get usb timeout")
    Cc: [email protected]
    Signed-off-by: Dave Penkler <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>