commit f96eb53cbd76415edfba99c2cfa88567a885a428
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 3 09:56:26 2021 +0200

    Linux 4.14.246
    
    Link: https://lore.kernel.org/r/20210901122249.786673285@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ac05376dbb8539d882ffa2069be680859920ce7
Author: Denis Efremov <efremov@linux.com>
Date:   Sat Aug 7 10:37:02 2021 +0300

    Revert "floppy: reintroduce O_NDELAY fix"
    
    commit c7e9d0020361f4308a70cdfd6d5335e273eb8717 upstream.
    
    The patch breaks userspace implementations (e.g. fdutils) and introduces
    regressions in behaviour. Previously, it was possible to O_NDELAY open a
    floppy device with no media inserted or with write protected media without
    an error. Some userspace tools use this particular behavior for probing.
    
    It's not the first time when we revert this patch. Previous revert is in
    commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
    
    This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
    
    Link: https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@compro.net/
    Reported-by: Mark Hounschell <markh@compro.net>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Wim Osterholt <wim@djo.tudelft.nl>
    Cc: Kurt Garloff <kurt@garloff.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Denis Efremov <efremov@linux.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cea9e8ee3b8059bd2b36d68f1f428d165e5d13ce
Author: Lai Jiangshan <laijs@linux.alibaba.com>
Date:   Thu Jun 3 13:24:55 2021 +0800

    KVM: X86: MMU: Use the correct inherited permissions to get shadow page
    
    commit b1bd5cba3306691c771d558e94baa73e8b0b96b7 upstream.
    
    When computing the access permissions of a shadow page, use the effective
    permissions of the walk up to that point, i.e. the logic AND of its parents'
    permissions.  Two guest PxE entries that point at the same table gfn need to
    be shadowed with different shadow pages if their parents' permissions are
    different.  KVM currently uses the effective permissions of the last
    non-leaf entry for all non-leaf entries.  Because all non-leaf SPTEs have
    full ("uwx") permissions, and the effective permissions are recorded only
    in role.access and merged into the leaves, this can lead to incorrect
    reuse of a shadow page and eventually to a missing guest protection page
    fault.
    
    For example, here is a shared pagetable:
    
       pgd[]   pud[]        pmd[]            virtual address pointers
                         /->pmd1(u--)->pte1(uw-)->page1 <- ptr1 (u--)
            /->pud1(uw-)--->pmd2(uw-)->pte2(uw-)->page2 <- ptr2 (uw-)
       pgd-|           (shared pmd[] as above)
            \->pud2(u--)--->pmd1(u--)->pte1(uw-)->page1 <- ptr3 (u--)
                         \->pmd2(uw-)->pte2(uw-)->page2 <- ptr4 (u--)
    
      pud1 and pud2 point to the same pmd table, so:
      - ptr1 and ptr3 points to the same page.
      - ptr2 and ptr4 points to the same page.
    
    (pud1 and pud2 here are pud entries, while pmd1 and pmd2 here are pmd entries)
    
    - First, the guest reads from ptr1 first and KVM prepares a shadow
      page table with role.access=u--, from ptr1's pud1 and ptr1's pmd1.
      "u--" comes from the effective permissions of pgd, pud1 and
      pmd1, which are stored in pt->access.  "u--" is used also to get
      the pagetable for pud1, instead of "uw-".
    
    - Then the guest writes to ptr2 and KVM reuses pud1 which is present.
      The hypervisor set up a shadow page for ptr2 with pt->access is "uw-"
      even though the pud1 pmd (because of the incorrect argument to
      kvm_mmu_get_page in the previous step) has role.access="u--".
    
    - Then the guest reads from ptr3.  The hypervisor reuses pud1's
      shadow pmd for pud2, because both use "u--" for their permissions.
      Thus, the shadow pmd already includes entries for both pmd1 and pmd2.
    
    - At last, the guest writes to ptr4.  This causes no vmexit or pagefault,
      because pud1's shadow page structures included an "uw-" page even though
      its role.access was "u--".
    
    Any kind of shared pagetable might have the similar problem when in
    virtual machine without TDP enabled if the permissions are different
    from different ancestors.
    
    In order to fix the problem, we change pt->access to be an array, and
    any access in it will not include permissions ANDed from child ptes.
    
    The test code is: https://lore.kernel.org/kvm/20210603050537.19605-1-jiangshanlai@gmail.com/
    Remember to test it with TDP disabled.
    
    The problem had existed long before the commit 41074d07c78b ("KVM: MMU:
    Fix inherited permissions for emulated guest pte updates"), and it
    is hard to find which is the culprit.  So there is no fixes tag here.
    
    Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
    Message-Id: <20210603052455.21023-1-jiangshanlai@gmail.com>
    Cc: stable@vger.kernel.org
    Fixes: cea0f0e7ea54 ("[PATCH] KVM: MMU: Shadow page table caching")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [OP: - apply arch/x86/kvm/mmu/* changes to arch/x86/kvm
         - apply documentation changes to Documentation/virtual/kvm/mmu.txt
         - add vcpu parameter to gpte_access() call]
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d1c01e5359a8e6e0d691f7ec6b40700230f6d45
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 22 10:56:47 2021 -0700

    KVM: x86/mmu: Treat NX as used (not reserved) for all !TDP shadow MMUs
    
    commit 112022bdb5bc372e00e6e43cb88ee38ea67b97bd upstream
    
    Mark NX as being used for all non-nested shadow MMUs, as KVM will set the
    NX bit for huge SPTEs if the iTLB mutli-hit mitigation is enabled.
    Checking the mitigation itself is not sufficient as it can be toggled on
    at any time and KVM doesn't reset MMU contexts when that happens.  KVM
    could reset the contexts, but that would require purging all SPTEs in all
    MMUs, for no real benefit.  And, KVM already forces EFER.NX=1 when TDP is
    disabled (for WP=0, SMEP=1, NX=0), so technically NX is never reserved
    for shadow MMUs.
    
    Fixes: b8e8c8303ff2 ("kvm: mmu: ITLB_MULTIHIT mitigation")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210622175739.3610207-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [sudip: use old path and adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 688dffd8db440196d33b801ad641036954125100
Author: George Kennedy <george.kennedy@oracle.com>
Date:   Tue Jul 7 15:26:03 2020 -0400

    fbmem: add margin check to fb_check_caps()
    
    commit a49145acfb975d921464b84fe00279f99827d816 upstream.
    
    A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
    or yres setting in struct fb_var_screeninfo will result in a
    KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as
    the margins are being cleared. The margins are cleared in
    chunks and if the xres setting or yres setting is a value of
    zero upto the chunk size, the failure will occur.
    
    Add a margin check to validate xres and yres settings.
    
    Signed-off-by: George Kennedy <george.kennedy@oracle.com>
    Reported-by: syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Dhaval Giani <dhaval.giani@oracle.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kennedy@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f488313d96fc6512a4a0fe3ed56cce92cbeec94
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Aug 30 08:55:18 2021 -0700

    vt_kdsetmode: extend console locking
    
    commit 2287a51ba822384834dafc1c798453375d1107c7 upstream.
    
    As per the long-suffering comment.
    
    Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2db4a6ce8326d7ece73e207e7c14d9224fd8f87
Author: Gerd Rausch <gerd.rausch@oracle.com>
Date:   Tue Aug 17 10:04:37 2021 -0700

    net/rds: dma_map_sg is entitled to merge entries
    
    [ Upstream commit fb4b1373dcab086d0619c29310f0466a0b2ceb8a ]
    
    Function "dma_map_sg" is entitled to merge adjacent entries
    and return a value smaller than what was passed as "nents".
    
    Subsequently "ib_map_mr_sg" needs to work with this value ("sg_dma_len")
    rather than the original "nents" parameter ("sg_len").
    
    This old RDS bug was exposed and reliably causes kernel panics
    (using RDMA operations "rds-stress -D") on x86_64 starting with:
    commit c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
    
    Simply put: Linux 5.11 and later.
    
    Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Link: https://lore.kernel.org/r/60efc69f-1f35-529d-a7ef-da0549cad143@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdd9f1fa85bb13d9c94eadb9b008132746be913f
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Aug 9 16:40:48 2021 +1000

    drm/nouveau/disp: power down unused DP links during init
    
    [ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
    
    When booted with multiple displays attached, the EFI GOP driver on (at
    least) Ampere, can leave DP links powered up that aren't being used to
    display anything.  This confuses our tracking of SOR routing, with the
    likely result being a failed modeset and display engine hang.
    
    Fix this by (ab?)using the DisableLT IED script to power-down the link,
    restoring HW to a state the driver expects.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f9d527e1dbb72d50477bb730601793cd055a660
Author: Mark Yacoub <markyacoub@google.com>
Date:   Thu Aug 12 15:49:17 2021 -0400

    drm: Copy drm_wait_vblank to user before returning
    
    [ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
    
    [Why]
    Userspace should get back a copy of drm_wait_vblank that's been modified
    even when drm_wait_vblank_ioctl returns a failure.
    
    Rationale:
    drm_wait_vblank_ioctl modifies the request and expects the user to read
    it back. When the type is RELATIVE, it modifies it to ABSOLUTE and updates
    the sequence to become current_vblank_count + sequence (which was
    RELATIVE), but now it became ABSOLUTE.
    drmWaitVBlank (in libdrm) expects this to be the case as it modifies
    the request to be Absolute so it expects the sequence to would have been
    updated.
    
    The change is in compat_drm_wait_vblank, which is called by
    drm_compat_ioctl. This change of copying the data back regardless of the
    return number makes it en par with drm_ioctl, which always copies the
    data before returning.
    
    [How]
    Return from the function after everything has been copied to user.
    
    Fixes IGT:kms_flip::modeset-vs-vblank-race-interruptible
    Tested on ChromeOS Trogdor(msm)
    
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210812194917.1703356-1-markyacoub@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6cd6452926f19fd14f820be1e26ec52a8fee242
Author: Neeraj Upadhyay <neeraju@codeaurora.org>
Date:   Fri Jun 25 08:55:02 2021 +0530

    vringh: Use wiov->used to check for read/write desc order
    
    [ Upstream commit e74cfa91f42c50f7f649b0eca46aa049754ccdbd ]
    
    As __vringh_iov() traverses a descriptor chain, it populates
    each descriptor entry into either read or write vring iov
    and increments that iov's ->used member. So, as we iterate
    over a descriptor chain, at any point, (riov/wriov)->used
    value gives the number of descriptor enteries available,
    which are to be read or written by the device. As all read
    iovs must precede the write iovs, wiov->used should be zero
    when we are traversing a read descriptor. Current code checks
    for wiov->i, to figure out whether any previous entry in the
    current descriptor chain was a write descriptor. However,
    iov->i is only incremented, when these vring iovs are consumed,
    at a later point, and remain 0 in __vringh_iov(). So, correct
    the check for read and write descriptor order, to use
    wiov->used.
    
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
    Link: https://lore.kernel.org/r/1624591502-4827-1-git-send-email-neeraju@codeaurora.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fbaac3e3c2f4bcc9b8ad64c0a143aeb0a7a7f46
Author: Parav Pandit <parav@nvidia.com>
Date:   Wed Jul 21 17:26:45 2021 +0300

    virtio: Improve vq->broken access to avoid any compiler optimization
    
    [ Upstream commit 60f0779862e4ab943810187752c462e85f5fa371 ]
    
    Currently vq->broken field is read by virtqueue_is_broken() in busy
    loop in one context by virtnet_send_command().
    
    vq->broken is set to true in other process context by
    virtio_break_device(). Reader and writer are accessing it without any
    synchronization. This may lead to a compiler optimization which may
    result to optimize reading vq->broken only once.
    
    Hence, force reading vq->broken on each invocation of
    virtqueue_is_broken() and also force writing it so that such
    update is visible to the readers.
    
    It is a theoretical fix that isn't yet encountered in the field.
    
    Signed-off-by: Parav Pandit <parav@nvidia.com>
    Link: https://lore.kernel.org/r/20210721142648.1525924-2-parav@nvidia.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b84caa3ff66c51b6437f050e69ce6cdfaa6660fa
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Mon Jul 26 10:30:56 2021 +0200

    opp: remove WARN when no valid OPPs remain
    
    [ Upstream commit 335ffab3ef864539e814b9a2903b0ae420c1c067 ]
    
    This WARN can be triggered per-core and the stack trace is not useful.
    Replace it with plain dev_err(). Fix a comment while at it.
    
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69451fe8a877a12baa3e00f9c972a76ab0c37739
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Aug 27 11:29:27 2021 +0200

    usb: gadget: u_audio: fix race condition on endpoint stop
    
    [ Upstream commit 068fdad20454f815e61e6f6eb9f051a8b3120e88 ]
    
    If the endpoint completion callback is call right after the ep_enabled flag
    is cleared and before usb_ep_dequeue() is call, we could do a double free
    on the request and the associated buffer.
    
    Fix this by clearing ep_enabled after all the endpoint requests have been
    dequeued.
    
    Fixes: 7de8681be2cd ("usb: gadget: u_audio: Free requests only after callback")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20210827092927.366482-1-jbrunet@baylibre.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11f2193a1b4edbdd39982144fe5052add3d77636
Author: Maxim Kiselev <bigunclemax@gmail.com>
Date:   Fri Aug 20 18:39:51 2021 +0300

    net: marvell: fix MVNETA_TX_IN_PRGRS bit number
    
    [ Upstream commit 359f4cdd7d78fdf8c098713b05fee950a730f131 ]
    
    According to Armada XP datasheet bit at 0 position is corresponding for
    TxInProg indication.
    
    Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
    Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 076662bfbf05637f0871c40a70828ca3da5e23a8
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 21 09:35:23 2021 +0200

    xgene-v2: Fix a resource leak in the error handling path of 'xge_probe()'
    
    [ Upstream commit 5ed74b03eb4d08f5dd281dcb5f1c9bb92b363a8d ]
    
    A successful 'xge_mdio_config()' call should be balanced by a corresponding
    'xge_mdio_remove()' call in the error handling path of the probe, as
    already done in the remove function.
    
    Update the error handling path accordingly.
    
    Fixes: ea8ab16ab225 ("drivers: net: xgene-v2: Add MDIO support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99279223a37b46dc7716ec4e0ed4b3e03f1cfa4c
Author: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
Date:   Sat Aug 21 12:44:24 2021 +0530

    ip_gre: add validation for csum_start
    
    [ Upstream commit 1d011c4803c72f3907eccfc1ec63caefb852fcbf ]
    
    Validate csum_start in gre_handle_offloads before we call _gre_xmit so
    that we do not crash later when the csum_start value is used in the
    lco_csum function call.
    
    This patch deals with ipv4 code.
    
    Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
    Reported-by: syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com
    Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82657502ef1f71bbe88144df7b43e55b6650a5c2
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Sun Jul 4 10:11:41 2021 +0300

    e1000e: Fix the max snoop/no-snoop latency for 10M
    
    [ Upstream commit 44a13a5d99c71bf9e1676d9e51679daf4d7b3d73 ]
    
    We should decode the latency and the max_latency before directly compare.
    The latency should be presented as lat_enc = scale x value:
    lat_enc_d = (lat_enc & 0x0x3ff) x (1U << (5*((max_ltr_enc & 0x1c00)
    >> 10)))
    
    Fixes: cf8fb73c23aa ("e1000e: add support for LTR on I217/I218")
    Suggested-by: Yee Li <seven.yi.lee@gmail.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba86c6a693b95cdb66459851a62c86264e251a90
Author: Tuo Li <islituo@gmail.com>
Date:   Fri Aug 6 06:30:29 2021 -0700

    IB/hfi1: Fix possible null-pointer dereference in _extend_sdma_tx_descs()
    
    [ Upstream commit cbe71c61992c38f72c2b625b2ef25916b9f0d060 ]
    
    kmalloc_array() is called to allocate memory for tx->descp. If it fails,
    the function __sdma_txclean() is called:
      __sdma_txclean(dd, tx);
    
    However, in the function __sdma_txclean(), tx-descp is dereferenced if
    tx->num_desc is not zero:
      sdma_unmap_desc(dd, &tx->descp[0]);
    
    To fix this possible null-pointer dereference, assign the return value of
    kmalloc_array() to a local variable descp, and then assign it to tx->descp
    if it is not NULL. Otherwise, go to enomem.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Link: https://lore.kernel.org/r/20210806133029.194964-1-islituo@gmail.com
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Tuo Li <islituo@gmail.com>
    Tested-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
    Acked-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a58d290e7cd85aaef2500ad1daea14202d0570c7
Author: Wesley Cheng <wcheng@codeaurora.org>
Date:   Tue Aug 24 21:28:55 2021 -0700

    usb: dwc3: gadget: Stop EP0 transfers during pullup disable
    
    commit 4a1e25c0a029b97ea4a3d423a6392bfacc3b2e39 upstream.
    
    During a USB cable disconnect, or soft disconnect scenario, a pending
    SETUP transaction may not be completed, leading to the following
    error:
    
        dwc3 a600000.dwc3: timed out waiting for SETUP phase
    
    If this occurs, then the entire pullup disable routine is skipped and
    proper cleanup and halting of the controller does not complete.
    
    Instead of returning an error (which is ignored from the UDC
    perspective), allow the pullup disable routine to continue, which
    will also handle disabling of EP0/1.  This will end any active
    transfers as well.  Ensure to clear any delayed_status also, as the
    timeout could happen within the STATUS stage.
    
    Fixes: bb0147364850 ("usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to do so")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
    Link: https://lore.kernel.org/r/20210825042855.7977-1-wcheng@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24749050f167ee4734f8b6183b6cb7403c7a09b6
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Aug 19 03:17:03 2021 +0200

    usb: dwc3: gadget: Fix dwc3_calc_trbs_left()
    
    commit 51f1954ad853d01ba4dc2b35dee14d8490ee05a1 upstream.
    
    We can't depend on the TRB's HWO bit to determine if the TRB ring is
    "full". A TRB is only available when the driver had processed it, not
    when the controller consumed and relinquished the TRB's ownership to the
    driver. Otherwise, the driver may overwrite unprocessed TRBs. This can
    happen when many transfer events accumulate and the system is slow to
    process them and/or when there are too many small requests.
    
    If a request is in the started_list, that means there is one or more
    unprocessed TRBs remained. Check this instead of the TRB's HWO bit
    whether the TRB ring is full.
    
    Fixes: c4233573f6ee ("usb: dwc3: gadget: prepare TRBs on update transfers too")
    Cc: <stable@vger.kernel.org>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13078d2d20fbeab1d8b82d1bb13b10ae71116b89
Author: Zhengjun Zhang <zhangzhengjun@aicrobo.com>
Date:   Mon Aug 9 21:35:53 2021 +0800

    USB: serial: option: add new VID/PID to support Fibocom FG150
    
    commit 2829a4e3cf3a6ac2fa3cdb681b37574630fb9c1a upstream.
    
    Fibocom FG150 is a 5G module based on Qualcomm SDX55 platform,
    support Sub-6G band.
    
    Here are the outputs of lsusb -v and usb-devices:
    
    > T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    > D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    > P:  Vendor=2cb7 ProdID=010b Rev=04.14
    > S:  Manufacturer=Fibocom
    > S:  Product=Fibocom Modem_SN:XXXXXXXX
    > S:  SerialNumber=XXXXXXXX
    > C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
    > I:  If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    > I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    > I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    > I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
    > I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    > Bus 002 Device 002: ID 2cb7:010b Fibocom Fibocom Modem_SN:XXXXXXXX
    > Device Descriptor:
    >   bLength                18
    >   bDescriptorType         1
    >   bcdUSB               3.20
    >   bDeviceClass            0
    >   bDeviceSubClass         0
    >   bDeviceProtocol         0
    >   bMaxPacketSize0         9
    >   idVendor           0x2cb7 Fibocom
    >   idProduct          0x010b
    >   bcdDevice            4.14
    >   iManufacturer           1 Fibocom
    >   iProduct                2 Fibocom Modem_SN:XXXXXXXX
    >   iSerial                 3 XXXXXXXX
    >   bNumConfigurations      1
    >   Configuration Descriptor:
    >     bLength                 9
    >     bDescriptorType         2
    >     wTotalLength       0x00e6
    >     bNumInterfaces          5
    >     bConfigurationValue     1
    >     iConfiguration          4 RNDIS_DUN_DIAG_ADB
    >     bmAttributes         0xa0
    >       (Bus Powered)
    >       Remote Wakeup
    >     MaxPower              896mA
    >     Interface Association:
    >       bLength                 8
    >       bDescriptorType        11
    >       bFirstInterface         0
    >       bInterfaceCount         2
    >       bFunctionClass        239 Miscellaneous Device
    >       bFunctionSubClass       4
    >       bFunctionProtocol       1
    >       iFunction               7 RNDIS
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        0
    >       bAlternateSetting       0
    >       bNumEndpoints           1
    >       bInterfaceClass       239 Miscellaneous Device
    >       bInterfaceSubClass      4
    >       bInterfaceProtocol      1
    >       iInterface              0
    >       ** UNRECOGNIZED:  05 24 00 10 01
    >       ** UNRECOGNIZED:  05 24 01 00 01
    >       ** UNRECOGNIZED:  04 24 02 00
    >       ** UNRECOGNIZED:  05 24 06 00 01
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x81  EP 1 IN
    >         bmAttributes            3
    >           Transfer Type            Interrupt
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0008  1x 8 bytes
    >         bInterval               9
    >         bMaxBurst               0
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        1
    >       bAlternateSetting       0
    >       bNumEndpoints           2
    >       bInterfaceClass        10 CDC Data
    >       bInterfaceSubClass      0
    >       bInterfaceProtocol      0
    >       iInterface              0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x8e  EP 14 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               6
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x0f  EP 15 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               6
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        2
    >       bAlternateSetting       0
    >       bNumEndpoints           3
    >       bInterfaceClass       255 Vendor Specific Class
    >       bInterfaceSubClass      0
    >       bInterfaceProtocol      0
    >       iInterface              0
    >       ** UNRECOGNIZED:  05 24 00 10 01
    >       ** UNRECOGNIZED:  05 24 01 00 00
    >       ** UNRECOGNIZED:  04 24 02 02
    >       ** UNRECOGNIZED:  05 24 06 00 00
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x83  EP 3 IN
    >         bmAttributes            3
    >           Transfer Type            Interrupt
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x000a  1x 10 bytes
    >         bInterval               9
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x82  EP 2 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x01  EP 1 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        3
    >       bAlternateSetting       0
    >       bNumEndpoints           2
    >       bInterfaceClass       255 Vendor Specific Class
    >       bInterfaceSubClass    255 Vendor Specific Subclass
    >       bInterfaceProtocol     48
    >       iInterface              0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x84  EP 4 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x02  EP 2 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        4
    >       bAlternateSetting       0
    >       bNumEndpoints           2
    >       bInterfaceClass       255 Vendor Specific Class
    >       bInterfaceSubClass     66
    >       bInterfaceProtocol      1
    >       iInterface              0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x03  EP 3 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x85  EP 5 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    > Binary Object Store Descriptor:
    >   bLength                 5
    >   bDescriptorType        15
    >   wTotalLength       0x0016
    >   bNumDeviceCaps          2
    >   USB 2.0 Extension Device Capability:
    >     bLength                 7
    >     bDescriptorType        16
    >     bDevCapabilityType      2
    >     bmAttributes   0x00000006
    >       BESL Link Power Management (LPM) Supported
    >   SuperSpeed USB Device Capability:
    >     bLength                10
    >     bDescriptorType        16
    >     bDevCapabilityType      3
    >     bmAttributes         0x00
    >     wSpeedsSupported   0x000f
    >       Device can operate at Low Speed (1Mbps)
    >       Device can operate at Full Speed (12Mbps)
    >       Device can operate at High Speed (480Mbps)
    >       Device can operate at SuperSpeed (5Gbps)
    >     bFunctionalitySupport   1
    >       Lowest fully-functional device speed is Full Speed (12Mbps)
    >     bU1DevExitLat           1 micro seconds
    >     bU2DevExitLat         500 micro seconds
    > Device Status:     0x0000
    >   (Bus Powered)
    
    Signed-off-by: Zhengjun Zhang <zhangzhengjun@aicrobo.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86363c32aed6c193ab9d6a5d909d14c5195d047f
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Aug 24 14:19:26 2021 +0200

    Revert "USB: serial: ch341: fix character loss at high transfer rates"
    
    commit df7b16d1c00ecb3da3a30c999cdb39f273c99a2f upstream.
    
    This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b.
    
    These devices do not appear to send a zero-length packet when the
    transfer size is a multiple of the bulk-endpoint max-packet size. This
    means that incoming data may not be processed by the driver until a
    short packet is received or the receive buffer is full.
    
    Revert back to using endpoint-sized receive buffers to avoid stalled
    reads.
    
    Reported-by: Paul Größel <pb.g@gmx.de>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131
    Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates")
    Cc: stable@vger.kernel.org
    Cc: Willy Tarreau <w@1wt.eu>
    Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 251b1f1ec9fdb2285a4e41ac473d2c111f3f8780
Author: Stefan Mätje <stefan.maetje@esd.eu>
Date:   Wed Aug 25 23:52:27 2021 +0200

    can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters
    
    commit 044012b52029204900af9e4230263418427f4ba4 upstream.
    
    This patch fixes the interchanged fetch of the CAN RX and TX error
    counters from the ESD_EV_CAN_ERROR_EXT message. The RX error counter
    is really in struct rx_msg::data[2] and the TX error counter is in
    struct rx_msg::data[3].
    
    Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
    Link: https://lore.kernel.org/r/20210825215227.4947-2-stefan.maetje@esd.eu
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1635eff280ee406186e96570a7ba332259f4be1
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Jul 10 07:50:33 2021 -0700

    ARC: Fix CONFIG_STACKDEPOT
    
    [ Upstream commit bf79167fd86f3b97390fe2e70231d383526bd9cc ]
    
    Enabling CONFIG_STACKDEPOT results in the following build error.
    
    arc-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks':
    stackdepot.c:(.text+0x456): undefined reference to `__irqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x456): undefined reference to `__irqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x476): undefined reference to `__irqentry_text_end'
    arc-elf-ld: stackdepot.c:(.text+0x476): undefined reference to `__irqentry_text_end'
    arc-elf-ld: stackdepot.c:(.text+0x484): undefined reference to `__softirqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x484): undefined reference to `__softirqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x48c): undefined reference to `__softirqentry_text_end'
    arc-elf-ld: stackdepot.c:(.text+0x48c): undefined reference to `__softirqentry_text_end'
    
    Other architectures address this problem by adding IRQENTRY_TEXT and
    SOFTIRQENTRY_TEXT to the text segment, so do the same here.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>