commit dfb571610ba392179348c8472bfb131d4173d585
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 4 09:40:00 2021 +0100

    Linux 4.19.178
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Hulk Robot <hulkci@huawei.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Jason Self <jason@bluehome.net>
    Link: https://lore.kernel.org/r/20210301193544.489324430@linuxfoundation.org
    Link: https://lore.kernel.org/r/20210302122300.309814713@linuxfoundation.org
    Link: https://lore.kernel.org/r/20210301161031.684018251@linuxfoundation.org
    Link: https://lore.kernel.org/r/20210302192550.512870321@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 694b95061452a534a7d9f7492075af5ff9524817
Author: John Wang <wangzhiqiang.bj@bytedance.com>
Date:   Wed Dec 2 13:16:34 2020 +0800

    ARM: dts: aspeed: Add LCLK to lpc-snoop
    
    commit d050d049f8b8077025292c1ecf456c4ee7f96861 upstream.
    
    Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20201202051634.490-2-wangzhiqiang.bj@bytedance.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19c5bc219a1ef70153fca5961f25fc2bd175ea17
Author: Takeshi Misawa <jeliantsurux@gmail.com>
Date:   Mon Feb 22 08:44:27 2021 +0900

    net: qrtr: Fix memory leak in qrtr_tun_open
    
    commit fc0494ead6398609c49afa37bc949b61c5c16b91 upstream.
    
    If qrtr_endpoint_register() failed, tun is leaked.
    Fix this, by freeing tun in error path.
    
    syzbot report:
    BUG: memory leak
    unreferenced object 0xffff88811848d680 (size 64):
      comm "syz-executor684", pid 10171, jiffies 4294951561 (age 26.070s)
      hex dump (first 32 bytes):
        80 dd 0a 84 ff ff ff ff 00 00 00 00 00 00 00 00  ................
        90 d6 48 18 81 88 ff ff 90 d6 48 18 81 88 ff ff  ..H.......H.....
      backtrace:
        [<0000000018992a50>] kmalloc include/linux/slab.h:552 [inline]
        [<0000000018992a50>] kzalloc include/linux/slab.h:682 [inline]
        [<0000000018992a50>] qrtr_tun_open+0x22/0x90 net/qrtr/tun.c:35
        [<0000000003a453ef>] misc_open+0x19c/0x1e0 drivers/char/misc.c:141
        [<00000000dec38ac8>] chrdev_open+0x10d/0x340 fs/char_dev.c:414
        [<0000000079094996>] do_dentry_open+0x1e6/0x620 fs/open.c:817
        [<000000004096d290>] do_open fs/namei.c:3252 [inline]
        [<000000004096d290>] path_openat+0x74a/0x1b00 fs/namei.c:3369
        [<00000000b8e64241>] do_filp_open+0xa0/0x190 fs/namei.c:3396
        [<00000000a3299422>] do_sys_openat2+0xed/0x230 fs/open.c:1172
        [<000000002c1bdcef>] do_sys_open fs/open.c:1188 [inline]
        [<000000002c1bdcef>] __do_sys_openat fs/open.c:1204 [inline]
        [<000000002c1bdcef>] __se_sys_openat fs/open.c:1199 [inline]
        [<000000002c1bdcef>] __x64_sys_openat+0x7f/0xe0 fs/open.c:1199
        [<00000000f3a5728f>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
        [<000000004b38b7ec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 28fb4e59a47d ("net: qrtr: Expose tunneling endpoint to user space")
    Reported-by: syzbot+5d6e4af21385f5cfc56a@syzkaller.appspotmail.com
    Signed-off-by: Takeshi Misawa <jeliantsurux@gmail.com>
    Link: https://lore.kernel.org/r/20210221234427.GA2140@DESKTOP
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f037f1f453952656b503c3e12d3bccff74dce165
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Fri Jan 22 17:19:31 2021 +0200

    dm era: Update in-core bitset after committing the metadata
    
    commit 2099b145d77c1d53f5711f029c37cc537897cee6 upstream.
    
    In case of a system crash, dm-era might fail to mark blocks as written
    in its metadata, although the corresponding writes to these blocks were
    passed down to the origin device and completed successfully.
    
    Consider the following sequence of events:
    
    1. We write to a block that has not been yet written in the current era
    2. era_map() checks the in-core bitmap for the current era and sees
       that the block is not marked as written.
    3. The write is deferred for submission after the metadata have been
       updated and committed.
    4. The worker thread processes the deferred write
       (process_deferred_bios()) and marks the block as written in the
       in-core bitmap, **before** committing the metadata.
    5. The worker thread starts committing the metadata.
    6. We do more writes that map to the same block as the write of step (1)
    7. era_map() checks the in-core bitmap and sees that the block is marked
       as written, **although the metadata have not been committed yet**.
    8. These writes are passed down to the origin device immediately and the
       device reports them as completed.
    9. The system crashes, e.g., power failure, before the commit from step
       (5) finishes.
    
    When the system recovers and we query the dm-era target for the list of
    written blocks it doesn't report the aforementioned block as written,
    although the writes of step (6) completed successfully.
    
    The issue is that era_map() decides whether to defer or not a write
    based on non committed information. The root cause of the bug is that we
    update the in-core bitmap, **before** committing the metadata.
    
    Fix this by updating the in-core bitmap **after** successfully
    committing the metadata.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9efa1af186114b17a8e797e89c005876b5eceaac
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 23 14:18:58 2021 +0100

    net: icmp: pass zeroed opts from icmp{,v6}_ndo_send before sending
    
    commit ee576c47db60432c37e54b1e2b43a8ca6d3a8dca upstream.
    
    The icmp{,v6}_send functions make all sorts of use of skb->cb, casting
    it with IPCB or IP6CB, assuming the skb to have come directly from the
    inet layer. But when the packet comes from the ndo layer, especially
    when forwarded, there's no telling what might be in skb->cb at that
    point. As a result, the icmp sending code risks reading bogus memory
    contents, which can result in nasty stack overflows such as this one
    reported by a user:
    
        panic+0x108/0x2ea
        __stack_chk_fail+0x14/0x20
        __icmp_send+0x5bd/0x5c0
        icmp_ndo_send+0x148/0x160
    
    In icmp_send, skb->cb is cast with IPCB and an ip_options struct is read
    from it. The optlen parameter there is of particular note, as it can
    induce writes beyond bounds. There are quite a few ways that can happen
    in __ip_options_echo. For example:
    
        // sptr/skb are attacker-controlled skb bytes
        sptr = skb_network_header(skb);
        // dptr/dopt points to stack memory allocated by __icmp_send
        dptr = dopt->__data;
        // sopt is the corrupt skb->cb in question
        if (sopt->rr) {
            optlen  = sptr[sopt->rr+1]; // corrupt skb->cb + skb->data
            soffset = sptr[sopt->rr+2]; // corrupt skb->cb + skb->data
            // this now writes potentially attacker-controlled data, over
            // flowing the stack:
            memcpy(dptr, sptr+sopt->rr, optlen);
        }
    
    In the icmpv6_send case, the story is similar, but not as dire, as only
    IP6CB(skb)->iif and IP6CB(skb)->dsthao are used. The dsthao case is
    worse than the iif case, but it is passed to ipv6_find_tlv, which does
    a bit of bounds checking on the value.
    
    This is easy to simulate by doing a `memset(skb->cb, 0x41,
    sizeof(skb->cb));` before calling icmp{,v6}_ndo_send, and it's only by
    good fortune and the rarity of icmp sending from that context that we've
    avoided reports like this until now. For example, in KASAN:
    
        BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0xa0e/0x12b0
        Write of size 38 at addr ffff888006f1f80e by task ping/89
        CPU: 2 PID: 89 Comm: ping Not tainted 5.10.0-rc7-debug+ #5
        Call Trace:
         dump_stack+0x9a/0xcc
         print_address_description.constprop.0+0x1a/0x160
         __kasan_report.cold+0x20/0x38
         kasan_report+0x32/0x40
         check_memory_region+0x145/0x1a0
         memcpy+0x39/0x60
         __ip_options_echo+0xa0e/0x12b0
         __icmp_send+0x744/0x1700
    
    Actually, out of the 4 drivers that do this, only gtp zeroed the cb for
    the v4 case, while the rest did not. So this commit actually removes the
    gtp-specific zeroing, while putting the code where it belongs in the
    shared infrastructure of icmp{,v6}_ndo_send.
    
    This commit fixes the issue by passing an empty IPCB or IP6CB along to
    the functions that actually do the work. For the icmp_send, this was
    already trivial, thanks to __icmp_send providing the plumbing function.
    For icmpv6_send, this required a tiny bit of refactoring to make it
    behave like the v4 case, after which it was straight forward.
    
    Fixes: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port MTUs")
    Reported-by: SinYu <liuxyon@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/netdev/CAF=yD-LOF116aHub6RMe8vB8ZpnrrnoTdqhobEx+bvoA8AsP0w@mail.gmail.com/T/
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://lore.kernel.org/r/20210223131858.72082-1-Jason@zx2c4.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 480c09809f7c67b148a102de5f8cdd5fcab04685
Author: Leon Romanovsky <leon@kernel.org>
Date:   Wed Feb 3 15:51:09 2021 +0200

    ipv6: silence compilation warning for non-IPV6 builds
    
    commit 1faba27f11c8da244e793546a1b35a9b1da8208e upstream.
    
    The W=1 compilation of allmodconfig generates the following warning:
    
    net/ipv6/icmp.c:448:6: warning: no previous prototype for 'icmp6_send' [-Wmissing-prototypes]
      448 | void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info,
          |      ^~~~~~~~~~
    
    Fix it by providing function declaration for builds with ipv6 as a module.
    
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00d3dc031d9a1aed4a56d4a83a3c31a5d42a0e4b
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jun 19 12:02:59 2020 -0700

    ipv6: icmp6: avoid indirect call for icmpv6_send()
    
    commit cc7a21b6fbd945f8d8f61422ccd27203c1fafeb7 upstream.
    
    If IPv6 is builtin, we do not need an expensive indirect call
    to reach icmp6_send().
    
    v2: put inline keyword before the type to avoid sparse warnings.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d6fad4686ec1418a36fb5295163652ffe8266fc
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 11 20:47:09 2020 +0100

    xfrm: interface: use icmp_ndo_send helper
    
    commit 45942ba890e6f35232727a5fa33d732681f4eb9f upstream.
    
    Because xfrmi is calling icmp from network device context, it should use
    the ndo helper so that the rate limiting applies correctly.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5351e67767ecde80ecba894d88f191c2c378c17c
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 11 20:47:07 2020 +0100

    sunvnet: use icmp_ndo_send helper
    
    commit 67c9a7e1e3ac491b5df018803639addc36f154ba upstream.
    
    Because sunvnet is calling icmp from network device context, it should use
    the ndo helper so that the rate limiting applies correctly. While we're
    at it, doing the additional route lookup before calling icmp_ndo_send is
    superfluous, since this is the job of the icmp code in the first place.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Shannon Nelson <shannon.nelson@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7538ce3f76a6b7e2c6394ba015c74a59445b60d6
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 11 20:47:06 2020 +0100

    gtp: use icmp_ndo_send helper
    
    commit e0fce6f945a26d4e953a147fe7ca11410322c9fe upstream.
    
    Because gtp is calling icmp from network device context, it should use
    the ndo helper so that the rate limiting applies correctly.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Harald Welte <laforge@gnumonks.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1820f4376528503812dc078de7651f17e84f43b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 25 18:05:35 2020 +0800

    icmp: allow icmpv6_ndo_send to work with CONFIG_IPV6=n
    
    commit a8e41f6033a0c5633d55d6e35993c9e2005d872f upstream.
    
    The icmpv6_send function has long had a static inline implementation
    with an empty body for CONFIG_IPV6=n, so that code calling it doesn't
    need to be ifdef'd. The new icmpv6_ndo_send function, which is intended
    for drivers as a drop-in replacement with an identical function
    signature, should follow the same pattern. Without this patch, drivers
    that used to work with CONFIG_IPV6=n now result in a linker error.
    
    Cc: Chen Zhou <chenzhou10@huawei.com>
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 0b41713b6066 ("icmp: introduce helper for nat'd source address in network device context")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3efde1864ab5552d8c9411e0112f5508b4c7ec47
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 11 20:47:05 2020 +0100

    icmp: introduce helper for nat'd source address in network device context
    
    commit 0b41713b606694257b90d61ba7e2712d8457648b upstream.
    
    This introduces a helper function to be called only by network drivers
    that wraps calls to icmp[v6]_send in a conntrack transformation, in case
    NAT has been used. We don't want to pollute the non-driver path, though,
    so we introduce this as a helper to be called by places that actually
    make use of this, as suggested by Florian.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc204c6b398378a70d79cbac24cd16cce412a0c7
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Thu Feb 11 16:22:43 2021 +0200

    dm era: only resize metadata in preresume
    
    commit cca2c6aebe86f68103a8615074b3578e854b5016 upstream.
    
    Metadata resize shouldn't happen in the ctr. The ctr loads a temporary
    (inactive) table that will only become active upon resume. That is why
    resize should always be done in terms of resume. Otherwise a load (ctr)
    whose inactive table never becomes active will incorrectly resize the
    metadata.
    
    Also, perform the resize directly in preresume, instead of using the
    worker to do it.
    
    The worker might run other metadata operations, e.g., it could start
    digestion, before resizing the metadata. These operations will end up
    using the old size.
    
    This could lead to errors, like:
    
      device-mapper: era: metadata_digest_transcribe_writeset: dm_array_set_value failed
      device-mapper: era: process_old_eras: digest step failed, stopping digestion
    
    The reason of the above error is that the worker started the digestion
    of the archived writeset using the old, larger size.
    
    As a result, metadata_digest_transcribe_writeset tried to write beyond
    the end of the era array.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ccfc76e5e0b3e7aa54e23568d2184c31b8a777f
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Fri Jan 22 17:22:04 2021 +0200

    dm era: Reinitialize bitset cache before digesting a new writeset
    
    commit 2524933307fd0036d5c32357c693c021ab09a0b0 upstream.
    
    In case of devices with at most 64 blocks, the digestion of consecutive
    eras uses the writeset of the first era as the writeset of all eras to
    digest, leading to lost writes. That is, we lose the information about
    what blocks were written during the affected eras.
    
    The digestion code uses a dm_disk_bitset object to access the archived
    writesets. This structure includes a one word (64-bit) cache to reduce
    the number of array lookups.
    
    This structure is initialized only once, in metadata_digest_start(),
    when we kick off digestion.
    
    But, when we insert a new writeset into the writeset tree, before the
    digestion of the previous writeset is done, or equivalently when there
    are multiple writesets in the writeset tree to digest, then all these
    writesets are digested using the same cache and the cache is not
    re-initialized when moving from one writeset to the next.
    
    For devices with more than 64 blocks, i.e., the size of the cache, the
    cache is indirectly invalidated when we move to a next set of blocks, so
    we avoid the bug.
    
    But for devices with at most 64 blocks we end up using the same cached
    data for digesting all archived writesets, i.e., the cache is loaded
    when digesting the first writeset and it never gets reloaded, until the
    digestion is done.
    
    As a result, the writeset of the first era to digest is used as the
    writeset of all the following archived eras, leading to lost writes.
    
    Fix this by reinitializing the dm_disk_bitset structure, and thus
    invalidating the cache, every time the digestion code starts digesting a
    new writeset.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51442dbcbe115c4ce2ad83fafa05345a57202d03
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Fri Jan 22 17:25:55 2021 +0200

    dm era: Use correct value size in equality function of writeset tree
    
    commit 64f2d15afe7b336aafebdcd14cc835ecf856df4b upstream.
    
    Fix the writeset tree equality test function to use the right value size
    when comparing two btree values.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79d47a39dbb0bb6f338fc0c340d6f386355f4cec
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Fri Jan 22 17:25:54 2021 +0200

    dm era: Fix bitset memory leaks
    
    commit 904e6b266619c2da5c58b5dce14ae30629e39645 upstream.
    
    Deallocate the memory allocated for the in-core bitsets when destroying
    the target and in error paths.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad537170e489f6ec0bfb188270b48116755d35b6
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Fri Jan 22 17:25:53 2021 +0200

    dm era: Verify the data block size hasn't changed
    
    commit c8e846ff93d5eaa5384f6f325a1687ac5921aade upstream.
    
    dm-era doesn't support changing the data block size of existing devices,
    so check explicitly that the requested block size for a new target
    matches the one stored in the metadata.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6d2d4183ccec8dc8a96897d13727e0143cf09e5
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date:   Fri Jan 22 17:19:30 2021 +0200

    dm era: Recover committed writeset after crash
    
    commit de89afc1e40fdfa5f8b666e5d07c43d21a1d3be0 upstream.
    
    Following a system crash, dm-era fails to recover the committed writeset
    for the current era, leading to lost writes. That is, we lose the
    information about what blocks were written during the affected era.
    
    dm-era assumes that the writeset of the current era is archived when the
    device is suspended. So, when resuming the device, it just moves on to
    the next era, ignoring the committed writeset.
    
    This assumption holds when the device is properly shut down. But, when
    the system crashes, the code that suspends the target never runs, so the
    writeset for the current era is not archived.
    
    There are three issues that cause the committed writeset to get lost:
    
    1. dm-era doesn't load the committed writeset when opening the metadata
    2. The code that resizes the metadata wipes the information about the
       committed writeset (assuming it was loaded at step 1)
    3. era_preresume() starts a new era, without taking into account that
       the current era might not have been archived, due to a system crash.
    
    To fix this:
    
    1. Load the committed writeset when opening the metadata
    2. Fix the code that resizes the metadata to make sure it doesn't wipe
       the loaded writeset
    3. Fix era_preresume() to check for a loaded writeset and archive it,
       before starting a new era.
    
    Fixes: eec40579d84873 ("dm: add era target")
    Cc: stable@vger.kernel.org # v3.15+
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c5bb514651aa174f15001b2624aca7b89976af6
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Feb 10 15:26:23 2021 -0500

    dm: fix deadlock when swapping to encrypted device
    
    commit a666e5c05e7c4aaabb2c5d58117b0946803d03d2 upstream.
    
    The system would deadlock when swapping to a dm-crypt device. The reason
    is that for each incoming write bio, dm-crypt allocates memory that holds
    encrypted data. These excessive allocations exhaust all the memory and the
    result is either deadlock or OOM trigger.
    
    This patch limits the number of in-flight swap bios, so that the memory
    consumed by dm-crypt is limited. The limit is enforced if the target set
    the "limit_swap_bios" variable and if the bio has REQ_SWAP set.
    
    Non-swap bios are not affected becuase taking the semaphore would cause
    performance degradation.
    
    This is similar to request-based drivers - they will also block when the
    number of requests is over the limit.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0a82e0117b341423633ff09ad8a8db60f950871
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Fri Feb 5 13:50:41 2021 -0500

    gfs2: Don't skip dlm unlock if glock has an lvb
    
    commit 78178ca844f0eb88f21f31c7fde969384be4c901 upstream.
    
    Patch fb6791d100d1 was designed to allow gfs2 to unmount quicker by
    skipping the step where it tells dlm to unlock glocks in EX with lvbs.
    This was done because when gfs2 unmounts a file system, it destroys the
    dlm lockspace shortly after it destroys the glocks so it doesn't need to
    unlock them all: the unlock is implied when the lockspace is destroyed
    by dlm.
    
    However, that patch introduced a use-after-free in dlm: as part of its
    normal dlm_recoverd process, it can call ls_recovery to recover dead
    locks. In so doing, it can call recover_rsbs which calls recover_lvb for
    any mastered rsbs. Func recover_lvb runs through the list of lkbs queued
    to the given rsb (if the glock is cached but unlocked, it will still be
    queued to the lkb, but in NL--Unlocked--mode) and if it has an lvb,
    copies it to the rsb, thus trying to preserve the lkb. However, when
    gfs2 skips the dlm unlock step, it frees the glock and its lvb, which
    means dlm's function recover_lvb references the now freed lvb pointer,
    copying the freed lvb memory to the rsb.
    
    This patch changes the check in gdlm_put_lock so that it calls
    dlm_unlock for all glocks that contain an lvb pointer.
    
    Fixes: fb6791d100d1 ("GFS2: skip dlm_unlock calls in unmount")
    Cc: stable@vger.kernel.org # v3.8+
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06604b22f06bc56c7c36681a71b2abac84574819
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Jul 20 02:21:51 2020 +0100

    sparc32: fix a user-triggerable oops in clear_user()
    
    commit 7780918b36489f0b2f9a3749d7be00c2ceaec513 upstream.
    
    Back in 2.1.29 the clear_user() guts (__bzero()) had been merged
    with memset().  Unfortunately, while all exception handlers had been
    copied, one of the exception table entries got lost.  As the result,
    clear_user() starting at 128*n bytes before the end of page and
    spanning between 8 and 127 bytes into the next page would oops when
    the second page is unmapped.  It's trivial to reproduce - all
    it takes is
    
    main()
    {
            int fd = open("/dev/zero", O_RDONLY);
            char *p = mmap(NULL, 16384, PROT_READ|PROT_WRITE,
                            MAP_PRIVATE|MAP_ANON, -1, 0);
            munmap(p + 8192, 8192);
            read(fd, p + 8192 - 128, 192);
    }
    
    which had been oopsing since March 1997.  Says something about
    the quality of test coverage... ;-/  And while today sparc32 port
    is nearly dead, back in '97 it had been very much alive; in fact,
    sparc64 had only been in mainline for 3 months by that point...
    
    Cc: stable@kernel.org
    Fixes: v2.1.29
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 504ee2c84e6c93b448482d05913ebd26ceec1728
Author: Chao Yu <chao@kernel.org>
Date:   Wed Dec 16 17:15:23 2020 +0800

    f2fs: fix out-of-repair __setattr_copy()
    
    commit 2562515f0ad7342bde6456602c491b64c63fe950 upstream.
    
    __setattr_copy() was copied from setattr_copy() in fs/attr.c, there is
    two missing patches doesn't cover this inner function, fix it.
    
    Commit 7fa294c8991c ("userns: Allow chown and setgid preservation")
    Commit 23adbe12ef7d ("fs,userns: Change inode_capable to capable_wrt_inode_uidgid")
    
    Fixes: fbfa2cc58d53 ("f2fs: add file operations")
    Cc: stable@vger.kernel.org
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4f0ed35df4d0acc1b5a72eef1da0635a3ccb52f
Author: Chen Yu <yu.c.chen@intel.com>
Date:   Tue Jan 12 13:21:27 2021 +0800

    cpufreq: intel_pstate: Get per-CPU max freq via MSR_HWP_CAPABILITIES if available
    
    commit 6f67e060083a84a4cc364eab6ae40c717165fb0c upstream.
    
    Currently, when turbo is disabled (either by BIOS or by the user),
    the intel_pstate driver reads the max non-turbo frequency from the
    package-wide MSR_PLATFORM_INFO(0xce) register.
    
    However, on asymmetric platforms it is possible in theory that small
    and big core with HWP enabled might have different max non-turbo CPU
    frequency, because MSR_HWP_CAPABILITIES is per-CPU scope according
    to Intel Software Developer Manual.
    
    The turbo max freq is already per-CPU in current code, so make
    similar change to the max non-turbo frequency as well.
    
    Reported-by: Wendy Wang <wendy.wang@intel.com>
    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
    [ rjw: Subject and changelog edits ]
    Cc: 4.18+ <stable@vger.kernel.org> # 4.18+: a45ee4d4e13b: cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba7ae3629d5b2ae4ed86a08f29afeac623550511
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Wed Feb 10 11:48:23 2021 +0800

    printk: fix deadlock when kernel panic
    
    commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream.
    
    printk_safe_flush_on_panic() caused the following deadlock on our
    server:
    
    CPU0:                                         CPU1:
    panic                                         rcu_dump_cpu_stacks
      kdump_nmi_shootdown_cpus                      nmi_trigger_cpumask_backtrace
        register_nmi_handler(crash_nmi_callback)      printk_safe_flush
                                                        __printk_safe_flush
                                                          raw_spin_lock_irqsave(&read_lock)
        // send NMI to other processors
        apic_send_IPI_allbutself(NMI_VECTOR)
                                                            // NMI interrupt, dead loop
                                                            crash_nmi_callback
      printk_safe_flush_on_panic
        printk_safe_flush
          __printk_safe_flush
            // deadlock
            raw_spin_lock_irqsave(&read_lock)
    
    DEADLOCK: read_lock is taken on CPU1 and will never get released.
    
    It happens when panic() stops a CPU by NMI while it has been in
    the middle of printk_safe_flush().
    
    Handle the lock the same way as logbuf_lock. The printk_safe buffers
    are flushed only when both locks can be safely taken. It can avoid
    the deadlock _in this particular case_ at expense of losing contents
    of printk_safe buffers.
    
    Note: It would actually be safe to re-init the locks when all CPUs were
          stopped by NMI. But it would require passing this information
          from arch-specific code. It is not worth the complexity.
          Especially because logbuf_lock and printk_safe buffers have been
          obsoleted by the lockless ring buffer.
    
    Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Cc: <stable@vger.kernel.org>
    Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20210210034823.64867-1-songmuchun@bytedance.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8aad9180a0a42fd7df070e4170ae63702b21ede5
Author: Maxim Kiselev <bigunclemax@gmail.com>
Date:   Wed Feb 17 14:10:00 2021 +0100

    gpio: pcf857x: Fix missing first interrupt
    
    commit a8002a35935aaefcd6a42ad3289f62bab947f2ca upstream.
    
    If no n_latch value will be provided at driver probe then all pins will
    be used as an input:
    
        gpio->out = ~n_latch;
    
    In that case initial state for all pins is "one":
    
        gpio->status = gpio->out;
    
    So if pcf857x IRQ happens with change pin value from "zero" to "one"
    then we miss it, because of "one" from IRQ and "one" from initial state
    leaves corresponding pin unchanged:
    change = (gpio->status ^ status) & gpio->irq_enabled;
    
    The right solution will be to read actual state at driver probe.
    
    Cc: stable@vger.kernel.org
    Fixes: 6e20a0a429bd ("gpio: pcf857x: enable gpio_to_irq() support")
    Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fbc9a3a040216dfcaac2833074cac8bdc6d14f4
Author: Frank Li <Frank.Li@nxp.com>
Date:   Wed Feb 10 12:19:33 2021 -0600

    mmc: sdhci-esdhc-imx: fix kernel panic when remove module
    
    commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.
    
    In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
    circumstances, this may be done while the device is runtime suspended,
    triggering the below splat.
    
    Fix the problem by adding a pm_runtime_get_sync(), before reading the
    register, which will turn on clocks etc making the device accessible again.
    
    [ 1811.323148] mmc1: card aaaa removed
    [ 1811.347483] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
    [ 1811.354988] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core [last unloaded: mmc_core]
    [ 1811.365726] CPU: 0 PID: 3464 Comm: rmmod Not tainted 5.10.1-sd-99871-g53835a2e8186 #5
    [ 1811.373559] Hardware name: Freescale i.MX8DXL EVK (DT)
    [ 1811.378705] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
    [ 1811.384723] pc : sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx]
    [ 1811.391090] lr : platform_drv_remove+0x2c/0x50
    [ 1811.395536] sp : ffff800012c7bcb0
    [ 1811.398855] x29: ffff800012c7bcb0 x28: ffff00002c72b900
    [ 1811.404181] x27: 0000000000000000 x26: 0000000000000000
    [ 1811.409497] x25: 0000000000000000 x24: 0000000000000000
    [ 1811.414814] x23: ffff0000042b3890 x22: ffff800009127120
    [ 1811.420131] x21: ffff00002c4c9580 x20: ffff0000042d0810
    [ 1811.425456] x19: ffff0000042d0800 x18: 0000000000000020
    [ 1811.430773] x17: 0000000000000000 x16: 0000000000000000
    [ 1811.436089] x15: 0000000000000004 x14: ffff000004019c10
    [ 1811.441406] x13: 0000000000000000 x12: 0000000000000020
    [ 1811.446723] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
    [ 1811.452040] x9 : fefefeff6364626d x8 : 7f7f7f7f7f7f7f7f
    [ 1811.457356] x7 : 78725e6473607372 x6 : 0000000080808080
    [ 1811.462673] x5 : 0000000000000000 x4 : 0000000000000000
    [ 1811.467990] x3 : ffff800011ac1cb0 x2 : 0000000000000000
    [ 1811.473307] x1 : ffff8000091214d4 x0 : ffff8000133a0030
    [ 1811.478624] Call trace:
    [ 1811.481081]  sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx]
    [ 1811.487098]  platform_drv_remove+0x2c/0x50
    [ 1811.491198]  __device_release_driver+0x188/0x230
    [ 1811.495818]  driver_detach+0xc0/0x14c
    [ 1811.499487]  bus_remove_driver+0x5c/0xb0
    [ 1811.503413]  driver_unregister+0x30/0x60
    [ 1811.507341]  platform_driver_unregister+0x14/0x20
    [ 1811.512048]  sdhci_esdhc_imx_driver_exit+0x1c/0x3a8 [sdhci_esdhc_imx]
    [ 1811.518495]  __arm64_sys_delete_module+0x19c/0x230
    [ 1811.523291]  el0_svc_common.constprop.0+0x78/0x1a0
    [ 1811.528086]  do_el0_svc+0x24/0x90
    [ 1811.531405]  el0_svc+0x14/0x20
    [ 1811.534461]  el0_sync_handler+0x1a4/0x1b0
    [ 1811.538474]  el0_sync+0x174/0x180
    [ 1811.541801] Code: a9025bf5 f9403e95 f9400ea0 9100c000 (b9400000)
    [ 1811.547902] ---[ end trace 3fb1a3bd48ff7be5 ]---
    
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Cc: stable@vger.kernel.org # v4.0+
    Link: https://lore.kernel.org/r/20210210181933.29263-1-Frank.Li@nxp.com
    [Ulf: Clarified the commit message a bit]
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8697aa8614cb58ad882c5453ca6786b32696a9fc
Author: Fangrui Song <maskray@google.com>
Date:   Fri Jan 15 11:52:22 2021 -0800

    module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols
    
    commit ebfac7b778fac8b0e8e92ec91d0b055f046b4604 upstream.
    
    clang-12 -fno-pic (since
    https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6)
    can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail`
    on x86.  The two forms should have identical behaviors on x86-64 but the
    former causes GNU as<2.37 to produce an unreferenced undefined symbol
    _GLOBAL_OFFSET_TABLE_.
    
    (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the
    linker behavior is identical as far as Linux kernel is concerned.)
    
    Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what
    scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the
    problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for
    external function calls on x86.
    
    Note: ld -z defs and dynamic loaders do not error for unreferenced
    undefined symbols so the module loader is reading too much.  If we ever
    need to ignore more symbols, the code should be refactored to ignore
    unreferenced symbols.
    
    Cc: <stable@vger.kernel.org>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1250
    Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27178
    Reported-by: Marco Elver <elver@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Tested-by: Marco Elver <elver@google.com>
    Signed-off-by: Fangrui Song <maskray@google.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a510f8da0c15776eb98f4c4ac069d98d75f1ddfb
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Wed Feb 3 23:00:57 2021 +0000

    arm64: Extend workaround for erratum 1024718 to all versions of Cortex-A55
    
    commit c0b15c25d25171db4b70cc0b7dbc1130ee94017d upstream.
    
    The erratum 1024718 affects Cortex-A55 r0p0 to r2p0. However
    we apply the work around for r0p0 - r1p0. Unfortunately this
    won't be fixed for the future revisions for the CPU. Thus
    extend the work around for all versions of A55, to cover
    for r2p0 and any future revisions.
    
    Cc: stable@vger.kernel.org
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: James Morse <james.morse@arm.com>
    Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20210203230057.3961239-1-suzuki.poulose@arm.com
    [will: Update Kconfig help text]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77d97b563a71914fa34a7e272dea36a895ffe67e
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Feb 1 16:20:40 2021 -0800

    libnvdimm/dimm: Avoid race between probe and available_slots_show()
    
    commit 7018c897c2f243d4b5f1b94bc6b4831a7eab80fb upstream
    
    Richard reports that the following test:
    
    (while true; do
         cat /sys/bus/nd/devices/nmem*/available_slots 2>&1 > /dev/null
     done) &
    
    while true; do
         for i in $(seq 0 4); do
             echo nmem$i > /sys/bus/nd/drivers/nvdimm/bind
         done
         for i in $(seq 0 4); do
             echo nmem$i > /sys/bus/nd/drivers/nvdimm/unbind
         done
     done
    
    ...fails with a crash signature like:
    
        divide error: 0000 [#1] SMP KASAN PTI
        RIP: 0010:nd_label_nfree+0x134/0x1a0 [libnvdimm]
        [..]
        Call Trace:
         available_slots_show+0x4e/0x120 [libnvdimm]
         dev_attr_show+0x42/0x80
         ? memset+0x20/0x40
         sysfs_kf_seq_show+0x218/0x410
    
    The root cause is that available_slots_show() consults driver-data, but
    fails to synchronize against device-unbind setting up a TOCTOU race to
    access uninitialized memory.
    
    Validate driver-data under the device-lock.
    
    Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure")
    Cc: <stable@vger.kernel.org>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Ira Weiny <ira.weiny@intel.com>
    Cc: Coly Li <colyli@suse.com>
    Reported-by: Richard Palethorpe <rpalethorpe@suse.com>
    Acked-by: Richard Palethorpe <rpalethorpe@suse.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    [sudip: use device_lock()]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 669e2d7db25e7536e81b2db931f0e217746f76aa
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Wed Feb 24 12:07:54 2021 -0800

    hugetlb: fix copy_huge_page_from_user contig page struct assumption
    
    commit 3272cfc2525b3a2810a59312d7a1e6f04a0ca3ef upstream.
    
    page structs are not guaranteed to be contiguous for gigantic pages.  The
    routine copy_huge_page_from_user can encounter gigantic pages, yet it
    assumes page structs are contiguous when copying pages from user space.
    
    Since page structs for the target gigantic page are not contiguous, the
    data copied from user space could overwrite other pages not associated
    with the gigantic page and cause data corruption.
    
    Non-contiguous page structs are generally not an issue.  However, they can
    exist with a specific kernel configuration and hotplug operations.  For
    example: Configure the kernel with CONFIG_SPARSEMEM and
    !CONFIG_SPARSEMEM_VMEMMAP.  Then, hotplug add memory for the area where
    the gigantic page will be allocated.
    
    Link: https://lkml.kernel.org/r/20210217184926.33567-2-mike.kravetz@oracle.com
    Fixes: 8fb5debc5fcd ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Zi Yan <ziy@nvidia.com>
    Cc: Davidlohr Bueso <dbueso@suse.de>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Joao Martins <joao.m.martins@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 745f2c5a63da405e01002c230275cceddcc1321f
Author: NeilBrown <neilb@suse.de>
Date:   Thu Feb 25 17:22:29 2021 -0800

    x86: fix seq_file iteration for pat/memtype.c
    
    commit 3d2fc4c082448e9c05792f9b2a11c1d5db408b85 upstream.
    
    The memtype seq_file iterator allocates a buffer in the ->start and ->next
    functions and frees it in the ->show function.  The preferred handling for
    such resources is to free them in the subsequent ->next or ->stop function
    call.
    
    Since Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration
    code and interface") there is no guarantee that ->show will be called
    after ->next, so this function can now leak memory.
    
    So move the freeing of the buffer to ->next and ->stop.
    
    Link: https://lkml.kernel.org/r/161248539022.21478.13874455485854739066.stgit@noble1
    Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Cc: Xin Long <lucien.xin@gmail.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Vlad Yasevich <vyasevich@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a384d0b6b978f7524c3685beb516b5fff4cd59e
Author: NeilBrown <neilb@suse.de>
Date:   Thu Feb 25 17:22:25 2021 -0800

    seq_file: document how per-entry resources are managed.
    
    commit b3656d8227f4c45812c6b40815d8f4e446ed372a upstream.
    
    Patch series "Fix some seq_file users that were recently broken".
    
    A recent change to seq_file broke some users which were using seq_file
    in a non-"standard" way ...  though the "standard" isn't documented, so
    they can be excused.  The result is a possible leak - of memory in one
    case, of references to a 'transport' in the other.
    
    These three patches:
     1/ document and explain the problem
     2/ fix the problem user in x86
     3/ fix the problem user in net/sctp
    
    This patch (of 3):
    
    Users of seq_file will sometimes find it convenient to take a resource,
    such as a lock or memory allocation, in the ->start or ->next operations.
    These are per-entry resources, distinct from per-session resources which
    are taken in ->start and released in ->stop.
    
    The preferred management of these is release the resource on the
    subsequent call to ->next or ->stop.
    
    However prior to Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file
    iteration code and interface") it happened that ->show would always be
    called after ->start or ->next, and a few users chose to release the
    resource in ->show.
    
    This is no longer reliable.  Since the mentioned commit, ->next will
    always come after a successful ->show (to ensure m->index is updated
    correctly), so the original ordering cannot be maintained.
    
    This patch updates the documentation to clearly state the required
    behaviour.  Other patches will fix the few problematic users.
    
    [akpm@linux-foundation.org: fix typo, per Willy]
    
    Link: https://lkml.kernel.org/r/161248518659.21478.2484341937387294998.stgit@noble1
    Link: https://lkml.kernel.org/r/161248539020.21478.3147971477400875336.stgit@noble1
    Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Cc: Xin Long <lucien.xin@gmail.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Vlad Yasevich <vyasevich@gmail.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce02ed6c4987105c6978a659e08bcf2663b6d7b3
Author: Pan Bian <bianpan2016@163.com>
Date:   Wed Jan 20 00:51:13 2021 -0800

    fs/affs: release old buffer head on error path
    
    commit 70779b897395b330ba5a47bed84f94178da599f9 upstream.
    
    The reference count of the old buffer head should be decremented on path
    that fails to get the new buffer head.
    
    Fixes: 6b4657667ba0 ("fs/affs: add rename exchange")
    CC: stable@vger.kernel.org # 4.14+
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e0a14124caaf194f63705454400891a5c1133d7
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Jan 21 01:18:47 2021 -0800

    mtd: spi-nor: hisi-sfc: Put child node np on error path
    
    commit fe6653460ee7a7dbe0cd5fd322992af862ce5ab0 upstream.
    
    Put the child node np when it fails to get or register device.
    
    Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    [ta: Add Fixes tag and Cc stable]
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20210121091847.85362-1-bianpan2016@163.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20b5124bc8c096bd934bfc8cfe1f7655d688fa94
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Sun Jan 24 13:49:38 2021 +0200

    watchdog: mei_wdt: request stop on unregister
    
    commit 740c0a57b8f1e36301218bf549f3c9cc833a60be upstream.
    
    The MEI bus has a special behavior on suspend it destroys
    all the attached devices, this is due to the fact that also
    firmware context is not persistent across power flows.
    
    If watchdog on MEI bus is ticking before suspending the firmware
    times out and reports that the OS is missing watchdog tick.
    Send the stop command to the firmware on watchdog unregistered
    to eliminate the false event on suspend.
    This does not make the things worse from the user-space perspective
    as a user-space should re-open watchdog device after
    suspending before this patch.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20210124114938.373885-1-tomas.winkler@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 606655cd15af53fe287468fac47f617b927216ac
Author: He Zhe <zhe.he@windriver.com>
Date:   Tue Feb 23 16:25:34 2021 +0800

    arm64: uprobe: Return EOPNOTSUPP for AARCH32 instruction probing
    
    commit d47422d953e258ad587b5edf2274eb95d08bdc7d upstream.
    
    As stated in linux/errno.h, ENOTSUPP should never be seen by user programs.
    When we set up uprobe with 32-bit perf and arm64 kernel, we would see the
    following vague error without useful hint.
    
    The sys_perf_event_open() syscall returned with 524 (INTERNAL ERROR:
    strerror_r(524, [buf], 128)=22)
    
    Use EOPNOTSUPP instead to indicate such cases.
    
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Link: https://lore.kernel.org/r/20210223082535.48730-1-zhe.he@windriver.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc744d02593646893fd28532bed01d72543836f8
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Fri Jan 22 12:13:20 2021 +0100

    floppy: reintroduce O_NDELAY fix
    
    commit 8a0c014cd20516ade9654fc13b51345ec58e7be8 upstream.
    
    This issue was originally fixed in 09954bad4 ("floppy: refactor open()
    flags handling").
    
    The fix as a side-effect, however, introduce issue for open(O_ACCMODE)
    that is being used for ioctl-only open. I wrote a fix for that, but
    instead of it being merged, full revert of 09954bad4 was performed,
    re-introducing the O_NDELAY / O_NONBLOCK issue, and it strikes again.
    
    This is a forward-port of the original fix to current codebase; the
    original submission had the changelog below:
    
    ====
    Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
    side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
    this is being used setfdprm userspace for ioctl-only open().
    
    Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
    modes, while still keeping the original O_NDELAY bug fixed.
    
    Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2101221209060.5622@cbobk.fhfr.pm
    Cc: stable@vger.kernel.org
    Reported-by: Wim Osterholt <wim@djo.tudelft.nl>
    Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
    Reported-and-tested-by: Kurt Garloff <kurt@garloff.de>
    Fixes: 09954bad4 ("floppy: refactor open() flags handling")
    Fixes: f2791e7ead ("Revert "floppy: refactor open() flags handling"")
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Denis Efremov <efremov@linux.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98c722efc083f9c1beba5e797ad198af06e31fe7
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Dec 30 16:26:55 2020 -0800

    x86/reboot: Force all cpus to exit VMX root if VMX is supported
    
    commit ed72736183c45a413a8d6974dd04be90f514cb6b upstream.
    
    Force all CPUs to do VMXOFF (via NMI shootdown) during an emergency
    reboot if VMX is _supported_, as VMX being off on the current CPU does
    not prevent other CPUs from being in VMX root (post-VMXON).  This fixes
    a bug where a crash/panic reboot could leave other CPUs in VMX root and
    prevent them from being woken via INIT-SIPI-SIPI in the new kernel.
    
    Fixes: d176720d34c7 ("x86: disable VMX on all CPUs on reboot")
    Cc: stable@vger.kernel.org
    Suggested-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: David P. Reed <dpreed@deepplum.com>
    [sean: reworked changelog and further tweaked comment]
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20201231002702.2223707-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7c829ddbf9942f26dd241e5f739abb8a37413e2
Author: Pavel Machek <pavel@denx.de>
Date:   Wed Dec 30 13:55:50 2020 +0100

    media: ipu3-cio2: Fix mbus_code processing in cio2_subdev_set_fmt()
    
    commit 334de4b45892f7e67074e1b1b2ac36fd3e091118 upstream.
    
    Loop was useless as it would always exit on the first iteration. Fix
    it with right condition.
    
    Signed-off-by: Pavel Machek (CIP) <pavel@denx.de>
    Fixes: a86cf9b29e8b ("media: ipu3-cio2: Validate mbus format in setting subdev format")
    Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: stable@vger.kernel.org # v4.16 and up
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b5d842a26f706cb8174fdc0f8890cf0e4649007
Author: Martin Kaiser <martin@kaiser.cx>
Date:   Thu Feb 4 09:52:17 2021 +0100

    staging: rtl8188eu: Add Edimax EW-7811UN V2 to device table
    
    commit 7a8d2f1908a59003e55ef8691d09efb7fbc51625 upstream.
    
    The Edimax EW-7811UN V2 uses an RTL8188EU chipset and works with this
    driver.
    
    Signed-off-by: Martin Kaiser <martin@kaiser.cx>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210204085217.9743-1-martin@kaiser.cx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59a18ff1feafcd4f7c141f72104ece3cce621582
Author: Amey Narkhede <ameynarkhede03@gmail.com>
Date:   Thu Feb 11 11:08:19 2021 +0530

    staging: gdm724x: Fix DMA from stack
    
    commit 7c3a0635cd008eaca9a734dc802709ee0b81cac5 upstream.
    
    Stack allocated buffers cannot be used for DMA
    on all architectures so allocate hci_packet buffer
    using kmalloc.
    
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
    Link: https://lore.kernel.org/r/20210211053819.34858-1-ameynarkhede03@gmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c366a2c4305ebc8dafb4d3e67914ac2bd2dd83d1
Author: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Date:   Fri Jan 29 19:45:07 2021 -0800

    staging/mt7621-dma: mtk-hsdma.c->hsdma-mt7621.c
    
    commit 1f92798cbe7fe923479cff754dd06dd23d352e36 upstream.
    
    Also use KBUILD_MODNAME for module name.
    
    This driver is only used by RALINK MIPS MT7621 SoCs. Tested by building
    against that target using OpenWrt with Linux 5.10.10.
    
    Fixes the following error:
    error: the following would cause module name conflict:
      drivers/dma/mediatek/mtk-hsdma.ko
      drivers/staging/mt7621-dma/mtk-hsdma.ko
    
    Cc: stable@vger.kernel.org
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
    Link: https://lore.kernel.org/r/20210130034507.2115280-1-ilya.lipnitskiy@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37963344af440a087f06f87df05ac3f9690d1512
Author: Frank Wunderlich <frank-w@public-files.de>
Date:   Wed Jan 13 19:09:19 2021 +0100

    dts64: mt7622: fix slow sd card access
    
    commit dc2e76175417e69c41d927dba75a966399f18354 upstream.
    
    Fix extreme slow speed (200MB takes ~20 min) on writing sdcard on
    bananapi-r64 by adding reset-control for mmc1 like it's done for mmc0/emmc.
    
    Fixes: 2c002a3049f7 ("arm64: dts: mt7622: add mmc related device nodes")
    Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210113180919.49523-1-linux@fw-web.de
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90c980ec7ffb78dc122f7194e3cce158a342eebe
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Thu Feb 18 12:15:47 2021 +0100

    pstore: Fix typo in compression option name
    
    commit 19d8e9149c27b689c6224f5c84b96a159342195a upstream.
    
    Both pstore_compress() and decompress_record() use a mistyped config
    option name ("PSTORE_COMPRESSION" instead of "PSTORE_COMPRESS"). As
    a result compression and decompression of pstore records was always
    disabled.
    
    Use the correct config option name.
    
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Fixes: fd49e03280e5 ("pstore: Fix linking when crypto API disabled")
    Acked-by: Matteo Croce <mcroce@microsoft.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210218111547.johvp5klpv3xrpnn@dwarf.suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 536618c1bdcb1ec34a151bb1fafffaf09e3f77b6
Author: Sabyrzhan Tasbolatov <snovitoll@gmail.com>
Date:   Tue Feb 9 16:26:12 2021 +0600

    drivers/misc/vmw_vmci: restrict too big queue size in qp_host_alloc_queue
    
    commit 2fd10bcf0310b9525b2af9e1f7aa9ddd87c3772e upstream.
    
    syzbot found WARNING in qp_broker_alloc[1] in qp_host_alloc_queue()
    when num_pages is 0x100001, giving queue_size + queue_page_size
    bigger than KMALLOC_MAX_SIZE for kzalloc(), resulting order >= MAX_ORDER
    condition.
    
    queue_size + queue_page_size=0x8000d8, where KMALLOC_MAX_SIZE=0x400000.
    
    [1]
    Call Trace:
     alloc_pages include/linux/gfp.h:547 [inline]
     kmalloc_order+0x40/0x130 mm/slab_common.c:837
     kmalloc_order_trace+0x15/0x70 mm/slab_common.c:853
     kmalloc_large include/linux/slab.h:481 [inline]
     __kmalloc+0x257/0x330 mm/slub.c:3959
     kmalloc include/linux/slab.h:557 [inline]
     kzalloc include/linux/slab.h:682 [inline]
     qp_host_alloc_queue drivers/misc/vmw_vmci/vmci_queue_pair.c:540 [inline]
     qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline]
     qp_broker_alloc+0x936/0x2740 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739
    
    Reported-by: syzbot+15ec7391f3d6a1a7cc7d@syzkaller.appspotmail.com
    Signed-off-by: Sabyrzhan Tasbolatov <snovitoll@gmail.com>
    Link: https://lore.kernel.org/r/20210209102612.2112247-1-snovitoll@gmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83494054fd635d21936ed112a96a1d9cbc0472d2
Author: Ricky Wu <ricky_wu@realtek.com>
Date:   Thu Feb 4 16:31:15 2021 +0800

    misc: rtsx: init of rts522a add OCP power off when no card is present
    
    commit 920fd8a70619074eac7687352c8f1c6f3c2a64a5 upstream.
    
    Power down OCP for power consumption
    when no SD/MMC card is present
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
    Link: https://lore.kernel.org/r/20210204083115.9471-1-ricky_wu@realtek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d03e908480dd1f2c092db45e467c508dad44ce48
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Mon Jan 11 17:28:39 2021 +0000

    seccomp: Add missing return in non-void function
    
    commit 04b38d012556199ba4c31195940160e0c44c64f0 upstream.
    
    We don't actually care about the value, since the kernel will panic
    before that; but a value should nonetheless be returned, otherwise the
    compiler will complain.
    
    Fixes: 8112c4f140fa ("seccomp: remove 2-phase API")
    Cc: stable@vger.kernel.org # 4.7+
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20210111172839.640914-1-paul@crapouillou.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c18f773e2ba56021eb321c649e12f1df61a0de1
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Mon Dec 14 20:02:28 2020 +0000

    crypto: sun4i-ss - handle BigEndian for cipher
    
    commit 5ab6177fa02df15cd8a02a1f1fb361d2d5d8b946 upstream.
    
    Ciphers produce invalid results on BE.
    Key and IV need to be written in LE.
    
    Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9819913f34dc60c3ef5cc2dc9710cf5a97e5fe2e
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Mon Dec 14 20:02:26 2020 +0000

    crypto: sun4i-ss - checking sg length is not sufficient
    
    commit 7bdcd851fa7eb66e8922aa7f6cba9e2f2427a7cf upstream.
    
    The optimized cipher function need length multiple of 4 bytes.
    But it get sometimes odd length.
    This is due to SG data could be stored with an offset.
    
    So the fix is to check also if the offset is aligned with 4 bytes.
    Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37b16c8023b649c7bd7277e7f29bce5b55241135
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Jan 14 19:10:10 2021 +0100

    crypto: arm64/sha - add missing module aliases
    
    commit 0df07d8117c3576f1603b05b84089742a118d10a upstream.
    
    The accelerated, instruction based implementations of SHA1, SHA2 and
    SHA3 are autoloaded based on CPU capabilities, given that the code is
    modest in size, and widely used, which means that resolving the algo
    name, loading all compatible modules and picking the one with the
    highest priority is taken to be suboptimal.
    
    However, if these algorithms are requested before this CPU feature
    based matching and autoloading occurs, these modules are not even
    considered, and we end up with suboptimal performance.
    
    So add the missing module aliases for the various SHA implementations.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d8d18dbcd4d69e5ac9b9ae50025ed6a33e8d5de
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Feb 4 14:35:44 2021 +0000

    btrfs: fix extent buffer leak on failure to copy root
    
    commit 72c9925f87c8b74f36f8e75a4cd93d964538d3ca upstream.
    
    At btrfs_copy_root(), if the call to btrfs_inc_ref() fails we end up
    returning without unlocking and releasing our reference on the extent
    buffer named "cow" we previously allocated with btrfs_alloc_tree_block().
    
    So fix that by unlocking the extent buffer and dropping our reference on
    it before returning.
    
    Fixes: be20aa9dbadc8c ("Btrfs: Add mount option to turn off data cow")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b1ef69663268b4afa9849004a4a2f8808e3cd81
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Thu Jan 14 14:02:42 2021 -0500

    btrfs: fix reloc root leak with 0 ref reloc roots on recovery
    
    commit c78a10aebb275c38d0cfccae129a803fe622e305 upstream.
    
    When recovering a relocation, if we run into a reloc root that has 0
    refs we simply add it to the reloc_control->reloc_roots list, and then
    clean it up later.  The problem with this is __del_reloc_root() doesn't
    do anything if the root isn't in the radix tree, which in this case it
    won't be because we never call __add_reloc_root() on the reloc_root.
    
    This exit condition simply isn't correct really.  During normal
    operation we can remove ourselves from the rb tree and then we're meant
    to clean up later at merge_reloc_roots() time, and this happens
    correctly.  During recovery we're depending on free_reloc_roots() to
    drop our references, but we're short-circuiting.
    
    Fix this by continuing to check if we're on the list and dropping
    ourselves from the reloc_control root list and dropping our reference
    appropriately.  Change the corresponding BUG_ON() to an ASSERT() that
    does the correct thing if we aren't in the rb tree.
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d26751988b47167074b1ab0831d585f59367288a
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Thu Jan 14 14:02:46 2021 -0500

    btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root
    
    commit 867ed321f90d06aaba84e2c91de51cd3038825ef upstream.
    
    While testing my error handling patches, I added a error injection site
    at btrfs_inc_extent_ref, to validate the error handling I added was
    doing the correct thing.  However I hit a pretty ugly corruption while
    doing this check, with the following error injection stack trace:
    
    btrfs_inc_extent_ref
      btrfs_copy_root
        create_reloc_root
          btrfs_init_reloc_root
            btrfs_record_root_in_trans
              btrfs_start_transaction
                btrfs_update_inode
                  btrfs_update_time
                    touch_atime
                      file_accessed
                        btrfs_file_mmap
    
    This is because we do not catch the error from btrfs_inc_extent_ref,
    which in practice would be ENOMEM, which means we lose the extent
    references for a root that has already been allocated and inserted,
    which is the problem.  Fix this by aborting the transaction if we fail
    to do the reference modification.
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 643a663251e07ea55178fd9bfede9a7a4199cc24
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Fri Jan 29 01:56:20 2021 +0200

    KEYS: trusted: Fix migratable=1 failing
    
    commit 8da7520c80468c48f981f0b81fc1be6599e3b0ad upstream.
    
    Consider the following transcript:
    
    $ keyctl add trusted kmk "new 32 blobauth=helloworld keyhandle=80000000 migratable=1" @u
    add_key: Invalid argument
    
    The documentation has the following description:
    
      migratable=   0|1 indicating permission to reseal to new PCR values,
                    default 1 (resealing allowed)
    
    The consequence is that "migratable=1" should succeed. Fix this by
    allowing this condition to pass instead of return -EINVAL.
    
    [*] Documentation/security/keys/trusted-encrypted.rst
    
    Cc: stable@vger.kernel.org
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: Mimi Zohar <zohar@linux.ibm.com>
    Cc: David Howells <dhowells@redhat.com>
    Fixes: d00a1c72f7f4 ("keys: add new trusted key-type")
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1167ca53dad823a5abe758232015c4a14e9ee4e1
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Thu Oct 1 11:09:22 2020 -0700

    tpm_tis: Clean up locality release
    
    commit e42acf104d6e0bd7ccd2f09103d5be5e6d3c637c upstream.
    
    The current release locality code seems to be based on the
    misunderstanding that the TPM interrupts when a locality is released:
    it doesn't, only when the locality is acquired.
    
    Furthermore, there seems to be no point in waiting for the locality to
    be released.  All it does is penalize the last TPM user.  However, if
    there's no next TPM user, this is a pointless wait and if there is a
    next TPM user, they'll pay the penalty waiting for the new locality
    (or possibly not if it's the same as the old locality).
    
    Fix the code by making release_locality as simple write to release
    with no waiting for completion.
    
    Cc: stable@ger.kernel.org
    Fixes: 33bafe90824b ("tpm_tis: verify locality released before returning from release_locality")
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b283eda4e55aed3a931c70a14cf6f6790789f1f
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Thu Oct 1 11:09:21 2020 -0700

    tpm_tis: Fix check_locality for correct locality acquisition
    
    commit 3d9ae54af1d02a7c0edc55c77d7df2b921e58a87 upstream.
    
    The TPM TIS specification says the TPM signals the acquisition of locality
    when the TMP_ACCESS_REQUEST_USE bit goes to one *and* the
    TPM_ACCESS_REQUEST_USE bit goes to zero.  Currently we only check the
    former not the latter, so check both.  Adding the check on
    TPM_ACCESS_REQUEST_USE should fix the case where the locality is
    re-requested before the TPM has released it.  In this case the locality may
    get released briefly before it is reacquired, which causes all sorts of
    problems. However, with the added check, TPM_ACCESS_REQUEST_USE should
    remain 1 until the second request for the locality is granted.
    
    Cc: stable@ger.kernel.org
    Fixes: 27084efee0c3 ("[PATCH] tpm: driver for next generation TPM chips")
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5add1824a24378e31c2c293aaf1c50b569b36d9a
Author: PeiSen Hou <pshou@realtek.com>
Date:   Tue Feb 2 10:30:22 2021 +0100

    ALSA: hda/realtek: modify EAPD in the ALC886
    
    commit 4841b8e6318a7f0ae57c4e5ec09032ea057c97a8 upstream.
    
    Modify 0x20 index 7 bit 5 to 1, make the 0x15 EAPD the same as 0x14.
    
    Signed-off-by: PeiSen Hou <pshou@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/e62c5058957f48d8b8953e97135ff108@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e8832c3c2dc0147815de5b040d7df79126c0094
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 28 12:35:23 2021 +0300

    USB: serial: mos7720: fix error code in mos7720_write()
    
    commit fea7372cbc40869876df0f045e367f6f97a1666c upstream.
    
    This code should return -ENOMEM if the kmalloc() fails but instead
    it returns success.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa2a883116d4a70ee97d7532cab25ed22cd1558f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jan 26 13:26:54 2021 +0300

    USB: serial: mos7840: fix error code in mos7840_write()
    
    commit a70aa7dc60099bbdcbd6faca42a915d80f31161e upstream.
    
    This should return -ENOMEM instead of 0 if the kmalloc() fails.
    
    Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e33bc5b4ac2cc33510649ac14a1df31b45a393d
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 26 14:59:17 2021 +0100

    USB: serial: ftdi_sio: fix FTX sub-integer prescaler
    
    commit 528222d0c8ce93e435a95cd1e476b60409dd5381 upstream.
    
    The most-significant bit of the sub-integer-prescaler index is set in
    the high byte of the baudrate request wIndex also for FTX devices.
    
    This fixes rates like 1152000 which got mapped to 1.2 MBd.
    
    Reported-by: Vladimir <svv75@mail.ru>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=210351
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6e8a635d725ef9a26628985dd29eb415edba942
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Mon Feb 8 13:53:16 2021 -0800

    usb: dwc3: gadget: Fix dep->interval for fullspeed interrupt
    
    commit 4b049f55ed95cd889bcdb3034fd75e1f01852b38 upstream.
    
    The dep->interval captures the number of frames/microframes per interval
    from bInterval. Fullspeed interrupt endpoint bInterval is the number of
    frames per interval and not 2^(bInterval - 1). So fix it here. This
    change is only for debugging purpose and should not affect the interrupt
    endpoint operation.
    
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/1263b563dedc4ab8b0fb854fba06ce4bc56bd495.1612820995.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7026b980749948bcbedb0b22c9189cf5a4d333b5
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Mon Feb 8 13:53:10 2021 -0800

    usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1
    
    commit a1679af85b2ae35a2b78ad04c18bb069c37330cc upstream.
    
    Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it must be set
    to 0 when the controller operates in full-speed. See the programming
    guide for DEPCFG command section 3.2.2.1 (v3.30a).
    
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/3f57026f993c0ce71498dbb06e49b3a47c4d0265.1612820995.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52a5a491a58ce7c2b9c0b9672ec4c314cc3bac45
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Sat Jan 23 14:24:59 2021 +0000

    usb: musb: Fix runtime PM race in musb_queue_resume_work
    
    commit 0eaa1a3714db34a59ce121de5733c3909c529463 upstream.
    
    musb_queue_resume_work() would call the provided callback if the runtime
    PM status was 'active'. Otherwise, it would enqueue the request if the
    hardware was still suspended (musb->is_runtime_suspended is true).
    
    This causes a race with the runtime PM handlers, as it is possible to be
    in the case where the runtime PM status is not yet 'active', but the
    hardware has been awaken (PM resume function has been called).
    
    When hitting the race, the resume work was not enqueued, which probably
    triggered other bugs further down the stack. For instance, a telnet
    connection on Ingenic SoCs would result in a 50/50 chance of a
    segmentation fault somewhere in the musb code.
    
    Rework the code so that either we call the callback directly if
    (musb->is_runtime_suspended == 0), or enqueue the query otherwise.
    
    Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid context for hdrc glue")
    Cc: stable@vger.kernel.org # v4.9+
    Tested-by: Tony Lindgren <tony@atomide.com>
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Link: https://lore.kernel.org/r/20210123142502.16980-1-paul@crapouillou.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b21b5b0b08391d32f7f6df7a89aec65af6f4b3d6
Author: Lech Perczak <lech.perczak@gmail.com>
Date:   Sun Feb 7 01:54:43 2021 +0100

    USB: serial: option: update interface mapping for ZTE P685M
    
    commit 6420a569504e212d618d4a4736e2c59ed80a8478 upstream.
    
    This patch prepares for qmi_wwan driver support for the device.
    Previously "option" driver mapped itself to interfaces 0 and 3 (matching
    ff/ff/ff), while interface 3 is in fact a QMI port.
    Interfaces 1 and 2 (matching ff/00/00) expose AT commands,
    and weren't supported previously at all.
    Without this patch, a possible conflict would exist if device ID was
    added to qmi_wwan driver for interface 3.
    
    Update and simplify device ID to match interfaces 0-2 directly,
    to expose QCDM (0), PCUI (1), and modem (2) ports and avoid conflict
    with QMI (3), and ADB (4).
    
    The modem is used inside ZTE MF283+ router and carriers identify it as
    such.
    Interface mapping is:
    0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB
    
    T:  Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=1275 Rev=f0.00
    S:  Manufacturer=ZTE,Incorporated
    S:  Product=ZTE Technologies MSM
    S:  SerialNumber=P685M510ZTED0000CP&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&0
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 0 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#= 1 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#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=87(I) Atr=03(Int.) MxPS=   8 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#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: Johan Hovold <johan@kernel.org>
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
    Link: https://lore.kernel.org/r/20210207005443.12936-1-lech.perczak@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18bd13e265ce06ad78c16e235f03b3249c2f3b49
Author: Marcos Paulo de Souza <mpdesouza@suse.com>
Date:   Fri Feb 19 10:37:13 2021 -0800

    Input: i8042 - add ASUS Zenbook Flip to noselftest list
    
    commit b5d6e7ab7fe7d186878142e9fc1a05e4c3b65eb9 upstream.
    
    After commit 77b425399f6d ("Input: i8042 - use chassis info to skip
    selftest on Asus laptops"), all modern Asus laptops have the i8042
    selftest disabled. It has done by using chassys type "10" (laptop).
    
    The Asus Zenbook Flip suffers from similar suspend/resume issues, but
    it _sometimes_ work and sometimes it doesn't. Setting noselftest makes
    it work reliably. In this case, we need to add chassis type "31"
    (convertible) in order to avoid selftest in this device.
    
    Reported-by: Ludvig Norgren Guldhag <ludvigng@gmail.com>
    Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
    Link: https://lore.kernel.org/r/20210219164638.761-1-mpdesouza@suse.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88438fdeeffe11dcb05c2dd0ddd22cb6e3f024b4
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Feb 17 12:21:10 2021 -0800

    Input: joydev - prevent potential read overflow in ioctl
    
    commit 182d679b2298d62bf42bb14b12a8067b8e17b617 upstream.
    
    The problem here is that "len" might be less than "joydev->nabs" so the
    loops which verfy abspam[i] and keypam[] might read beyond the buffer.
    
    Fixes: 999b874f4aa3 ("Input: joydev - validate axis/button maps before clobbering current ones")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YCyzR8WvFRw4HWw6@mwanda
    [dtor: additional check for len being even in joydev_handle_JSIOCSBTNMAP]
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3096bea3d255eeffbcd55c375b3662c071278567
Author: Olivier Crête <olivier.crete@ocrete.ca>
Date:   Fri Feb 5 11:59:08 2021 -0800

    Input: xpad - add support for PowerA Enhanced Wired Controller for Xbox Series X|S
    
    commit 42ffcd1dba1796bcda386eb6f260df9fc23c90af upstream.
    
    Signed-off-by: Olivier Crête <olivier.crete@ocrete.ca>
    Link: https://lore.kernel.org/r/20210204005318.615647-1-olivier.crete@collabora.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1861f63e3b484aa4a577685814eafdb8a0cb450d
Author: jeffrey.lin <jeffrey.lin@rad-ic.com>
Date:   Tue Dec 15 10:50:12 2020 -0800

    Input: raydium_ts_i2c - do not send zero length
    
    commit fafd320ae51b9c72d371585b2501f86640ea7b7d upstream.
    
    Add default write command package to prevent i2c quirk error of zero
    data length as Raydium touch firmware update is executed.
    
    Signed-off-by: jeffrey.lin <jeffrey.lin@rad-ic.com>
    Link: https://lore.kernel.org/r/1608031217-7247-1-git-send-email-jeffrey.lin@raydium.corp-partner.google.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 912e3e9a43118b231f896df567b1a13124548467
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Tue Feb 16 11:41:54 2021 -0800

    HID: wacom: Ignore attempts to overwrite the touch_max value from HID
    
    commit 88f38846bfb1a452a3d47e38aeab20a4ceb74294 upstream.
    
    The `wacom_feature_mapping` function is careful to only set the the
    touch_max value a single time, but this care does not extend to the
    `wacom_wac_finger_event` function. In particular, if a device sends
    multiple HID_DG_CONTACTMAX items in a single feature report, the
    driver will end up retaining the value of last item.
    
    The HID descriptor for the Cintiq Companion 2 does exactly this. It
    incorrectly sets a "Report Count" of 2, which will cause the driver
    to process two HID_DG_CONTACTCOUNT items. The first item has the actual
    count, while the second item should have been declared as a constant
    zero. The constant zero is the value the driver ends up using, however,
    since it is the last HID_DG_CONTACTCOUNT in the report.
    
        Report ID (16),
        Usage (Contact Count Maximum),  ; Contact count maximum (55h, static value)
        Report Count (2),
        Logical Maximum (10),
        Feature (Variable),
    
    To address this, we add a check that the touch_max is not already set
    within the `wacom_wac_finger_event` function that processes the
    HID_DG_TOUCHMAX item. We emit a warning if the value is set and ignore
    the updated value.
    
    This could potentially cause problems if there is a tablet which has
    a similar issue but requires the last item to be used. This is unlikely,
    however, since it would have to have a different non-zero value for
    HID_DG_CONTACTMAX earlier in the same report, which makes no sense
    except in the case of a firmware bug. Note that cases where the
    HID_DG_CONTACTMAX items are in different reports is already handled
    (and similarly ignored) by `wacom_feature_mapping` as mentioned above.
    
    Link: https://github.com/linuxwacom/input-wacom/issues/223
    Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report")
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 025f2a33dec87ab8542895df1c4fae62585c398b
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Fri Jan 15 10:22:50 2021 +0800

    ACPI: configfs: add missing check after configfs_register_default_group()
    
    commit 67e40054de86aae520ddc2a072d7f6951812a14f upstream.
    
    A list_add corruption is reported by Hulk Robot like this:
    ==============
    list_add corruption.
    Call Trace:
    link_obj+0xc0/0x1c0
    link_group+0x21/0x140
    configfs_register_subsystem+0xdb/0x380
    acpi_configfs_init+0x25/0x1000 [acpi_configfs]
    do_one_initcall+0x149/0x820
    do_init_module+0x1ef/0x720
    load_module+0x35c8/0x4380
    __do_sys_finit_module+0x10d/0x1a0
    do_syscall_64+0x34/0x80
    
    It's because of the missing check after configfs_register_default_group,
    where configfs_unregister_subsystem should be called once failure.
    
    Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Suggested-by: Hanjun Guo <guohanjun@huawei.com>
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7725683a82b6bd32f266bacf2b41d47de0f82e92
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Feb 11 19:30:01 2021 +0100

    ACPI: property: Fix fwnode string properties matching
    
    commit e1e6bd2995ac0e1ad0c2a2d906a06f59ce2ed293 upstream.
    
    Property matching does not work for ACPI fwnodes if the value of the
    given property is not represented as a package in the _DSD package
    containing it.  For example, the "compatible" property in the _DSD
    below
    
      Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
          Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
        }
      })
    
    will not be found by fwnode_property_match_string(), because the ACPI
    code handling device properties does not regard the single value as a
    "list" in that case.
    
    Namely, fwnode_property_match_string() invoked to match a given
    string property value first calls fwnode_property_read_string_array()
    with the last two arguments equal to NULL and 0, respectively, in
    order to count the items in the value of the given property, with the
    assumption that this value may be an array.  For ACPI fwnodes, that
    operation is carried out by acpi_node_prop_read() which calls
    acpi_data_prop_read() for this purpose.  However, when the return
    (val) pointer is NULL, that function only looks for a property whose
    value is a package without checking the single-value case at all.
    
    To fix that, make acpi_data_prop_read() check the single-value
    case if its return pointer argument is NULL and modify
    acpi_data_prop_read_single() handling that case to attempt to
    read the value of the property if the return pointer is NULL
    and return 1 if that succeeds.
    
    Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
    Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
    Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 108d5817b044d480de8f4e86dd4741f7899020c0
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Feb 23 19:25:30 2021 -0700

    blk-settings: align max_sectors on "logical_block_size" boundary
    
    commit 97f433c3601a24d3513d06f575a389a2ca4e11e4 upstream.
    
    We get I/O errors when we run md-raid1 on the top of dm-integrity on the
    top of ramdisk.
    device-mapper: integrity: Bio not aligned on 8 sectors: 0xff00, 0xff
    device-mapper: integrity: Bio not aligned on 8 sectors: 0xff00, 0xff
    device-mapper: integrity: Bio not aligned on 8 sectors: 0xffff, 0x1
    device-mapper: integrity: Bio not aligned on 8 sectors: 0xffff, 0x1
    device-mapper: integrity: Bio not aligned on 8 sectors: 0x8048, 0xff
    device-mapper: integrity: Bio not aligned on 8 sectors: 0x8147, 0xff
    device-mapper: integrity: Bio not aligned on 8 sectors: 0x8246, 0xff
    device-mapper: integrity: Bio not aligned on 8 sectors: 0x8345, 0xbb
    
    The ramdisk device has logical_block_size 512 and max_sectors 255. The
    dm-integrity device uses logical_block_size 4096 and it doesn't affect the
    "max_sectors" value - thus, it inherits 255 from the ramdisk. So, we have
    a device with max_sectors not aligned on logical_block_size.
    
    The md-raid device sees that the underlying leg has max_sectors 255 and it
    will split the bios on 255-sector boundary, making the bios unaligned on
    logical_block_size.
    
    In order to fix the bug, we round down max_sectors to logical_block_size.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60ab88a4dae3043049492678022aa00258ef0511
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 13 11:24:28 2021 -0800

    scsi: bnx2fc: Fix Kconfig warning & CNIC build errors
    
    [ Upstream commit eefb816acb0162e94a85a857f3a55148f671d5a5 ]
    
    CNIC depends on MMU, but since 'select' does not follow any dependency
    chains, SCSI_BNX2X_FCOE also needs to depend on MMU, so that erroneous
    configs are not generated, which cause build errors in cnic.
    
    WARNING: unmet direct dependencies detected for CNIC
      Depends on [n]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && MMU [=n]
      Selected by [y]:
      - SCSI_BNX2X_FCOE [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && LIBFC [=y] && LIBFCOE [=y]
    
    riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L154':
    cnic.c:(.text+0x1094): undefined reference to `uio_event_notify'
    riscv64-linux-ld: cnic.c:(.text+0x10bc): undefined reference to `uio_event_notify'
    riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L1442':
    cnic.c:(.text+0x96a8): undefined reference to `__uio_register_device'
    riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L0 ':
    cnic.c:(.text.unlikely+0x68): undefined reference to `uio_unregister_device'
    
    Link: https://lore.kernel.org/r/20210213192428.22537-1-rdunlap@infradead.org
    Fixes: 853e2bd2103a ("[SCSI] bnx2fc: Broadcom FCoE offload driver")
    Cc: Saurav Kashyap <skashyap@marvell.com>
    Cc: Javed Hasan <jhasan@marvell.com>
    Cc: GR-QLogic-Storage-Upstream@marvell.com
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: linux-scsi@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97065f403cd6cf12bec2612cae9b056b064177a5
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Thu Feb 25 17:18:09 2021 -0800

    mm/rmap: fix potential pte_unmap on an not mapped pte
    
    [ Upstream commit 5d5d19eda6b0ee790af89c45e3f678345be6f50f ]
    
    For PMD-mapped page (usually THP), pvmw->pte is NULL.  For PTE-mapped THP,
    pvmw->pte is mapped.  But for HugeTLB pages, pvmw->pte is not mapped and
    set to the relevant page table entry.  So in page_vma_mapped_walk_done(),
    we may do pte_unmap() for HugeTLB pte which is not mapped.  Fix this by
    checking pvmw->page against PageHuge before trying to do pte_unmap().
    
    Link: https://lkml.kernel.org/r/20210127093349.39081-1-linmiaohe@huawei.com
    Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
    Signed-off-by: Hongxiang Lou <louhongxiang@huawei.com>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Nathan Chancellor <natechancellor@gmail.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
    Cc: Dmitry Safonov <0x7f454c46@gmail.com>
    Cc: Brian Geffon <bgeffon@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07cf234a271cc69210e92603ef708ea5a0db041d
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Thu Feb 25 17:11:01 2021 +0100

    i2c: brcmstb: Fix brcmstd_send_i2c_cmd condition
    
    [ Upstream commit a1858ce0cfe31368b23ba55794e409fb57ced4a4 ]
    
    The brcmstb_send_i2c_cmd currently has a condition that is (CMD_RD ||
    CMD_WR) which always evaluates to true, while the obvious fix is to test
    whether the cmd variable passed as parameter holds one of these two
    values.
    
    Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver")
    Reported-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73ff5db113009d6072e63b25b8beed1f47e55baf
Author: Marc Zyngier <maz@kernel.org>
Date:   Wed Feb 24 09:37:37 2021 +0000

    arm64: Add missing ISB after invalidating TLB in __primary_switch
    
    [ Upstream commit 9d41053e8dc115c92b8002c3db5f545d7602498b ]
    
    Although there has been a bit of back and forth on the subject, it
    appears that invalidating TLBs requires an ISB instruction when FEAT_ETS
    is not implemented by the CPU.
    
    From the bible:
    
      | In an implementation that does not implement FEAT_ETS, a TLB
      | maintenance instruction executed by a PE, PEx, can complete at any
      | time after it is issued, but is only guaranteed to be finished for a
      | PE, PEx, after the execution of DSB by the PEx followed by a Context
      | synchronization event
    
    Add the missing ISB in __primary_switch, just in case.
    
    Fixes: 3c5e9f238bc4 ("arm64: head.S: move KASLR processing out of __enable_mmu()")
    Suggested-by: Will Deacon <will@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20210224093738.3629662-3-maz@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffd9995b886d39ad63313dc5c18ecaf1ec2f5af9
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Thu Feb 25 16:05:19 2021 +0100

    r8169: fix jumbo packet handling on RTL8168e
    
    [ Upstream commit 6cf739131a15e4177e58a1b4f2bede9d5da78552 ]
    
    Josef reported [0] that using jumbo packets fails on RTL8168e.
    Aligning the values for register MaxTxPacketSize with the
    vendor driver fixes the problem.
    
    [0] https://bugzilla.kernel.org/show_bug.cgi?id=211827
    
    Fixes: d58d46b5d851 ("r8169: jumbo fixes.")
    Reported-by: Josef Oškera <joskera@redhat.com>
    Tested-by: Josef Oškera <joskera@redhat.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/b15ddef7-0d50-4320-18f4-6a3f86fbfd3e@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d0324108fa80446d6b41228bac40c03cd3b5d35
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Wed Feb 24 12:06:50 2021 -0800

    mm/hugetlb: fix potential double free in hugetlb_register_node() error path
    
    [ Upstream commit cc2205a67dec5a700227a693fc113441e73e4641 ]
    
    In hugetlb_sysfs_add_hstate(), we would do kobject_put() on hstate_kobjs
    when failed to create sysfs group but forget to set hstate_kobjs to NULL.
    Then in hugetlb_register_node() error path, we may free it again via
    hugetlb_unregister_node().
    
    Link: https://lkml.kernel.org/r/20210107123249.36964-1-linmiaohe@huawei.com
    Fixes: a3437870160c ("hugetlb: new sysfs interface")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Muchun Song <smuchun@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39e913ee4c4e143434d251c2a2e4f340f0e4e7fe
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Wed Feb 24 12:04:33 2021 -0800

    mm/memory.c: fix potential pte_unmap_unlock pte error
    
    [ Upstream commit 90a3e375d324b2255b83e3dd29e99e2b05d82aaf ]
    
    Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged
    high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed,
    we would break the loop with pte unchanged.  Then the wrong pte - 1 would
    be passed to pte_unmap_unlock.
    
    Andi said:
    
     "While the fix is correct, I'm not sure if it actually is a real bug.
      Is there any architecture that would do something else than unlocking
      the underlying page? If it's just the underlying page then it should
      be always the same page, so no bug"
    
    Link: https://lkml.kernel.org/r/20210109080118.20885-1-linmiaohe@huawei.com
    Fixes: 42e4089c789 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
    Signed-off-by: Hongxiang Lou <louhongxiang@huawei.com>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23f96a69ba239bfe39d2845c5105016f48da5955
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Feb 24 12:00:41 2021 -0800

    ocfs2: fix a use after free on error
    
    [ Upstream commit c57d117f2b2f2a19b570c36f2819ef8d8210af20 ]
    
    The error handling in this function frees "reg" but it is still on the
    "o2hb_all_regions" list so it will lead to a use after freew.  Joseph Qi
    points out that we need to clear the bit in the "o2hb_region_bitmap" as
    well
    
    Link: https://lkml.kernel.org/r/YBk4M6HUG8jB/jc7@mwanda
    Fixes: 1cf257f51191 ("ocfs2: fix memory leak")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15a9b01a25396aeb21406e553b5f2fd5ed900afe
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun Feb 21 15:45:52 2021 +0000

    vxlan: move debug check after netdev unregister
    
    [ Upstream commit 92584ddf550ae72d492858c19d1f9025e07a9350 ]
    
    The debug check must be done after unregister_netdevice_many() call --
    the hlist_del_rcu() for this is done inside .ndo_stop.
    
    This is the same with commit 0fda7600c2e1 ("geneve: move debug check after
    netdev unregister")
    
    Test commands:
        ip netns del A
        ip netns add A
        ip netns add B
    
        ip netns exec B ip link add vxlan0 type vxlan vni 100 local 10.0.0.1 \
                remote 10.0.0.2 dstport 4789 srcport 4789 4789
        ip netns exec B ip link set vxlan0 netns A
        ip netns exec A ip link set vxlan0 up
        ip netns del B
    
    Splat looks like:
    [   73.176249][    T7] ------------[ cut here ]------------
    [   73.178662][    T7] WARNING: CPU: 4 PID: 7 at drivers/net/vxlan.c:4743 vxlan_exit_batch_net+0x52e/0x720 [vxlan]
    [   73.182597][    T7] Modules linked in: vxlan openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 mlx5_core nfp mlxfw ixgbevf tls sch_fq_codel nf_tables nfnetlink ip_tables x_tables unix
    [   73.190113][    T7] CPU: 4 PID: 7 Comm: kworker/u16:0 Not tainted 5.11.0-rc7+ #838
    [   73.193037][    T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    [   73.196986][    T7] Workqueue: netns cleanup_net
    [   73.198946][    T7] RIP: 0010:vxlan_exit_batch_net+0x52e/0x720 [vxlan]
    [   73.201509][    T7] Code: 00 01 00 00 0f 84 39 fd ff ff 48 89 ca 48 c1 ea 03 80 3c 1a 00 0f 85 a6 00 00 00 89 c2 48 83 c2 02 49 8b 14 d4 48 85 d2 74 ce <0f> 0b eb ca e8 b9 51 db dd 84 c0 0f 85 4a fe ff ff 48 c7 c2 80 bc
    [   73.208813][    T7] RSP: 0018:ffff888100907c10 EFLAGS: 00010286
    [   73.211027][    T7] RAX: 000000000000003c RBX: dffffc0000000000 RCX: ffff88800ec411f0
    [   73.213702][    T7] RDX: ffff88800a278000 RSI: ffff88800fc78c70 RDI: ffff88800fc78070
    [   73.216169][    T7] RBP: ffff88800b5cbdc0 R08: fffffbfff424de61 R09: fffffbfff424de61
    [   73.218463][    T7] R10: ffffffffa126f307 R11: fffffbfff424de60 R12: ffff88800ec41000
    [   73.220794][    T7] R13: ffff888100907d08 R14: ffff888100907c50 R15: ffff88800fc78c40
    [   73.223337][    T7] FS:  0000000000000000(0000) GS:ffff888114800000(0000) knlGS:0000000000000000
    [   73.225814][    T7] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   73.227616][    T7] CR2: 0000562b5cb4f4d0 CR3: 0000000105fbe001 CR4: 00000000003706e0
    [   73.229700][    T7] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   73.231820][    T7] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   73.233844][    T7] Call Trace:
    [   73.234698][    T7]  ? vxlan_err_lookup+0x3c0/0x3c0 [vxlan]
    [   73.235962][    T7]  ? ops_exit_list.isra.11+0x93/0x140
    [   73.237134][    T7]  cleanup_net+0x45e/0x8a0
    [ ... ]
    
    Fixes: 57b61127ab7d ("vxlan: speedup vxlan tunnels dismantle")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Link: https://lore.kernel.org/r/20210221154552.11749-1-ap420073@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 212ada9045e0631d2fa54761e873f4f6746fa77c
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Sun Feb 21 22:35:59 2021 +0800

    net/mlx4_core: Add missed mlx4_free_cmd_mailbox()
    
    [ Upstream commit 8eb65fda4a6dbd59cd5de24b106a10b6ee0d2176 ]
    
    mlx4_do_mirror_rule() forgets to call mlx4_free_cmd_mailbox() to
    free the memory region allocated by mlx4_alloc_cmd_mailbox() before
    an exit.
    Add the missed call to fix it.
    
    Fixes: 78efed275117 ("net/mlx4_core: Support mirroring VF DMFS rules on both ports")
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20210221143559.390277-1-hslester96@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c18d591701cddc9cab0166fcc22e185e1c0913b
Author: Mateusz Palczewski <mateusz.palczewski@intel.com>
Date:   Mon Dec 28 11:38:00 2020 +0100

    i40e: Fix add TC filter for IPv6
    
    [ Upstream commit 61c1e0eb8375def7c891bfe857bb795a57090526 ]
    
    Fix insufficient distinction between IPv4 and IPv6 addresses
    when creating a filter.
    IPv4 and IPv6 are kept in the same memory area. If IPv6 is added,
    then it's caught by IPv4 check, which leads to err -95.
    
    Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Reviewed-by: Jaroslaw Gawin <jaroslawx.gawin@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f12eb7beea5b695601eedf9514421fd2880c0ae
Author: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
Date:   Fri Nov 27 11:23:01 2020 +0000

    i40e: Fix VFs not created
    
    [ Upstream commit dc8812626440fa6a27f1f3f654f6dc435e042e42 ]
    
    When creating VFs they were sometimes not getting resources.
    It was caused by not executing i40e_reset_all_vfs due to
    flag __I40E_VF_DISABLE being set on PF. Because of this
    IAVF was never able to finish setup sequence never
    getting reset indication from PF.
    Changed test_and_set_bit __I40E_VF_DISABLE in
    i40e_sync_filters_subtask to test_bit and removed clear_bit.
    This function should not set this bit it should only check
    if it hasn't been already set.
    
    Fixes: a7542b876075 ("i40e: check __I40E_VF_DISABLE bit in i40e_sync_filters_subtask")
    Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4611dd1f4632295e9207ad0b23542750e9ef339
Author: Mateusz Palczewski <mateusz.palczewski@intel.com>
Date:   Tue Nov 24 15:08:27 2020 +0000

    i40e: Fix overwriting flow control settings during driver loading
    
    [ Upstream commit 4cdb9f80dcd46aab3c0020b4a6920c22735c5d6e ]
    
    During driver loading flow control settings were written to FW
    using a variable which was always zero, since it was being set
    only by ethtool. This behavior has been corrected and driver
    no longer overwrites the default FW/NVM settings.
    
    Fixes: 373149fc99a0 ("i40e: Decrease the scope of rtnl lock")
    Signed-off-by: Dawid Lukwinski <dawid.lukwinski@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bb7470ad9278dd8c5cd46d4a6e5e789010184d3
Author: Mateusz Palczewski <mateusz.palczewski@intel.com>
Date:   Fri Nov 20 10:35:37 2020 +0000

    i40e: Add zero-initialization of AQ command structures
    
    [ Upstream commit d2c788f739b6f68090e968a2ee31b543701e795f ]
    
    Zero-initialize AQ command data structures to comply with
    API specifications.
    
    Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower")
    Fixes: f4492db16df8 ("i40e: Add NPAR BW get and set functions")
    Signed-off-by: Andrzej Sawuła <andrzej.sawula@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33eb33b43d8bae43b3da9869fe454809f8bf87d7
Author: Slawomir Laba <slawomirx.laba@intel.com>
Date:   Thu Sep 10 07:57:04 2020 +0000

    i40e: Fix flow for IPv6 next header (extension header)
    
    [ Upstream commit 92c6058024e87087cf1b99b0389d67c0a886360e ]
    
    When a packet contains an IPv6 header with next header which is
    an extension header and not a protocol one, the kernel function
    skb_transport_header called with such sk_buff will return a
    pointer to the extension header and not to the TCP one.
    
    The above explained call caused a problem with packet processing
    for skb with encapsulation for tunnel with I40E_TX_CTX_EXT_IP_IPV6.
    The extension header was not skipped at all.
    
    The ipv6_skip_exthdr function does check if next header of the IPV6
    header is an extension header and doesn't modify the l4_proto pointer
    if it points to a protocol header value so its safe to omit the
    comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can
    return value -1. This means that the skipping process failed
    and there is something wrong with the packet so it will be dropped.
    
    Fixes: a3fd9d8876a5 ("i40e/i40evf: Handle IPv6 extension headers in checksum offload")
    Signed-off-by: Slawomir Laba <slawomirx.laba@intel.com>
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 024613c35c375ad121d6f60aecd36fcbc758b892
Author: Bard Liao <yung-chuan.liao@linux.intel.com>
Date:   Fri Jan 22 15:06:30 2021 +0800

    regmap: sdw: use _no_pm functions in regmap_read/write
    
    [ Upstream commit d288a5712ef961e16d588bbdb2d846e00b5ef154 ]
    
    sdw_update_slave_status will be invoked when a codec is attached,
    and the codec driver will initialize the codec with regmap functions
    while the codec device is pm_runtime suspended.
    
    regmap routines currently rely on regular SoundWire IO functions,
    which will call pm_runtime_get_sync()/put_autosuspend.
    
    This causes a deadlock where the resume routine waits for an
    initialization complete signal that while the initialization complete
    can only be reached when the resume completes.
    
    The only solution if we allow regmap functions to be used in resume
    operations as well as during codec initialization is to use _no_pm
    routines. The duty of making sure the bus is operational needs to be
    handled above the regmap level.
    
    Fixes: 7c22ce6e21840 ('regmap: Add SoundWire bus support')
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210122070634.12825-6-yung-chuan.liao@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ffa768fe5cf06ec9b9c37baa9b1335dcba41595
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Feb 4 00:05:20 2021 -0500

    ext4: fix potential htree index checksum corruption
    
    [ Upstream commit b5776e7524afbd4569978ff790864755c438bba7 ]
    
    In the case where we need to do an interior node split, and
    immediately afterwards, we are unable to allocate a new directory leaf
    block due to ENOSPC, the directory index checksum's will not be filled
    in correctly (and indeed, will not be correctly journalled).
    
    This looks like a bug that was introduced when we added largedir
    support.  The original code doesn't make any sense (and should have
    been caught in code review), but it was hidden because most of the
    time, the index node checksum will be set by do_split().  But if
    do_split bails out due to ENOSPC, then ext4_handle_dirty_dx_node()
    won't get called, and so the directory index checksum field will not
    get set, leading to:
    
    EXT4-fs error (device sdb): dx_probe:858: inode #6635543: block 4022: comm nfsd: Directory index failed checksum
    
    Google-Bug-Id: 176345532
    Fixes: e08ac99fa2a2 ("ext4: add largedir feature")
    Cc: Artem Blagodarenko <artem.blagodarenko@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d109283a1e3700d810296c311cbd7b628e981bb4
Author: Konrad Dybcio <konrad.dybcio@somainline.org>
Date:   Mon Jan 18 17:15:58 2021 +0100

    drm/msm/dsi: Correct io_start for MSM8994 (20nm PHY)
    
    [ Upstream commit 33a7808ce1aea6e2edc1af25db25928137940c02 ]
    
    The previous registers were *almost* correct, but instead of
    PHYs, they were pointing at DSI PLLs, resulting in the PHY id
    autodetection failing miserably.
    
    Fixes: dcefc117cc19 ("drm/msm/dsi: Add support for msm8x94")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68e1f776a739931b8e78c1bb07470303ef8a96f8
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jan 24 16:39:32 2021 +0100

    PCI: Align checking of syscall user config accessors
    
    [ Upstream commit ef9e4005cbaf022c6251263aa27836acccaef65d ]
    
    After 34e3207205ef ("PCI: handle positive error codes"),
    pci_user_read_config_*() and pci_user_write_config_*() return 0 or negative
    errno values, not PCIBIOS_* values like PCIBIOS_SUCCESSFUL or
    PCIBIOS_BAD_REGISTER_NUMBER.
    
    Remove comparisons with PCIBIOS_SUCCESSFUL and check only for non-zero.  It
    happens that PCIBIOS_SUCCESSFUL is zero, so this is not a functional
    change, but it aligns this code with the user accessors.
    
    [bhelgaas: commit log]
    Fixes: 34e3207205ef ("PCI: handle positive error codes")
    Link: https://lore.kernel.org/r/f1220314-e518-1e18-bf94-8e6f8c703758@gmail.com
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bca5a72d1f9459b2162d7aee7a8e48c9c6d03b27
Author: Jorgen Hansen <jhansen@vmware.com>
Date:   Wed Jan 20 08:32:40 2021 -0800

    VMCI: Use set_page_dirty_lock() when unregistering guest memory
    
    [ Upstream commit 5a16c535409f8dcb7568e20737309e3027ae3e49 ]
    
    When the VMCI host support releases guest memory in the case where
    the VM was killed, the pinned guest pages aren't locked. Use
    set_page_dirty_lock() instead of set_page_dirty().
    
    Testing done: Killed VM while having an active VMCI based vSocket
    connection and observed warning from ext4. With this fix, no
    warning was observed. Ran various vSocket tests without issues.
    
    Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
    Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
    Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
    Link: https://lore.kernel.org/r/1611160360-30299-1-git-send-email-jhansen@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d73b5a9983002578f23786eee2191f2ef40e7ba3
Author: Simon South <simon@simonsouth.net>
Date:   Tue Jan 19 11:12:06 2021 -0500

    pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()
    
    [ Upstream commit d5d8d675865ccddfe4da26c85f22c55cec663bf2 ]
    
    If rockchip_pwm_probe() fails to register a PWM device it calls
    clk_unprepare() for the device's PWM clock, without having first disabled
    the clock and before jumping to an error handler that also unprepares
    it. This is likely to produce warnings from the kernel about the clock
    being unprepared when it is still enabled, and then being unprepared when
    it has already been unprepared.
    
    Prevent these warnings by removing this unnecessary call to
    clk_unprepare().
    
    Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs")
    Signed-off-by: Simon South <simon@simonsouth.net>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d786e3e7e942e45e09b5946d38426c7f20789b17
Author: Aswath Govindraju <a-govindraju@ti.com>
Date:   Wed Jan 13 10:42:52 2021 +0530

    misc: eeprom_93xx46: Add module alias to avoid breaking support for non device tree users
    
    [ Upstream commit 4540b9fbd8ebb21bb3735796d300a1589ee5fbf2 ]
    
    Module alias "spi:93xx46" is used by non device tree users like
    drivers/misc/eeprom/digsy_mtc_eeprom.c  and removing it will
    break support for them.
    
    Fix this by adding back the module alias "spi:93xx46".
    
    Fixes: 13613a2246bf ("misc: eeprom_93xx46: Fix module alias to enable module autoprobe")
    Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
    Link: https://lore.kernel.org/r/20210113051253.15061-1-a-govindraju@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85ab6a01adfa9307168121f677233abdbdf94339
Author: Aswath Govindraju <a-govindraju@ti.com>
Date:   Thu Jan 7 22:09:53 2021 +0530

    misc: eeprom_93xx46: Fix module alias to enable module autoprobe
    
    [ Upstream commit 13613a2246bf531f5fc04e8e62e8f21a3d39bf1c ]
    
    Fix module autoprobe by correcting module alias to match the string from
    /sys/class/.../spi1.0/modalias content.
    
    Fixes: 06b4501e88ad ("misc/eeprom: add driver for microwire 93xx46 EEPROMs")
    Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
    Link: https://lore.kernel.org/r/20210107163957.28664-2-a-govindraju@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de368817d0b99aa9d000aaf029e4f038bbb491ab
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Nov 25 16:40:11 2020 -0800

    sparc64: only select COMPAT_BINFMT_ELF if BINFMT_ELF is set
    
    [ Upstream commit 80bddf5c93a99e11fc9faf7e4b575d01cecd45d3 ]
    
    Currently COMPAT on SPARC64 selects COMPAT_BINFMT_ELF unconditionally,
    even when BINFMT_ELF is not enabled. This causes a kconfig warning.
    
    Instead, just select COMPAT_BINFMT_ELF if BINFMT_ELF is enabled.
    This builds cleanly with no kconfig warnings.
    
    WARNING: unmet direct dependencies detected for COMPAT_BINFMT_ELF
      Depends on [n]: COMPAT [=y] && BINFMT_ELF [=n]
      Selected by [y]:
      - COMPAT [=y] && SPARC64 [=y]
    
    Fixes: 26b4c912185a ("sparc,sparc64: unify Kconfig files")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 920eb9f8a270b8d4dd0c4c78d9d64ea85e622759
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 16 20:29:05 2021 -0800

    Input: elo - fix an error code in elo_connect()
    
    [ Upstream commit 0958351e93fa0ac142f6dd8bd844441594f30a57 ]
    
    If elo_setup_10() fails then this should return an error code instead
    of success.
    
    Fixes: fae3006e4b42 ("Input: elo - add support for non-pressure-sensitive touchscreens")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YBKFd5CvDu+jVmfW@mwanda
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b49e0bc05053d924bcfbd9c8cfdf4d4cf593026
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Sun Feb 14 18:16:38 2021 +0900

    perf test: Fix unaligned access in sample parsing test
    
    [ Upstream commit c5c97cadd7ed13381cb6b4bef5c841a66938d350 ]
    
    The ubsan reported the following error.  It was because sample's raw
    data missed u32 padding at the end.  So it broke the alignment of the
    array after it.
    
    The raw data contains an u32 size prefix so the data size should have
    an u32 padding after 8-byte aligned data.
    
    27: Sample parsing  :util/synthetic-events.c:1539:4:
      runtime error: store to misaligned address 0x62100006b9bc for type
      '__u64' (aka 'unsigned long long'), which requires 8 byte alignment
    0x62100006b9bc: note: pointer points here
      00 00 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
                  ^
        #0 0x561532a9fc96 in perf_event__synthesize_sample util/synthetic-events.c:1539:13
        #1 0x5615327f4a4f in do_test tests/sample-parsing.c:284:8
        #2 0x5615327f3f50 in test__sample_parsing tests/sample-parsing.c:381:9
        #3 0x56153279d3a1 in run_test tests/builtin-test.c:424:9
        #4 0x56153279c836 in test_and_print tests/builtin-test.c:454:9
        #5 0x56153279b7eb in __cmd_test tests/builtin-test.c:675:4
        #6 0x56153279abf0 in cmd_test tests/builtin-test.c:821:9
        #7 0x56153264e796 in run_builtin perf.c:312:11
        #8 0x56153264cf03 in handle_internal_command perf.c:364:8
        #9 0x56153264e47d in run_argv perf.c:408:2
        #10 0x56153264c9a9 in main perf.c:538:3
        #11 0x7f137ab6fbbc in __libc_start_main (/lib64/libc.so.6+0x38bbc)
        #12 0x561532596828 in _start ...
    
    SUMMARY: UndefinedBehaviorSanitizer: misaligned-pointer-use
     util/synthetic-events.c:1539:4 in
    
    Fixes: 045f8cd8542d ("perf tests: Add a sample parsing test")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: https://lore.kernel.org/r/20210214091638.519643-1-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fae2d6e917bcb6ea098055b494e844fcfe2f916
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Feb 5 19:53:47 2021 +0200

    perf intel-pt: Fix missing CYC processing in PSB
    
    [ Upstream commit 03fb0f859b45d1eb05c984ab4bd3bef67e45ede2 ]
    
    Add missing CYC packet processing when walking through PSB+. This
    improves the accuracy of timestamps that follow PSB+, until the next
    MTC.
    
    Fixes: 3d49807870f08 ("perf tools: Add new Intel PT packet definitions")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Link: https://lore.kernel.org/r/20210205175350.23817-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 644caa32fbf602882d957c6f68c08b8e9cf2325b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 16 20:30:45 2021 -0800

    Input: sur40 - fix an error code in sur40_probe()
    
    [ Upstream commit b0b7d2815839024e5181bd2572f5d8d4f65363b3 ]
    
    If v4l2_ctrl_handler_setup() fails then probe() should return an error
    code instead of returning success.
    
    Fixes: cee1e3e2ef39 ("media: add video control handlers using V4L2 control framework")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YBKFkbATXa5fA3xj@mwanda
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98a31a662ae819104429b30c3c2d52ed73e17c5f
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Feb 8 18:38:15 2021 +0200

    spi: pxa2xx: Fix the controller numbering for Wildcat Point
    
    [ Upstream commit 54c5d3bfb0cfb7b31259765524567871dee11615 ]
    
    Wildcat Point has two SPI controllers and added one is actually second one.
    Fix the numbering by adding the description of the first one.
    
    Fixes: caba248db286 ("spi: spi-pxa2xx-pci: Add ID and driver type for WildcatPoint PCH")
    Cc: Leif Liddy <leif.liddy@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20210208163816.22147-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb6711d1ca85c32533f0ab864e304e92e66254bc
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Date:   Thu Jan 14 23:10:54 2021 +0100

    clk: qcom: gcc-msm8998: Fix Alpha PLL type for all GPLLs
    
    [ Upstream commit 292f75ecff07e8a07fe2e3e19b4b567d0b698842 ]
    
    All of the GPLLs in the MSM8998 Global Clock Controller are Fabia PLLs
    and not generic alphas: this was producing bad effects over the entire
    clock tree of MSM8998, where any GPLL child clock was declaring a false
    clock rate, due to their parent also showing the same.
    
    The issue resides in the calculation of the clock rate for the specific
    Alpha PLL type, where Fabia has a different register layout; switching
    the MSM8998 GPLLs to the correct Alpha Fabia PLL type fixes the rate
    (calculation) reading. While at it, also make these PLLs fixed since
    their rate is supposed to *never* be changed while the system runs, as
    this would surely crash the entire SoC.
    
    Now all the children of all the PLLs are also complying with their
    specified clock table and system stability is improved.
    
    Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Link: https://lore.kernel.org/r/20210114221059.483390-7-angelogioacchino.delregno@somainline.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40c83897e406a7e603c81c80eee8ee745fbb3b05
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Feb 5 08:56:13 2021 +0000

    powerpc/8xx: Fix software emulation interrupt
    
    [ Upstream commit 903178d0ce6bb30ef80a3604ab9ee2b57869fbc9 ]
    
    For unimplemented instructions or unimplemented SPRs, the 8xx triggers
    a "Software Emulation Exception" (0x1000). That interrupt doesn't set
    reason bits in SRR1 as the "Program Check Exception" does.
    
    Go through emulation_assist_interrupt() to set REASON_ILLEGAL.
    
    Fixes: fbbcc3bb139e ("powerpc/8xx: Remove SoftwareEmulation()")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/ad782af87a222efc79cfb06079b0fd23d4224eaf.1612515180.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cab5b8b9257a92b1bcfd2060a20b60b6ca67c2b0
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Wed Jan 6 20:59:00 2021 -0600

    powerpc/pseries/dlpar: handle ibm, configure-connector delay status
    
    [ Upstream commit 768d70e19ba525debd571b36e6d0ab19956c63d7 ]
    
    dlpar_configure_connector() has two problems in its handling of
    ibm,configure-connector's return status:
    
    1. When the status is -2 (busy, call again), we call
       ibm,configure-connector again immediately without checking whether
       to schedule, which can result in monopolizing the CPU.
    2. Extended delay status (9900..9905) goes completely unhandled,
       causing the configuration to unnecessarily terminate.
    
    Fix both of these issues by using rtas_busy_delay().
    
    Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure")
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210107025900.410369-1-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4a0bb8b78e69a8fb8a77a9d6806f54d81c4092c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jan 29 17:37:24 2021 +0300

    mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq()
    
    [ Upstream commit 26783d74cc6a440ee3ef9836a008a697981013d0 ]
    
    The "req" struct is always added to the "wm831x->auxadc_pending" list,
    but it's only removed from the list on the success path.  If a failure
    occurs then the "req" struct is freed but it's still on the list,
    leading to a use after free.
    
    Fixes: 78bb3688ea18 ("mfd: Support multiple active WM831x AUXADC conversions")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f6f38cb8629488d5c206ca89c88ae007731e380
Author: Alain Volmat <alain.volmat@foss.st.com>
Date:   Fri Feb 5 19:59:25 2021 +0100

    spi: stm32: properly handle 0 byte transfer
    
    [ Upstream commit 2269f5a8b1a7b38651d62676b98182828f29d11a ]
    
    On 0 byte transfer request, return straight from the
    xfer function after finalizing the transfer.
    
    Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller")
    Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
    Link: https://lore.kernel.org/r/1612551572-495-2-git-send-email-alain.volmat@foss.st.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd5560b4376efe3c1e79d86cfb2ff1b65737f459
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Thu Jan 28 12:23:02 2021 -0600

    RDMA/rxe: Correct skb on loopback path
    
    [ Upstream commit 5120bf0a5fc15dec210a0fe0f39e4a256bb6e349 ]
    
    rxe_net.c sends packets at the IP layer with skb->data pointing at the IP
    header but receives packets from a UDP tunnel with skb->data pointing at
    the UDP header.  On the loopback path this was not correctly accounted
    for.  This patch corrects for this by using sbk_pull() to strip the IP
    header from the skb on received packets.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20210128182301.16859-1-rpearson@hpe.com
    Signed-off-by: Bob Pearson <rpearson@hpe.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61f183818999ab8a9220b74d86cf2233da687ac0
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Wed Jan 27 15:45:01 2021 -0600

    RDMA/rxe: Fix coding error in rxe_recv.c
    
    [ Upstream commit 7d9ae80e31df57dd3253e1ec514f0000aa588a81 ]
    
    check_type_state() in rxe_recv.c is written as if the type bits in the
    packet opcode were a bit mask which is not correct. This patch corrects
    this code to compare all 3 type bits to the required type.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20210127214500.3707-1-rpearson@hpe.com
    Signed-off-by: Bob Pearson <rpearson@hpe.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9089d5275801c440411fde1904cac43df2f0771
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Jan 28 09:52:47 2021 -0300

    perf tools: Fix DSO filtering when not finding a map for a sampled address
    
    [ Upstream commit c69bf11ad3d30b6bf01cfa538ddff1a59467c734 ]
    
    When we lookup an address and don't find a map we should filter that
    sample if the user specified a list of --dso entries to filter on, fix
    it.
    
    Before:
    
      $ perf script
                 sleep 274800  2843.556162:          1 cycles:u:  ffffffffbb26bff4 [unknown] ([unknown])
                 sleep 274800  2843.556168:          1 cycles:u:  ffffffffbb2b047d [unknown] ([unknown])
                 sleep 274800  2843.556171:          1 cycles:u:  ffffffffbb2706b2 [unknown] ([unknown])
                 sleep 274800  2843.556174:          6 cycles:u:  ffffffffbb2b0267 [unknown] ([unknown])
                 sleep 274800  2843.556176:         59 cycles:u:  ffffffffbb2b03b1 [unknown] ([unknown])
                 sleep 274800  2843.556180:        691 cycles:u:  ffffffffbb26bff4 [unknown] ([unknown])
                 sleep 274800  2843.556189:       9160 cycles:u:      7fa9550eeaa3 __GI___tunables_init+0xf3 (/usr/lib64/ld-2.32.so)
                 sleep 274800  2843.556312:      86937 cycles:u:      7fa9550e157b _dl_lookup_symbol_x+0x4b (/usr/lib64/ld-2.32.so)
      $
    
    So we have some samples we somehow didn't find in a map for, if we now
    do:
    
      $ perf report --stdio --dso /usr/lib64/ld-2.32.so
      # dso: /usr/lib64/ld-2.32.so
      #
      # Total Lost Samples: 0
      #
      # Samples: 8  of event 'cycles:u'
      # Event count (approx.): 96856
      #
      # Overhead  Command  Symbol
      # ........  .......  ........................
      #
          89.76%  sleep    [.] _dl_lookup_symbol_x
           9.46%  sleep    [.] __GI___tunables_init
           0.71%  sleep    [k] 0xffffffffbb26bff4
           0.06%  sleep    [k] 0xffffffffbb2b03b1
           0.01%  sleep    [k] 0xffffffffbb2b0267
           0.00%  sleep    [k] 0xffffffffbb2706b2
           0.00%  sleep    [k] 0xffffffffbb2b047d
      $
    
    After this patch we get the right output with just entries for the DSOs
    specified in --dso:
    
      $ perf report --stdio --dso /usr/lib64/ld-2.32.so
      # dso: /usr/lib64/ld-2.32.so
      #
      # Total Lost Samples: 0
      #
      # Samples: 8  of event 'cycles:u'
      # Event count (approx.): 96856
      #
      # Overhead  Command  Symbol
      # ........  .......  ........................
      #
          89.76%  sleep    [.] _dl_lookup_symbol_x
           9.46%  sleep    [.] __GI___tunables_init
      $
      #
    
    Fixes: 96415e4d3f5fdf9c ("perf symbols: Avoid unnecessary symbol loading when dso list is specified")
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jin Yao <yao.jin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/20210128131209.GD775562@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc782e5a4d4cd20e5c365532b85be53696f0c320
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Nov 18 09:34:05 2020 -0500

    tracepoint: Do not fail unregistering a probe due to memory failure
    
    [ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ]
    
    The list of tracepoint callbacks is managed by an array that is protected
    by RCU. To update this array, a new array is allocated, the updates are
    copied over to the new array, and then the list of functions for the
    tracepoint is switched over to the new array. After a completion of an RCU
    grace period, the old array is freed.
    
    This process happens for both adding a callback as well as removing one.
    But on removing a callback, if the new array fails to be allocated, the
    callback is not removed, and may be used after it is freed by the clients
    of the tracepoint.
    
    There's really no reason to fail if the allocation for a new array fails
    when removing a function. Instead, the function can simply be replaced by a
    stub function that could be cleaned up on the next modification of the
    array. That is, instead of calling the function registered to the
    tracepoint, it would call a stub function in its place.
    
    Link: https://lore.kernel.org/r/20201115055256.65625-1-mmullins@mmlx.us
    Link: https://lore.kernel.org/r/20201116175107.02db396d@gandalf.local.home
    Link: https://lore.kernel.org/r/20201117211836.54acaef2@oasis.local.home
    Link: https://lkml.kernel.org/r/20201118093405.7a6d2290@gandalf.local.home
    
    [ Note, this version does use undefined compiler behavior (assuming that
      a stub function with no parameters or return, can be called by a location
      that thinks it has parameters but still no return value. Static calls
      do the same thing, so this trick is not without precedent.
    
      There's another solution that uses RCU tricks and is more complex, but
      can be an alternative if this solution becomes an issue.
    
      Link: https://lore.kernel.org/lkml/20210127170721.58bce7cc@gandalf.local.home/
    ]
    
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: Andrii Nakryiko <andriin@fb.com>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: KP Singh <kpsingh@chromium.org>
    Cc: netdev <netdev@vger.kernel.org>
    Cc: bpf <bpf@vger.kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Florian Weimer <fw@deneb.enyo.de>
    Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
    Reported-by: syzbot+83aa762ef23b6f0d1991@syzkaller.appspotmail.com
    Reported-by: syzbot+d29e58bb557324e55e5e@syzkaller.appspotmail.com
    Reported-by: Matt Mullins <mmullins@mmlx.us>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Tested-by: Matt Mullins <mmullins@mmlx.us>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8fdb9d0c2abfb8b7db862b54ccdb6408047e94c
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Tue Jan 26 17:58:31 2021 +0100

    amba: Fix resource leak for drivers without .remove
    
    [ Upstream commit de5d7adb89367bbc87b4e5ce7afe7ae9bd86dc12 ]
    
    Consider an amba driver with a .probe but without a .remove callback (e.g.
    pl061_gpio_driver). The function amba_probe() is called to bind a device
    and so dev_pm_domain_attach() and others are called. As there is no remove
    callback amba_remove() isn't called at unbind time however and so calling
    dev_pm_domain_detach() is missed and the pm domain keeps active.
    
    To fix this always use the core driver callbacks and handle missing amba
    callbacks there. For probe refuse registration as a driver without probe
    doesn't make sense.
    
    Fixes: 7cfe249475fd ("ARM: AMBA: Add pclk support to AMBA bus infrastructure")
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20210126165835.687514-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc1703fc8c3eaea2e156f5d0bcfad4e46c0d21c5
Author: Vladimir Murzin <vladimir.murzin@arm.com>
Date:   Thu Jan 7 10:47:24 2021 +0100

    ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores
    
    [ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ]
    
    It was observed that decompressor running on hardware implementing ARM v8.2
    Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest,
    would stuck just after:
    
    Uncompressing Linux... done, booting the kernel.
    
    The reason is that it clears nTLSMD bit when disabling caches:
    
      nTLSMD, bit [3]
    
      When ARMv8.2-LSMAOC is implemented:
    
        No Trap Load Multiple and Store Multiple to
        Device-nGRE/Device-nGnRE/Device-nGnRnE memory.
    
        0b0 All memory accesses by A32 and T32 Load Multiple and Store
            Multiple at EL1 or EL0 that are marked at stage 1 as
            Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and
            generate a stage 1 Alignment fault.
    
        0b1 All memory accesses by A32 and T32 Load Multiple and Store
            Multiple at EL1 or EL0 that are marked at stage 1 as
            Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped.
    
      This bit is permitted to be cached in a TLB.
    
      This field resets to 1.
    
      Otherwise:
    
      Reserved, RES1
    
    So as effect we start getting traps we are not quite ready for.
    
    Looking into history it seems that mask used for SCTLR clear came from
    the similar code for ARMv4, where bit[3] is the enable/disable bit for
    the write buffer. That not applicable to ARMv7 and onwards, so retire
    that bit from the masks.
    
    Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format")
    Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3467365c7f9acc1fe190e0c0fb781aaf58441038
Author: Takeshi Saito <takeshi.saito.xv@renesas.com>
Date:   Wed Dec 16 19:29:31 2020 +0900

    mmc: renesas_sdhi_internal_dmac: Fix DMA buffer alignment from 8 to 128-bytes
    
    [ Upstream commit d7aefb2887601cf1fc3f86f55d43b2c9aece5e8f ]
    
    According to the latest datasheet, the internal DMAC buffer alignment
    R-Car Gen3 SDHI HW should be 128-bytes. So, fix it.
    
    Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
    [shimoda: revise commit description, rebase]
    Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/1608114572-1892-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa1c3e15b6a9ddd6fb83d8f35e973ec45f8037b0
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Dec 17 22:09:22 2020 +0100

    mmc: usdhi6rol0: Fix a resource leak in the error handling path of the probe
    
    [ Upstream commit 6052b3c370fb82dec28bcfff6d7ec0da84ac087a ]
    
    A call to 'ausdhi6_dma_release()' to undo a previous call to
    'usdhi6_dma_request()' is missing in the error handling path of the probe
    function.
    
    It is already present in the remove function.
    
    Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/20201217210922.165340-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 862bfa44c6c53b3a48d7907743bcfa96ad6b5ee2
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Jan 20 07:49:13 2021 +0000

    powerpc/47x: Disable 256k page size
    
    [ Upstream commit 910a0cb6d259736a0c86e795d4c2f42af8d0d775 ]
    
    PPC47x_TLBE_SIZE isn't defined for 256k pages, leading to a build
    break if 256k pages is selected.
    
    So change the kconfig so that 256k pages can't be selected for 47x.
    
    Fixes: e7f75ad01d59 ("powerpc/47x: Base ppc476 support")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Expand change log to mention build break]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/2fed79b1154c872194f98bac4422c23918325e61.1611128938.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fda4b70c02fcab42135d1875dfc35a04517d9d27
Author: Cédric Le Goater <clg@kaod.org>
Date:   Mon Jan 4 15:32:01 2021 +0100

    KVM: PPC: Make the VMX instruction emulation routines static
    
    [ Upstream commit 9236f57a9e51c72ce426ccd2e53e123de7196a0f ]
    
    These are only used locally. It fixes these W=1 compile errors :
    
    ../arch/powerpc/kvm/powerpc.c:1521:5: error: no previous prototype for ‘kvmppc_get_vmx_dword’ [-Werror=missing-prototypes]
     1521 | int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int index, u64 *val)
          |     ^~~~~~~~~~~~~~~~~~~~
    ../arch/powerpc/kvm/powerpc.c:1539:5: error: no previous prototype for ‘kvmppc_get_vmx_word’ [-Werror=missing-prototypes]
     1539 | int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, u64 *val)
          |     ^~~~~~~~~~~~~~~~~~~
    ../arch/powerpc/kvm/powerpc.c:1557:5: error: no previous prototype for ‘kvmppc_get_vmx_hword’ [-Werror=missing-prototypes]
     1557 | int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int index, u64 *val)
          |     ^~~~~~~~~~~~~~~~~~~~
    ../arch/powerpc/kvm/powerpc.c:1575:5: error: no previous prototype for ‘kvmppc_get_vmx_byte’ [-Werror=missing-prototypes]
     1575 | int kvmppc_get_vmx_byte(struct kvm_vcpu *vcpu, int index, u64 *val)
          |     ^~~~~~~~~~~~~~~~~~~
    
    Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction mmio emulation with analyse_instr() input")
    Signed-off-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210104143206.695198-19-clg@kaod.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c22944505cb0f056e5ed74a5468966a8267ab496
Author: Shay Drory <shayd@nvidia.com>
Date:   Mon Jan 25 14:13:39 2021 +0200

    IB/umad: Return EPOLLERR in case of when device disassociated
    
    [ Upstream commit def4cd43f522253645b72c97181399c241b54536 ]
    
    Currently, polling a umad device will always works, even if the device was
    disassociated. A disassociated device should immediately return EPOLLERR
    from poll(). Otherwise userspace is endlessly hung on poll() with no idea
    that the device has been removed from the system.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://lore.kernel.org/r/20210125121339.837518-3-leon@kernel.org
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16d7084da27efa34b95a67419bba6c5f51e09596
Author: Shay Drory <shayd@nvidia.com>
Date:   Mon Jan 25 14:13:38 2021 +0200

    IB/umad: Return EIO in case of when device disassociated
    
    [ Upstream commit 4fc5461823c9cad547a9bdfbf17d13f0da0d6bb5 ]
    
    MAD message received by the user has EINVAL error in all flows
    including when the device is disassociated. That makes it impossible
    for the applications to treat such flow differently.
    
    Change it to return EIO, so the applications will be able to perform
    disassociation recovery.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://lore.kernel.org/r/20210125121339.837518-2-leon@kernel.org
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 208c697db98bd1394cb02f25dc092217456ac882
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Jan 22 16:39:40 2021 +0100

    auxdisplay: ht16k33: Fix refresh rate handling
    
    [ Upstream commit e89b0a426721a8ca5971bc8d70aa5ea35c020f90 ]
    
    Drop the call to msecs_to_jiffies(), as "HZ / fbdev->refresh_rate" is
    already the number of jiffies to wait.
    
    Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e51a6f8cf9c2a6e8e7b321a7fbccf6108b9e50c
Author: Pan Bian <bianpan2016@163.com>
Date:   Mon Jan 18 04:04:55 2021 -0800

    isofs: release buffer head before return
    
    [ Upstream commit 0a6dc67a6aa45f19bd4ff89b4f468fc50c4b8daa ]
    
    Release the buffer_head before returning error code in
    do_isofs_readdir() and isofs_find_entry().
    
    Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading corrupted filesystem")
    Link: https://lore.kernel.org/r/20210118120455.118955-1-bianpan2016@163.com
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b824250842db53048e09f971991a8aad463753b0
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Jan 21 16:59:14 2021 +0100

    regulator: s5m8767: Drop regulators OF node reference
    
    [ Upstream commit a5872bd3398d0ff2ce4c77794bc7837899c69024 ]
    
    The device node reference obtained with of_get_child_by_name() should be
    dropped on error paths.
    
    Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20210121155914.48034-1-krzk@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 865432a6e63ca1a7ce858cc73963e1a9c675c446
Author: Pan Bian <bianpan2016@163.com>
Date:   Tue Jan 19 21:00:25 2021 -0800

    spi: atmel: Put allocated master before return
    
    [ Upstream commit 21ea2743f015dbacec1831bdc8afc848db9c2b8c ]
    
    The allocated master is not released. Goto error handling label rather
    than directly return.
    
    Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring")
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20210120050025.25426-1-bianpan2016@163.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9cf7b6615f46bc66b0afa3eedd480b85be1a256d
Author: David Howells <dhowells@redhat.com>
Date:   Fri Nov 20 19:04:23 2020 +0100

    certs: Fix blacklist flag type confusion
    
    [ Upstream commit 4993e1f9479a4161fd7d93e2b8b30b438f00cb0f ]
    
    KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(),
    as these only take KEY_ALLOC_* flags.  KEY_FLAG_KEEP has the same value as
    KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only key_create_or_update()
    uses it.  LSMs using the key_alloc hook don't check that flag.
    
    KEY_FLAG_KEEP is then ignored but fortunately (again) the root user cannot
    write to the blacklist keyring, so it is not possible to remove a key/hash
    from it.
    
    Fix this by adding a KEY_ALLOC_SET_KEEP flag that tells key_alloc() to set
    KEY_FLAG_KEEP on the new key.  blacklist_init() can then, correctly, pass
    this to keyring_alloc().
    
    We can also use this in ima_mok_init() rather than setting the flag
    manually.
    
    Note that this doesn't fix an observable bug with the current
    implementation but it is required to allow addition of new hashes to the
    blacklist in the future without making it possible for them to be removed.
    
    Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
    Reported-by: Mickaël Salaün <mic@linux.microsoft.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Mickaël Salaün <mic@linux.microsoft.com>
    cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee399e0859211c9b0e98cda5aa6455e222a7f839
Author: Pan Bian <bianpan2016@163.com>
Date:   Wed Jan 20 04:33:13 2021 -0800

    regulator: axp20x: Fix reference cout leak
    
    [ Upstream commit e78bf6be7edaacb39778f3a89416caddfc6c6d70 ]
    
    Decrements the reference count of device node and its child node.
    
    Fixes: dfe7a1b058bb ("regulator: AXP20x: Add support for regulators subsystem")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Link: https://lore.kernel.org/r/20210120123313.107640-1-bianpan2016@163.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit accd39fc0f31ae5644b6808f49ee929a395ecf7f
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Mon Jan 18 00:09:12 2021 +0000

    clk: sunxi-ng: h6: Fix clock divider range on some clocks
    
    [ Upstream commit 04ef679591c76571a9e7d5ca48316cc86fa0ef12 ]
    
    While comparing clocks between the H6 and H616, some of the M factor
    ranges were found to be wrong: the manual says they are only covering
    two bits [1:0], but our code had "5" in the number-of-bits field.
    
    By writing 0xff into that register in U-Boot and via FEL, it could be
    confirmed that bits [4:2] are indeed masked off, so the manual is right.
    
    Change to number of bits in the affected clock's description.
    
    Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210118000912.28116-1-andre.przywara@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b56ef459c9f585e472630f7433f87fe534771437
Author: Yishai Hadas <yishaih@nvidia.com>
Date:   Wed Dec 30 15:01:19 2020 +0200

    RDMA/mlx5: Use the correct obj_id upon DEVX TIR creation
    
    [ Upstream commit 8798e4ad0abe0ba1221928a46561981c510be0c6 ]
    
    Use the correct obj_id upon DEVX TIR creation by strictly taking the tirn
    24 bits and not the general obj_id which is 32 bits.
    
    Fixes: 7efce3691d33 ("IB/mlx5: Add obj create and destroy functionality")
    Link: https://lore.kernel.org/r/20201230130121.180350-2-leon@kernel.org
    Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ac171abc715e45c09232391bac1f1cca443c6a5
Author: Tom Rix <trix@redhat.com>
Date:   Mon Jan 18 13:19:55 2021 -0800

    clocksource/drivers/mxs_timer: Add missing semicolon when DEBUG is defined
    
    [ Upstream commit 7da390694afbaed8e0f05717a541dfaf1077ba51 ]
    
    When DEBUG is defined this error occurs
    
    drivers/clocksource/mxs_timer.c:138:1: error:
      expected ‘;’ before ‘}’ token
    
    The preceding statement needs a semicolon.
    Replace pr_info() with pr_debug() and remove the unneeded ifdef.
    
    Fixes: eb8703e2ef7c ("clockevents/drivers/mxs: Migrate to new 'set-state' interface")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20210118211955.763609-1-trix@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3bba17f53a18a5d07cb900f313bc3b0cd5c7483
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Thu Jan 14 11:22:17 2021 +0100

    rtc: s5m: select REGMAP_I2C
    
    [ Upstream commit 1f0cbda3b452b520c5f3794f8f0e410e8bc7386a ]
    
    The rtc-s5m uses the I2C regmap but doesn't select it in Kconfig so
    depending on the configuration the build may fail. Fix it.
    
    Fixes: 959df7778bbd ("rtc: Enable compile testing for Maxim and Samsung drivers")
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20210114102219.23682-2-brgl@bgdev.pl
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44bacbd7bf05309b5395c48df5c32986e5921811
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Dec 16 14:57:31 2020 +0200

    power: reset: at91-sama5d2_shdwc: fix wkupdbc mask
    
    [ Upstream commit 95aa21a3f1183260db1b0395e03df5bebc5ed641 ]
    
    According to datasheet WKUPDBC mask is b/w bits 26..24.
    
    Fixes: f80cb48843987 ("power: reset: at91-shdwc: add new shutdown controller driver")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74f2678aab60c9915daa83e6e23d31a896932d9d
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Fri Jan 15 11:45:44 2021 +0000

    of/fdt: Make sure no-map does not remove already reserved regions
    
    [ Upstream commit 8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ]
    
    If the device tree is incorrectly configured, and attempts to
    define a "no-map" reserved memory that overlaps with the kernel
    data/code, the kernel would crash quickly after boot, with no
    obvious clue about the nature of the issue.
    
    For example, this would happen if we have the kernel mapped at
    these addresses (from /proc/iomem):
    40000000-41ffffff : System RAM
      40080000-40dfffff : Kernel code
      40e00000-411fffff : reserved
      41200000-413e0fff : Kernel data
    
    And we declare a no-map shared-dma-pool region at a fixed address
    within that range:
    mem_reserved: mem_region {
            compatible = "shared-dma-pool";
            reg = <0 0x40000000 0 0x01A00000>;
            no-map;
    };
    
    To fix this, when removing memory regions at early boot (which is
    what "no-map" regions do), we need to make sure that the memory
    is not already reserved. If we do, __reserved_mem_reserve_reg
    will throw an error:
    [    0.000000] OF: fdt: Reserved memory: failed to reserve memory
       for node 'mem_region': base 0x0000000040000000, size 26 MiB
    and the code that will try to use the region should also fail,
    later on.
    
    We do not do anything for non-"no-map" regions, as memblock
    explicitly allows reserved regions to overlap, and the commit
    that this fixes removed the check for that precise reason.
    
    [ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ]
    
    Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Quentin Perret <qperret@google.com>
    Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03972d6b1bbac1620455589e0367f6f69ff7b2df
Author: KarimAllah Ahmed <karahmed@amazon.de>
Date:   Fri Jan 15 11:45:43 2021 +0000

    fdt: Properly handle "no-map" field in the memory region
    
    [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]
    
    Mark the memory region with NOMAP flag instead of completely removing it
    from the memory blocks. That makes the FDT handling consistent with the EFI
    memory map handling.
    
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Frank Rowand <frowand.list@gmail.com>
    Cc: devicetree@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
    Signed-off-by: Quentin Perret <qperret@google.com>
    Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7f077672d16a0b5a40377df17a60ce0f28021b6
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Jan 12 18:00:56 2021 +0900

    mfd: bd9571mwv: Use devm_mfd_add_devices()
    
    [ Upstream commit c58ad0f2b052b5675d6394e03713ee41e721b44c ]
    
    To remove mfd devices when unload this driver, should use
    devm_mfd_add_devices() instead.
    
    Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d97e4771e14e5b80d15640a7f63e4a44059e92f7
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Tue Jan 12 23:37:49 2021 +0100

    dmaengine: hsu: disable spurious interrupt
    
    [ Upstream commit 035b73b2b3b2e074a56489a7bf84b6a8012c0e0d ]
    
    On Intel Tangier B0 and Anniedale the interrupt line, disregarding
    to have different numbers, is shared between HSU DMA and UART IPs.
    Thus on such SoCs we are expecting that IRQ handler is called in
    UART driver only. hsu_pci_irq was handling the spurious interrupt
    from HSU DMA by returning immediately. This wastes CPU time and
    since HSU DMA and HSU UART interrupt occur simultaneously they race
    to be handled causing delay to the HSU UART interrupt handling.
    Fix this by disabling the interrupt entirely.
    
    Fixes: 4831e0d9054c ("serial: 8250_mid: handle interrupt correctly in DMA case")
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210112223749.97036-1-ftoth@exalondelft.nl
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9a6d68eed8fcc91c637b4f6026922636b7728f9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 17:25:35 2020 +0100

    dmaengine: owl-dma: Fix a resource leak in the remove function
    
    [ Upstream commit 1f0a16f04113f9f0ab0c8e6d3abe661edab549e6 ]
    
    A 'dma_pool_destroy()' call is missing in the remove function.
    Add it.
    
    This call is already made in the error handling path of the probe function.
    
    Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/20201212162535.95727-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdaafae0fcd958832dd1f114ce58466fdcd49264
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 17:06:14 2020 +0100

    dmaengine: fsldma: Fix a resource leak in an error handling path of the probe function
    
    [ Upstream commit b202d4e82531a62a33a6b14d321dd2aad491578e ]
    
    In case of error, the previous 'fsl_dma_chan_probe()' calls must be undone
    by some 'fsl_dma_chan_remove()', as already done in the remove function.
    
    It was added in the remove function in commit 77cd62e8082b ("fsldma: allow
    Freescale Elo DMA driver to be compiled as a module")
    
    Fixes: d3f620b2c4fe ("fsldma: simplify IRQ probing and handling")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/20201212160614.92576-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2efd906656cbf6ddde4e87648a63b2eb4cd09ba
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 17:05:16 2020 +0100

    dmaengine: fsldma: Fix a resource leak in the remove function
    
    [ Upstream commit cbc0ad004c03ad7971726a5db3ec84dba3dcb857 ]
    
    A 'irq_dispose_mapping()' call is missing in the remove function.
    Add it.
    
    This is needed to undo the 'irq_of_parse_and_map() call from the probe
    function and already part of the error handling path of the probe function.
    
    It was added in the probe function only in commit d3f620b2c4fe ("fsldma:
    simplify IRQ probing and handling")
    
    Fixes: 77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as a module")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/20201212160516.92515-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 968b95996da83c206e5d12d8e57116197d1be6a6
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Dec 16 17:12:21 2020 -0800

    HID: core: detect and skip invalid inputs to snto32()
    
    [ Upstream commit a0312af1f94d13800e63a7d0a66e563582e39aec ]
    
    Prevent invalid (0, 0) inputs to hid-core's snto32() function.
    
    Maybe it is just the dummy device here that is causing this, but
    there are hundreds of calls to snto32(0, 0). Having n (bits count)
    of 0 is causing the current UBSAN trap with a shift value of
    0xffffffff (-1, or n - 1 in this function).
    
    Either of the value to shift being 0 or the bits count being 0 can be
    handled by just returning 0 to the caller, avoiding the following
    complex shift + OR operations:
    
            return value & (1 << (n - 1)) ? value | (~0U << n) : value;
    
    Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: syzbot+1e911ad71dd4ea72e04a@syzkaller.appspotmail.com
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Cc: linux-input@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cc86838e0d9eeb945915ca6da5448f3fa044695
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Wed Jan 6 14:32:46 2021 +0000

    clk: sunxi-ng: h6: Fix CEC clock
    
    [ Upstream commit 756650820abd4770c4200763505b634a3c04e05e ]
    
    The CEC clock on the H6 SoC is a bit special, since it uses a fixed
    pre-dividier for one source clock (the PLL), but conveys the other clock
    (32K OSC) directly.
    We are using a fixed predivider array for that, but fail to use the right
    flag to actually activate that.
    
    Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU")
    Reported-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210106143246.11255-1-andre.przywara@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3fbf7d82124fd7d39e3ca5ebb93909f65c96bbfd
Author: Pratyush Yadav <p.yadav@ti.com>
Date:   Wed Dec 23 00:14:20 2020 +0530

    spi: cadence-quadspi: Abort read if dummy cycles required are too many
    
    [ Upstream commit ceeda328edeeeeac7579e9dbf0610785a3b83d39 ]
    
    The controller can only support up to 31 dummy cycles. If the command
    requires more it falls back to using 31. This command is likely to fail
    because the correct number of cycles are not waited upon. Rather than
    silently issuing an incorrect command, fail loudly so the caller can get
    a chance to find out the command can't be supported by the controller.
    
    Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
    Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
    Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96826c805ae7190082af58d2c609cafe88e41f2d
Author: Jan Kara <jack@suse.cz>
Date:   Tue Dec 22 12:09:53 2020 +0100

    quota: Fix memory leak when handling corrupted quota file
    
    [ Upstream commit a4db1072e1a3bd7a8d9c356e1902b13ac5deb8ef ]
    
    When checking corrupted quota file we can bail out and leak allocated
    info structure. Properly free info structure on error return.
    
    Reported-by: syzbot+77779c9b52ab78154b08@syzkaller.appspotmail.com
    Fixes: 11c514a99bb9 ("quota: Sanity-check quota file headers on load")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a59c98efaff421a48cdac59394b829911e5731b3
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Dec 26 13:15:54 2020 +0100

    clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL
    
    [ Upstream commit 2f290b7c67adf6459a17a4c978102af35cd62e4a ]
    
    The "rate" parameter in meson_clk_pll_set_rate() contains the new rate.
    Retrieve the old rate with clk_hw_get_rate() so we don't inifinitely try
    to switch from the new rate to the same rate again.
    
    Fixes: 7a29a869434e8b ("clk: meson: Add support for Meson clock controller")
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20201226121556.975418-2-martin.blumenstingl@googlemail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9060e01f5c9c30813696a5f76f521c3b040c4e07
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 17 09:42:00 2020 -0600

    capabilities: Don't allow writing ambiguous v3 file capabilities
    
    [ Upstream commit 95ebabde382c371572297915b104e55403674e73 ]
    
    The v3 file capabilities have a uid field that records the filesystem
    uid of the root user of the user namespace the file capabilities are
    valid in.
    
    When someone is silly enough to have the same underlying uid as the
    root uid of multiple nested containers a v3 filesystem capability can
    be ambiguous.
    
    In the spirit of don't do that then, forbid writing a v3 filesystem
    capability if it is ambiguous.
    
    Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
    Reviewed-by: Andrew G. Morgan <morgan@kernel.org>
    Reviewed-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4c07aaafcb56ff62aef2028e7562525ddde1358
Author: Tom Rix <trix@redhat.com>
Date:   Wed Dec 30 06:56:04 2020 -0800

    jffs2: fix use after free in jffs2_sum_write_data()
    
    [ Upstream commit 19646447ad3a680d2ab08c097585b7d96a66126b ]
    
    clang static analysis reports this problem
    
    fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed
                    c->summary->sum_list_head = temp->u.next;
                                                ^~~~~~~~~~~~
    
    In jffs2_sum_write_data(), in a loop summary data is handles a node at
    a time.  When it has written out the node it is removed the summary list,
    and the node is deleted.  In the corner case when a
    JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to
    jffs2_sum_disable_collecting().  jffs2_sum_disable_collecting() deletes
    the whole list which conflicts with the loop's deleting the list by parts.
    
    To preserve the old behavior of stopping the write midway, bail out of
    the loop after disabling summary collection.
    
    Fixes: 6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98a5971b9421fdaab5fbb9d547f94f31b59353d1
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Feb 11 13:01:08 2021 +0000

    fs/jfs: fix potential integer overflow on shift of a int
    
    [ Upstream commit 4208c398aae4c2290864ba15c3dab7111f32bec1 ]
    
    The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
    arithmetic and then assigned to a signed 64 bit integer. In the case where
    l2nb is 32 or more this can lead to an overflow.  Avoid this by shifting
    the value 1LL instead.
    
    Addresses-Coverity: ("Uninitentional integer overflow")
    Fixes: b40c2e665cd5 ("fs/jfs: TRIM support for JFS Filesystem")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14145d3ad8841ee5c0621f923e14ef877c160c7b
Author: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Date:   Thu Feb 4 09:49:51 2021 -0800

    ima: Free IMA measurement buffer after kexec syscall
    
    [ Upstream commit f31e3386a4e92ba6eda7328cb508462956c94c64 ]
    
    IMA allocates kernel virtual memory to carry forward the measurement
    list, from the current kernel to the next kernel on kexec system call,
    in ima_add_kexec_buffer() function.  This buffer is not freed before
    completing the kexec system call resulting in memory leak.
    
    Add ima_buffer field in "struct kimage" to store the virtual address
    of the buffer allocated for the IMA measurement list.
    Free the memory allocated for the IMA measurement list in
    kimage_file_post_load_cleanup() function.
    
    Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
    Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
    Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
    Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
    Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3911ee3ddf944dbf0cf2894ee701cad61b609697
Author: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Date:   Thu Feb 4 09:49:50 2021 -0800

    ima: Free IMA measurement buffer on error
    
    [ Upstream commit 6d14c6517885fa68524238787420511b87d671df ]
    
    IMA allocates kernel virtual memory to carry forward the measurement
    list, from the current kernel to the next kernel on kexec system call,
    in ima_add_kexec_buffer() function.  In error code paths this memory
    is not freed resulting in memory leak.
    
    Free the memory allocated for the IMA measurement list in
    the error code paths in ima_add_kexec_buffer() function.
    
    Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
    Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
    Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d143897232cf30cdd1f4af3dc471959bbc274c0
Author: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Date:   Wed Feb 3 11:28:37 2021 +0000

    crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key()
    
    [ Upstream commit a53ab94eb6850c3657392e2d2ce9b38c387a2633 ]
    
    The length ('len' parameter) passed to crypto_ecdh_decode_key() is never
    checked against the length encoded in the passed buffer ('buf'
    parameter). This could lead to an out-of-bounds access when the passed
    length is less than the encoded length.
    
    Add a check to prevent that.
    
    Fixes: 3c4b23901a0c7 ("crypto: ecdh - Add ECDH software support")
    Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41b9ed365456ee8dcc33758fa3bd40dcb73b25df
Author: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
Date:   Mon Feb 1 16:14:59 2021 +0100

    hwrng: timeriomem - Fix cooldown period calculation
    
    [ Upstream commit e145f5565dc48ccaf4cb50b7cfc48777bed8c100 ]
    
    Ensure cooldown period tolerance of 1% is actually accounted for.
    
    Fixes: ca3bff70ab32 ("hwrng: timeriomem - Improve performance...")
    Signed-off-by: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 957a92872a7506b51f310b892f4e95cb46a60034
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Nov 20 09:08:04 2020 +0800

    btrfs: clarify error returns values in __load_free_space_cache
    
    [ Upstream commit 3cc64e7ebfb0d7faaba2438334c43466955a96e8 ]
    
    Return value in __load_free_space_cache is not properly set after
    (unlikely) memory allocation failures and 0 is returned instead.
    This is not a problem for the caller load_free_space_cache because only
    value 1 is considered as 'cache loaded' but for clarity it's better
    to set the errors accordingly.
    
    Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afd88a7b172d32f7ac3108e42fc1510e2b1a1562
Author: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Date:   Wed Dec 9 08:08:25 2020 +0100

    Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind()
    
    [ Upstream commit e3fa4b747f085d2cda09bba0533b86fa76038635 ]
    
    When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could
    invoke put_device(), that will eventually release the device and free
    the channel object (cf. vmbus_device_release()).  However, a pointer
    to the object is dereferenced again later to load the primary_channel.
    The use-after-free can be avoided by noticing that this load/check is
    redundant if device_obj is non-NULL: primary_channel must be NULL if
    device_obj is non-NULL, cf. vmbus_add_channel_work().
    
    Fixes: 54a66265d6754b ("Drivers: hv: vmbus: Fix rescind handling")
    Reported-by: Juan Vazquez <juvazq@microsoft.com>
    Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Link: https://lore.kernel.org/r/20201209070827.29335-5-parri.andrea@gmail.com
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fde5b4f428b62d73162eb7f278e14f835b66f6a2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 2 08:56:36 2021 +0300

    drm/amdgpu: Prevent shift wrapping in amdgpu_read_mask()
    
    [ Upstream commit c915ef890d5dc79f483e1ca3b3a5b5f1a170690c ]
    
    If the user passes a "level" value which is higher than 31 then that
    leads to shift wrapping.  The undefined behavior will lead to a
    syzkaller stack dump.
    
    Fixes: 5632708f4452 ("drm/amd/powerplay: add dpm force multiple levels on cz/tonga/fiji/polaris (v2)")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f61aa8c4c0ac366a7f4f2f0099ed61fa9dc3f29
Author: Yi Chen <chenyi77@huawei.com>
Date:   Thu Jan 28 17:02:56 2021 +0800

    f2fs: fix to avoid inconsistent quota data
    
    [ Upstream commit 25fb04dbce6a0e165d28fd1fa8a1d7018c637fe8 ]
    
    Occasionally, quota data may be corrupted detected by fsck:
    
    Info: checkpoint state = 45 :  crc compacted_summary unmount
    [QUOTA WARNING] Usage inconsistent for ID 0:actual (1543036928, 762) != expected (1543032832, 762)
    [ASSERT] (fsck_chk_quota_files:1986)  --> Quota file is missing or invalid quota file content found.
    [QUOTA WARNING] Usage inconsistent for ID 0:actual (1352478720, 344) != expected (1352474624, 344)
    [ASSERT] (fsck_chk_quota_files:1986)  --> Quota file is missing or invalid quota file content found.
    
    [FSCK] Unreachable nat entries                        [Ok..] [0x0]
    [FSCK] SIT valid block bitmap checking                [Ok..]
    [FSCK] Hard link checking for regular file            [Ok..] [0x0]
    [FSCK] valid_block_count matching with CP             [Ok..] [0xdf299]
    [FSCK] valid_node_count matcing with CP (de lookup)   [Ok..] [0x2b01]
    [FSCK] valid_node_count matcing with CP (nat lookup)  [Ok..] [0x2b01]
    [FSCK] valid_inode_count matched with CP              [Ok..] [0x2665]
    [FSCK] free segment_count matched with CP             [Ok..] [0xcb04]
    [FSCK] next block offset is free                      [Ok..]
    [FSCK] fixing SIT types
    [FSCK] other corrupted bugs                           [Fail]
    
    The root cause is:
    If we open file w/ readonly flag, disk quota info won't be initialized
    for this file, however, following mmap() will force to convert inline
    inode via f2fs_convert_inline_inode(), which may increase block usage
    for this inode w/o updating quota data, it causes inconsistent disk quota
    info.
    
    The issue will happen in following stack:
    open(file, O_RDONLY)
    mmap(file)
    - f2fs_convert_inline_inode
     - f2fs_convert_inline_page
      - f2fs_reserve_block
       - f2fs_reserve_new_block
        - f2fs_reserve_new_blocks
         - f2fs_i_blocks_write
          - dquot_claim_block
    inode->i_blocks increase, but the dqb_curspace keep the size for the dquots
    is NULL.
    
    To fix this issue, let's call dquot_initialize() anyway in both
    f2fs_truncate() and f2fs_convert_inline_inode() functions to avoid potential
    inconsistent quota data issue.
    
    Fixes: 0abd675e97e6 ("f2fs: support plain user/group quota")
    Signed-off-by: Daiyue Zhang <zhangdaiyue1@huawei.com>
    Signed-off-by: Dehe Gu <gudehe@huawei.com>
    Signed-off-by: Junchao Jiang <jiangjunchao1@huawei.com>
    Signed-off-by: Ge Qiu <qiuge@huawei.com>
    Signed-off-by: Yi Chen <chenyi77@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c42012fd50c91e99dfd9128454f153811bcdb95
Author: Sebastian Reichel <sre@kernel.org>
Date:   Sat Jan 23 18:29:45 2021 +0100

    ASoC: cpcap: fix microphone timeslot mask
    
    [ Upstream commit de5bfae2fd962a9da99f56382305ec7966a604b9 ]
    
    The correct mask is 0x1f8 (Bit 3-8), but due to missing BIT() 0xf (Bit
    0-3) was set instead. This means setting of CPCAP_BIT_MIC1_RX_TIMESLOT0
    (Bit 3) still worked (part of both masks). On the other hand the code
    does not properly clear the other MIC timeslot bits. I think this
    is not a problem, since they are probably initialized to 0 and not
    touched by the driver anywhere else. But the mask also contains some
    wrong bits, that will be cleared. Bit 0 (CPCAP_BIT_SMB_CDC) should be
    safe, since the driver enforces it to be 0 anyways.
    
    Bit 1-2 are CPCAP_BIT_FS_INV and CPCAP_BIT_CLK_INV. This means enabling
    audio recording forces the codec into SND_SOC_DAIFMT_NB_NF mode, which
    is obviously bad.
    
    The bug probably remained undetected, because there are not many use
    cases for routing microphone to the CPU on platforms using cpcap and
    user base is small. I do remember having some issues with bad sound
    quality when testing voice recording back when I wrote the driver.
    It probably was this bug.
    
    Fixes: f6cdf2d3445d ("ASoC: cpcap: new codec")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210123172945.3958622-1-sre@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 274b959307bd393c771f4bcc62262a5b5fa25032
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Fri Jan 29 10:28:45 2021 -0800

    ata: ahci_brcm: Add back regulators management
    
    [ Upstream commit 10340f8d7b6dd54e616339c8ccb2f397133ebea0 ]
    
    While reworking the resources management and departing from using
    ahci_platform_enable_resources() which did not allow a proper step
    separation like we need, we unfortunately lost the ability to control
    AHCI regulators. This broke some Broadcom STB systems that do expect
    regulators to be turned on to link up with attached hard drives.
    
    Fixes: c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed21a9e6a79f6bc5ec2c9107c9050c6f746e1af6
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Jan 20 18:57:24 2021 +0000

    crypto: talitos - Work around SEC6 ERRATA (AES-CTR mode data size error)
    
    [ Upstream commit 416b846757bcea20006a9197e67ba3a8b5b2a680 ]
    
    Talitos Security Engine AESU considers any input
    data size that is not a multiple of 16 bytes to be an error.
    This is not a problem in general, except for Counter mode
    that is a stream cipher and can have an input of any size.
    
    Test Manager for ctr(aes) fails on 4th test vector which has
    a length of 499 while all previous vectors which have a 16 bytes
    multiple length succeed.
    
    As suggested by Freescale, round up the input data length to the
    nearest 16 bytes.
    
    Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 782f3140c1d3c2fdef87138bce1cee682c780508
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Sun Dec 20 15:11:13 2020 +0100

    media: uvcvideo: Accept invalid bFormatIndex and bFrameIndex values
    
    [ Upstream commit dc9455ffae02d7b7fb51ba1e007fffcb9dc5d890 ]
    
    The Renkforce RF AC4K 300 Action Cam 4K reports invalid bFormatIndex and
    bFrameIndex values when negotiating the video probe and commit controls.
    The UVC descriptors report a single supported format and frame size,
    with bFormatIndex and bFrameIndex both equal to 2, but the video probe
    and commit controls report bFormatIndex and bFrameIndex set to 1.
    
    The device otherwise operates correctly, but the driver rejects the
    values and fails the format try operation. Fix it by ignoring the
    invalid indices, and assuming that the format and frame requested by the
    driver are accepted by the device.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=210767
    
    Fixes: 8a652a17e3c0 ("media: uvcvideo: Ensure all probed info is returned to v4l2")
    Reported-by: Till Dörges <doerges@pre-sense.de>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71a33c8a4ee2a759aa6ef68eeab79928bb991b10
Author: Tom Rix <trix@redhat.com>
Date:   Mon Jan 18 14:45:13 2021 +0100

    media: pxa_camera: declare variable when DEBUG is defined
    
    [ Upstream commit 031b9212eeee365443aaef013360ea6cded7b2c4 ]
    
    When DEBUG is defined this error occurs
    
    drivers/media/platform/pxa_camera.c:1410:7: error:
      ‘i’ undeclared (first use in this function)
      for (i = 0; i < vb->num_planes; i++)
           ^
    The variable 'i' is missing, so declare it.
    
    Fixes: 6f28435d1c15 ("[media] media: platform: pxa_camera: trivial move of functions")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4688f00f5e04089aa79a7ffaae7d2a350b00afa4
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jan 16 22:21:46 2021 +0100

    media: cx25821: Fix a bug when reallocating some dma memory
    
    [ Upstream commit b2de3643c5024fc4fd128ba7767c7fb8b714bea7 ]
    
    This function looks like a realloc.
    
    However, if 'risc->cpu != NULL', the memory will be freed, but never
    reallocated with the bigger 'size'.
    Explicitly set 'risc->cpu' to NULL, so that the reallocation is
    correctly performed a few lines below.
    
    [hverkuil: NULL != risc->cpu -> risc->cpu]
    
    Fixes: 5ede94c70553 ("[media] cx25821: remove bogus btcx_risc dependency)
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4c159be8b8c155ba8a86320a60d4840f7b84742
Author: Luo Meng <luomeng12@huawei.com>
Date:   Wed Nov 25 02:34:37 2020 +0100

    media: qm1d1c0042: fix error return code in qm1d1c0042_init()
    
    [ Upstream commit fcf8d018bdca0453b8d6359062e6bc1512d04c38 ]
    
    Fix to return a negative error code from the error handling case
    instead of 0 in function qm1d1c0042_init(), as done elsewhere
    in this function.
    
    Fixes: ab4d14528fdf ("[media] em28xx: add support for PLEX PX-BCUD (ISDB-S)")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Acked-by: Akihiro Tsukada <tskd08@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73bce30e79b1fe58fd9eec3062ebd71c52cf532a
Author: Joe Perches <joe@perches.com>
Date:   Sun Aug 23 20:13:31 2020 +0200

    media: lmedm04: Fix misuse of comma
    
    [ Upstream commit 59a3e78f8cc33901fe39035c1ab681374bba95ad ]
    
    There's a comma used instead of a semicolon that causes multiple
    statements to be executed after an if instead of just the intended
    single statement.
    
    Replace the comma with a semicolon.
    
    Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb")
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6b4fb922cbd78977fc9f1c40f97d7356289e656
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Thu Jan 21 07:17:02 2021 +0100

    drm/amd/display: Fix 10/12 bpc setup in DCE output bit depth reduction.
    
    [ Upstream commit 1916866dfa4aaceba1a70db83fde569387649d93 ]
    
    In set_clamp(), the comments and definitions for the COLOR_DEPTH_101010
    and COLOR_DEPTH_121212 cases directly contradict the code comment which
    explains how this should work, whereas the COLOR_DEPTH_888 case
    is consistent with the code comments. Comment says the bitmask should
    be chosen to align to the top-most 10 or 12 MSB's on a 14 bit bus, but
    the implementation contradicts that: 10 bit case sets a mask for 12 bpc
    clamping, whereas 12 bit case sets a mask for 14 bpc clamping.
    
    Note that during my limited testing on DCE-8.3 (HDMI deep color)
    and DCE-11.2 (DP deep color), this didn't have any obvious ill
    effects, neither did fixing it change anything obvious for the
    better, so this fix may be inconsequential on DCE, and just
    reduce the confusion of innocent bystanders when reading the code
    and trying to investigate problems with 10 bpc+ output.
    
    Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
    
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 283a70f3ed26107093c919cd91950c4ba633de07
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Jan 5 00:02:37 2021 +0100

    crypto: bcm - Rename struct device_private to bcm_device_private
    
    [ Upstream commit f7f2b43eaf6b4cfe54c75100709be31d5c4b52c8 ]
    
    Renaming 'struct device_private' to 'struct bcm_device_private',
    because it clashes with 'struct device_private' from
    'drivers/base/base.h'.
    
    While it's not a functional problem, it's causing two distinct
    type hierarchies in BTF data. It also breaks build with options:
      CONFIG_DEBUG_INFO_BTF=y
      CONFIG_CRYPTO_DEV_BCM_SPU=y
    
    as reported by Qais Yousef [1].
    
    [1] https://lore.kernel.org/lkml/20201229151352.6hzmjvu3qh6p2qgg@e107158-lin/
    
    Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Qais Yousef <qais.yousef@arm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e92cbbfabe65ca8f6476a6c8483c197e88bdaf2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 11 13:07:59 2020 +0300

    ASoC: cs42l56: fix up error handling in probe
    
    [ Upstream commit 856fe64da84c95a1d415564b981ae3908eea2a76 ]
    
    There are two issues with this code.  The first error path forgot to set
    the error code and instead returns success.  The second error path
    doesn't clean up.
    
    Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X9NE/9nK9/TuxuL+@mwanda
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abd1df54afe9e8853c8146d17e1a5e046f815113
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sat Jan 2 09:26:37 2021 +0100

    media: tm6000: Fix memleak in tm6000_start_stream
    
    [ Upstream commit 76aaf8a96771c16365b8510f1fb97738dc88026e ]
    
    When usb_clear_halt() fails, dvb->bulk_urb->transfer_buffer
    and dvb->bulk_urb should be freed just like when
    usb_submit_urb() fails.
    
    Fixes: 3169c9b26fffa ("V4L/DVB (12788): tm6000: Add initial DVB-T support")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7565046ba301ce7b6a07b97b79b4e5879436b88b
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sat Jan 2 07:27:22 2021 +0100

    media: media/pci: Fix memleak in empress_init
    
    [ Upstream commit 15d0c52241ecb1c9d802506bff6f5c3f7872c0df ]
    
    When vb2_queue_init() fails, dev->empress_dev
    should be released just like other error handling
    paths.
    
    Fixes: 2ada815fc48bb ("[media] saa7134: convert to vb2")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a451eaf492db63db0484b496cf66ec1486e8c09f
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Dec 28 14:02:05 2020 +0100

    media: em28xx: Fix use-after-free in em28xx_alloc_urbs
    
    [ Upstream commit a26efd1961a18b91ae4cd2e433adbcf865b40fa3 ]
    
    When kzalloc() fails, em28xx_uninit_usb_xfer() will free
    usb_bufs->buf and set it to NULL. Thus the later access
    to usb_bufs->buf[i] will lead to null pointer dereference.
    Also the kfree(usb_bufs->buf) after that is redundant.
    
    Fixes: d571b592c6206 ("media: em28xx: don't use coherent buffer for DMA transfers")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2858242af6e3566ffdaaf960cc57bc3afa3303a
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 18:41:19 2020 +0100

    media: vsp1: Fix an error handling path in the probe function
    
    [ Upstream commit 7113469dafc2d545fa4fa9bc649c31dc27db492e ]
    
    A previous 'rcar_fcp_get()' call must be undone in the error handling path,
    as already done in the remove function.
    
    Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbec8a25755cbfe1f1be9301f413dce07858e750
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Dec 9 07:51:30 2020 +0100

    media: camss: missing error code in msm_video_register()
    
    [ Upstream commit 9c67ed2ab299123872be14a3dc2ea44ce7e4538b ]
    
    This error path returns success but it should return -EINVAL.
    
    Fixes: cba3819d1e93 ("media: camss: Format configuration per hardware version")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea5aaf162acfee98cdb298ef825c173df33e7717
Author: Jacopo Mondi <jacopo@jmondi.org>
Date:   Mon Dec 21 18:52:20 2020 +0100

    media: i2c: ov5670: Fix PIXEL_RATE minimum value
    
    [ Upstream commit dc1eb7c9c290cba52937c9a224b22a400bb0ffd7 ]
    
    The driver currently reports a single supported value for
    V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0,
    which is very risky, as userspace might accidentally use it as divider
    when calculating the time duration of a line.
    
    Fix this by using as minimum the only supported value when registering
    the control.
    
    Fixes: 5de35c9b8dcd1 ("media: i2c: Add Omnivision OV5670 5M sensor support")
    Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef8fc6b741213898d6d5747b8130aa17bad1c498
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 5 13:15:48 2021 -0700

    MIPS: lantiq: Explicitly compare LTQ_EBU_PCC_ISTAT against 0
    
    [ Upstream commit c6f2a9e17b9bef7677caddb1626c2402f3e9d2bd ]
    
    When building xway_defconfig with clang:
    
    arch/mips/lantiq/irq.c:305:48: error: use of logical '&&' with constant
    operand [-Werror,-Wconstant-logical-operand]
            if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
                                                          ^ ~~~~~~~~~~~~~~~~~
    arch/mips/lantiq/irq.c:305:48: note: use '&' for a bitwise operation
            if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
                                                          ^~
                                                          &
    arch/mips/lantiq/irq.c:305:48: note: remove constant to silence this
    warning
            if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
                                                         ~^~~~~~~~~~~~~~~~~~~~
    1 error generated.
    
    Explicitly compare the constant LTQ_EBU_PCC_ISTAT against 0 to fix the
    warning. Additionally, remove the unnecessary parentheses as this is a
    simple conditional statement and shorthand '== 0' to '!'.
    
    Fixes: 3645da0276ae ("OF: MIPS: lantiq: implement irq_domain support")
    Link: https://github.com/ClangBuiltLinux/linux/issues/807
    Reported-by: Dmitry Golovin <dima@golovin.in>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eafd39a83533d601b86566f14f467031c568faeb
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 5 13:34:56 2021 -0700

    MIPS: c-r4k: Fix section mismatch for loongson2_sc_init
    
    [ Upstream commit c58734eee6a2151ba033c0dcb31902c89e310374 ]
    
    When building with clang, the following section mismatch warning occurs:
    
    WARNING: modpost: vmlinux.o(.text+0x24490): Section mismatch in
    reference from the function r4k_cache_init() to the function
    .init.text:loongson2_sc_init()
    
    This should have been fixed with commit ad4fddef5f23 ("mips: fix Section
    mismatch in reference") but it was missed. Remove the improper __init
    annotation like that commit did.
    
    Fixes: 078a55fc824c ("MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code")
    Link: https://github.com/ClangBuiltLinux/linux/issues/787
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84f35d89983f2fc0587ee3a303ab0cc1da3ac9f5
Author: Chenyang Li <lichenyang@loongson.cn>
Date:   Sat Dec 26 16:56:07 2020 +0800

    drm/amdgpu: Fix macro name _AMDGPU_TRACE_H_ in preprocessor if condition
    
    [ Upstream commit 956e20eb0fbb206e5e795539db5469db099715c8 ]
    
    Add an underscore in amdgpu_trace.h line 24 "_AMDGPU_TRACE_H".
    
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Reviewed-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Chenyang Li <lichenyang@loongson.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4df4b9d6a597ed76f035b6b9d6e7351e2812b3e5
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Mon Dec 14 20:02:30 2020 +0000

    crypto: sun4i-ss - fix kmap usage
    
    [ Upstream commit 9bc3dd24e7dccd50757db743a3635ad5b0497e6e ]
    
    With the recent kmap change, some tests which were conditional on
    CONFIG_DEBUG_HIGHMEM now are enabled by default.
    This permit to detect a problem in sun4i-ss usage of kmap.
    
    sun4i-ss uses two kmap via sg_miter (one for input, one for output), but
    using two kmap at the same time is hard:
    "the ordering has to be correct and with sg_miter that's probably hard to get
    right." (quoting Tlgx)
    
    So the easiest solution is to never have two sg_miter/kmap open at the same time.
    After each use of sg_miter, I store the current index, for being able to
    resume sg_miter to the right place.
    
    Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53d73f0757525cfed5785e8ea43fee982f9dfebc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 3 11:40:48 2020 +0300

    gma500: clean up error handling in init
    
    [ Upstream commit 15ccc39b3aab667c6fa131206f01f31bfbccdf6a ]
    
    The main problem with this error handling was that it didn't clean up if
    i2c_add_numbered_adapter() failed.  This code is pretty old, and doesn't
    match with today's checkpatch.pl standards so I took the opportunity to
    tidy it up a bit.  I changed the NULL comparison, and removed the
    WARNING message if kzalloc() fails and updated the label names.
    
    Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/X8ikkAqZfnDO2lu6@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 390453f94637e1bef1cc8901fc74ebda2d5a4c46
Author: Jialin Zhang <zhangjialin11@huawei.com>
Date:   Mon Nov 30 10:02:16 2020 +0800

    drm/gma500: Fix error return code in psb_driver_load()
    
    [ Upstream commit 6926872ae24452d4f2176a3ba2dee659497de2c4 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201130020216.1906141-1-zhangjialin11@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 534d0b5ff436b7b82958f7e53e37f54f233870a8
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu Nov 26 19:17:52 2020 -0800

    fbdev: aty: SPARC64 requires FB_ATY_CT
    
    [ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
    
    It looks like SPARC64 requires FB_ATY_CT to build without errors,
    so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
    instead of using "default y if SPARC64 && PCI", which is not strong
    enough to prevent build errors.
    
    As it currently is, FB_ATY_CT can be disabled, resulting in build
    errors:
    
    ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
    ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
    
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: linux-fbdev@vger.kernel.org
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f646dd928d3c32142fa763c32ca0c293b1567483
Author: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date:   Tue Feb 16 10:25:35 2021 +0100

    net: mvneta: Remove per-cpu queue mapping for Armada 3700
    
    [ Upstream commit cf9bf871280d9e0a8869d98c2602d29caf69dfa3 ]
    
    According to Errata #23 "The per-CPU GbE interrupt is limited to Core
    0", we can't use the per-cpu interrupt mechanism on the Armada 3700
    familly.
    
    This is correctly checked for RSS configuration, but the initial queue
    mapping is still done by having the queues spread across all the CPUs in
    the system, both in the init path and in the cpu_hotplug path.
    
    Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700 SoC")
    Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dcb18068f97979fae4800d762ff45e78a5673420
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date:   Wed Feb 17 00:37:10 2021 +0530

    net: amd-xgbe: Fix network fluctuations when using 1G BELFUSE SFP
    
    [ Upstream commit 9eab3fdb419916f66a72d1572f68d82cd9b3f963 ]
    
    Frequent link up/down events can happen when a Bel Fuse SFP part is
    connected to the amd-xgbe device. Try to avoid the frequent link
    issues by resetting the PHY as documented in Bel Fuse SFP datasheets.
    
    Fixes: e722ec82374b ("amd-xgbe: Update the BelFuse quirk to support SGMII")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a58697e22b3abe1fc1b64df641f938078bf14b03
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date:   Wed Feb 17 00:37:09 2021 +0530

    net: amd-xgbe: Reset link when the link never comes back
    
    [ Upstream commit 84fe68eb67f9499309cffd97c1ba269de125ff14 ]
    
    Normally, auto negotiation and reconnect should be automatically done by
    the hardware. But there seems to be an issue where auto negotiation has
    to be restarted manually. This happens because of link training and so
    even though still connected to the partner the link never "comes back".
    This needs an auto-negotiation restart.
    
    Also, a change in xgbe-mdio is needed to get ethtool to recognize the
    link down and get the link change message. This change is only
    required in a backplane connection mode.
    
    Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5dba0b4e6d11681e22f30165f23dae1aaa229ab
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date:   Wed Feb 17 00:37:08 2021 +0530

    net: amd-xgbe: Fix NETDEV WATCHDOG transmit queue timeout warning
    
    [ Upstream commit 186edbb510bd60e748f93975989ccba25ee99c50 ]
    
    The current driver calls netif_carrier_off() late in the link tear down
    which can result in a netdev watchdog timeout.
    
    Calling netif_carrier_off() immediately after netif_tx_stop_all_queues()
    avoids the warning.
    
     ------------[ cut here ]------------
     NETDEV WATCHDOG: enp3s0f2 (amd-xgbe): transmit queue 0 timed out
     WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x20d/0x220
     Modules linked in: amd_xgbe(E)  amd-xgbe 0000:03:00.2 enp3s0f2: Link is Down
     CPU: 3 PID: 0 Comm: swapper/3 Tainted: G            E
     Hardware name: AMD Bilby-RV2/Bilby-RV2, BIOS RBB1202A 10/18/2019
     RIP: 0010:dev_watchdog+0x20d/0x220
     Code: 00 49 63 4e e0 eb 92 4c 89 e7 c6 05 c6 e2 c1 00 01 e8 e7 ce fc ff 89 d9 48
     RSP: 0018:ffff90cfc28c3e88 EFLAGS: 00010286
     RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
     RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff90cfc28d63c0
     RBP: ffff90cfb977845c R08: 0000000000000050 R09: 0000000000196018
     R10: ffff90cfc28c3ef8 R11: 0000000000000000 R12: ffff90cfb9778000
     R13: 0000000000000003 R14: ffff90cfb9778480 R15: 0000000000000010
     FS:  0000000000000000(0000) GS:ffff90cfc28c0000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007f240ff2d9d0 CR3: 00000001e3e0a000 CR4: 00000000003406e0
     Call Trace:
      <IRQ>
      ? pfifo_fast_reset+0x100/0x100
      call_timer_fn+0x2b/0x130
      run_timer_softirq+0x3e8/0x440
      ? enqueue_hrtimer+0x39/0x90
    
    Fixes: e722ec82374b ("amd-xgbe: Update the BelFuse quirk to support SGMII")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c086661f07b6a4b5078a8aa094693437365efc2e
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date:   Wed Feb 17 00:37:07 2021 +0530

    net: amd-xgbe: Reset the PHY rx data path when mailbox command timeout
    
    [ Upstream commit 30b7edc82ec82578f4f5e6706766f0a9535617d3 ]
    
    Sometimes mailbox commands timeout when the RX data path becomes
    unresponsive. This prevents the submission of new mailbox commands to DXIO.
    This patch identifies the timeout and resets the RX data path so that the
    next message can be submitted properly.
    
    Fixes: 549b32af9f7c ("amd-xgbe: Simplify mailbox interface rate change code")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1176062c04d73d6d0460e9eeed098c297c834e4
Author: Lijun Pan <ljp@linux.ibm.com>
Date:   Fri Feb 12 20:49:00 2021 -0600

    ibmvnic: skip send_request_unmap for timeout reset
    
    [ Upstream commit 7d3a7b9ea59ddb223aec59b45fa1713c633aaed4 ]
    
    Timeout reset will trigger the VIOS to unmap it automatically,
    similarly as FAILVOER and MOBILITY events. If we unmap it
    in the linux side, we will see errors like
    "30000003: Error 4 in REQUEST_UNMAP_RSP".
    So, don't call send_request_unmap for timeout reset.
    
    Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
    Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a3c6e02f180555123be899dc7ca03e2afaa37bb
Author: Lijun Pan <ljp@linux.ibm.com>
Date:   Fri Feb 12 20:48:40 2021 -0600

    ibmvnic: add memory barrier to protect long term buffer
    
    [ Upstream commit 42557dab78edc8235aba5b441f2eb35f725a0ede ]
    
    dma_rmb() barrier is added to load the long term buffer before copying
    it to socket buffer; and dma_wmb() barrier is added to update the
    long term buffer before it being accessed by VIOS (virtual i/o server).
    
    Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
    Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
    Acked-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d6c742302d9cc7186a429fbd8403204c4d90981
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Feb 15 12:05:32 2021 +0000

    b43: N-PHY: Fix the update of coef for the PHY revision >= 3case
    
    [ Upstream commit 4773acf3d4b50768bf08e9e97a204819e9ea0895 ]
    
    The documentation for the PHY update [1] states:
    
    Loop 4 times with index i
    
        If PHY Revision >= 3
            Copy table[i] to coef[i]
        Otherwise
            Set coef[i] to 0
    
    the copy of the table to coef is currently implemented the wrong way
    around, table is being updated from uninitialized values in coeff.
    Fix this by swapping the assignment around.
    
    [1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/
    
    Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration")
    Addresses-Coverity: ("Uninitialized scalar variable")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1be15667db84116d4acdc38b5a8c738107060cc8
Author: Ayush Sawal <ayush.sawal@chelsio.com>
Date:   Mon Feb 15 17:12:26 2021 +0530

    cxgb4/chtls/cxgbit: Keeping the max ofld immediate data size same in cxgb4 and ulds
    
    [ Upstream commit 2355a6773a2cb0d2dce13432dde78497f1d6617b ]
    
    The Max imm data size in cxgb4 is not similar to the max imm data size
    in the chtls. This caused an mismatch in output of is_ofld_imm() of
    cxgb4 and chtls. So fixed this by keeping the max wreq size of imm data
    same in both chtls and cxgb4 as MAX_IMM_OFLD_TX_DATA_WR_LEN.
    
    As cxgb4's max imm. data value for ofld packets is changed to
    MAX_IMM_OFLD_TX_DATA_WR_LEN. Using the same in cxgbit also.
    
    Fixes: 36bedb3f2e5b8 ("crypto: chtls - Inline TLS record Tx")
    Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 777d796966484f5b2b6245706057a05d1d1b642a
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 12 15:22:13 2021 -0800

    tcp: fix SO_RCVLOWAT related hangs under mem pressure
    
    [ Upstream commit f969dc5a885736842c3511ecdea240fbb02d25d9 ]
    
    While commit 24adbc1676af ("tcp: fix SO_RCVLOWAT hangs with fat skbs")
    fixed an issue vs too small sk_rcvbuf for given sk_rcvlowat constraint,
    it missed to address issue caused by memory pressure.
    
    1) If we are under memory pressure and socket receive queue is empty.
    First incoming packet is allowed to be queued, after commit
    76dfa6082032 ("tcp: allow one skb to be received per socket under memory pressure")
    
    But we do not send EPOLLIN yet, in case tcp_data_ready() sees sk_rcvlowat
    is bigger than skb length.
    
    2) Then, when next packet comes, it is dropped, and we directly
    call sk->sk_data_ready().
    
    3) If application is using poll(), tcp_poll() will then use
    tcp_stream_is_readable() and decide the socket receive queue is
    not yet filled, so nothing will happen.
    
    Even when sender retransmits packets, phases 2) & 3) repeat
    and flow is effectively frozen, until memory pressure is off.
    
    Fix is to consider tcp_under_memory_pressure() to take care
    of global memory pressure or memcg pressure.
    
    Fixes: 24adbc1676af ("tcp: fix SO_RCVLOWAT hangs with fat skbs")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Arjun Roy <arjunroy@google.com>
    Suggested-by: Wei Wang <weiwan@google.com>
    Reviewed-by: Wei Wang <weiwan@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0dcf08ec0e85b6d2d0d5408fc0e50b61d314047
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Tue Feb 9 14:38:14 2021 +0100

    bpf: Fix bpf_fib_lookup helper MTU check for SKB ctx
    
    [ Upstream commit 2c0a10af688c02adcf127aad29e923e0056c6b69 ]
    
    BPF end-user on Cilium slack-channel (Carlo Carraro) wants to use
    bpf_fib_lookup for doing MTU-check, but *prior* to extending packet size,
    by adjusting fib_params 'tot_len' with the packet length plus the expected
    encap size. (Just like the bpf_check_mtu helper supports). He discovered
    that for SKB ctx the param->tot_len was not used, instead skb->len was used
    (via MTU check in is_skb_forwardable() that checks against netdev MTU).
    
    Fix this by using fib_params 'tot_len' for MTU check. If not provided (e.g.
    zero) then keep existing TC behaviour intact. Notice that 'tot_len' for MTU
    check is done like XDP code-path, which checks against FIB-dst MTU.
    
    V16:
    - Revert V13 optimization, 2nd lookup is against egress/resulting netdev
    
    V13:
    - Only do ifindex lookup one time, calling dev_get_by_index_rcu().
    
    V10:
    - Use same method as XDP for 'tot_len' MTU check
    
    Fixes: 4c79579b44b1 ("bpf: Change bpf_fib_lookup to return lookup status")
    Reported-by: Carlo Carraro <colrack@gmail.com>
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/161287789444.790810.15247494756551413508.stgit@firesoul
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a4b99ffcda9f6739d4deb7bd7d2e0ed8444dda7
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Feb 5 17:53:52 2021 +0000

    mac80211: fix potential overflow when multiplying to u32 integers
    
    [ Upstream commit 6194f7e6473be78acdc5d03edd116944bdbb2c4e ]
    
    The multiplication of the u32 variables tx_time and estimated_retx is
    performed using a 32 bit multiplication and the result is stored in
    a u64 result. This has a potential u32 overflow issue, so avoid this
    by casting tx_time to a u64 to force a 64 bit multiply.
    
    Addresses-Coverity: ("Unintentional integer overflow")
    Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20210205175352.208841-1-colin.king@canonical.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 135ba06d0bf883bca848d02c8583d4f66b299e3c
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Feb 11 11:16:12 2021 +0100

    xen/netback: fix spurious event detection for common event case
    
    [ Upstream commit a3daf3d39132b405781be8d9ede0c449b244b64e ]
    
    In case of a common event for rx and tx queue the event should be
    regarded to be spurious if no rx and no tx requests are pending.
    
    Unfortunately the condition for testing that is wrong causing to
    decide a event being spurious if no rx OR no tx requests are
    pending.
    
    Fix that plus using local variables for rx/tx pending indicators in
    order to split function calls and if condition.
    
    Fixes: 23025393dbeb3b ("xen/netback: use lateeoi irq binding")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Reviewed-by: Wei Liu <wl@xen.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bd28e4aaa1be84f6c1d5bb20e7a9286ca57e5a9
Author: Edwin Peer <edwin.peer@broadcom.com>
Date:   Thu Feb 11 02:24:23 2021 -0500

    bnxt_en: reverse order of TX disable and carrier off
    
    [ Upstream commit 132e0b65dc2b8bfa9721bfce834191f24fd1d7ed ]
    
    A TX queue can potentially immediately timeout after it is stopped
    and the last TX timestamp on that queue was more than 5 seconds ago with
    carrier still up.  Prevent these intermittent false TX timeouts
    by bringing down carrier first before calling netif_tx_disable().
    
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 978c9d9776afc24d9389a9b5fb3e0694284c3702
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Wed Feb 10 17:41:43 2021 -0800

    ibmvnic: Set to CLOSED state even on error
    
    [ Upstream commit d4083d3c00f60a09ad82e3bf17ff57fec69c8aa6 ]
    
    If set_link_state() fails for any reason, we still cleanup the adapter
    state and cannot recover from a partial close anyway. So set the adapter
    to CLOSED state. That way if a new soft/hard reset is processed, the
    adapter will remain in the CLOSED state until the next ibmvnic_open().
    
    Fixes: 01d9bd792d16 ("ibmvnic: Reorganize device close")
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 342bb369347ad8fc4edfd607dc643c8c8d89ef83
Author: Linus Lüssing <ll@simonwunderlich.de>
Date:   Wed Feb 10 09:53:44 2021 +0200

    ath9k: fix data bus crash when setting nf_override via debugfs
    
    [ Upstream commit 12c8f3d1cdd84f01ee777b756db9dddc1f1c9d17 ]
    
    When trying to set the noise floor via debugfs, a "data bus error"
    crash like the following can happen:
    
    [   88.433133] Data bus error, epc == 80221c28, ra == 83314e60
    [   88.438895] Oops[#1]:
    [   88.441246] CPU: 0 PID: 7263 Comm: sh Not tainted 4.14.195 #0
    [   88.447174] task: 838a1c20 task.stack: 82d5e000
    [   88.451847] $ 0   : 00000000 00000030 deadc0de 83141de4
    [   88.457248] $ 4   : b810a2c4 0000a2c4 83230fd4 00000000
    [   88.462652] $ 8   : 0000000a 00000000 00000001 00000000
    [   88.468055] $12   : 7f8ef318 00000000 00000000 77f802a0
    [   88.473457] $16   : 83230080 00000002 0000001b 83230080
    [   88.478861] $20   : 83a1c3f8 00841000 77f7adb0 ffffff92
    [   88.484263] $24   : 00000fa4 77edd860
    [   88.489665] $28   : 82d5e000 82d5fda8 00000000 83314e60
    [   88.495070] Hi    : 00000000
    [   88.498044] Lo    : 00000000
    [   88.501040] epc   : 80221c28 ioread32+0x8/0x10
    [   88.505671] ra    : 83314e60 ath9k_hw_loadnf+0x88/0x520 [ath9k_hw]
    [   88.512049] Status: 1000fc03 KERNEL EXL IE
    [   88.516369] Cause : 5080801c (ExcCode 07)
    [   88.520508] PrId  : 00019374 (MIPS 24Kc)
    [   88.524556] Modules linked in: ath9k ath9k_common pppoe ppp_async l2tp_ppp cdc_mbim batman_adv ath9k_hw ath sr9700 smsc95xx sierra_net rndis_host qmi_wwan pppox ppp_generic pl2303 nf_conntrack_ipv6 mcs7830 mac80211 kalmia iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm ftdi_sio dm9601 cfg80211 cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY usbserial usbnet usbhid slhc rtl8150 r8152 pegasus nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack
    [   88.597894]  libcrc32c kaweth iptable_mangle iptable_filter ipt_ECN ipheth ip_tables hso hid_generic crc_ccitt compat cdc_wdm cdc_acm br_netfilter hid evdev input_core nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 l2tp_netlink l2tp_core udp_tunnel ip6_udp_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 tunnel6 tunnel4 tun xfrm_user xfrm_ipcomp af_key xfrm_algo sha256_generic sha1_generic jitterentropy_rng drbg md5 hmac echainiv des_generic deflate zlib_inflate zlib_deflate cbc authenc crypto_acompress ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common crc16 mii aead crypto_null cryptomgr crc32c_generic
    [   88.671671]  crypto_hash
    [   88.674292] Process sh (pid: 7263, threadinfo=82d5e000, task=838a1c20, tls=77f81efc)
    [   88.682279] Stack : 00008060 00000008 00000200 00000000 00000000 00000000 00000000 00000002
    [   88.690916]         80500000 83230080 82d5fe22 00841000 77f7adb0 00000000 00000000 83156858
    [   88.699553]         00000000 8352fa00 83ad62b0 835302a8 00000000 300a00f8 00000003 82d5fe38
    [   88.708190]         82d5fef4 00000001 77f54dc4 77f80000 77f7adb0 c79fe901 00000000 00000000
    [   88.716828]         80510000 00000002 00841000 77f54dc4 77f80000 801ce4cc 0000000b 41824292
    [   88.725465]         ...
    [   88.727994] Call Trace:
    [   88.730532] [<80221c28>] ioread32+0x8/0x10
    [   88.734765] Code: 00000000  8c820000  0000000f <03e00008> 00000000  08088708  00000000  aca40000  03e00008
    [   88.744846]
    [   88.746464] ---[ end trace db226b2de1b69b9e ]---
    [   88.753477] Kernel panic - not syncing: Fatal exception
    [   88.759981] Rebooting in 3 seconds..
    
    The "REG_READ(ah, AR_PHY_AGC_CONTROL)" in ath9k_hw_loadnf() does not
    like being called when the hardware is asleep, leading to this crash.
    
    The easiest way to reproduce this is trying to set nf_override while
    the hardware is down:
    
      $ ip link set down dev wlan0
      $ echo "-85" > /sys/kernel/debug/ieee80211/phy0/ath9k/nf_override
    
    Fixing this crash by waking the hardware up before trying to set the
    noise floor. Similar to what other ath9k debugfs files do.
    
    Tested on a Lima board from 8devices, which has a QCA 4531 chipset.
    
    Fixes: b90189759a7f ("ath9k: add noise floor override option")
    Cc: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210209184352.4272-1-linus.luessing@c0d3.blue
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b343380c0cecd338e87dca306814587798b6c386
Author: Marco Elver <elver@google.com>
Date:   Tue Feb 9 12:27:01 2021 +0100

    bpf_lru_list: Read double-checked variable once without lock
    
    [ Upstream commit 6df8fb83301d68ea0a0c0e1cbcc790fcc333ed12 ]
    
    For double-checked locking in bpf_common_lru_push_free(), node->type is
    read outside the critical section and then re-checked under the lock.
    However, concurrent writes to node->type result in data races.
    
    For example, the following concurrent access was observed by KCSAN:
    
      write to 0xffff88801521bc22 of 1 bytes by task 10038 on cpu 1:
       __bpf_lru_node_move_in        kernel/bpf/bpf_lru_list.c:91
       __local_list_flush            kernel/bpf/bpf_lru_list.c:298
       ...
      read to 0xffff88801521bc22 of 1 bytes by task 10043 on cpu 0:
       bpf_common_lru_push_free      kernel/bpf/bpf_lru_list.c:507
       bpf_lru_push_free             kernel/bpf/bpf_lru_list.c:555
       ...
    
    Fix the data races where node->type is read outside the critical section
    (for double-checked locking) by marking the access with READ_ONCE() as
    well as ensuring the variable is only accessed once.
    
    Fixes: 3a08c2fd7634 ("bpf: LRU List")
    Reported-by: syzbot+3536db46dfa58c573458@syzkaller.appspotmail.com
    Reported-by: syzbot+516acdb03d3e27d91bcd@syzkaller.appspotmail.com
    Signed-off-by: Marco Elver <elver@google.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/bpf/20210209112701.3341724-1-elver@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fe538319de3bd328c7e721316628a63474bdc3b
Author: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
Date:   Tue Dec 8 17:17:47 2020 +0800

    soc: aspeed: snoop: Add clock control logic
    
    [ Upstream commit 3f94cf15583be554df7aaa651b8ff8e1b68fbe51 ]
    
    If LPC SNOOP driver is registered ahead of lpc-ctrl module, LPC
    SNOOP block will be enabled without heart beating of LCLK until
    lpc-ctrl enables the LCLK. This issue causes improper handling on
    host interrupts when the host sends interrupt in that time frame.
    Then kernel eventually forcibly disables the interrupt with
    dumping stack and printing a 'nobody cared this irq' message out.
    
    To prevent this issue, all LPC sub-nodes should enable LCLK
    individually so this patch adds clock control logic into the LPC
    SNOOP driver.
    
    Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev")
    Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
    Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
    Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20201208091748.1920-1-wangzhiqiang.bj@bytedance.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d5e300134241ee3dd030bbd45de92b900a031a7
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Feb 4 17:23:42 2021 +0100

    ARM: s3c: fix fiq for clang IAS
    
    [ Upstream commit 7f9942c61fa60eda7cc8e42f04bd25b7d175876e ]
    
    Building with the clang integrated assembler produces a couple of
    errors for the s3c24xx fiq support:
    
      arch/arm/mach-s3c/irq-s3c24xx-fiq.S:52:2: error: instruction 'subne' can not set flags, but 's' suffix specified
        subnes pc, lr, #4 @@ return, still have work to do
    
      arch/arm/mach-s3c/irq-s3c24xx-fiq.S:64:1: error: invalid symbol redefinition
        s3c24xx_spi_fiq_txrx:
    
    There are apparently two problems: one with extraneous or duplicate
    labels, and one with old-style opcode mnemonics. Stefan Agner has
    previously fixed other problems like this, but missed this particular
    file.
    
    Fixes: bec0806cfec6 ("spi_s3c24xx: add FIQ pseudo-DMA support")
    Cc: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20210204162416.3030114-1-arnd@kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f2c52c1f5b476943c82178cb3b26f8ebd3f87f1
Author: Vincent Knecht <vincent.knecht@mailoo.org>
Date:   Sat Jan 23 11:44:16 2021 +0100

    arm64: dts: msm8916: Fix reserved and rfsa nodes unit address
    
    [ Upstream commit d5ae2528b0b56cf054b27d48b0cb85330900082f ]
    
    Fix `reserved` and `rfsa` unit address according to their reg address
    
    Fixes: 7258e10e6a0b ("ARM: dts: msm8916: Update reserved-memory")
    
    Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
    Link: https://lore.kernel.org/r/20210123104417.518105-1-vincent.knecht@mailoo.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 825f888f67014c221eaee1bed5a53a60d704fe63
Author: Rosen Penev <rosenp@gmail.com>
Date:   Wed Dec 2 18:23:21 2020 -0800

    ARM: dts: armada388-helios4: assign pinctrl to each fan
    
    [ Upstream commit 46ecdfc1830eaa40a11d7f832089c82b0e67ea96 ]
    
    Split up the pins for each fan. This is needed in order to control them
    
    Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
    
    Signed-off-by: Rosen Penev <rosenp@gmail.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0bf3cb37bb40ae1251682689406f506583e5767
Author: Rosen Penev <rosenp@gmail.com>
Date:   Wed Dec 2 18:23:20 2020 -0800

    ARM: dts: armada388-helios4: assign pinctrl to LEDs
    
    [ Upstream commit e011c9025a4691b5c734029577a920bd6c320994 ]
    
    Split up the pins to match earlier definitions. Allows LEDs to flash
    properly.
    
    Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
    
    Signed-off-by: Rosen Penev <rosenp@gmail.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72ff4fd132998e6635fbb415c8abe3b608cddf43
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Fri Jan 8 22:14:01 2021 +0800

    staging: rtl8723bs: wifi_regd.c: Fix incorrect number of regulatory rules
    
    [ Upstream commit 61834c967a929f6b4b7fcb91f43fa225cc29aa19 ]
    
    The custom regulatory ruleset in the rtl8723bs driver lists an incorrect
    number of rules: one too many. This results in an out-of-bounds access,
    as detected by KASAN. This was possible thanks to the newly added support
    for KASAN on ARMv7.
    
    Fix this by filling in the correct number of rules given.
    
    KASAN report:
    
    ==================================================================
    BUG: KASAN: global-out-of-bounds in cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211]
    Read of size 4 at addr bf20c254 by task ip/971
    
    CPU: 2 PID: 971 Comm: ip Tainted: G         C        5.11.0-rc2-00020-gf7fe528a7ebe #1
    Hardware name: Allwinner sun8i Family
    [<c0113338>] (unwind_backtrace) from [<c010e8a4>] (show_stack+0x10/0x14)
    [<c010e8a4>] (show_stack) from [<c0e0f868>] (dump_stack+0x9c/0xb4)
    [<c0e0f868>] (dump_stack) from [<c0388284>] (print_address_description.constprop.2+0x1dc/0x2dc)
    [<c0388284>] (print_address_description.constprop.2) from [<c03885cc>] (kasan_report+0x1a8/0x1c4)
    [<c03885cc>] (kasan_report) from [<bf00a354>] (cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211])
    [<bf00a354>] (cfg80211_does_bw_fit_range [cfg80211]) from [<bf00b41c>] (freq_reg_info_regd.part.6+0x108/0x124 [>
    [<bf00b41c>] (freq_reg_info_regd.part.6 [cfg80211]) from [<bf00df00>] (handle_channel_custom.constprop.12+0x48/>
    [<bf00df00>] (handle_channel_custom.constprop.12 [cfg80211]) from [<bf00e150>] (wiphy_apply_custom_regulatory+0>
    [<bf00e150>] (wiphy_apply_custom_regulatory [cfg80211]) from [<bf1fb9e8>] (rtw_regd_init+0x60/0x70 [r8723bs])
    [<bf1fb9e8>] (rtw_regd_init [r8723bs]) from [<bf1ee5a8>] (rtw_cfg80211_init_wiphy+0x164/0x1e8 [r8723bs])
    [<bf1ee5a8>] (rtw_cfg80211_init_wiphy [r8723bs]) from [<bf1f8d50>] (_netdev_open+0xe4/0x28c [r8723bs])
    [<bf1f8d50>] (_netdev_open [r8723bs]) from [<bf1f8f58>] (netdev_open+0x60/0x88 [r8723bs])
    [<bf1f8f58>] (netdev_open [r8723bs]) from [<c0bb3730>] (__dev_open+0x178/0x220)
    [<c0bb3730>] (__dev_open) from [<c0bb3cdc>] (__dev_change_flags+0x258/0x2c4)
    [<c0bb3cdc>] (__dev_change_flags) from [<c0bb3d88>] (dev_change_flags+0x40/0x80)
    [<c0bb3d88>] (dev_change_flags) from [<c0bc86fc>] (do_setlink+0x538/0x1160)
    [<c0bc86fc>] (do_setlink) from [<c0bcf9e8>] (__rtnl_newlink+0x65c/0xad8)
    [<c0bcf9e8>] (__rtnl_newlink) from [<c0bcfeb0>] (rtnl_newlink+0x4c/0x6c)
    [<c0bcfeb0>] (rtnl_newlink) from [<c0bc67c8>] (rtnetlink_rcv_msg+0x1f8/0x454)
    [<c0bc67c8>] (rtnetlink_rcv_msg) from [<c0c330e4>] (netlink_rcv_skb+0xc4/0x1e0)
    [<c0c330e4>] (netlink_rcv_skb) from [<c0c32478>] (netlink_unicast+0x2c8/0x3c4)
    [<c0c32478>] (netlink_unicast) from [<c0c32894>] (netlink_sendmsg+0x320/0x5f0)
    [<c0c32894>] (netlink_sendmsg) from [<c0b75eb0>] (____sys_sendmsg+0x320/0x3e0)
    [<c0b75eb0>] (____sys_sendmsg) from [<c0b78394>] (___sys_sendmsg+0xe8/0x12c)
    [<c0b78394>] (___sys_sendmsg) from [<c0b78a50>] (__sys_sendmsg+0xc0/0x120)
    [<c0b78a50>] (__sys_sendmsg) from [<c0100060>] (ret_fast_syscall+0x0/0x58)
    Exception stack(0xc5693fa8 to 0xc5693ff0)
    3fa0:                   00000074 c7a39800 00000003 b6cee648 00000000 00000000
    3fc0: 00000074 c7a39800 00000001 00000128 78d18349 00000000 b6ceeda0 004f7cb0
    3fe0: 00000128 b6cee5e8 aeca151f aec1d746
    
    The buggy address belongs to the variable:
     rtw_drv_halt+0xf908/0x6b4 [r8723bs]
    
    Memory state around the buggy address:
     bf20c100: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9
     bf20c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >bf20c200: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9
                                             ^
     bf20c280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     bf20c300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ==================================================================
    
    Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20210108141401.31741-1-wens@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b707bc92c97b694fbcf0396d0d066a2eb6e93db
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Jan 13 12:20:51 2021 +0100

    usb: dwc2: Make "trimming xfer length" a debug message
    
    [ Upstream commit 1a9e38cabd80356ffb98c2c88fec528ea9644fd5 ]
    
    With some USB network adapters, such as DM96xx, the following message
    is seen for each maximum size receive packet.
    
    dwc2 ff540000.usb: dwc2_update_urb_state(): trimming xfer length
    
    This happens because the packet size requested by the driver is 1522
    bytes, wMaxPacketSize is 64, the dwc2 driver configures the chip to
    receive 24*64 = 1536 bytes, and the chip does indeed send more than
    1522 bytes of data. Since the event does not indicate an error condition,
    the message is just noise. Demote it to debug level.
    
    Fixes: 7359d482eb4d3 ("staging: HCD files for the DWC2 driver")
    Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Link: https://lore.kernel.org/r/20210113112052.17063-4-nsaenzjulienne@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b392d1b1c1f861443c63e3ea2be5ca4f2be8f43
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Jan 13 12:20:50 2021 +0100

    usb: dwc2: Abort transaction after errors with unknown reason
    
    [ Upstream commit f74b68c61cbc4b2245022fcce038509333d63f6f ]
    
    In some situations, the following error messages are reported.
    
    dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown
    dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021
    
    This is sometimes followed by:
    
    dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length
    
    and then:
    
    WARNING: CPU: 0 PID: 0 at kernel/v4.19/drivers/usb/dwc2/hcd.c:2913
                            dwc2_assign_and_init_hc+0x98c/0x990
    
    The warning suggests that an odd buffer address is to be used for DMA.
    
    After an error is observed, the receive buffer may be full
    (urb->actual_length >= urb->length). However, the urb is still left in
    the queue unless three errors were observed in a row. When it is queued
    again, the dwc2 hcd code translates this into a 1-block transfer.
    If urb->actual_length (ie the total expected receive length) is not
    DMA-aligned, the buffer pointer programmed into the chip will be
    unaligned. This results in the observed warning.
    
    To solve the problem, abort input transactions after an error with
    unknown cause if the entire packet was already received. This may be
    a bit drastic, but we don't really know why the transfer was aborted
    even though the entire packet was received. Aborting the transfer in
    this situation is less risky than accepting a potentially corrupted
    packet.
    
    With this patch in place, the 'ChHltd set' and 'trimming xfer length'
    messages are still observed, but there are no more transfer attempts
    with odd buffer addresses.
    
    Fixes: 151d0cbdbe860 ("usb: dwc2: make the scheduler handle excessive NAKs better")
    Cc: Boris ARZUR <boris@konbu.org>
    Cc: Douglas Anderson <dianders@chromium.org>
    Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Link: https://lore.kernel.org/r/20210113112052.17063-3-nsaenzjulienne@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36585c098ad8a6abdbe17bbe2e8139dd6f3dbc6d
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Jan 13 12:20:49 2021 +0100

    usb: dwc2: Do not update data length if it is 0 on inbound transfers
    
    [ Upstream commit 415fa1c7305dedbb345e2cc8ac91769bc1c83f1a ]
    
    The DWC2 documentation states that transfers with zero data length should
    set the number of packets to 1 and the transfer length to 0. This is not
    currently the case for inbound transfers: the transfer length is set to
    the maximum packet length. This can have adverse effects if the chip
    actually does transfer data as it is programmed to do. Follow chip
    documentation and keep the transfer length set to 0 in that situation.
    
    Fixes: 56f5b1cff22a1 ("staging: Core files for the DWC2 driver")
    Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Link: https://lore.kernel.org/r/20210113112052.17063-2-nsaenzjulienne@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba2d5d1a7bc261da8ccd69d0408a53889759c82b
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Dec 30 10:42:30 2020 +0200

    ARM: dts: Configure missing thermal interrupt for 4430
    
    [ Upstream commit 44f416879a442600b006ef7dec3a6dc98bcf59c6 ]
    
    We have gpio_86 wired internally to the bandgap thermal shutdown
    interrupt on 4430 like we have it on 4460 according to the TRM.
    This can be found easily by searching for TSHUT.
    
    For some reason the thermal shutdown interrupt was never added
    for 4430, let's add it. I believe this is needed for the thermal
    shutdown interrupt handler ti_bandgap_tshut_irq_handler() to call
    orderly_poweroff().
    
    Fixes: aa9bb4bb8878 ("arm: dts: add omap4430 thermal data")
    Cc: Carl Philipp Klemm <philipp@uvos.xyz>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Eduardo Valentin <edubezval@gmail.com>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Cc: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1eeb712abe3ff1d17b1b68e37c51239b473a4f46
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Jan 21 01:03:59 2021 -0800

    memory: ti-aemif: Drop child node when jumping out loop
    
    [ Upstream commit 94e9dd43cf327366388c8f146bccdc6322c0d999 ]
    
    Call of_node_put() to decrement the reference count of the child node
    child_np when jumping out of the loop body of
    for_each_available_child_of_node(), which is a macro that increments and
    decrements the reference count of child node. If the loop is broken, the
    reference of the child node should be dropped manually.
    
    Fixes: 5a7c81547c1d ("memory: ti-aemif: introduce AEMIF driver")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Link: https://lore.kernel.org/r/20210121090359.61763-1-bianpan2016@163.com
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33840f94e3c7824f171ba283f2b9c3cd00f4c831
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Jan 21 00:10:45 2021 -0800

    Bluetooth: Put HCI device if inquiry procedure interrupts
    
    [ Upstream commit 28a758c861ff290e39d4f1ee0aa5df0f0b9a45ee ]
    
    Jump to the label done to decrement the reference count of HCI device
    hdev on path that the Inquiry procedure is interrupted.
    
    Fixes: 3e13fa1e1fab ("Bluetooth: Fix hci_inquiry ioctl usage")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6d84f17336559177cf4cd1b7c7a8781a67d8c91
Author: Pan Bian <bianpan2016@163.com>
Date:   Wed Jan 20 23:34:19 2021 -0800

    Bluetooth: drop HCI device reference before return
    
    [ Upstream commit 5a3ef03afe7e12982dc3b978f4c5077c907f7501 ]
    
    Call hci_dev_put() to decrement reference count of HCI device hdev if
    fails to duplicate memory.
    
    Fixes: 0b26ab9dce74 ("Bluetooth: AMP: Handle Accept phylink command status evt")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bffffc285b2ec79fdc29295ae57c0f172c8b06d8
Author: Jack Pham <jackp@codeaurora.org>
Date:   Mon Jan 18 09:46:39 2021 +0100

    usb: gadget: u_audio: Free requests only after callback
    
    [ Upstream commit 7de8681be2cde9f6953d3be1fa6ce05f9fe6e637 ]
    
    As per the kernel doc for usb_ep_dequeue(), it states that "this
    routine is asynchronous, that is, it may return before the completion
    routine runs". And indeed since v5.0 the dwc3 gadget driver updated
    its behavior to place dequeued requests on to a cancelled list to be
    given back later after the endpoint is stopped.
    
    The free_ep() was incorrectly assuming that a request was ready to
    be freed after calling dequeue which results in a use-after-free
    in dwc3 when it traverses its cancelled list. Fix this by moving
    the usb_ep_free_request() call to the callback itself in case the
    ep is disabled.
    
    Fixes: eb9fecb9e69b0 ("usb: gadget: f_uac2: split out audio core")
    Reported-and-tested-by: Ferry Toth <fntoth@gmail.com>
    Reviewed-and-tested-by: Peter Chen <peter.chen@nxp.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Jack Pham <jackp@codeaurora.org>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20210118084642.322510-2-jbrunet@baylibre.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 615b6d0e159b682cc60847102309288b595f5bc7
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Fri Jan 15 10:48:18 2021 -0800

    ACPICA: Fix exception code class checks
    
    [ Upstream commit 3dfaea3811f8b6a89a347e8da9ab862cdf3e30fe ]
    
    ACPICA commit 1a3a549286ea9db07d7ec700e7a70dd8bcc4354e
    
    The macros to classify different AML exception codes are broken. For
    instance,
    
      ACPI_ENV_EXCEPTION(Status)
    
    will always evaluate to zero due to
    
      #define AE_CODE_ENVIRONMENTAL      0x0000
      #define ACPI_ENV_EXCEPTION(Status) (Status & AE_CODE_ENVIRONMENTAL)
    
    Similarly, ACPI_AML_EXCEPTION(Status) will evaluate to a non-zero
    value for error codes of type AE_CODE_PROGRAMMER, AE_CODE_ACPI_TABLES,
    as well as AE_CODE_AML, and not just AE_CODE_AML as the name suggests.
    
    This commit fixes those checks.
    
    Fixes: d46b6537f0ce ("ACPICA: AML Parser: ignore all exceptions resulting from incorrect AML during table load")
    Link: https://github.com/acpica/acpica/commit/1a3a5492
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa21224447ef131d87e778dea3ee8162ee75dab9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jan 17 15:26:44 2021 +0100

    cpufreq: brcmstb-avs-cpufreq: Fix resource leaks in ->remove()
    
    [ Upstream commit 3657f729b6fb5f2c0bf693742de2dcd49c572aa1 ]
    
    If 'cpufreq_unregister_driver()' fails, just WARN and continue, so that
    other resources are freed.
    
    Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    [ Viresh: Updated Subject ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fe373d16fcccb86dcf6c12809697a1c50dc79a8
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jan 17 15:26:35 2021 +0100

    cpufreq: brcmstb-avs-cpufreq: Free resources in error path
    
    [ Upstream commit 05f456286fd489558c72a4711d22a5612c965685 ]
    
    If 'cpufreq_register_driver()' fails, we must release the resources
    allocated in 'brcm_avs_prepare_init()' as already done in the remove
    function.
    
    To do that, introduce a new function 'brcm_avs_prepare_uninit()' in order
    to avoid code duplication. This also makes the code more readable (IMHO).
    
    Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    [ Viresh: Updated Subject ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a429d135749e8e8a82c3a7912dc93faa55829ab
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Wed Jan 13 15:26:28 2021 +0000

    arm64: dts: allwinner: A64: Limit MMC2 bus frequency to 150 MHz
    
    [ Upstream commit 948c657cc45e8ce48cb533d4e2106145fa765759 ]
    
    In contrast to the H6 (and later) manuals, the A64 datasheet does not
    specify any limitations in the maximum possible frequency for eMMC
    controllers.
    However experimentation has found that a 150 MHz limit similar to other
    SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist
    for the MMC2 controller.
    
    Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi.
    The Pinebook seems to be the an odd exception, since it apparently seems
    to work with 200 MHz as well, so overwrite this in its board .dts file.
    
    Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works.
    
    Fixes: 22be992faea7 ("arm64: allwinner: a64: Increase the MMC max frequency")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210113152630.28810-7-andre.przywara@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5401debf6e6ca67754760080c74f5735d81cc15d
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Wed Jan 13 15:26:26 2021 +0000

    arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card
    
    [ Upstream commit 941432d007689f3774646e41a1439228b6c6ee0e ]
    
    The SD card on the SoPine SoM module is somewhat concealed, so was
    originally defined as "non-removable".
    However there is a working card-detect pin (tested on two different
    SoM versions), and in certain SoM base boards it might be actually
    accessible at runtime.
    Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the
    non-removable flag, even though the SD card slot is perfectly accessible
    and usable there. (It turns out that just *my* board has a broken card
    detect switch, so I originally thought CD wouldn't work on the LTS.)
    
    Drop the "non-removable" flag to describe the SD card slot properly.
    
    Fixes: c3904a269891 ("arm64: allwinner: a64: add DTSI file for SoPine SoM")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210113152630.28810-5-andre.przywara@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b6c3023fdc15d2c00426d6bb50cbbdeb5f3722c
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Wed Jan 13 15:26:23 2021 +0000

    arm64: dts: allwinner: A64: properly connect USB PHY to port 0
    
    [ Upstream commit cc72570747e43335f4933a24dd74d5653639176a ]
    
    In recent Allwinner SoCs the first USB host controller (HCI0) shares
    the first PHY with the MUSB controller. Probably to make this sharing
    work, we were avoiding to declare this in the DT. This has two
    shortcomings:
    - U-Boot (which uses the same .dts) cannot use this port in host mode
      without a PHY linked, so we were loosing one USB port there.
    - It requires the MUSB driver to be enabled and loaded, although we
      don't actually use it.
    
    To avoid those issues, let's add this PHY link to the A64 .dtsi file.
    After all PHY port 0 *is* connected to HCI0, so we should describe
    it as this. Remove the part from the Pinebook DTS which already had
    this property.
    
    This makes it work in U-Boot, also improves compatiblity when no MUSB
    driver is loaded (for instance in distribution installers).
    
    Fixes: dc03a047df1d ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210113152630.28810-2-andre.przywara@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d7fdbb979fa84cd63c3efb3c49ff7101774da73
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Jan 11 23:55:15 2021 -0800

    bpf: Avoid warning when re-casting __bpf_call_base into __bpf_call_base_args
    
    [ Upstream commit 6943c2b05bf09fd5c5729f7d7d803bf3f126cb9a ]
    
    BPF interpreter uses extra input argument, so re-casts __bpf_call_base into
    __bpf_call_base_args. Avoid compiler warning about incompatible function
    prototypes by casting to void * first.
    
    Fixes: 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20210112075520.4103414-3-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 758a4da553576b9de88e4751be7a484568c9d0af
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:29:02 2020 +0100

    arm64: dts: exynos: correct PMIC interrupt trigger level on Espresso
    
    [ Upstream commit 1fea2eb2f5bbd3fbbe2513d2386b5f6e6db17fd7 ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  Without specifying the
    interrupt type in Devicetree, kernel might apply some fixed
    configuration, not necessarily working for this hardware.
    
    Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20201210212903.216728-8-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e96bba1fb53842d9b2041bd4a1f5554aad1b725
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:29:01 2020 +0100

    arm64: dts: exynos: correct PMIC interrupt trigger level on TM2
    
    [ Upstream commit e98e2367dfb4b6d7a80c8ce795c644124eff5f36 ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  Without specifying the
    interrupt type in Devicetree, kernel might apply some fixed
    configuration, not necessarily working for this hardware.
    
    Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20201210212903.216728-7-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c5b5b1f08b1e9a90e037e808dd4b42597a86448
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:29:00 2020 +0100

    ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family
    
    [ Upstream commit 3e7d9a583a24f7582c6bc29a0d4d624feedbc2f9 ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  The falling edge
    interrupt will mostly work but it's not correct.
    
    Fixes: aac4e0615341 ("ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20201210212903.216728-6-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6a4d2565f44ad1ed586b4795f63e563f0134628
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:28:59 2020 +0100

    ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa
    
    [ Upstream commit 1ac8893c4fa3d4a34915dc5cdab568a39db5086c ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  The falling edge
    interrupt will mostly work but it's not correct.
    
    Fixes: 1fed2252713e ("ARM: dts: fix pinctrl for s2mps11-irq on exynos5420-arndale-octa")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20201210212903.216728-5-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1019798a04a50f86c61733056b06297cb6c03be
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:28:58 2020 +0100

    ARM: dts: exynos: correct PMIC interrupt trigger level on Spring
    
    [ Upstream commit 77e6a5467cb8657cf8b5e610a30a4c502085e4f9 ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  Without specifying the
    interrupt type in Devicetree, kernel might apply some fixed
    configuration, not necessarily working for this hardware.
    
    Fixes: 53dd4138bb0a ("ARM: dts: Add exynos5250-spring device tree")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20201210212903.216728-4-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 452ee0e8467f9b6ae60dcb7d3621d01e2d46a981
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:28:57 2020 +0100

    ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato
    
    [ Upstream commit 437ae60947716bb479e2f32466f49445c0509b1e ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  Without specifying the
    interrupt type in Devicetree, kernel might apply some fixed
    configuration, not necessarily working for this hardware.
    
    Fixes: faaf348ef468 ("ARM: dts: Add board dts file for exynos3250-rinato")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20201210212903.216728-3-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f4b8caae80ea99b771bc97c08b4d714526b2342
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:28:56 2020 +0100

    ARM: dts: exynos: correct PMIC interrupt trigger level on Monk
    
    [ Upstream commit 8528cda2b7c667e9cd173aef1a677c71b7d5a096 ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  Without specifying the
    interrupt type in Devicetree, kernel might apply some fixed
    configuration, not necessarily working for this hardware.
    
    Fixes: e0cefb3f79d3 ("ARM: dts: add board dts file for Exynos3250-based Monk board")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20201210212903.216728-2-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0dbc02ca1be95eec807491b118f260af4f676f5
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Dec 10 22:28:55 2020 +0100

    ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5
    
    [ Upstream commit cb31334687db31c691901269d65074a7ffaecb18 ]
    
    The Samsung PMIC datasheets describe the interrupt line as active low
    with a requirement of acknowledge from the CPU.  Without specifying the
    interrupt type in Devicetree, kernel might apply some fixed
    configuration, not necessarily working for this hardware.
    
    Fixes: b004a34bd0ff ("ARM: dts: exynos: Add exynos3250-artik5 dtsi file for ARTIK5 module")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20201210212903.216728-1-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60f6880c92b22ee6a4c27f8cce14491e8835bc70
Author: Christopher William Snowhill <chris@kode54.net>
Date:   Sat Dec 26 19:12:32 2020 -0800

    Bluetooth: Fix initializing response id after clearing struct
    
    [ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]
    
    Looks like this was missed when patching the source to clear the structures
    throughout, causing this one instance to clear the struct after the response
    id is assigned.
    
    Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
    Signed-off-by: Christopher William Snowhill <chris@kode54.net>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7847b90bd178f537c30c9fa6cbf3f5a49c057280
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 12 10:46:58 2020 +0100

    Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function
    
    [ Upstream commit 9a39a927be01d89e53f04304ab99a8761e08910d ]
    
    Some resource should be released in the error handling path of the probe
    function, as already done in the remove function.
    
    The remove function was fixed in commit 5052de8deff5 ("soc: qcom: smd:
    Transition client drivers from smd to rpmsg")
    
    Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98cbfd15adf53094103616fe8f251be923086da8
Author: Rakesh Pillai <pillair@codeaurora.org>
Date:   Sat Dec 12 00:30:10 2020 +0530

    ath10k: Fix error handling in case of CE pipe init failure
    
    [ Upstream commit 31561e8557cd1eeba5806ac9ce820f8323b2201b ]
    
    Currently if the copy engine pipe init fails for snoc based
    chipsets, the rri is not freed.
    
    Fix this error handling for copy engine pipe init
    failure.
    
    Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
    
    Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990")
    Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
    Reviewed-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1607713210-18320-1-git-send-email-pillair@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fc338cde538bc2d73006fffb0ea20fa97fdbd55
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Jan 12 11:28:18 2021 -0800

    random: fix the RNDRESEEDCRNG ioctl
    
    commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
    
    The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
    doesn't make sense.  Reseed it from the input_pool instead.
    
    Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
    Cc: stable@vger.kernel.org
    Cc: linux-crypto@vger.kernel.org
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Jann Horn <jannh@google.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jann Horn <jannh@google.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20210112192818.69921-1-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b56bc4692412ca0497a5256d8fefe910982ae53
Author: Alexander Lobakin <alobakin@pm.me>
Date:   Sun Jan 10 11:56:08 2021 +0000

    MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section
    
    commit 8ac7c87acdcac156670f9920c8acbd84308ff4b1 upstream.
    
    MIPS uses its own declaration of rwdata, and thus it should be kept
    in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is
    missing from the linker script, which emits the following ld
    warnings:
    
    mips-alpine-linux-musl-ld: warning: orphan section
    `.data..page_aligned' from `arch/mips/kernel/vdso.o' being placed
    in section `.data..page_aligned'
    mips-alpine-linux-musl-ld: warning: orphan section
    `.data..page_aligned' from `arch/mips/vdso/vdso-image.o' being placed
    in section `.data..page_aligned'
    
    Add the necessary declaration, so the mentioned structures will be
    placed in vmlinux as intended:
    
    ffffffff80630580 D __end_once
    ffffffff80630580 D __start___dyndbg
    ffffffff80630580 D __start_once
    ffffffff80630580 D __stop___dyndbg
    ffffffff80634000 d mips_vdso_data
    ffffffff80638000 d vdso_data
    ffffffff80638580 D _gp
    ffffffff8063c000 T __init_begin
    ffffffff8063c000 D _edata
    ffffffff8063c000 T _sinittext
    
    ->
    
    ffffffff805a4000 D __end_init_task
    ffffffff805a4000 D __nosave_begin
    ffffffff805a4000 D __nosave_end
    ffffffff805a4000 d mips_vdso_data
    ffffffff805a8000 d vdso_data
    ffffffff805ac000 D mmlist_lock
    ffffffff805ac080 D tasklist_lock
    
    Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
    Signed-off-by: Alexander Lobakin <alobakin@pm.me>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Cc: stable@vger.kernel.org # 4.4+
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea627a9e861ab61eef0d9723e4adbfae47f214c8
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Feb 5 15:45:59 2021 +0100

    ALSA: usb-audio: Fix PCM buffer allocation in non-vmalloc mode
    
    commit fb3c293b82c31a9a68fbcf4e7a45fadd8a47ea2b upstream.
    
    The commit f274baa49be6 ("ALSA: usb-audio: Allow non-vmalloc buffer
    for PCM buffers") introduced the mode to allocate coherent pages for
    PCM buffers, and it used bus->controller device as its DMA device.
    It turned out, however, that bus->sysdev is a more appropriate device
    to be used for DMA mapping in HCD code.
    
    This patch corrects the device reference accordingly.
    
    Note that, on most platforms, both point to the very same device,
    hence this patch doesn't change anything practically.  But on
    platforms like xhcd-plat hcd, the change becomes effective.
    
    Fixes: f274baa49be6 ("ALSA: usb-audio: Allow non-vmalloc buffer for PCM buffers")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210205144559.29555-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 904e2953231a8b040108584965561a1ba8c197f2
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 5 16:16:16 2020 +0200

    bfq: Avoid false bfq queue merging
    
    commit 41e76c85660c022c6bf5713bfb6c21e64a487cec upstream.
    
    bfq_setup_cooperator() uses bfqd->in_serv_last_pos so detect whether it
    makes sense to merge current bfq queue with the in-service queue.
    However if the in-service queue is freshly scheduled and didn't dispatch
    any requests yet, bfqd->in_serv_last_pos is stale and contains value
    from the previously scheduled bfq queue which can thus result in a bogus
    decision that the two queues should be merged. This bug can be observed
    for example with the following fio jobfile:
    
    [global]
    direct=0
    ioengine=sync
    invalidate=1
    size=1g
    rw=read
    
    [reader]
    numjobs=4
    directory=/mnt
    
    where the 4 processes will end up in the one shared bfq queue although
    they do IO to physically very distant files (for some reason I was able to
    observe this only with slice_idle=1ms setting).
    
    Fix the problem by invalidating bfqd->in_serv_last_pos when switching
    in-service queue.
    
    Fixes: 058fdecc6de7 ("block, bfq: fix in-service-queue check for queue merging")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Acked-by: Paolo Valente <paolo.valente@linaro.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5408022a0ba23d743764122c12ea7e5aee8de845
Author: Ansuel Smith <ansuelsmth@gmail.com>
Date:   Mon Oct 19 18:55:55 2020 +0200

    PCI: qcom: Use PHY_REFCLK_USE_PAD only for ipq8064
    
    commit 2cfef1971aea6119ee27429181d6cb3383031ac2 upstream.
    
    The use of PHY_REFCLK_USE_PAD introduced a regression for apq8064 devices.
    It was tested that while apq doesn't require the padding, ipq SoC must use
    it or the kernel hangs on boot.
    
    Link: https://lore.kernel.org/r/20201019165555.8269-1-ansuelsmth@gmail.com
    Fixes: de3c4bf64897 ("PCI: qcom: Add support for tx term offset for rev 2.1.0")
    Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
    Cc: stable@vger.kernel.org      # v4.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2040647cbff14f19a8fe52022fdc73a5bdc73c91
Author: Sumit Garg <sumit.garg@linaro.org>
Date:   Fri Jan 22 16:35:56 2021 +0530

    kdb: Make memory allocations more robust
    
    commit 93f7a6d818deef69d0ba652d46bae6fbabbf365c upstream.
    
    Currently kdb uses in_interrupt() to determine whether its library
    code has been called from the kgdb trap handler or from a saner calling
    context such as driver init. This approach is broken because
    in_interrupt() alone isn't able to determine kgdb trap handler entry from
    normal task context. This can happen during normal use of basic features
    such as breakpoints and can also be trivially reproduced using:
    echo g > /proc/sysrq-trigger
    
    We can improve this by adding check for in_dbg_master() instead which
    explicitly determines if we are running in debugger context.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
    Link: https://lore.kernel.org/r/1611313556-4004-1-git-send-email-sumit.garg@linaro.org
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a5e6d954a3c527ea66d3c36a73469d6af5aec6c
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri Feb 5 12:22:18 2021 -0800

    vmlinux.lds.h: add DWARF v5 sections
    
    commit 3c4fa46b30c551b1df2fb1574a684f68bc22067c upstream.
    
    We expect toolchains to produce these new debug info sections as part of
    DWARF v5. Add explicit placements to prevent the linker warnings from
    --orphan-section=warn.
    
    Compilers may produce such sections with explicit -gdwarf-5, or based on
    the implicit default version of DWARF when -g is used via DEBUG_INFO.
    This implicit default changes over time, and has changed to DWARF v5
    with GCC 11.
    
    .debug_sup was mentioned in review, but without compilers producing it
    today, let's wait to add it until it becomes necessary.
    
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707
    Reported-by: Chris Murphy <lists@colorremedies.com>
    Suggested-by: Fangrui Song <maskray@google.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Mark Wielaard <mark@klomp.org>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4eb9488bd27b969b248748ae02053f508c9b529e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Mar 19 13:18:56 2019 +0100

    locking/static_key: Fix false positive warnings on concurrent dec/inc
    
    commit a1247d06d01045d7ab2882a9c074fbf21137c690 upstream.
    
    Even though the atomic_dec_and_mutex_lock() in
    __static_key_slow_dec_cpuslocked() can never see a negative value in
    key->enabled the subsequent sanity check is re-reading key->enabled, which may
    have been set to -1 in the meantime by static_key_slow_inc_cpuslocked().
    
                    CPU  A                               CPU B
    
     __static_key_slow_dec_cpuslocked():          static_key_slow_inc_cpuslocked():
                                   # enabled = 1
       atomic_dec_and_mutex_lock()
                                   # enabled = 0
                                                  atomic_read() == 0
                                                  atomic_set(-1)
                                   # enabled = -1
       val = atomic_read()
       # Oops - val == -1!
    
    The test case is TCP's clean_acked_data_enable() / clean_acked_data_disable()
    as tickled by KTLS (net/ktls).
    
    Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Tested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: ard.biesheuvel@linaro.org
    Cc: oss-drivers@netronome.com
    Cc: pbonzini@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 158c3ec956d3881c86df5c0a842f39a2ee0c926b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jul 31 14:35:32 2018 +0200

    jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations
    
    commit cb538267ea1e9e025ec692577c9ae75797261889 upstream.
    
    Weirdly we seem to have forgotten this...
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5aefd25d2be3a73cec4f3d81d5a7eb714302377
Author: Rong Chen <rong.a.chen@intel.com>
Date:   Fri Feb 12 20:52:41 2021 -0800

    scripts/recordmcount.pl: support big endian for ARCH sh
    
    [ Upstream commit 93ca696376dd3d44b9e5eae835ffbc84772023ec ]
    
    The kernel test robot reported the following issue:
    
        CC [M]  drivers/soc/litex/litex_soc_ctrl.o
      sh4-linux-objcopy: Unable to change endianness of input file(s)
      sh4-linux-ld: cannot find drivers/soc/litex/.tmp_gl_litex_soc_ctrl.o: No such file or directory
      sh4-linux-objcopy: 'drivers/soc/litex/.tmp_mx_litex_soc_ctrl.o': No such file
    
    The problem is that the format of input file is elf32-shbig-linux, but
    sh4-linux-objcopy wants to output a file which format is elf32-sh-linux:
    
      $ sh4-linux-objdump -d drivers/soc/litex/litex_soc_ctrl.o | grep format
      drivers/soc/litex/litex_soc_ctrl.o:     file format elf32-shbig-linux
    
    Link: https://lkml.kernel.org/r/20210210150435.2171567-1-rong.a.chen@intel.com
    Link: https://lore.kernel.org/linux-mm/202101261118.GbbYSlHu-lkp@intel.com
    Signed-off-by: Rong Chen <rong.a.chen@intel.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Yoshinori Sato <ysato@users.osdn.me>
    Cc: Rich Felker <dalias@libc.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7496d7034a4e1b715c2baf6fe976bbaf7a361106
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Thu Feb 11 03:26:54 2021 -0800

    cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.
    
    [ Upstream commit a738c93fb1c17e386a09304b517b1c6b2a6a5a8b ]
    
    While debugging another issue today, Steve and I noticed that if a
    subdir for a file share is already mounted on the client, any new
    mount of any other subdir (or the file share root) of the same share
    results in sharing the cifs superblock, which e.g. can result in
    incorrect device name.
    
    While setting prefix path for the root of a cifs_sb,
    CIFS_MOUNT_USE_PREFIX_PATH flag should also be set.
    Without it, prepath is not even considered in some places,
    and output of "mount" and various /proc/<>/*mount* related
    options can be missing part of the device name.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fb5db68587ace6425012c00358c0379abb96fb7
Author: Christoph Schemmel <christoph.schemmel@gmail.com>
Date:   Tue Feb 2 09:45:23 2021 +0100

    NET: usb: qmi_wwan: Adding support for Cinterion MV31
    
    [ Upstream commit a4dc7eee9106a9d2a6e08b442db19677aa9699c7 ]
    
    Adding support for Cinterion MV31 with PID 0x00B7.
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b7 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion USB Mobile Broadband
    S:  SerialNumber=b3246eed
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    Signed-off-by: Christoph Schemmel <christoph.schemmel@gmail.com>
    Link: https://lore.kernel.org/r/20210202084523.4371-1-christoph.schemmel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee3d84e67d013662fc239658f451028bb016415c
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Sep 23 23:12:09 2019 +0800

    block: don't release queue's sysfs lock during switching elevator
    
    commit b89f625e28d44552083f43752f62d8621ded0a04 upstream.
    
    cecf5d87ff20 ("block: split .sysfs_lock into two locks") starts to
    release & acquire sysfs_lock before registering/un-registering elevator
    queue during switching elevator for avoiding potential deadlock from
    showing & storing 'queue/iosched' attributes and removing elevator's
    kobject.
    
    Turns out there isn't such deadlock because 'q->sysfs_lock' isn't
    required in .show & .store of queue/iosched's attributes, and just
    elevator's sysfs lock is acquired in elv_iosched_store() and
    elv_iosched_show(). So it is safe to hold queue's sysfs lock when
    registering/un-registering elevator queue.
    
    The biggest issue is that commit cecf5d87ff20 assumes that concurrent
    write on 'queue/scheduler' can't happen. However, this assumption isn't
    true, because kernfs_fop_write() only guarantees that concurrent write
    aren't called on the same open file, but the write could be from
    different open on the file. So we can't release & re-acquire queue's
    sysfs lock during switching elevator, otherwise use-after-free on
    elevator could be triggered.
    
    Fixes the issue by not releasing queue's sysfs lock during switching
    elevator.
    
    Fixes: cecf5d87ff20 ("block: split .sysfs_lock into two locks")
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    (jwang: adjust ctx for 4.19)
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c63a7be2b11b378f77adfa8dd81e66b0df2795b
Author: Ming Lei <ming.lei@redhat.com>
Date:   Thu Sep 12 12:02:24 2019 +0800

    block: fix race between switching elevator and removing queues
    
    commit 0a67b5a926e63ff5492c3c675eab5900580d056d upstream.
    
    cecf5d87ff20 ("block: split .sysfs_lock into two locks") starts to
    release & actuire sysfs_lock again during switching elevator. So it
    isn't enough to prevent switching elevator from happening by simply
    clearing QUEUE_FLAG_REGISTERED with holding sysfs_lock, because
    in-progress switch still can move on after re-acquiring the lock,
    meantime the flag of QUEUE_FLAG_REGISTERED won't get checked.
    
    Fixes this issue by checking 'q->elevator' directly & locklessly after
    q->kobj is removed in blk_unregister_queue(), this way is safe because
    q->elevator can't be changed at that time.
    
    Fixes: cecf5d87ff20 ("block: split .sysfs_lock into two locks")
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa137b50f3264a157575413030464c19ab553b0e
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Aug 27 19:01:48 2019 +0800

    block: split .sysfs_lock into two locks
    
    commit cecf5d87ff2035127bb5a9ee054d0023a4a7cad3 upstream.
    
    The kernfs built-in lock of 'kn->count' is held in sysfs .show/.store
    path. Meantime, inside block's .show/.store callback, q->sysfs_lock is
    required.
    
    However, when mq & iosched kobjects are removed via
    blk_mq_unregister_dev() & elv_unregister_queue(), q->sysfs_lock is held
    too. This way causes AB-BA lock because the kernfs built-in lock of
    'kn-count' is required inside kobject_del() too, see the lockdep warning[1].
    
    On the other hand, it isn't necessary to acquire q->sysfs_lock for
    both blk_mq_unregister_dev() & elv_unregister_queue() because
    clearing REGISTERED flag prevents storing to 'queue/scheduler'
    from being happened. Also sysfs write(store) is exclusive, so no
    necessary to hold the lock for elv_unregister_queue() when it is
    called in switching elevator path.
    
    So split .sysfs_lock into two: one is still named as .sysfs_lock for
    covering sync .store, the other one is named as .sysfs_dir_lock
    for covering kobjects and related status change.
    
    sysfs itself can handle the race between add/remove kobjects and
    showing/storing attributes under kobjects. For switching scheduler
    via storing to 'queue/scheduler', we use the queue flag of
    QUEUE_FLAG_REGISTERED with .sysfs_lock for avoiding the race, then
    we can avoid to hold .sysfs_lock during removing/adding kobjects.
    
    [1]  lockdep warning
        ======================================================
        WARNING: possible circular locking dependency detected
        5.3.0-rc3-00044-g73277fc75ea0 #1380 Not tainted
        ------------------------------------------------------
        rmmod/777 is trying to acquire lock:
        00000000ac50e981 (kn->count#202){++++}, at: kernfs_remove_by_name_ns+0x59/0x72
    
        but task is already holding lock:
        00000000fb16ae21 (&q->sysfs_lock){+.+.}, at: blk_unregister_queue+0x78/0x10b
    
        which lock already depends on the new lock.
    
        the existing dependency chain (in reverse order) is:
    
        -> #1 (&q->sysfs_lock){+.+.}:
               __lock_acquire+0x95f/0xa2f
               lock_acquire+0x1b4/0x1e8
               __mutex_lock+0x14a/0xa9b
               blk_mq_hw_sysfs_show+0x63/0xb6
               sysfs_kf_seq_show+0x11f/0x196
               seq_read+0x2cd/0x5f2
               vfs_read+0xc7/0x18c
               ksys_read+0xc4/0x13e
               do_syscall_64+0xa7/0x295
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
        -> #0 (kn->count#202){++++}:
               check_prev_add+0x5d2/0xc45
               validate_chain+0xed3/0xf94
               __lock_acquire+0x95f/0xa2f
               lock_acquire+0x1b4/0x1e8
               __kernfs_remove+0x237/0x40b
               kernfs_remove_by_name_ns+0x59/0x72
               remove_files+0x61/0x96
               sysfs_remove_group+0x81/0xa4
               sysfs_remove_groups+0x3b/0x44
               kobject_del+0x44/0x94
               blk_mq_unregister_dev+0x83/0xdd
               blk_unregister_queue+0xa0/0x10b
               del_gendisk+0x259/0x3fa
               null_del_dev+0x8b/0x1c3 [null_blk]
               null_exit+0x5c/0x95 [null_blk]
               __se_sys_delete_module+0x204/0x337
               do_syscall_64+0xa7/0x295
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
        other info that might help us debug this:
    
         Possible unsafe locking scenario:
    
               CPU0                    CPU1
               ----                    ----
          lock(&q->sysfs_lock);
                                       lock(kn->count#202);
                                       lock(&q->sysfs_lock);
          lock(kn->count#202);
    
         *** DEADLOCK ***
    
        2 locks held by rmmod/777:
         #0: 00000000e69bd9de (&lock){+.+.}, at: null_exit+0x2e/0x95 [null_blk]
         #1: 00000000fb16ae21 (&q->sysfs_lock){+.+.}, at: blk_unregister_queue+0x78/0x10b
    
        stack backtrace:
        CPU: 0 PID: 777 Comm: rmmod Not tainted 5.3.0-rc3-00044-g73277fc75ea0 #1380
        Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20180724_192412-buildhw-07.phx4
        Call Trace:
         dump_stack+0x9a/0xe6
         check_noncircular+0x207/0x251
         ? print_circular_bug+0x32a/0x32a
         ? find_usage_backwards+0x84/0xb0
         check_prev_add+0x5d2/0xc45
         validate_chain+0xed3/0xf94
         ? check_prev_add+0xc45/0xc45
         ? mark_lock+0x11b/0x804
         ? check_usage_forwards+0x1ca/0x1ca
         __lock_acquire+0x95f/0xa2f
         lock_acquire+0x1b4/0x1e8
         ? kernfs_remove_by_name_ns+0x59/0x72
         __kernfs_remove+0x237/0x40b
         ? kernfs_remove_by_name_ns+0x59/0x72
         ? kernfs_next_descendant_post+0x7d/0x7d
         ? strlen+0x10/0x23
         ? strcmp+0x22/0x44
         kernfs_remove_by_name_ns+0x59/0x72
         remove_files+0x61/0x96
         sysfs_remove_group+0x81/0xa4
         sysfs_remove_groups+0x3b/0x44
         kobject_del+0x44/0x94
         blk_mq_unregister_dev+0x83/0xdd
         blk_unregister_queue+0xa0/0x10b
         del_gendisk+0x259/0x3fa
         ? disk_events_poll_msecs_store+0x12b/0x12b
         ? check_flags+0x1ea/0x204
         ? mark_held_locks+0x1f/0x7a
         null_del_dev+0x8b/0x1c3 [null_blk]
         null_exit+0x5c/0x95 [null_blk]
         __se_sys_delete_module+0x204/0x337
         ? free_module+0x39f/0x39f
         ? blkcg_maybe_throttle_current+0x8a/0x718
         ? rwlock_bug+0x62/0x62
         ? __blkcg_punt_bio_submit+0xd0/0xd0
         ? trace_hardirqs_on_thunk+0x1a/0x20
         ? mark_held_locks+0x1f/0x7a
         ? do_syscall_64+0x4c/0x295
         do_syscall_64+0xa7/0x295
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7fb696cdbe6b
        Code: 73 01 c3 48 8b 0d 1d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 008
        RSP: 002b:00007ffec9588788 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
        RAX: ffffffffffffffda RBX: 0000559e589137c0 RCX: 00007fb696cdbe6b
        RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000559e58913828
        RBP: 0000000000000000 R08: 00007ffec9587701 R09: 0000000000000000
        R10: 00007fb696d4eae0 R11: 0000000000000206 R12: 00007ffec95889b0
        R13: 00007ffec95896b3 R14: 0000559e58913260 R15: 0000559e589137c0
    
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    (jwang:cherry picked from commit cecf5d87ff2035127bb5a9ee054d0023a4a7cad3,
    adjust ctx for 4,19)
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f1ba7ee94ad1392fa4aace6d70cfece4e958ea0
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Aug 27 19:01:47 2019 +0800

    block: add helper for checking if queue is registered
    
    commit 58c898ba370e68d39470cd0d932b524682c1f9be upstream.
    
    There are 4 users which check if queue is registered, so add one helper
    to check it.
    
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1727e0e5c680938734586af2b5764c42fc16aec
Author: Rolf Eike Beer <eb@emlix.com>
Date:   Fri Feb 12 08:22:27 2021 +0100

    scripts: set proper OpenSSL include dir also for sign-file
    
    commit fe968c41ac4f4ec9ffe3c4cf16b72285f5e9674f upstream.
    
    Fixes: 2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto")
    Signed-off-by: Rolf Eike Beer <eb@emlix.com>
    Cc: stable@vger.kernel.org # 5.6.x
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c796145707dfe5d6276146e6fe82dcbe350769d0
Author: Rolf Eike Beer <eb@emlix.com>
Date:   Thu Nov 22 16:40:49 2018 +0100

    scripts: use pkg-config to locate libcrypto
    
    commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream.
    
    Otherwise build fails if the headers are not in the default location. While at
    it also ask pkg-config for the libs, with fallback to the existing value.
    
    Signed-off-by: Rolf Eike Beer <eb@emlix.com>
    Cc: stable@vger.kernel.org # 5.6.x
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c28da48cc54f273f6b2dffaf890f7e6f5d668e
Author: Sameer Pujar <spujar@nvidia.com>
Date:   Thu Jan 7 10:36:10 2021 +0530

    arm64: tegra: Add power-domain for Tegra210 HDA
    
    commit 1e0ca5467445bc1f41a9e403d6161a22f313dae7 upstream.
    
    HDA initialization is failing occasionally on Tegra210 and following
    print is observed in the boot log. Because of this probe() fails and
    no sound card is registered.
    
      [16.800802] tegra-hda 70030000.hda: no codecs found!
    
    Codecs request a state change and enumeration by the controller. In
    failure cases this does not seem to happen as STATETS register reads 0.
    
    The problem seems to be related to the HDA codec dependency on SOR
    power domain. If it is gated during HDA probe then the failure is
    observed. Building Tegra HDA driver into kernel image avoids this
    failure but does not completely address the dependency part. Fix this
    problem by adding 'power-domains' DT property for Tegra210 HDA. Note
    that Tegra186 and Tegra194 HDA do this already.
    
    Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
    Depends-on: 96d1f078ff0 ("arm64: tegra: Add SOR power-domain for Tegra210")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Acked-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23e895868b518f48eab7925aeb93aeeac3ac2594
Author: Rustam Kovhaev <rkovhaev@gmail.com>
Date:   Wed Feb 24 12:00:30 2021 -0800

    ntfs: check for valid standard information attribute
    
    commit 4dfe6bd94959222e18d512bdf15f6bf9edb9c27c upstream.
    
    Mounting a corrupted filesystem with NTFS resulted in a kernel crash.
    
    We should check for valid STANDARD_INFORMATION attribute offset and length
    before trying to access it
    
    Link: https://lkml.kernel.org/r/20210217155930.1506815-1-rkovhaev@gmail.com
    Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969
    Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
    Reported-by: syzbot+c584225dabdea2f71969@syzkaller.appspotmail.com
    Tested-by: syzbot+c584225dabdea2f71969@syzkaller.appspotmail.com
    Acked-by: Anton Altaparmakov <anton@tuxera.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c4a31480b728b706844a47c262d9562e2f86ada
Author: Stefan Ursella <stefan.ursella@wolfvision.net>
Date:   Wed Feb 10 15:07:11 2021 +0100

    usb: quirks: add quirk to start video capture on ELMO L-12F document camera reliable
    
    commit 1ebe718bb48278105816ba03a0408ecc2d6cf47f upstream.
    
    Without this quirk starting a video capture from the device often fails with
    
    kernel: uvcvideo: Failed to set UVC probe control : -110 (exp. 34).
    
    Signed-off-by: Stefan Ursella <stefan.ursella@wolfvision.net>
    Link: https://lore.kernel.org/r/20210210140713.18711-1-stefan.ursella@wolfvision.net
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 223a86b933bca7cf449f25af1c34ce2183a66711
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Feb 10 12:17:46 2021 +0100

    USB: quirks: sort quirk entries
    
    commit 43861d29c0810a70792bf69d37482efb7bb6677d upstream.
    
    Move the last entry to its proper place to maintain the VID/PID sort
    order.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20210210111746.13360-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffca531f71d078c6caf752d64bc2a592f420f7c6
Author: Will McVicker <willmcvicker@google.com>
Date:   Sat Dec 5 00:48:48 2020 +0000

    HID: make arrays usage and value to be the same
    
    commit ed9be64eefe26d7d8b0b5b9fa3ffdf425d87a01f upstream.
    
    The HID subsystem allows an "HID report field" to have a different
    number of "values" and "usages" when it is allocated. When a field
    struct is created, the size of the usage array is guaranteed to be at
    least as large as the values array, but it may be larger. This leads to
    a potential out-of-bounds write in
    __hidinput_change_resolution_multipliers() and an out-of-bounds read in
    hidinput_count_leds().
    
    To fix this, let's make sure that both the usage and value arrays are
    the same size.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Will McVicker <willmcvicker@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>