Linux 5.10.165

 
Linux: Add exception protection processing for vd in axi_chan_handle_err function [+ + +]
Author: Shawn.Shao <shawn.shao@jaguarmicro.com>
Date:   Thu Jan 12 13:58:02 2023 +0800

    Add exception protection processing for vd in axi_chan_handle_err function
    
    commit 57054fe516d59d03a7bcf1888e82479ccc244f87 upstream.
    
    Since there is no protection for vd, a kernel panic will be
    triggered here in exceptional cases.
    
    You can refer to the processing of axi_chan_block_xfer_complete function
    
    The triggered kernel panic is as follows:
    
    [   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
    [   67.848447] Mem abort info:
    [   67.848449]   ESR = 0x96000004
    [   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   67.848454]   SET = 0, FnV = 0
    [   67.848456]   EA = 0, S1PTW = 0
    [   67.848458] Data abort info:
    [   67.848460]   ISV = 0, ISS = 0x00000004
    [   67.848462]   CM = 0, WnR = 0
    [   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000
    [   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000
    [   67.848472] Internal error: Oops: 96000004 [#1] SMP
    [   67.848475] Modules linked in: dmatest
    [   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11
    [   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)
    [   67.848487] pc : axi_chan_handle_err+0xc4/0x230
    [   67.848491] lr : axi_chan_handle_err+0x30/0x230
    [   67.848493] sp : ffff0803fe55ae50
    [   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200
    [   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080
    [   67.848504] x25: ffff800010d33880 x24: ffff80001139d850
    [   67.848508] x23: ffff0800c097c168 x22: 0000000000000000
    [   67.848512] x21: 0000000000000080 x20: 0000000000002000
    [   67.848517] x19: ffff0800c097c080 x18: 0000000000000000
    [   67.848521] x17: 0000000000000000 x16: 0000000000000000
    [   67.848525] x15: 0000000000000000 x14: 0000000000000000
    [   67.848529] x13: 0000000000000000 x12: 0000000000000040
    [   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a
    [   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270
    [   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0
    [   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480
    [   67.848550] x3 : dead000000000100 x2 : dead000000000122
    [   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168
    [   67.848559] Call trace:
    [   67.848562]  axi_chan_handle_err+0xc4/0x230
    [   67.848566]  dw_axi_dma_interrupt+0xf4/0x590
    [   67.848569]  __handle_irq_event_percpu+0x60/0x220
    [   67.848573]  handle_irq_event+0x64/0x120
    [   67.848576]  handle_fasteoi_irq+0xc4/0x220
    [   67.848580]  __handle_domain_irq+0x80/0xe0
    [   67.848583]  gic_handle_irq+0xc0/0x138
    [   67.848585]  el1_irq+0xc8/0x180
    [   67.848588]  arch_cpu_idle+0x14/0x2c
    [   67.848591]  default_idle_call+0x40/0x16c
    [   67.848594]  do_idle+0x1f0/0x250
    [   67.848597]  cpu_startup_entry+0x2c/0x60
    [   67.848600]  rest_init+0xc0/0xcc
    [   67.848603]  arch_call_rest_init+0x14/0x1c
    [   67.848606]  start_kernel+0x4cc/0x500
    [   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)
    [   67.848613] ---[ end trace 585a97036f88203a ]---
    
    Signed-off-by: Shawn.Shao <shawn.shao@jaguarmicro.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230112055802.1764-1-shawn.shao@jaguarmicro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: hda/realtek - Turn on power early [+ + +]
Author: Yuchi Yang <yangyuchi66@gmail.com>
Date:   Fri Dec 30 15:22:25 2022 +0800

    ALSA: hda/realtek - Turn on power early
    
    [ Upstream commit 1f680609bf1beac20e2a31ddcb1b88874123c39f ]
    
    Turn on power early to avoid wrong state for power relation register.
    This can earlier update JD state when resume back.
    
    Signed-off-by: Yuchi Yang <yangyuchi66@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/e35d8f4fa18f4448a2315cc7d4a3715f@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: efi: Execute runtime services from a dedicated stack [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Dec 5 11:31:25 2022 +0100

    arm64: efi: Execute runtime services from a dedicated stack
    
    commit ff7a167961d1b97e0e205f245f806e564d3505e7 upstream.
    
    With the introduction of PRMT in the ACPI subsystem, the EFI rts
    workqueue is no longer the only caller of efi_call_virt_pointer() in the
    kernel. This means the EFI runtime services lock is no longer sufficient
    to manage concurrent calls into firmware, but also that firmware calls
    may occur that are not marshalled via the workqueue mechanism, but
    originate directly from the caller context.
    
    For added robustness, and to ensure that the runtime services have 8 KiB
    of stack space available as per the EFI spec, introduce a spinlock
    protected EFI runtime stack of 8 KiB, where the spinlock also ensures
    serialization between the EFI rts workqueue (which itself serializes EFI
    runtime calls) and other callers of efi_call_virt_pointer().
    
    While at it, use the stack pivot to avoid reloading the shadow call
    stack pointer from the ordinary stack, as doing so could produce a
    gadget to defeat it.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Lee Jones <lee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: hci_qca: check for SSR triggered flag while suspend [+ + +]
Author: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Date:   Tue Feb 2 20:27:42 2021 +0530

    Bluetooth: hci_qca: check for SSR triggered flag while suspend
    
    commit 1bb0c66332babc5cbc4581d962da0b03af9f23e8 upstream.
    
    QCA_IBS_DISABLED flag will be set after memorydump started from
    controller.Currently qca_suspend() is waiting for SSR to complete
    based on flag QCA_IBS_DISABLED.Added to check for QCA_SSR_TRIGGERED
    flag too.
    
    Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend")
    Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_qca: Fix driver shutdown on closed serdev [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Dec 29 11:28:29 2022 +0100

    Bluetooth: hci_qca: Fix driver shutdown on closed serdev
    
    [ Upstream commit 272970be3dabd24cbe50e393ffee8f04aec3b9a8 ]
    
    The driver shutdown callback (which sends EDL_SOC_RESET to the device
    over serdev) should not be invoked when HCI device is not open (e.g. if
    hci_dev_open_sync() failed), because the serdev and its TTY are not open
    either.  Also skip this step if device is powered off
    (qca_power_shutdown()).
    
    The shutdown callback causes use-after-free during system reboot with
    Qualcomm Atheros Bluetooth:
    
      Unable to handle kernel paging request at virtual address
      0072662f67726fd7
      ...
      CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G        W
      6.1.0-rt5-00325-g8a5f56bcfcca #8
      Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
      Call trace:
       tty_driver_flush_buffer+0x4/0x30
       serdev_device_write_flush+0x24/0x34
       qca_serdev_shutdown+0x80/0x130 [hci_uart]
       device_shutdown+0x15c/0x260
       kernel_restart+0x48/0xac
    
    KASAN report:
    
      BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50
      Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1
    
      CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted
      6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28
      Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
      Call trace:
       dump_backtrace.part.0+0xdc/0xf0
       show_stack+0x18/0x30
       dump_stack_lvl+0x68/0x84
       print_report+0x188/0x488
       kasan_report+0xa4/0xf0
       __asan_load8+0x80/0xac
       tty_driver_flush_buffer+0x1c/0x50
       ttyport_write_flush+0x34/0x44
       serdev_device_write_flush+0x48/0x60
       qca_serdev_shutdown+0x124/0x274
       device_shutdown+0x1e8/0x350
       kernel_restart+0x48/0xb0
       __do_sys_reboot+0x244/0x2d0
       __arm64_sys_reboot+0x54/0x70
       invoke_syscall+0x60/0x190
       el0_svc_common.constprop.0+0x7c/0x160
       do_el0_svc+0x44/0xf0
       el0_svc+0x2c/0x6c
       el0t_64_sync_handler+0xbc/0x140
       el0t_64_sync+0x190/0x194
    
    Fixes: 7e7bbddd029b ("Bluetooth: hci_qca: Fix qca6390 enable failure after warm reboot")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_qca: Fixed issue during suspend [+ + +]
Author: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Date:   Fri Feb 5 21:07:16 2021 +0530

    Bluetooth: hci_qca: Fixed issue during suspend
    
    commit 55c0bd77479b60ea29fd390faf4545cfb3a1d79e upstream.
    
    If BT SoC is running with ROM FW then just return in
    qca_suspend function as ROM FW does not support
    in-band sleep.
    
    Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend")
    Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_qca: Wait for SSR completion during suspend [+ + +]
Author: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Date:   Wed Dec 30 22:47:08 2020 +0530

    Bluetooth: hci_qca: Wait for SSR completion during suspend
    
    commit ad3a9c0ec2d2baed936cfdd05870f9d1e1f40e0e upstream.
    
    During SSR after memory dump collection,BT controller will be powered off,
    powered on and then FW will be downloaded.During suspend if BT controller
    is powered off due to SSR then we should wait until SSR is completed and
    then suspend.
    
    Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend")
    Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_qca: Wait for timeout during suspend [+ + +]
Author: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Date:   Tue Oct 6 20:50:21 2020 +0530

    Bluetooth: hci_qca: Wait for timeout during suspend
    
    [ Upstream commit 2be43abac5a839d44bf9d14716573ae0ac920f2b ]
    
    Currently qca_suspend() is relied on IBS mechanism. During
    FW download and memory dump collections, IBS will be disabled.
    In those cases, driver will allow suspend and still uses the
    serdev port, which results to errors. Now added a wait timeout
    if suspend is triggered during FW download and memory collections.
    
    Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
    Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Stable-dep-of: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: always report error in run_one_delayed_ref() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Mon Dec 26 09:00:40 2022 +0800

    btrfs: always report error in run_one_delayed_ref()
    
    [ Upstream commit 39f501d68ec1ed5cd5c66ac6ec2a7131c517bb92 ]
    
    Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but
    if end users hit such problem, there will be no chance that
    btrfs_debug() is enabled.  This can lead to very little useful info for
    debugging.
    
    This patch will:
    
    - Add extra info for error reporting
      Including:
      * logical bytenr
      * num_bytes
      * type
      * action
      * ref_mod
    
    - Replace the btrfs_debug() with btrfs_err()
    
    - Move the error reporting into run_one_delayed_ref()
      This is to avoid use-after-free, the @node can be freed in the caller.
    
    This error should only be triggered at most once.
    
    As if run_one_delayed_ref() failed, we trigger the error message, then
    causing the call chain to error out:
    
    btrfs_run_delayed_refs()
    `- btrfs_run_delayed_refs()
       `- btrfs_run_delayed_refs_for_head()
          `- run_one_delayed_ref()
    
    And we will abort the current transaction in btrfs_run_delayed_refs().
    If we have to run delayed refs for the abort transaction,
    run_one_delayed_ref() will just cleanup the refs and do nothing, thus no
    new error messages would be output.
    
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: fix race between quota rescan and disable leading to NULL pointer deref [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 12 16:31:08 2023 +0000

    btrfs: fix race between quota rescan and disable leading to NULL pointer deref
    
    commit b7adbf9ada3513d2092362c8eac5cddc5b651f5c upstream.
    
    If we have one task trying to start the quota rescan worker while another
    one is trying to disable quotas, we can end up hitting a race that results
    in the quota rescan worker doing a NULL pointer dereference. The steps for
    this are the following:
    
    1) Quotas are enabled;
    
    2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
       It calls qgroup_rescan_init() which returns 0 (success) and then joins a
       transaction and commits it;
    
    3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
       It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls
       btrfs_qgroup_wait_for_completion(), which returns immediately since the
       rescan worker is not yet running.
       Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;
    
    4) Task A queues the rescan worker, by calling btrfs_queue_work();
    
    5) The rescan worker starts, and calls rescan_should_stop() at the start
       of its while loop, which results in 0 iterations of the loop, since
       the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by
       task B at step 3);
    
    6) Task B sets fs_info->quota_root to NULL;
    
    7) The rescan worker tries to start a transaction and uses
       fs_info->quota_root as the root argument for btrfs_start_transaction().
       This results in a NULL pointer dereference down the call chain of
       btrfs_start_transaction(). The stack trace is something like the one
       reported in Link tag below:
    
       general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
       KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
       CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
       Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
       Workqueue: btrfs-qgroup-rescan btrfs_work_helper
       RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
       Code: 48 89 fb 48 (...)
       RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
       RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
       RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
       R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
       R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
       FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        <TASK>
        btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402
        btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280
        process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
        worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
        kthread+0x266/0x300 kernel/kthread.c:376
        ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
        </TASK>
       Modules linked in:
    
    So fix this by having the rescan worker function not attempt to start a
    transaction if it didn't do any rescan work.
    
    Reported-by: syzbot+96977faa68092ad382c4@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-btrfs/000000000000e5454b05f065a803@google.com/
    Fixes: e804861bd4e6 ("btrfs: fix deadlock between quota disable and qgroup rescan worker")
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix trace event name typo for FLUSH_DELAYED_REFS [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Wed Dec 14 11:06:07 2022 +0900

    btrfs: fix trace event name typo for FLUSH_DELAYED_REFS
    
    [ Upstream commit 0a3212de8ab3e2ce5808c6265855e528d4a6767b ]
    
    Fix a typo of printing FLUSH_DELAYED_REFS event in flush_space() as
    FLUSH_ELAYED_REFS.
    
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
cifs: do not include page data when checking signature [+ + +]
Author: Enzo Matsumiya <ematsumiya@suse.de>
Date:   Wed Jan 18 14:06:57 2023 -0300

    cifs: do not include page data when checking signature
    
    commit 30b2b2196d6e4cc24cbec633535a2404f258ce69 upstream.
    
    On async reads, page data is allocated before sending.  When the
    response is received but it has no data to fill (e.g.
    STATUS_END_OF_FILE), __calc_signature() will still include the pages in
    its computation, leading to an invalid signature check.
    
    This patch fixes this by not setting the async read smb_rqst page data
    (zeroed by default) if its got_bytes is 0.
    
    This can be reproduced/verified with xfstests generic/465.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
comedi: adv_pci1760: Fix PWM instruction handling [+ + +]
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jan 3 14:37:54 2023 +0000

    comedi: adv_pci1760: Fix PWM instruction handling
    
    commit 2efb6edd52dc50273f5e68ad863dd1b1fb2f2d1c upstream.
    
    (Actually, this is fixing the "Read the Current Status" command sent to
    the device's outgoing mailbox, but it is only currently used for the PWM
    instructions.)
    
    The PCI-1760 is operated mostly by sending commands to a set of Outgoing
    Mailbox registers, waiting for the command to complete, and reading the
    result from the Incoming Mailbox registers.  One of these commands is
    the "Read the Current Status" command.  The number of this command is
    0x07 (see the User's Manual for the PCI-1760 at
    <https://advdownload.advantech.com/productfile/Downloadfile2/1-11P6653/PCI-1760.pdf>.
    The `PCI1760_CMD_GET_STATUS` macro defined in the driver should expand
    to this command number 0x07, but unfortunately it currently expands to
    0x03.  (Command number 0x03 is not defined in the User's Manual.)
    Correct the definition of the `PCI1760_CMD_GET_STATUS` macro to fix it.
    
    This is used by all the PWM subdevice related instructions handled by
    `pci1760_pwm_insn_config()` which are probably all broken.  The effect
    of sending the undefined command number 0x03 is not known.
    
    Fixes: 14b93bb6bbf0 ("staging: comedi: adv_pci_dio: separate out PCI-1760 support")
    Cc: <stable@vger.kernel.org> # v4.5+
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20230103143754.17564-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dmaengine: tegra210-adma: fix global intr clear [+ + +]
Author: Mohan Kumar <mkumard@nvidia.com>
Date:   Mon Jan 2 12:18:44 2023 +0530

    dmaengine: tegra210-adma: fix global intr clear
    
    commit 9c7e355ccbb33d239360c876dbe49ad5ade65b47 upstream.
    
    The current global interrupt clear programming register offset
    was not correct. Fix the programming with right offset
    
    Fixes: ded1f3db4cd6 ("dmaengine: tegra210-adma: prepare for supporting newer Tegra chips")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
    Link: https://lore.kernel.org/r/20230102064844.31306-1-mkumard@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Calculate output_color_space after pixel encoding adjustment [+ + +]
Author: Joshua Ashton <joshua@froggi.es>
Date:   Tue Jan 10 20:12:21 2023 +0000

    drm/amd/display: Calculate output_color_space after pixel encoding adjustment
    
    commit 79601b894849cb6f6d6122e6590f1887ac4a66b3 upstream.
    
    Code in get_output_color_space depends on knowing the pixel encoding to
    determine whether to pick between eg. COLOR_SPACE_SRGB or
    COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.
    
    v2: Fixed patch being accidentally based on a personal feature branch, oops!
    
    Fixes: ea117312ea9f ("drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded")
    Reviewed-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Joshua Ashton <joshua@froggi.es>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix [+ + +]
Author: Joshua Ashton <joshua@froggi.es>
Date:   Tue Jan 10 22:50:42 2023 +0000

    drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix
    
    commit 973a9c810c785ac270a6d50d8cf862b0c1643a10 upstream.
    
    The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
    missing the values for the fourth column of the matrix.
    
    The fourth column of the matrix is essentially just a value that is
    added given that the color is 3 components in size.
    These values are needed to bias the chroma from the [-1, 1] -> [0, 1]
    range.
    
    This fixes color being very green when using Gamescope HDR on HDMI
    output which prefers YCC 4:4:4.
    
    Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")
    Reviewed-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Joshua Ashton <joshua@froggi.es>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Fix set scaling doesn's work [+ + +]
Author: hongao <hongao@uniontech.com>
Date:   Tue Nov 22 19:20:34 2022 +0800

    drm/amd/display: Fix set scaling doesn's work
    
    commit 040625ab82ce6dca7772cb3867fe5c9eb279a344 upstream.
    
    [Why]
    Setting scaling does not correctly update CRTC state. As a result
    dc stream state's src (composition area) && dest (addressable area)
    was not calculated as expected. This causes set scaling doesn's work.
    
    [How]
    Correctly update CRTC state when setting scaling property.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Tested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: hongao <hongao@uniontech.com>
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/gt: Reset twice [+ + +]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Dec 12 17:13:38 2022 +0100

    drm/i915/gt: Reset twice
    
    [ Upstream commit d3de5616d36462a646f5b360ba82d3b09ff668eb ]
    
    After applying an engine reset, on some platforms like Jasperlake, we
    occasionally detect that the engine state is not cleared until shortly
    after the resume. As we try to resume the engine with volatile internal
    state, the first request fails with a spurious CS event (it looks like
    it reports a lite-restore to the hung context, instead of the expected
    idle->active context switch).
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@vger.kernel.org
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221212161338.1007659-1-andi.shyti@linux.intel.com
    (cherry picked from commit 3db9d590557da3aa2c952f2fecd3e9b703dad790)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915: re-disable RC6p on Sandy Bridge [+ + +]
Author: Sasa Dragic <sasa.dragic@gmail.com>
Date:   Mon Dec 19 18:29:27 2022 +0100

    drm/i915: re-disable RC6p on Sandy Bridge
    
    commit 67b0b4ed259e425b7eed09da75b42c80682ca003 upstream.
    
    RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
    and GPU hangs.
    
    Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
    RC6p on Sandy Bridge").
    
    Signed-off-by: Sasa Dragic <sasa.dragic@gmail.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221219172927.9603-2-sasa.dragic@gmail.com
    Fixes: fb6db0f5bf1d ("drm/i915: Remove unsafe i915.enable_rc6")
    Fixes: 13c5a577b342 ("drm/i915/gt: Select the deepest available parking mode for rc6")
    Cc: stable@vger.kernel.org
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    (cherry picked from commit 0c8a6e9ea232c221976a0670256bd861408d9917)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dt-bindings: phy: g12a-usb2-phy: fix compatible string documentation [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Jan 16 21:17:39 2023 +0100

    dt-bindings: phy: g12a-usb2-phy: fix compatible string documentation
    
    commit c63835bf1c750c9b3aec1d5c23d811d6375fc23d upstream.
    
    The compatible strings in the driver don't have the meson prefix.
    Fix this in the documentation and rename the file accordingly.
    
    Fixes: da86d286cce8 ("dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/8d960029-e94d-224b-911f-03e5deb47ebc@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dt-bindings: phy: g12a-usb3-pcie-phy: fix compatible string documentation [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Jan 16 21:19:03 2023 +0100

    dt-bindings: phy: g12a-usb3-pcie-phy: fix compatible string documentation
    
    commit e181119046a0ec16126b682163040e8e33f310c1 upstream.
    
    The compatible string in the driver doesn't have the meson prefix.
    Fix this in the documentation and rename the file accordingly.
    
    Fixes: 87a55485f2fc ("dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/0a82be92-ce85-da34-9d6f-4b33034473e5@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
efi: fix userspace infinite retry read efivars after EFI runtime services page fault [+ + +]
Author: Ding Hui <dinghui@sangfor.com.cn>
Date:   Tue Dec 27 23:09:36 2022 +0800

    efi: fix userspace infinite retry read efivars after EFI runtime services page fault
    
    [ Upstream commit e006ac3003080177cf0b673441a4241f77aaecce ]
    
    After [1][2], if we catch exceptions due to EFI runtime service, we will
    clear EFI_RUNTIME_SERVICES bit to disable EFI runtime service, then the
    subsequent routine which invoke the EFI runtime service should fail.
    
    But the userspace cat efivars through /sys/firmware/efi/efivars/ will stuck
    and infinite loop calling read() due to efivarfs_file_read() return -EINTR.
    
    The -EINTR is converted from EFI_ABORTED by efi_status_to_err(), and is
    an improper return value in this situation, so let virt_efi_xxx() return
    EFI_DEVICE_ERROR and converted to -EIO to invoker.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 3425d934fc03 ("efi/x86: Handle page faults occurring while running EFI runtime services")
    Fixes: 23715a26c8d8 ("arm64: efi: Recover from synchronous exceptions occurring in firmware")
    Signed-off-by: Ding Hui <dinghui@sangfor.com.cn>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

efi: rt-wrapper: Add missing include [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Jan 9 12:41:46 2023 +0100

    efi: rt-wrapper: Add missing include
    
    commit 18bba1843fc7f264f58c9345d00827d082f9c558 upstream.
    
    Add the missing #include of asm/assembler.h, which is where the ldr_l
    macro is defined.
    
    Fixes: ff7a167961d1b97e ("arm64: efi: Execute runtime services from a dedicated stack")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Lee Jones <lee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
f2fs: let's avoid panic if extent_tree is not created [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Wed Dec 21 16:14:10 2022 -0800

    f2fs: let's avoid panic if extent_tree is not created
    
    [ Upstream commit df9d44b645b83fffccfb4e28c1f93376585fdec8 ]
    
    This patch avoids the below panic.
    
    pc : __lookup_extent_tree+0xd8/0x760
    lr : f2fs_do_write_data_page+0x104/0x87c
    sp : ffffffc010cbb3c0
    x29: ffffffc010cbb3e0 x28: 0000000000000000
    x27: ffffff8803e7f020 x26: ffffff8803e7ed40
    x25: ffffff8803e7f020 x24: ffffffc010cbb460
    x23: ffffffc010cbb480 x22: 0000000000000000
    x21: 0000000000000000 x20: ffffffff22e90900
    x19: 0000000000000000 x18: ffffffc010c5d080
    x17: 0000000000000000 x16: 0000000000000020
    x15: ffffffdb1acdbb88 x14: ffffff888759e2b0
    x13: 0000000000000000 x12: ffffff802da49000
    x11: 000000000a001200 x10: ffffff8803e7ed40
    x9 : ffffff8023195800 x8 : ffffff802da49078
    x7 : 0000000000000001 x6 : 0000000000000000
    x5 : 0000000000000006 x4 : ffffffc010cbba28
    x3 : 0000000000000000 x2 : ffffffc010cbb480
    x1 : 0000000000000000 x0 : ffffff8803e7ed40
    Call trace:
     __lookup_extent_tree+0xd8/0x760
     f2fs_do_write_data_page+0x104/0x87c
     f2fs_write_single_data_page+0x420/0xb60
     f2fs_write_cache_pages+0x418/0xb1c
     __f2fs_write_data_pages+0x428/0x58c
     f2fs_write_data_pages+0x30/0x40
     do_writepages+0x88/0x190
     __writeback_single_inode+0x48/0x448
     writeback_sb_inodes+0x468/0x9e8
     __writeback_inodes_wb+0xb8/0x2a4
     wb_writeback+0x33c/0x740
     wb_do_writeback+0x2b4/0x400
     wb_workfn+0xe4/0x34c
     process_one_work+0x24c/0x5bc
     worker_thread+0x3e8/0xa50
     kthread+0x150/0x1b4
    
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gsmi: fix null-deref in gsmi_get_variable [+ + +]
Author: Khazhismel Kumykov <khazhy@chromium.org>
Date:   Tue Jan 17 17:02:12 2023 -0800

    gsmi: fix null-deref in gsmi_get_variable
    
    commit a769b05eeed7accc4019a1ed9799dd72067f1ce8 upstream.
    
    We can get EFI variables without fetching the attribute, so we must
    allow for that in gsmi.
    
    commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
    access layer") added a new get_variable call with attr=NULL, which
    triggers panic in gsmi.
    
    Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
    Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/net: fix fast_iov assignment in io_setup_async_msg() [+ + +]
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Sep 29 09:39:10 2022 +0200

    io_uring/net: fix fast_iov assignment in io_setup_async_msg()
    
    commit 3e4cb6ebbb2bad201c1186bc0b7e8cf41dd7f7e6 upstream.
    
    I hit a very bad problem during my tests of SENDMSG_ZC.
    BUG(); in first_iovec_segment() triggered very easily.
    The problem was io_setup_async_msg() in the partial retry case,
    which seems to happen more often with _ZC.
    
    iov_iter_iovec_advance() may change i->iov in order to have i->iov_offset
    being only relative to the first element.
    
    Which means kmsg->msg.msg_iter.iov is no longer the
    same as kmsg->fast_iov.
    
    But this would rewind the copy to be the start of
    async_msg->fast_iov, which means the internal
    state of sync_msg->msg.msg_iter is inconsitent.
    
    I tested with 5 vectors with length like this 4, 0, 64, 20, 8388608
    and got a short writes with:
    - ret=2675244 min_ret=8388692 => remaining 5713448 sr->done_io=2675244
    - ret=-EAGAIN => io_uring_poll_arm
    - ret=4911225 min_ret=5713448 => remaining 802223  sr->done_io=7586469
    - ret=-EAGAIN => io_uring_poll_arm
    - ret=802223  min_ret=802223  => res=8388692
    
    While this was easily triggered with SENDMSG_ZC (queued for 6.1),
    it was a potential problem starting with 7ba89d2af17aa879dda30f5d5d3f152e587fc551
    in 5.18 for IORING_OP_RECVMSG.
    And also with 4c3c09439c08b03d9503df0ca4c7619c5842892e in 5.19
    for IORING_OP_SENDMSG.
    
    However 257e84a5377fbbc336ff563833a8712619acce56 introduced the critical
    code into io_setup_async_msg() in 5.11.
    
    Fixes: 7ba89d2af17aa ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly")
    Fixes: 257e84a5377fb ("io_uring: refactor sendmsg/recvmsg iov managing")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/b2e7be246e2fb173520862b0c7098e55767567a2.1664436949.git.metze@samba.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/rw: defer fsnotify calls to task context [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sat Jan 21 13:38:51 2023 -0700

    io_uring/rw: defer fsnotify calls to task context
    
    commit b000145e9907809406d8164c3b2b8861d95aecd1 upstream.
    
    We can't call these off the kiocb completion as that might be off
    soft/hard irq context. Defer the calls to when we process the
    task_work for this request. That avoids valid complaints like:
    
    stack backtrace:
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
    Call Trace:
     <IRQ>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     print_usage_bug kernel/locking/lockdep.c:3961 [inline]
     valid_state kernel/locking/lockdep.c:3973 [inline]
     mark_lock_irq kernel/locking/lockdep.c:4176 [inline]
     mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632
     mark_lock kernel/locking/lockdep.c:4596 [inline]
     mark_usage kernel/locking/lockdep.c:4527 [inline]
     __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007
     lock_acquire kernel/locking/lockdep.c:5666 [inline]
     lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631
     __fs_reclaim_acquire mm/page_alloc.c:4674 [inline]
     fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688
     might_alloc include/linux/sched/mm.h:271 [inline]
     slab_pre_alloc_hook mm/slab.h:700 [inline]
     slab_alloc mm/slab.c:3278 [inline]
     __kmem_cache_alloc_lru mm/slab.c:3471 [inline]
     kmem_cache_alloc+0x39/0x520 mm/slab.c:3491
     fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline]
     fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline]
     fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948
     send_to_group fs/notify/fsnotify.c:360 [inline]
     fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570
     __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230
     fsnotify_parent include/linux/fsnotify.h:77 [inline]
     fsnotify_file include/linux/fsnotify.h:99 [inline]
     fsnotify_access include/linux/fsnotify.h:309 [inline]
     __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195
     io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228
     iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline]
     iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178
     bio_endio+0x5f9/0x780 block/bio.c:1564
     req_bio_endio block/blk-mq.c:695 [inline]
     blk_update_request+0x3fc/0x1300 block/blk-mq.c:825
     scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541
     scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971
     scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438
     blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022
     __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571
     invoke_softirq kernel/softirq.c:445 [inline]
     __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
     irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
     common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240
    
    Fixes: f63cf5192fe3 ("io_uring: ensure that fsnotify is always called")
    Link: https://lore.kernel.org/all/20220929135627.ykivmdks2w5vzrwg@quack3/
    Reported-by: syzbot+dfcc5f4da15868df7d4d@syzkaller.appspotmail.com
    Reported-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring/rw: ensure kiocb_end_write() is always called [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Jan 22 10:36:37 2023 -0700

    io_uring/rw: ensure kiocb_end_write() is always called
    
    commit 2ec33a6c3cca9fe2465e82050c81f5ffdc508b36 upstream.
    
    A previous commit moved the notifications and end-write handling, but
    it is now missing a few spots where we also want to call both of those.
    Without that, we can potentially be missing file notifications, and
    more importantly, have an imbalance in the super_block writers sem
    accounting.
    
    Fixes: b000145e9907 ("io_uring/rw: defer fsnotify calls to task context")
    Reported-by: Dave Chinner <david@fromorbit.com>
    Link: https://lore.kernel.org/all/20221010050319.GC2703033@dread.disaster.area/
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring/rw: remove leftover debug statement [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Oct 16 17:24:10 2022 -0600

    io_uring/rw: remove leftover debug statement
    
    commit 5c61795ea97c170347c5c4af0c159bd877b8af71 upstream.
    
    This debug statement was never meant to go into the upstream release,
    kill it off before it ends up in a release. It was just part of the
    testing for the initial version of the patch.
    
    Fixes: 2ec33a6c3cca ("io_uring/rw: ensure kiocb_end_write() is always called")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring: add flag for disabling provided buffer recycling [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Mar 23 09:30:05 2022 -0600

    io_uring: add flag for disabling provided buffer recycling
    
    commit 8a3e8ee56417f5e0e66580d93941ed9d6f4c8274 upstream.
    
    If we need to continue doing this IO, then we don't want a potentially
    selected buffer recycled. Add a flag for that.
    
    Set this for recv/recvmsg if they do partial IO.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: allow re-poll if we made progress [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sat Jan 21 10:39:22 2023 -0700

    io_uring: allow re-poll if we made progress
    
    commit 10c873334febaeea9aa0c25c10b5ac0951b77a5f upstream.
    
    We currently check REQ_F_POLLED before arming async poll for a
    notification to retry. If it's set, then we don't allow poll and will
    punt to io-wq instead. This is done to prevent a situation where a buggy
    driver will repeatedly return that there's space/data available yet we
    get -EAGAIN.
    
    However, if we already transferred data, then it should be safe to rely
    on poll again. Gate the check on whether or not REQ_F_PARTIAL_IO is
    also set.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: check for valid register opcode earlier [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Dec 23 06:37:08 2022 -0700

    io_uring: check for valid register opcode earlier
    
    [ Upstream commit 343190841a1f22b96996d9f8cfab902a4d1bfd0e ]
    
    We only check the register opcode value inside the restricted ring
    section, move it into the main io_uring_register() function instead
    and check it up front.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: Clean up a false-positive warning from GCC 9.3.0 [+ + +]
Author: Alviro Iskandar Setiawan <alviro.iskandar@gmail.com>
Date:   Mon Feb 7 21:05:33 2022 +0700

    io_uring: Clean up a false-positive warning from GCC 9.3.0
    
    commit 0d7c1153d9291197c1dc473cfaade77acb874b4b upstream.
    
    In io_recv(), if import_single_range() fails, the @flags variable is
    uninitialized, then it will goto out_free.
    
    After the goto, the compiler doesn't know that (ret < min_ret) is
    always true, so it thinks the "if ((flags & MSG_WAITALL) ..."  path
    could be taken.
    
    The complaint comes from gcc-9 (Debian 9.3.0-22) 9.3.0:
    ```
      fs/io_uring.c:5238 io_recvfrom() error: uninitialized symbol 'flags'
    ```
    Fix this by bypassing the @ret and @flags check when
    import_single_range() fails.
    
    Reasons:
     1. import_single_range() only returns -EFAULT when it fails.
     2. At that point, @flags is uninitialized and shouldn't be read.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reported-by: "Chen, Rong A" <rong.a.chen@intel.com>
    Link: https://lore.gnuweeb.org/timl/d33bb5a9-8173-f65b-f653-51fc0681c6d6@intel.com/
    Cc: Pavel Begunkov <asml.silence@gmail.com>
    Suggested-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>
    Fixes: 7297ce3d59449de49d3c9e1f64ae25488750a1fc ("io_uring: improve send/recv error handling")
    Signed-off-by: Alviro Iskandar Setiawan <alviro.iskandar@gmail.com>
    Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>
    Link: https://lore.kernel.org/r/20220207140533.565411-1-ammarfaizi2@gnuweeb.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: do not recalculate ppos unnecessarily [+ + +]
Author: Dylan Yudaken <dylany@fb.com>
Date:   Tue Feb 22 02:55:03 2022 -0800

    io_uring: do not recalculate ppos unnecessarily
    
    commit b4aec40015953b65f2f114641e7fd7714c8df8e6 upstream.
    
    There is a slight optimisation to be had by calculating the correct pos
    pointer inside io_kiocb_update_pos and then using that later.
    
    It seems code size drops by a bit:
    000000000000a1b0 0000000000000400 t io_read
    000000000000a5b0 0000000000000319 t io_write
    
    vs
    000000000000a1b0 00000000000003f6 t io_read
    000000000000a5b0 0000000000000310 t io_write
    
    Signed-off-by: Dylan Yudaken <dylany@fb.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: don't gate task_work run on TIF_NOTIFY_SIGNAL [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Jan 20 20:50:24 2023 -0700

    io_uring: don't gate task_work run on TIF_NOTIFY_SIGNAL
    
    commit 46a525e199e4037516f7e498c18f065b09df32ac upstream.
    
    This isn't a reliable mechanism to tell if we have task_work pending, we
    really should be looking at whether we have any items queued. This is
    problematic if forward progress is gated on running said task_work. One
    such example is reading from a pipe, where the write side has been closed
    right before the read is started. The fput() of the file queues TWA_RESUME
    task_work, and we need that task_work to be run before ->release() is
    called for the pipe. If ->release() isn't called, then the read will sit
    forever waiting on data that will never arise.
    
    Fix this by io_run_task_work() so it checks if we have task_work pending
    rather than rely on TIF_NOTIFY_SIGNAL for that. The latter obviously
    doesn't work for task_work that is queued without TWA_SIGNAL.
    
    Reported-by: Christiano Haesbaert <haesbaert@haesbaert.org>
    Cc: stable@vger.kernel.org
    Link: https://github.com/axboe/liburing/issues/665
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sat Jan 21 10:21:22 2023 -0700

    io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly
    
    commit 7ba89d2af17aa879dda30f5d5d3f152e587fc551 upstream.
    
    We currently don't attempt to get the full asked for length even if
    MSG_WAITALL is set, if we get a partial receive. If we do see a partial
    receive, then just note how many bytes we did and return -EAGAIN to
    get it retried.
    
    The iov is advanced appropriately for the vector based case, and we
    manually bump the buffer and remainder for the non-vector case.
    
    Cc: stable@vger.kernel.org
    Reported-by: Constantine Gavrilov <constantine.gavrilov@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: ensure that cached task references are always put on exit [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sat Jan 21 12:36:08 2023 -0700

    io_uring: ensure that cached task references are always put on exit
    
    commit e775f93f2ab976a2cdb4a7b53063cbe890904f73 upstream.
    
    io_uring caches task references to avoid doing atomics for each of them
    per request. If a request is put from the same task that allocated it,
    then we can maintain a per-ctx cache of them. This obviously relies
    on io_uring always pruning caches in a reliable way, and there's
    currently a case off io_uring fd release where we can miss that.
    
    One example is a ring setup with IOPOLL, which relies on the task
    polling for completions, which will free them. However, if such a task
    submits a request and then exits or closes the ring without reaping
    the completion, then ring release will reap and put. If release happens
    from that very same task, the completed request task refs will get
    put back into the cache pool. This is problematic, as we're now beyond
    the point of pruning caches.
    
    Manually drop these caches after doing an IOPOLL reap. This releases
    references from the current task, which is enough. If another task
    happens to be doing the release, then the caching will not be
    triggered and there's no issue.
    
    Cc: stable@vger.kernel.org
    Fixes: e98e49b2bbf7 ("io_uring: extend task put optimisations")
    Reported-by: Homin Rhee <hominlab@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: fix async accept on O_NONBLOCK sockets [+ + +]
Author: Dylan Yudaken <dylany@meta.com>
Date:   Sat Jan 21 09:13:12 2023 -0700

    io_uring: fix async accept on O_NONBLOCK sockets
    
    commit a73825ba70c93e1eb39a845bb3d9885a787f8ffe upstream.
    
    Do not set REQ_F_NOWAIT if the socket is non blocking. When enabled this
    causes the accept to immediately post a CQE with EAGAIN, which means you
    cannot perform an accept SQE on a NONBLOCK socket asynchronously.
    
    By removing the flag if there is no pending accept then poll is armed as
    usual and when a connection comes in the CQE is posted.
    
    Signed-off-by: Dylan Yudaken <dylany@fb.com>
    Link: https://lore.kernel.org/r/20220324143435.2875844-1-dylany@fb.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: fix CQ waiting timeout handling [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Thu Jan 5 10:49:15 2023 +0000

    io_uring: fix CQ waiting timeout handling
    
    commit 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 upstream.
    
    Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
    particular we rearm it anew every time we get into
    io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
    CQEs and getting a task_work in the middle may double the timeout value,
    or even worse in some cases task may wait indefinitely.
    
    Cc: stable@vger.kernel.org
    Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/f7bffddd71b08f28a877d44d37ac953ddb01590d.1672915663.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: fix double poll leak on repolling [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Sun Jan 22 10:24:20 2023 -0700

    io_uring: fix double poll leak on repolling
    
    commit c0737fa9a5a5cf5a053bcc983f72d58919b997c6 upstream.
    
    We have re-polling for partial IO, so a request can be polled twice. If
    it used two poll entries the first time then on the second
    io_arm_poll_handler() it will find the old apoll entry and NULL
    kmalloc()'ed second entry, i.e. apoll->double_poll, so leaking it.
    
    Fixes: 10c873334feba ("io_uring: allow re-poll if we made progress")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/fee2452494222ecc7f1f88c8fb659baef971414a.1655852245.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: improve send/recv error handling [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Tue Nov 23 00:07:47 2021 +0000

    io_uring: improve send/recv error handling
    
    commit 7297ce3d59449de49d3c9e1f64ae25488750a1fc upstream.
    
    Hide all error handling under common if block, removes two extra ifs on
    the success path and keeps the handling more condensed.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/5761545158a12968f3caf30f747eea65ed75dfc1.1637524285.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: io_kiocb_update_pos() should not touch file for non -1 offset [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Apr 11 09:48:30 2022 -0600

    io_uring: io_kiocb_update_pos() should not touch file for non -1 offset
    
    commit 6f83ab22adcb77a5824d2c274dace0d99e21319f upstream.
    
    -1 tells use to use the current position, but we check if the file is
    a stream regardless of that. Fix up io_kiocb_update_pos() to only
    dip into file if we need to. This is both more efficient and also drops
    12 bytes of text on aarch64 and 64 bytes on x86-64.
    
    Fixes: b4aec4001595 ("io_uring: do not recalculate ppos unnecessarily")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: lock overflowing for IOPOLL [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Sat Jan 14 09:14:03 2023 -0700

    io_uring: lock overflowing for IOPOLL
    
    commit 544d163d659d45a206d8929370d5a2984e546cb7 upstream.
    
    syzbot reports an issue with overflow filling for IOPOLL:
    
    WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734
    CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0
    Workqueue: events_unbound io_ring_exit_work
    Call trace:
     io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734
     io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773
     io_fill_cqe_req io_uring/io_uring.h:168 [inline]
     io_do_iopoll+0x474/0x62c io_uring/rw.c:1065
     io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513
     io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056
     io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869
     process_one_work+0x2d8/0x504 kernel/workqueue.c:2289
     worker_thread+0x340/0x610 kernel/workqueue.c:2436
     kthread+0x12c/0x158 kernel/kthread.c:376
     ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863
    
    There is no real problem for normal IOPOLL as flush is also called with
    uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL,
    for which __io_cqring_overflow_flush() happens from the CQ waiting path.
    
    Reported-and-tested-by: syzbot+6805087452d72929404e@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: remove duplicated calls to io_kiocb_ppos [+ + +]
Author: Dylan Yudaken <dylany@fb.com>
Date:   Tue Feb 22 02:55:01 2022 -0800

    io_uring: remove duplicated calls to io_kiocb_ppos
    
    commit af9c45ecebaf1b428306f41421f4bcffe439f735 upstream.
    
    io_kiocb_ppos is called in both branches, and it seems that the compiler
    does not fuse this. Fusing removes a few bytes from loop_rw_iter.
    
    Before:
    $ nm -S fs/io_uring.o | grep loop_rw_iter
    0000000000002430 0000000000000124 t loop_rw_iter
    
    After:
    $ nm -S fs/io_uring.o | grep loop_rw_iter
    0000000000002430 000000000000010d t loop_rw_iter
    
    Signed-off-by: Dylan Yudaken <dylany@fb.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: support MSG_WAITALL for IORING_OP_SEND(MSG) [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Apr 20 19:21:36 2022 -0600

    io_uring: support MSG_WAITALL for IORING_OP_SEND(MSG)
    
    commit 4c3c09439c08b03d9503df0ca4c7619c5842892e upstream.
    
    Like commit 7ba89d2af17a for recv/recvmsg, support MSG_WAITALL for the
    send side. If this flag is set and we do a short send, retry for a
    stream of seqpacket socket.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: update kiocb->ki_pos at execution time [+ + +]
Author: Dylan Yudaken <dylany@fb.com>
Date:   Tue Feb 22 02:55:02 2022 -0800

    io_uring: update kiocb->ki_pos at execution time
    
    commit d34e1e5b396a0dbaa4a29b7138df662cfb9d8e8e upstream.
    
    Update kiocb->ki_pos at execution time rather than in io_prep_rw().
    io_prep_rw() happens before the job is enqueued to a worker and so the
    offset might be read multiple times before being executed once.
    
    Ensures that the file position in a set of _linked_ SQEs will be only
    obtained after earlier SQEs have completed, and so will include their
    incremented file position.
    
    Signed-off-by: Dylan Yudaken <dylany@fb.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.10.165 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jan 24 07:20:02 2023 +0100

    Linux 5.10.165
    
    Link: https://lore.kernel.org/r/20230122150229.351631432@linuxfoundation.org
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Link: https://lore.kernel.org/r/20230123094914.748265495@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mei: me: add meteor lake point M DID [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Tue Dec 13 00:02:47 2022 +0200

    mei: me: add meteor lake point M DID
    
    commit 0c4d68261717f89fa8c4f98a6967c3832fcb3ad0 upstream.
    
    Add Meteor Lake Point M device id.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20221212220247.286019-2-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
misc: fastrpc: Don't remove map on creater_process and device_release [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Thu Nov 24 17:49:40 2022 +0000

    misc: fastrpc: Don't remove map on creater_process and device_release
    
    commit 5bb96c8f9268e2fdb0e5321cbc358ee5941efc15 upstream.
    
    Do not remove the map from the list on error path in
    fastrpc_init_create_process, instead call fastrpc_map_put, to avoid
    use-after-free. Do not remove it on fastrpc_device_release either,
    call fastrpc_map_put instead.
    
    The fastrpc_free_map is the only proper place to remove the map.
    This is called only after the reference count is 0.
    
    Fixes: b49f6d83e290 ("misc: fastrpc: Fix a possible double free")
    Cc: stable <stable@kernel.org>
    Co-developed-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20221124174941.418450-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Fix use-after-free race condition for maps [+ + +]
Author: Ola Jeppsson <ola@snap.com>
Date:   Thu Nov 24 17:49:41 2022 +0000

    misc: fastrpc: Fix use-after-free race condition for maps
    
    commit 96b328d119eca7563c1edcc4e1039a62e6370ecb upstream.
    
    It is possible that in between calling fastrpc_map_get() until
    map->fl->lock is taken in fastrpc_free_map(), another thread can call
    fastrpc_map_lookup() and get a reference to a map that is about to be
    deleted.
    
    Rewrite fastrpc_map_get() to only increase the reference count of a map
    if it's non-zero. Propagate this to callers so they can know if a map is
    about to be deleted.
    
    Fixes this warning:
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate
    ...
    Call trace:
     refcount_warn_saturate
     [fastrpc_map_get inlined]
     [fastrpc_map_lookup inlined]
     fastrpc_map_create
     fastrpc_internal_invoke
     fastrpc_device_ioctl
     __arm64_sys_ioctl
     invoke_syscall
    
    Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ola Jeppsson <ola@snap.com>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20221124174941.418450-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma [+ + +]
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Dec 22 12:41:50 2022 -0800

    mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma
    
    commit ab0c3f1251b4670978fde0bd54161795a139b060 upstream.
    
    uprobe_write_opcode() uses collapse_pte_mapped_thp() to restore huge pmd,
    when removing a breakpoint from hugepage text: vma->anon_vma is always set
    in that case, so undo the prohibition.  And MADV_COLLAPSE ought to be able
    to collapse some page tables in a vma which happens to have anon_vma set
    from CoWing elsewhere.
    
    Is anon_vma lock required?  Almost not: if any page other than expected
    subpage of the non-anon huge page is found in the page table, collapse is
    aborted without making any change.  However, it is possible that an anon
    page was CoWed from this extent in another mm or vma, in which case a
    concurrent lookup might look here: so keep it away while clearing pmd (but
    perhaps we shall go back to using pmd_lock() there in future).
    
    Note that collapse_pte_mapped_thp() is exceptional in freeing a page table
    without having cleared its ptes: I'm uneasy about that, and had thought
    pte_clear()ing appropriate; but exclusive i_mmap lock does fix the
    problem, and we would have to move the mmu_notification if clearing those
    ptes.
    
    What this fixes is not a dangerous instability.  But I suggest Cc stable
    because uprobes "healing" has regressed in that way, so this should follow
    8d3c106e19e8 into those stable releases where it was backported (and may
    want adjustment there - I'll supply backports as needed).
    
    Link: https://lkml.kernel.org/r/b740c9fb-edba-92ba-59fb-7a5592e5dfc@google.com
    Fixes: 8d3c106e19e8 ("mm/khugepaged: take the right locks for page table retraction")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: Zach O'Keefe <zokeefe@google.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: <stable@vger.kernel.org>    [5.4+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting [+ + +]
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Wed Dec 7 19:23:15 2022 +0800

    mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting
    
    commit 1e336aa0c0250ec84c6f16efac40c9f0138e367d upstream.
    
    Current code logic may be impacted by the setting of ROM/Bootloader,
    so unmask these bits first, then setting these bits accordingly.
    
    Fixes: 2b16cf326b70 ("mmc: sdhci-esdhc-imx: move tuning static configuration into hwinit function")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20221207112315.1812222-1-haibo.chen@nxp.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sunxi-mmc: Fix clock refcount imbalance during unbind [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Tue Aug 9 21:25:09 2022 -0500

    mmc: sunxi-mmc: Fix clock refcount imbalance during unbind
    
    commit 8509419758f2cc28dd05370385af0d91573b76b4 upstream.
    
    If the controller is suspended by runtime PM, the clock is already
    disabled, so do not try to disable it again during removal. Use
    pm_runtime_disable() to flush any pending runtime PM transitions.
    
    Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220810022509.43743-1-samuel@sholland.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/ethtool/ioctl: return -EOPNOTSUPP if we have no phy stats [+ + +]
Author: Daniil Tatianin <d-tatianin@yandex-team.ru>
Date:   Mon Dec 26 14:48:23 2022 +0300

    net/ethtool/ioctl: return -EOPNOTSUPP if we have no phy stats
    
    [ Upstream commit 9deb1e9fb88b1120a908676fa33bdf9e2eeaefce ]
    
    It's not very useful to copy back an empty ethtool_stats struct and
    return 0 if we didn't actually have any stats. This also allows for
    further simplification of this function in the future commits.
    
    Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: fix missing mutex_unlock in mlx5_fw_fatal_reporter_err_work() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Jan 5 19:42:20 2023 +0800

    net/mlx5: fix missing mutex_unlock in mlx5_fw_fatal_reporter_err_work()
    
    commit 90e7cb78b81543998217b0eb446c067ce2191a79 upstream.
    
    Add missing mutex_unlock() before returning from
    mlx5_fw_fatal_reporter_err_work().
    
    Fixes: 9078e843efec ("net/mlx5: Avoid recovery in probe flows")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/ulp: use consistent error code when blocking ULP [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Jan 18 13:24:12 2023 +0100

    net/ulp: use consistent error code when blocking ULP
    
    commit 8ccc99362b60c6f27bb46f36fdaaccf4ef0303de upstream.
    
    The referenced commit changed the error code returned by the kernel
    when preventing a non-established socket from attaching the ktls
    ULP. Before to such a commit, the user-space got ENOTCONN instead
    of EINVAL.
    
    The existing self-tests depend on such error code, and the change
    caused a failure:
    
      RUN           global.non_established ...
     tls.c:1673:non_established:Expected errno (22) == ENOTCONN (107)
     non_established: Test failed at step #3
              FAIL  global.non_established
    
    In the unlikely event existing applications do the same, address
    the issue by restoring the prior error code in the above scenario.
    
    Note that the only other ULP performing similar checks at init
    time - smc_ulp_ops - also fails with ENOTCONN when trying to attach
    the ULP to a non-established socket.
    
    Reported-by: Sabrina Dubroca <sd@queasysnail.net>
    Fixes: 2c02d41d71f9 ("net/ulp: prevent ULP without clone op from entering the LISTEN status")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/7bb199e7a93317fb6f8bf8b9b2dc71c18f337cde.1674042685.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nilfs2: fix general protection fault in nilfs_btree_insert() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Jan 5 14:53:56 2023 +0900

    nilfs2: fix general protection fault in nilfs_btree_insert()
    
    commit 7633355e5c7f29c049a9048e461427d1d8ed3051 upstream.
    
    If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
    block by calling __nilfs_btree_get_block() against an invalid virtual
    block address, it returns -ENOENT because conversion of the virtual block
    address to a disk block address fails.  However, this return value is the
    same as the internal code that b-tree lookup routines return to indicate
    that the block being searched does not exist, so functions that operate on
    that b-tree may misbehave.
    
    When nilfs_btree_insert() receives this spurious 'not found' code from
    nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
    successful and continues the insert operation using incomplete lookup path
    data, causing the following crash:
    
     general protection fault, probably for non-canonical address
     0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
     KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
     ...
     RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
     RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
     RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
     Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
     ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c
     28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
     ...
     Call Trace:
     <TASK>
      nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]
      nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147
      nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101
      __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991
      __block_write_begin fs/buffer.c:2041 [inline]
      block_write_begin+0x93/0x1e0 fs/buffer.c:2102
      nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261
      generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
      __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900
      generic_file_write_iter+0xab/0x310 mm/filemap.c:3932
      call_write_iter include/linux/fs.h:2186 [inline]
      new_sync_write fs/read_write.c:491 [inline]
      vfs_write+0x7dc/0xc50 fs/read_write.c:584
      ksys_write+0x177/0x2a0 fs/read_write.c:637
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
     ...
     </TASK>
    
    This patch fixes the root cause of this problem by replacing the error
    code that __nilfs_btree_get_block() returns on block address conversion
    failure from -ENOENT to another internal code -EINVAL which means that the
    b-tree metadata is corrupted.
    
    By returning -EINVAL, it propagates without glitches, and for all relevant
    b-tree operations, functions in the upper bmap layer output an error
    message indicating corrupted b-tree metadata via
    nilfs_bmap_convert_error(), and code -EIO will be eventually returned as
    it should be.
    
    Link: https://lkml.kernel.org/r/000000000000bd89e205f0e38355@google.com
    Link: https://lkml.kernel.org/r/20230105055356.8811-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+ede796cecd5296353515@syzkaller.appspotmail.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pNFS/filelayout: Fix coalescing test for single DS [+ + +]
Author: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Date:   Tue Dec 20 12:31:29 2022 -0500

    pNFS/filelayout: Fix coalescing test for single DS
    
    [ Upstream commit a6b9d2fa0024e7e399c26facd0fb466b7396e2b9 ]
    
    When there is a single DS no striping constraints need to be placed on
    the IO. When such constraint is applied then buffered reads don't
    coalesce to the DS's rsize.
    
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
prlimit: do_prlimit needs to have a speculation check [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jan 20 11:03:20 2023 +0100

    prlimit: do_prlimit needs to have a speculation check
    
    commit 739790605705ddcf18f21782b9c99ad7d53a8c11 upstream.
    
    do_prlimit() adds the user-controlled resource value to a pointer that
    will subsequently be dereferenced.  In order to help prevent this
    codepath from being used as a spectre "gadget" a barrier needs to be
    added after checking the range.
    
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Tested-by: Jordy Zomer <jordyzomer@google.com>
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/srp: Move large values to a new enum for gcc13 [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Mon Dec 12 13:04:11 2022 +0100

    RDMA/srp: Move large values to a new enum for gcc13
    
    [ Upstream commit 56c5dab20a6391604df9521f812c01d1e3fe1bd0 ]
    
    Since gcc13, each member of an enum has the same type as the enum [1]. And
    that is inherited from its members. Provided these two:
      SRP_TAG_NO_REQ        = ~0U,
      SRP_TAG_TSK_MGMT      = 1U << 31
    all other members are unsigned ints.
    
    Esp. with SRP_MAX_SGE and SRP_TSK_MGMT_SQ_SIZE and their use in min(),
    this results in the following warnings:
      include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast
      drivers/infiniband/ulp/srp/ib_srp.c:563:42: note: in expansion of macro 'min'
    
      include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast
      drivers/infiniband/ulp/srp/ib_srp.c:2369:27: note: in expansion of macro 'min'
    
    So move the large values away to a separate enum, so that they don't
    affect other members.
    
    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
    
    Link: https://lore.kernel.org/r/20221212120411.13750-1-jirislaby@kernel.org
    Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "drm/amdgpu: make display pinning more flexible (v2)" [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jan 16 16:44:11 2023 -0500

    Revert "drm/amdgpu: make display pinning more flexible (v2)"
    
    This reverts commit 630270978483a63dd641c1183a179437ab4900df which is
    commit 81d0bcf9900932633d270d5bc4a54ff599c6ebdb upstream.
    
    This commit causes hiberation regressions on some platforms on kernels
    older than 6.1.x (6.1.x and newer kernels works fine) so let's revert it
    from 5.15 and older stable kernels.  This should be reverted from 6.0.x
    as well, but that kernel is no longer supported.
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216917
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: kolAflash@kolahilft.de
    Cc: jrf@mailbox.org
    Cc: mario.limonciello@amd.com
    Cc: stable@vger.kernel.org # 5.15.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()" [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 13 12:43:26 2023 +0000

    Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()"
    
    commit 80f8a66dede0a4b4e9e846765a97809c6fe49ce5 upstream.
    
    This reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293.
    
    ieee80211_if_free() is already called from free_netdev(ndev)
    because ndev->priv_destructor == ieee80211_if_free
    
    syzbot reported:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
    CPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline]
    RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline]
    RIP: 0010:free_percpu mm/percpu.c:2271 [inline]
    RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254
    Code: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc
    RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002
    RAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004
    RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020
    RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000
    R13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988
    FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352
    ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411
    mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583
    hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176
    genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968
    genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
    genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065
    netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564
    genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
    netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]
    netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356
    netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xd3/0x120 net/socket.c:734
    ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
    __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Fixes: 13e5afd3d773 ("wifi: mac80211: fix memory leak in ieee80211_if_add()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Zhengchao Shao <shaozhengchao@huawei.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230113124326.3533978-1-edumazet@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID [+ + +]
Author: Hao Sun <sunhao.th@gmail.com>
Date:   Thu Dec 22 10:44:14 2022 +0800

    selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID
    
    [ Upstream commit cedebd74cf3883f0384af9ec26b4e6f8f1964dd4 ]
    
    Verify that nullness information is not porpagated in the branches
    of register to register JEQ and JNE operations if one of them is
    PTR_TO_BTF_ID. Implement this in C level so we can use CO-RE.
    
    Signed-off-by: Hao Sun <sunhao.th@gmail.com>
    Suggested-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20221222024414.29539-2-sunhao.th@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: atmel: fix incorrect baudrate setup [+ + +]
Author: Tobias Schramm <t.schramm@manjaro.org>
Date:   Mon Jan 9 08:29:40 2023 +0100

    serial: atmel: fix incorrect baudrate setup
    
    commit 5bfdd3c654bd879bff50c2e85e42f85ae698b42f upstream.
    
    Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
    setup") changed uart_set_options to select the correct baudrate
    configuration based on the absolute error between requested baudrate and
    available standard baudrate settings.
    Prior to that commit the baudrate was selected based on which predefined
    standard baudrate did not exceed the requested baudrate.
    This change of selection logic was never reflected in the atmel serial
    driver. Thus the comment left in the atmel serial driver is no longer
    accurate.
    Additionally the manual rounding up described in that comment and applied
    via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
    tty_termios_encode_baud_rate to determine the appropriate baudrate flags
    this can cause baudrate selection to fail entirely because
    tty_termios_encode_baud_rate will only select a baudrate if relative error
    between requested and selected baudrate does not exceed +/-2%.
    Fix that by requesting actual, exact baudrate used by the serial.
    
    Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
    Acked-by: Richard Genoud <richard.genoud@gmail.com>
    Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: pch_uart: Pass correct sg to dma_unmap_sg() [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Tue Jan 3 11:34:35 2023 +0200

    serial: pch_uart: Pass correct sg to dma_unmap_sg()
    
    commit e8914b52e5b024e4af3d810a935fe0805eee8a36 upstream.
    
    A local variable sg is used to store scatterlist pointer in
    pch_dma_tx_complete(). The for loop doing Tx byte accounting before
    dma_unmap_sg() alters sg in its increment statement. Therefore, the
    pointer passed into dma_unmap_sg() won't match to the one given to
    dma_map_sg().
    
    To fix the problem, use priv->sg_tx_p directly in dma_unmap_sg()
    instead of the local variable.
    
    Fixes: da3564ee027e ("pch_uart: add multi-scatter processing")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20230103093435.4396-1-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soc: qcom: apr: Make qcom,protection-domain optional again [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Thu Dec 29 16:16:48 2022 +0100

    soc: qcom: apr: Make qcom,protection-domain optional again
    
    commit 599d41fb8ea8bd2a99ca9525dd69405020e43dda upstream.
    
    APR should not fail if the service device tree node does not have
    the qcom,protection-domain property, since this functionality does
    not exist on older platforms such as MSM8916 and MSM8996.
    
    Ignore -EINVAL (returned when the property does not exist) to fix
    a regression on 6.2-rc1 that prevents audio from working:
    
      qcom,apr remoteproc0:smd-edge.apr_audio_svc.-1.-1:
        Failed to read second value of qcom,protection-domain
      qcom,apr remoteproc0:smd-edge.apr_audio_svc.-1.-1:
        Failed to add apr 3 svc
    
    Fixes: 6d7860f5750d ("soc: qcom: apr: Add check for idr_alloc and of_property_read_string_index")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221229151648.19839-3-stephan@gerhold.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
staging: vchiq_arm: fix enum vchiq_status return types [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 17:39:32 2023 +0100

    staging: vchiq_arm: fix enum vchiq_status return types
    
    commit 7d83299351fe7c812c529f5e39fe63b5312e4233 upstream.
    
    gcc-13 notices a type mismatch between function declaration
    and definition for a few functions that have been converted
    from returning vchiq specific status values to regular error
    codes:
    
    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:662:5: error: conflicting types for 'vchiq_initialise' due to enum/integer mismatch; have 'int(struct vchiq_instance **)' [-Werror=enum-int-mismatch]
    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1411:1: error: conflicting types for 'vchiq_use_internal' due to enum/integer mismatch; have 'int(struct vchiq_state *, struct vchiq_service *, enum USE_TYPE_E)' [-Werror=enum-int-mismatch]
    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1468:1: error: conflicting types for 'vchiq_release_internal' due to enum/integer mismatch; have 'int(struct vchiq_state *, struct vchiq_service *)' [-Werror=enum-int-mismatch]
    
    Change the declarations to match the actual function definition.
    
    Fixes: a9fbd828be7f ("staging: vchiq_arm: drop enum vchiq_status from vchiq_*_internal")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20230117163957.1109872-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
thunderbolt: Use correct function to calculate maximum USB3 link rate [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri May 20 13:35:19 2022 +0300

    thunderbolt: Use correct function to calculate maximum USB3 link rate
    
    commit e8ff07fb33026c5c1bb5b81293496faba5d68059 upstream.
    
    We need to take minimum of both sides of the USB3 link into consideration,
    not just the downstream port. Fix this by calling tb_usb3_max_link_rate()
    instead.
    
    Fixes: 0bd680cd900c ("thunderbolt: Add USB3 bandwidth management")
    Cc: stable@vger.kernel.org
    Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tools/virtio: initialize spinlocks in vring_test.c [+ + +]
Author: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Date:   Wed Oct 12 08:29:49 2022 +0200

    tools/virtio: initialize spinlocks in vring_test.c
    
    [ Upstream commit c262f75cb6bb5a63828e72ce3b8fe808e5029479 ]
    
    The virtio_device vqs_list spinlocks must be initialized before use to
    prevent functions that manipulate the device virtualqueues, such as
    vring_new_virtqueue(), from blocking indefinitely.
    
    Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
    Message-Id: <20221012062949.1526176-1-ricardo.canuelo@collabora.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing: Use alignof__(struct {type b;}) instead of offsetof() [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Aug 2 15:44:12 2022 -0400

    tracing: Use alignof__(struct {type b;}) instead of offsetof()
    
    commit 09794a5a6c348f629b35fc1687071a1622ef4265 upstream.
    
    Simplify:
    
      #define ALIGN_STRUCTFIELD(type) ((int)(offsetof(struct {char a; type b;}, b)))
    
    with
    
      #define  ALIGN_STRUCTFIELD(type) __alignof__(struct {type b;})
    
    Which works just the same.
    
    Link: https://lore.kernel.org/all/a7d202457150472588df0bd3b7334b3f@AcuMS.aculab.com/
    Link: https://lkml.kernel.org/r/20220802154412.513c50e3@gandalf.local.home
    
    Suggested-by: David Laight <David.Laight@ACULAB.COM>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Dec 21 17:40:22 2022 +0100

    tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
    
    commit b8caf69a6946e18ffebad49847e258f5b6d52ac2 upstream.
    
    Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on
    default RX FIFO depth, e.g. 16.  Later during serial startup the
    qcom_geni_serial_port_setup() updates the RX FIFO depth
    (port->rx_fifo_depth) to match real device capabilities, e.g. to 32.
    
    The RX UART handle code will read "port->rx_fifo_depth" number of words
    into "port->rx_fifo" buffer, thus exceeding the bounds.  This can be
    observed in certain configurations with Qualcomm Bluetooth HCI UART
    device and KASAN:
    
      Bluetooth: hci0: QCA Product ID   :0x00000010
      Bluetooth: hci0: QCA SOC Version  :0x400a0200
      Bluetooth: hci0: QCA ROM Version  :0x00000200
      Bluetooth: hci0: QCA Patch Version:0x00000d2b
      Bluetooth: hci0: QCA controller version 0x02000200
      Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
      bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2
      Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)
      Bluetooth: hci0: QCA Failed to download patch (-2)
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c
      Write of size 4 at addr ffff279347d578c0 by task swapper/0/0
    
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26
      Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
      Call trace:
       dump_backtrace.part.0+0xe0/0xf0
       show_stack+0x18/0x40
       dump_stack_lvl+0x8c/0xb8
       print_report+0x188/0x488
       kasan_report+0xb4/0x100
       __asan_store4+0x80/0xa4
       handle_rx_uart+0xa8/0x18c
       qcom_geni_serial_handle_rx+0x84/0x9c
       qcom_geni_serial_isr+0x24c/0x760
       __handle_irq_event_percpu+0x108/0x500
       handle_irq_event+0x6c/0x110
       handle_fasteoi_irq+0x138/0x2cc
       generic_handle_domain_irq+0x48/0x64
    
    If the RX FIFO depth changes after probe, be sure to resize the buffer.
    
    Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210 [+ + +]
Author: Juhyung Park <qkrwngud825@gmail.com>
Date:   Tue Jan 17 17:51:54 2023 +0900

    usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210
    
    commit dbd24ec17b85b45f4e823d1aa5607721920f2b05 upstream.
    
    The commit e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
    blacklists UAS for all of RTL9210 enclosures.
    
    The RTL9210 controller was advertised with UAS since its release back in
    2019 and was shipped with a lot of enclosure products with different
    firmware combinations.
    
    Blacklist UAS only for HIKSEMI MD202.
    
    This should hopefully be replaced with more robust method than just
    comparing strings.  But with limited information [1] provided thus far
    (dmesg when the device is plugged in, which includes manufacturer and
    product, but no lsusb -v to compare against), this is the best we can do
    for now.
    
    [1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com
    
    Fixes: e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Hongling Zeng <zenghongling@kylinos.cn>
    Cc: stable@vger.kernel.org
    Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20230117085154.123301-1-qkrwngud825@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: acpi: add helper to check port lpm capability using acpi _DSM [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:15 2023 +0200

    usb: acpi: add helper to check port lpm capability using acpi _DSM
    
    commit cd702d18c882d5a4ea44bbdb38edd5d5577ef640 upstream.
    
    Add a helper to evaluate ACPI usb device specific method (_DSM) provided
    in case the USB3 port shouldn't enter U1 and U2 link states.
    
    This _DSM was added as port specific retimer configuration may lead to
    exit latencies growing beyond U1/U2 exit limits, and OS needs a way to
    find which ports can't support U1/U2 link power management states.
    
    This _DSM is also used by windows:
    Link: https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-
    
    Some patch issues found in testing resolved by Ron Lee
    
    Cc: stable@vger.kernel.org
    Tested-by: Ron Lee <ron.lee@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-7-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: hub: disable autosuspend for TI TUSB8041 [+ + +]
Author: Flavio Suligoi <f.suligoi@asem.it>
Date:   Mon Dec 19 13:47:59 2022 +0100

    usb: core: hub: disable autosuspend for TI TUSB8041
    
    commit 7171b0e261b17de96490adf053b8bb4b00061bcf upstream.
    
    The Texas Instruments TUSB8041 has an autosuspend problem at high
    temperature.
    
    If there is not USB traffic, after a couple of ms, the device enters in
    autosuspend mode. In this condition the external clock stops working, to
    save energy. When the USB activity turns on, ther hub exits the
    autosuspend state, the clock starts running again and all works fine.
    
    At ambient temperature all works correctly, but at high temperature,
    when the USB activity turns on, the external clock doesn't restart and
    the hub disappears from the USB bus.
    
    Disabling the autosuspend mode for this hub solves the issue.
    
    Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
    Cc: stable <stable@kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() [+ + +]
Author: Maciej Żenczykowski <maze@google.com>
Date:   Tue Jan 17 05:18:39 2023 -0800

    usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
    
    commit c6ec929595c7443250b2a4faea988c62019d5cd2 upstream.
    
    In Google internal bug 265639009 we've received an (as yet) unreproducible
    crash report from an aarch64 GKI 5.10.149-android13 running device.
    
    AFAICT the source code is at:
      https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10
    
    The call stack is:
      ncm_close() -> ncm_notify() -> ncm_do_notify()
    with the crash at:
      ncm_do_notify+0x98/0x270
    Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)
    
    Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):
    
      // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)
      0B 0D 00 79    strh w11, [x8, #6]
    
      // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)
      6C 0A 00 B9    str  w12, [x19, #8]
    
      // x10 (NULL) was read here from offset 0 of valid pointer x9
      // IMHO we're reading 'cdev->gadget' and getting NULL
      // gadget is indeed at offset 0 of struct usb_composite_dev
      2A 01 40 F9    ldr  x10, [x9]
    
      // loading req->buf pointer, which is at offset 0 of struct usb_request
      69 02 40 F9    ldr  x9, [x19]
    
      // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed
      4B 5D 40 B9    ldr  w11, [x10, #0x5c]
    
    which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:
    
      event->wLength = cpu_to_le16(8);
      req->length = NCM_STATUS_BYTECOUNT;
    
      /* SPEED_CHANGE data is up/down speeds in bits/sec */
      data = req->buf + sizeof *event;
      data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
    
    My analysis of registers and NULL ptr deref crash offset
      (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
    heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:
      data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
    which calls:
      ncm_bitrate(NULL)
    which then calls:
      gadget_is_superspeed(NULL)
    which reads
      ((struct usb_gadget *)NULL)->max_speed
    and hits a panic.
    
    AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
    (remember there's a GKI KABI reservation of 16 bytes in struct work_struct)
    
    It's not at all clear to me how this is all supposed to work...
    but returning 0 seems much better than panic-ing...
    
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Cc: Carlos Llamas <cmllamas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: g_webcam: Send color matching descriptor per frame [+ + +]
Author: Daniel Scally <dan.scally@ideasonboard.com>
Date:   Fri Dec 16 16:05:28 2022 +0000

    usb: gadget: g_webcam: Send color matching descriptor per frame
    
    commit e95765e97d9cb93258a4840440d410fa6ff7e819 upstream.
    
    Currently the color matching descriptor is only sent across the wire
    a single time, following the descriptors for each format and frame.
    According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching
    Descriptors"):
    
    "Only one instance is allowed for a given format and if present,
    the Color Matching descriptor shall be placed following the Video
    and Still Image Frame descriptors for that format".
    
    Add another reference to the color matching descriptor after the
    yuyv frames so that it's correctly transmitted for that format
    too.
    
    Fixes: a9914127e834 ("USB gadget: Webcam device")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Link: https://lore.kernel.org/r/20221216160528.479094-1-dan.scally@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: gadgetfs: Fix race between mounting and unmounting [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Dec 23 09:59:09 2022 -0500

    USB: gadgetfs: Fix race between mounting and unmounting
    
    commit d18dcfe9860e842f394e37ba01ca9440ab2178f4 upstream.
    
    The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
    in the gadgetfs driver, involving processes concurrently mounting and
    unmounting the gadgetfs filesystem.  In particular, gadgetfs_fill_super()
    can race with gadgetfs_kill_sb(), causing the latter to deallocate
    the_device while the former is using it.  The output from KASAN says,
    in part:
    
    BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
    BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
    BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
    BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
    BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
    BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
    BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
    Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
    
    CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Call Trace:
     <TASK>
    ...
     atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
     __refcount_sub_and_test include/linux/refcount.h:272 [inline]
     __refcount_dec_and_test include/linux/refcount.h:315 [inline]
     refcount_dec_and_test include/linux/refcount.h:333 [inline]
     put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
     gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
     deactivate_locked_super+0xa7/0xf0 fs/super.c:332
     vfs_get_super fs/super.c:1190 [inline]
     get_tree_single+0xd0/0x160 fs/super.c:1207
     vfs_get_tree+0x88/0x270 fs/super.c:1531
     vfs_fsconfig_locked fs/fsopen.c:232 [inline]
    
    The simplest solution is to ensure that gadgetfs_fill_super() and
    gadgetfs_kill_sb() are serialized by making them both acquire a new
    mutex.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+33d7ad66d65044b93f16@syzkaller.appspotmail.com
    Reported-and-tested-by: Gerald Lee <sundaywind2004@gmail.com>
    Link: https://lore.kernel.org/linux-usb/CAO3qeMVzXDP-JU6v1u5Ags6Q-bb35kg3=C6d04DjzA9ffa5x1g@mail.gmail.com/
    Fixes: e5d82a7360d1 ("vfs: Convert gadgetfs to use the new mount API")
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/Y6XCPXBpn3tmjdCC@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: host: ehci-fsl: Fix module alias [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Jan 20 13:27:14 2023 +0100

    usb: host: ehci-fsl: Fix module alias
    
    commit 5d3d01ae15d2f37ed0325c99ab47ef0ae5d05f3c upstream.
    
    Commit ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent
    driver module") changed DRV_NAME which was used for MODULE_ALIAS as well.
    Starting from this the module alias didn't match the platform device
    name created in fsl-mph-dr-of.c
    Change DRV_NAME to match the driver name for host mode in fsl-mph-dr-of.
    This is needed for module autoloading on ls1021a.
    
    Fixes: ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent driver module")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20230120122714.3848784-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jan 20 14:53:30 2023 +0100

    USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100
    
    commit 14ff7460bb58662d86aa50298943cc7d25532e28 upstream.
    
    The USB_DEVICE_ID_CODEMERCS_IOW100 header size was incorrect, it should
    be 12, not 13.
    
    Cc: stable <stable@kernel.org>
    Fixes: 17a82716587e ("USB: iowarrior: fix up report size handling for some devices")
    Reported-by: Christoph Jung <jung@codemercs.com>
    Link: https://lore.kernel.org/r/20230120135330.3842518-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: cp210x: add SCALANCE LPE-9000 device id [+ + +]
Author: Michael Adler <michael.adler@siemens.com>
Date:   Tue Jan 3 14:48:50 2023 +0100

    USB: serial: cp210x: add SCALANCE LPE-9000 device id
    
    commit 3f9e76e31704a325170e5aec2243c8d084d74854 upstream.
    
    Add the USB serial console device ID for Siemens SCALANCE LPE-9000
    which have a USB port for their serial console.
    
    Signed-off-by: Michael Adler <michael.adler@siemens.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EC200U modem [+ + +]
Author: Ali Mirghasemi <ali.mirghasemi1376@gmail.com>
Date:   Wed Dec 28 15:08:47 2022 +0330

    USB: serial: option: add Quectel EC200U modem
    
    commit d9bbb15881046bd76f8710c76e26a740eee997ef upstream.
    
    Add support for EC200U modem
    
    0x0901: EC200U - AT + AP + CP + NMEA + DIAG + MOS
    
    usb-device output:
    T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=2c7c ProdID=0901 Rev= 3.18
    S: Manufacturer=Android
    S: Product=Android
    C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=400mA
    A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=32ms
    I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=83(I) Atr=03(Int.) MxPS= 512 Ivl=4096ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=89(I) Atr=03(Int.) MxPS= 512 Ivl=4096ms
    I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Ali Mirghasemi <ali.mirghasemi1376@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G (CS) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Tue Dec 27 01:28:25 2022 -0800

    USB: serial: option: add Quectel EM05-G (CS) modem
    
    commit bb78654b0b46316dac687fd4b7dc7cce636f46cd upstream.
    
    The EM05-G (CS) modem has 2 USB configurations that are configurable via
    the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate
    with the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=030C Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=030C Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G (GR) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Tue Dec 27 01:44:30 2022 -0800

    USB: serial: option: add Quectel EM05-G (GR) modem
    
    commit 6c331f32e32ac71eb3e8b93fceda2802d7ecb889 upstream.
    
    The EM05-G (GR) modem has 2 USB configurations that are configurable via
    the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate
    with the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0313 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0313 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G (RS) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Tue Dec 27 01:51:27 2022 -0800

    USB: serial: option: add Quectel EM05-G (RS) modem
    
    commit b72d13977689f0c717444010e108c4f20658dfee upstream.
    
    The EM05-G (RS) modem has 2 USB configurations that are configurable via
    the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate
    with the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0314 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0314 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05CN (SG) modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Sun Jan 15 18:07:27 2023 -0800

    USB: serial: option: add Quectel EM05CN (SG) modem
    
    commit 1541dd0097c0f8f470e76eddf5120fc55a7e3101 upstream.
    
    The EM05CN (SG) modem has 2 USB configurations that are configurable via the AT
    command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with
    the following interfaces, respectively:
    
    "MBIM"  : AT + MBIM + DIAG + NMEA  + MODEM
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    
    The detailed description of the USB configuration for each mode as follows:
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0310 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 2 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0310 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05CN modem [+ + +]
Author: Duke Xin(辛安文) <duke_xinanwen@163.com>
Date:   Sun Jan 15 18:33:28 2023 -0800

    USB: serial: option: add Quectel EM05CN modem
    
    commit 71dfd381a7c051f16a61f82fbd38a4cca563bdca upstream.
    
    The EM05CN modem has 2 USB configurations that are configurable via the AT
    command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with
    the following interfaces, respectively:
    
    "MBIM"  : AT + MBIM + DIAG + NMEA  + MODEM
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    
    The detailed description of the USB configuration for each mode as follows:
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0312 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 2 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0312 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-CN
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin(辛安文) <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: altmodes/displayport: Add pin assignment helper [+ + +]
Author: Prashant Malani <pmalani@chromium.org>
Date:   Wed Jan 11 02:05:41 2023 +0000

    usb: typec: altmodes/displayport: Add pin assignment helper
    
    commit 582836e3cfab4faafbdc93bbec96fce036a08ee1 upstream.
    
    The code to extract a peripheral's currently supported Pin Assignments
    is repeated in a couple of locations. Factor it out into a separate
    function.
    
    This will also make it easier to add fixes (we only need to update 1
    location instead of 2).
    
    Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
    Cc: stable@vger.kernel.org
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Prashant Malani <pmalani@chromium.org>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20230111020546.3384569-1-pmalani@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: altmodes/displayport: Fix pin assignment calculation [+ + +]
Author: Prashant Malani <pmalani@chromium.org>
Date:   Wed Jan 11 02:05:42 2023 +0000

    usb: typec: altmodes/displayport: Fix pin assignment calculation
    
    commit 9682b41e52cc9f42f5c33caf410464392adaef04 upstream.
    
    Commit c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin
    assignment for UFP receptacles") fixed the pin assignment calculation
    to take into account whether the peripheral was a plug or a receptacle.
    
    But the "pin_assignments" sysfs logic was not updated. Address this by
    using the macros introduced in the aforementioned commit in the sysfs
    logic too.
    
    Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
    Cc: stable@vger.kernel.org
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Prashant Malani <pmalani@chromium.org>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20230111020546.3384569-2-pmalani@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci: Check endpoint is valid before dereferencing it [+ + +]
Author: Jimmy Hu <hhhuuu@google.com>
Date:   Mon Jan 16 16:22:11 2023 +0200

    usb: xhci: Check endpoint is valid before dereferencing it
    
    commit e8fb5bc76eb86437ab87002d4a36d6da02165654 upstream.
    
    When the host controller is not responding, all URBs queued to all
    endpoints need to be killed. This can cause a kernel panic if we
    dereference an invalid endpoint.
    
    Fix this by using xhci_get_virt_ep() helper to find the endpoint and
    checking if the endpoint is valid before dereferencing it.
    
    [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
    [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8
    
    [233311.853964] pc : xhci_hc_died+0x10c/0x270
    [233311.853971] lr : xhci_hc_died+0x1ac/0x270
    
    [233311.854077] Call trace:
    [233311.854085]  xhci_hc_died+0x10c/0x270
    [233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4
    [233311.854105]  call_timer_fn+0x50/0x2d4
    [233311.854112]  expire_timers+0xac/0x2e4
    [233311.854118]  run_timer_softirq+0x300/0xabc
    [233311.854127]  __do_softirq+0x148/0x528
    [233311.854135]  irq_exit+0x194/0x1a8
    [233311.854143]  __handle_domain_irq+0x164/0x1d0
    [233311.854149]  gic_handle_irq.22273+0x10c/0x188
    [233311.854156]  el1_irq+0xfc/0x1a8
    [233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
    [233311.854185]  cpuidle_enter_state+0x1f0/0x764
    [233311.854194]  do_idle+0x594/0x6ac
    [233311.854201]  cpu_startup_entry+0x7c/0x80
    [233311.854209]  secondary_start_kernel+0x170/0x198
    
    Fixes: 50e8725e7c42 ("xhci: Refactor command watchdog and fix split string.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jimmy Hu <hhhuuu@google.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Message-ID: <0fe978ed-8269-9774-1c40-f8a98c17e838@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices [+ + +]
Author: Arend van Spriel <arend.vanspriel@broadcom.com>
Date:   Wed Jan 11 12:24:19 2023 +0100

    wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices
    
    commit ed05cb177ae5cd7f02f1d6e7706ba627d30f1696 upstream.
    
    A sanity check was introduced considering maximum flowrings above
    256 as insane and effectively aborting the device probe. This
    resulted in regression for number of users as the value turns out
    to be sane after all.
    
    Fixes: 2aca4f3734bd ("brcmfmac: return error when getting invalid max_flowrings from dongle")
    Reported-by: chainofflowers <chainofflowers@posteo.net>
    Link: https://lore.kernel.org/all/4781984.GXAFRqVoOG@luna/
    Reported-by: Christian Marillat <marillat@debian.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216894
    Cc: stable@vger.kernel.org
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230111112419.24185-1-arend.vanspriel@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: mac80211: sdata can be NULL during AMPDU start [+ + +]
Author: Alexander Wetzel <alexander@wetzel-home.de>
Date:   Fri Dec 30 13:18:50 2022 +0100

    wifi: mac80211: sdata can be NULL during AMPDU start
    
    commit 69403bad97aa0162e3d7911b27e25abe774093df upstream.
    
    ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
    deauthentication is ongoing.
    
    Here a trace triggering the race with the hostapd test
    multi_ap_fronthaul_on_ap:
    
    (gdb) list *drv_ampdu_action+0x46
    0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
    391             int ret = -EOPNOTSUPP;
    392
    393             might_sleep();
    394
    395             sdata = get_bss_sdata(sdata);
    396             if (!check_sdata_in_driver(sdata))
    397                     return -EIO;
    398
    399             trace_drv_ampdu_action(local, sdata, params);
    400
    
    wlan0: moving STA 02:00:00:00:03:00 to state 3
    wlan0: associated
    wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
    wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
    wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
    wlan0: moving STA 02:00:00:00:03:00 to state 2
    wlan0: moving STA 02:00:00:00:03:00 to state 1
    wlan0: Removed STA 02:00:00:00:03:00
    wlan0: Destroyed STA 02:00:00:00:03:00
    BUG: unable to handle page fault for address: fffffffffffffb48
    PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G        W          6.1.0-rc8-wt+ #59
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
    Workqueue: phy3 ieee80211_ba_session_work [mac80211]
    RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
    Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
    RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
    RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
    RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
    RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
    R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
    R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
    FS:  0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
    Call Trace:
     <TASK>
     ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]
     ieee80211_ba_session_work+0xff/0x2e0 [mac80211]
     process_one_work+0x29f/0x620
     worker_thread+0x4d/0x3d0
     ? process_one_work+0x620/0x620
     kthread+0xfb/0x120
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x22/0x30
     </TASK>
    
    Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
    Link: https://lore.kernel.org/r/20221230121850.218810-2-alexander@wetzel-home.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/asm: Fix an assembler warning with current binutils [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 3 10:24:11 2023 -0500

    x86/asm: Fix an assembler warning with current binutils
    
    [ Upstream commit 55d235361fccef573990dfa5724ab453866e7816 ]
    
    Fix a warning: "found `movsd'; assuming `movsl' was meant"
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN [+ + +]
Author: YingChi Long <me@inclyc.cn>
Date:   Fri Nov 18 08:55:35 2022 +0800

    x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN
    
    commit 55228db2697c09abddcb9487c3d9fa5854a932cd upstream.
    
    WG14 N2350 specifies that it is an undefined behavior to have type
    definitions within offsetof", see
    
      https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
    
    This specification is also part of C23.
    
    Therefore, replace the TYPE_ALIGN macro with the _Alignof builtin to
    avoid undefined behavior. (_Alignof itself is C11 and the kernel is
    built with -gnu11).
    
    ISO C11 _Alignof is subtly different from the GNU C extension
    __alignof__. Latter is the preferred alignment and _Alignof the
    minimal alignment. For long long on x86 these are 8 and 4
    respectively.
    
    The macro TYPE_ALIGN's behavior matches _Alignof rather than
    __alignof__.
    
      [ bp: Massage commit message. ]
    
    Signed-off-by: YingChi Long <me@inclyc.cn>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20220925153151.2467884-1-me@inclyc.cn
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci-pci: set the dma max_seg_size [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Jan 16 16:22:10 2023 +0200

    xhci-pci: set the dma max_seg_size
    
    commit 93915a4170e9defd56a767a18e6c4076f3d18609 upstream.
    
    Allow devices to have dma operations beyond 64K, and avoid warnings such
    as:
    
    xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536]
    
    Cc: stable@vger.kernel.org
    Cc: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci: Add a flag to disable USB3 lpm on a xhci root port level. [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:14 2023 +0200

    xhci: Add a flag to disable USB3 lpm on a xhci root port level.
    
    commit 0522b9a1653048440da5f21747f21e498b9220d1 upstream.
    
    One USB3 roothub port may support link power management, while another
    root port on the same xHC can't due to different retimers used for
    the ports.
    
    This is the case with Intel Alder Lake, and possible future platforms
    where retimers used for USB4 ports cause too long exit latecy to
    enable native USB3 lpm U1 and U2 states.
    
    Add a flag in the xhci port structure to indicate if the port is
    lpm_incapable, and check it while calculating exit latency.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Add update_hub_device override for PCI xHCI hosts [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:13 2023 +0200

    xhci: Add update_hub_device override for PCI xHCI hosts
    
    commit 23a3b8d5a2365653fd9bc5a9454d1e7f4facbf85 upstream.
    
    Allow PCI hosts to check and tune roothub and port settings
    before the hub is up and running.
    
    This override is needed to turn off U1 and U2 LPM for some ports
    based on per port ACPI _DSM, _UPC, or possibly vendor specific mmio
    values for Intel xHC hosts.
    
    Usb core calls the host update_hub_device once it creates a hub.
    
    Entering U1 or U2 link power save state on ports with this limitation
    will cause link to fail, turning the usb device unusable in that setup.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:16 2023 +0200

    xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables
    
    commit 74622f0a81d0c2bcfc39f9192b788124e8c7f0af upstream.
    
    USB3 ports on xHC hosts may have retimers that cause too long
    exit latency to work with native USB3 U1/U2 link power management states.
    
    For now only use usb_acpi_port_lpm_incapable() to evaluate if port lpm
    should be disabled while setting up the USB3 roothub.
    
    Other ways to identify lpm incapable ports can be added here later if
    ACPI _DSM does not exist.
    
    Limit this to Intel hosts for now, this is to my knowledge only
    an Intel issue.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-8-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Fix null pointer dereference when host dies [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 16 16:22:12 2023 +0200

    xhci: Fix null pointer dereference when host dies
    
    commit a2bc47c43e70cf904b1af49f76d572326c08bca7 upstream.
    
    Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
    and cause null pointer dereference when host suddenly dies.
    
    Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]
    virt device at the same time that xhci_kill_endpoint_urbs() tries to
    loop through all the device's endpoints, checking if there are any
    cancelled urbs left to give back.
    
    hold the xhci spinlock while freeing the virt device
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230116142216.1141605-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
zonefs: Detect append writes at invalid locations [+ + +]
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Fri Jan 6 17:43:06 2023 +0900

    zonefs: Detect append writes at invalid locations
    
    commit a608da3bd730d718f2d3ebec1c26f9865f8f17ce upstream.
    
    Using REQ_OP_ZONE_APPEND operations for synchronous writes to sequential
    files succeeds regardless of the zone write pointer position, as long as
    the target zone is not full. This means that if an external (buggy)
    application writes to the zone of a sequential file underneath the file
    system, subsequent file write() operation will succeed but the file size
    will not be correct and the file will contain invalid data written by
    another application.
    
    Modify zonefs_file_dio_append() to check the written sector of an append
    write (returned in bio->bi_iter.bi_sector) and return -EIO if there is a
    mismatch with the file zone wp offset field. This change triggers a call
    to zonefs_io_error() and a zone check. Modify zonefs_io_error_cb() to
    not expose the unexpected data after the current inode size when the
    errors=remount-ro mode is used. Other error modes are correctly handled
    already.
    
    Fixes: 02ef12a663c7 ("zonefs: use REQ_OP_ZONE_APPEND for sync DIO")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>