Linux 4.19.271

 
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>

 
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>

 
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>

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

    Linux 4.19.271
    
    Link: https://lore.kernel.org/r/20230122150219.557984692@linuxfoundation.org
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    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>

 
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 "ext4: add new pending reservation mechanism" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jan 22 15:12:37 2023 +0100

    Revert "ext4: add new pending reservation mechanism"
    
    This reverts commit 9bacbb4cfdbc41518d13f620d3f53c0ba36ca87e which is
    commit 1dc0aa46e74a3366e12f426b7caaca477853e9c3 upstream.
    
    Eric writes:
            I recommend not backporting this patch or the other three
            patches apparently intended to support it to 4.19 stable.  All
            these patches are related to ext4's bigalloc feature, which was
            experimental as of 4.19 (expressly noted by contemporary
            versions of e2fsprogs) and also suffered from a number of bugs.
            A significant number of additional patches that were applied to
            5.X kernels over time would have to be backported to 4.19 for
            the patch below to function correctly. It's really not worth
            doing that given bigalloc's experimental status as of 4.19 and
            the very rare combination of the bigalloc and inline features.
    
    Link: https://lore.kernel.org/r/Y8mAe1SlcLD5fykg@debian-BULLSEYE-live-builder-AMD64
    Cc: Eric Whitney <enwlinux@gmail.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jan 22 15:10:23 2023 +0100

    Revert "ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline"
    
    This reverts commit 1ed1eef0551bebee8e56973ccd0900e3578edfb7 which is
    commit 131294c35ed6f777bd4e79d42af13b5c41bf2775 upstream.
    
    Eric writes:
            I recommend not backporting this patch or the other three
            patches apparently intended to support it to 4.19 stable.  All
            these patches are related to ext4's bigalloc feature, which was
            experimental as of 4.19 (expressly noted by contemporary
            versions of e2fsprogs) and also suffered from a number of bugs.
            A significant number of additional patches that were applied to
            5.X kernels over time would have to be backported to 4.19 for
            the patch below to function correctly. It's really not worth
            doing that given bigalloc's experimental status as of 4.19 and
            the very rare combination of the bigalloc and inline features.
    
    Link: https://lore.kernel.org/r/Y8mAe1SlcLD5fykg@debian-BULLSEYE-live-builder-AMD64
    Cc: Eric Whitney <enwlinux@gmail.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "ext4: fix reserved cluster accounting at delayed write time" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jan 22 15:12:07 2023 +0100

    Revert "ext4: fix reserved cluster accounting at delayed write time"
    
    This reverts commit d40e09f701cf7a44e595a558b067b2b4f67fbf87 which is
    commit 0b02f4c0d6d9e2c611dfbdd4317193e9dca740e6 upstream.
    
    Eric writes:
            I recommend not backporting this patch or the other three
            patches apparently intended to support it to 4.19 stable.  All
            these patches are related to ext4's bigalloc feature, which was
            experimental as of 4.19 (expressly noted by contemporary
            versions of e2fsprogs) and also suffered from a number of bugs.
            A significant number of additional patches that were applied to
            5.X kernels over time would have to be backported to 4.19 for
            the patch below to function correctly. It's really not worth
            doing that given bigalloc's experimental status as of 4.19 and
            the very rare combination of the bigalloc and inline features.
    
    Link: https://lore.kernel.org/r/Y8mAe1SlcLD5fykg@debian-BULLSEYE-live-builder-AMD64
    Cc: Eric Whitney <enwlinux@gmail.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "ext4: generalize extents status tree search functions" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jan 22 15:13:05 2023 +0100

    Revert "ext4: generalize extents status tree search functions"
    
    This reverts commit cca8671f3a7f5775a078f2676f6d1039afb925e6 which is
    commit ad431025aecda85d3ebef5e4a3aca5c1c681d0c7 upstream.
    
    Eric writes:
            I recommend not backporting this patch or the other three
            patches apparently intended to support it to 4.19 stable.  All
            these patches are related to ext4's bigalloc feature, which was
            experimental as of 4.19 (expressly noted by contemporary
            versions of e2fsprogs) and also suffered from a number of bugs.
            A significant number of additional patches that were applied to
            5.X kernels over time would have to be backported to 4.19 for
            the patch below to function correctly. It's really not worth
            doing that given bigalloc's experimental status as of 4.19 and
            the very rare combination of the bigalloc and inline features.
    
    Link: https://lore.kernel.org/r/Y8mAe1SlcLD5fykg@debian-BULLSEYE-live-builder-AMD64
    Cc: Eric Whitney <enwlinux@gmail.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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: 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: 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>

 
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: 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>