commit 1e5fd752d32d276166e48dc80e662cc913434c1d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 14 18:45:21 2022 +0200

    Linux 5.18.4
    
    Link: https://lore.kernel.org/r/20220613094926.497929857@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de
    Tested-by: Zan Aziz <zanaziz313@gmail.com>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Link: https://lore.kernel.org/r/20220613181233.078148768@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jiri Slaby <jirislaby@kernel.org>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdbcdddb8076a09aa6ddaf20fd911fc787dca0e5
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Thu May 26 08:15:28 2022 +0300

    net/mlx5: E-Switch, pair only capable devices
    
    commit 3008e6a0049361e731b803c60fe8f3ab44e1d73f upstream.
    
    OFFLOADS paring using devcom is possible only on devices
    that support LAG. Filter based on lag capabilities.
    
    This fixes an issue where mlx5_get_next_phys_dev() was
    called without holding the interface lock.
    
    This issue was found when commit
    bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")
    added an assert that verifies the interface lock is held.
    
    WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]
    Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]
    CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]
    Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff
    RSP: 0018:ffff88811bf47458 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001
    RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78
    RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437
    R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000
    R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428
    FS:  00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core]
     mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core]
     esw_offloads_enable+0x1153/0x1500 [mlx5_core]
     ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core]
     ? wait_for_completion_io_timeout+0x20/0x20
     ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core]
     mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core]
     ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core]
     ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core]
     ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core]
     ? __debugfs_create_file+0x260/0x3e0
     mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core]
     ? mutex_lock_io_nested+0x12c0/0x12c0
     ? esw_offloads_disable+0x250/0x250 [mlx5_core]
     ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470
     ? rcu_read_lock_sched_held+0x3f/0x70
     devlink_nl_cmd_eswitch_set_doit+0x217/0x620
    
    Fixes: dd3fddb82780 ("net/mlx5: E-Switch, handle devcom events only for ports on the same device")
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38ca71a24cd4845021eed35fd2594d89dba9a5a8
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 27 14:28:29 2022 -0700

    tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
    
    commit 11825765291a93d8e7f44230da67b9f607c777bf upstream.
    
    syzbot got a new report [1] finally pointing to a very old bug,
    added in initial support for MTU probing.
    
    tcp_mtu_probe() has checks about starting an MTU probe if
    tcp_snd_cwnd(tp) >= 11.
    
    But nothing prevents tcp_snd_cwnd(tp) to be reduced later
    and before the MTU probe succeeds.
    
    This bug would lead to potential zero-divides.
    
    Debugging added in commit 40570375356c ("tcp: add accessors
    to read/set tp->snd_cwnd") has paid off :)
    
    While we are at it, address potential overflows in this code.
    
    [1]
    WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
    Modules linked in:
    CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
    RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
    Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
    RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
    RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
    RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
    RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
    R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
    R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
    FS:  00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356
     tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861
     tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973
     tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476
     sk_backlog_rcv include/net/sock.h:1061 [inline]
     __release_sock+0x1d8/0x4c0 net/core/sock.c:2849
     release_sock+0x5d/0x1c0 net/core/sock.c:3404
     sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145
     tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410
     tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg net/socket.c:734 [inline]
     __sys_sendto+0x439/0x5c0 net/socket.c:2119
     __do_sys_sendto net/socket.c:2131 [inline]
     __se_sys_sendto net/socket.c:2127 [inline]
     __x64_sys_sendto+0xda/0xf0 net/socket.c:2127
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f6431289109
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109
    RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a
    RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
    
    Fixes: 5d424d5a674f ("[TCP]: MTU probing")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8c376772aab67bdb2f27db274d4ba29f4a97dd6
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Apr 26 15:32:06 2022 -0700

    dmaengine: idxd: add missing callback function to support DMA_INTERRUPT
    
    commit 2112b8f4fb5cc35d1c384324763765953186b81f upstream.
    
    When setting DMA_INTERRUPT capability, a callback function
    dma->device_prep_dma_interrupt() is needed to support this capability.
    Without setting the callback, dma_async_device_register() will fail dma
    capability check.
    
    Fixes: 4e5a4eb20393 ("dmaengine: idxd: set DMA_INTERRUPT cap bit")
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/165101232637.3951447.15765792791591763119.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d51ef87510365e70c559004bea6144f1b875990
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jun 11 10:30:20 2022 -0700

    iov_iter: fix build issue due to possible type mis-match
    
    commit 1c27f1fc1549f0e470429f5497a76ad28a37f21a upstream.
    
    Commit 6c77676645ad ("iov_iter: Fix iter_xarray_get_pages{,_alloc}()")
    introduced a problem on some 32-bit architectures (at least arm, xtensa,
    csky,sparc and mips), that have a 'size_t' that is 'unsigned int'.
    
    The reason is that we now do
    
        min(nr * PAGE_SIZE - offset, maxsize);
    
    where 'nr' and 'offset' and both 'unsigned int', and PAGE_SIZE is
    'unsigned long'.  As a result, the normal C type rules means that the
    first argument to 'min()' ends up being 'unsigned long'.
    
    In contrast, 'maxsize' is of type 'size_t'.
    
    Now, 'size_t' and 'unsigned long' are always the same physical type in
    the kernel, so you'd think this doesn't matter, and from an actual
    arithmetic standpoint it doesn't.
    
    But on 32-bit architectures 'size_t' is commonly 'unsigned int', even if
    it could also be 'unsigned long'.  In that situation, both are unsigned
    32-bit types, but they are not the *same* type.
    
    And as a result 'min()' will complain about the distinct types (ignore
    the "pointer types" part of the error message: that's an artifact of the
    way we have made 'min()' check types for being the same):
    
      lib/iov_iter.c: In function 'iter_xarray_get_pages':
      include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast [-Werror]
         20 |         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
            |                                   ^~
      lib/iov_iter.c:1464:16: note: in expansion of macro 'min'
       1464 |         return min(nr * PAGE_SIZE - offset, maxsize);
            |                ^~~
    
    This was not visible on 64-bit architectures (where we always define
    'size_t' to be 'unsigned long').
    
    Force these cases to use 'min_t(size_t, x, y)' to make the type explicit
    and avoid the issue.
    
    [ Nit-picky note: technically 'size_t' doesn't have to match 'unsigned
      long' arithmetically. We've certainly historically seen environments
      with 16-bit address spaces and 32-bit 'unsigned long'.
    
      Similarly, even in 64-bit modern environments, 'size_t' could be its
      own type distinct from 'unsigned long', even if it were arithmetically
      identical.
    
      So the above type commentary is only really descriptive of the kernel
      environment, not some kind of universal truth for the kinds of wild
      and crazy situations that are allowed by the C standard ]
    
    Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Link: https://lore.kernel.org/all/YqRyL2sIqQNDfky2@debian/
    Cc: Jeff Layton <jlayton@kernel.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a66a89cf202edd684b5c35523ddb02429cfc362f
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Thu Jun 2 23:16:57 2022 +0900

    zonefs: fix handling of explicit_open option on mount
    
    commit a2a513be7139b279f1b5b2cee59c6c4950c34346 upstream.
    
    Ignoring the explicit_open mount option on mount for devices that do not
    have a limit on the number of open zones must be done after the mount
    options are parsed and set in s_mount_opts. Move the check to ignore
    the explicit_open option after the call to zonefs_parse_options() in
    zonefs_fill_super().
    
    Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e2670ffd08975f452dfe435e209df66648aa7a0
Author: Pascal Hambourg <pascal@plouf.fr.eu.org>
Date:   Wed Apr 13 08:53:56 2022 +0200

    md/raid0: Ignore RAID0 layout if the second zone has only one device
    
    commit ea23994edc4169bd90d7a9b5908c6ccefd82fa40 upstream.
    
    The RAID0 layout is irrelevant if all members have the same size so the
    array has only one zone. It is *also* irrelevant if the array has two
    zones and the second zone has only one device, for example if the array
    has two members of different sizes.
    
    So in that case it makes sense to allow assembly even when the layout is
    undefined, like what is done when the array has only one zone.
    
    Reviewed-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60e198d152a9a17cd8107c284ec6a9fc1e96ee98
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 10:07:49 2022 +0200

    random: account for arch randomness in bits
    
    commit 77fc95f8c0dc9e1f8e620ec14d2fb65028fb7adc upstream.
    
    Rather than accounting in bytes and multiplying (shifting), we can just
    account in bits and avoid the shift. The main motivation for this is
    there are other patches in flux that expand this code a bit, and
    avoiding the duplication of "* 8" everywhere makes things a bit clearer.
    
    Cc: stable@vger.kernel.org
    Fixes: 12e45a2a6308 ("random: credit architectural init the exact amount")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e061ef6818f2aea2baacd5b5b2492a011936598a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 10:07:48 2022 +0200

    random: mark bootloader randomness code as __init
    
    commit 39e0f991a62ed5efabd20711a7b6e7da92603170 upstream.
    
    add_bootloader_randomness() and the variables it touches are only used
    during __init and not after, so mark these as __init. At the same time,
    unexport this, since it's only called by other __init code that's
    built-in.
    
    Cc: stable@vger.kernel.org
    Fixes: 428826f5358c ("fdt: add support for rng-seed")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63aac575f5b00362517bde2dc21357d1be668b3a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 10:07:47 2022 +0200

    random: avoid checking crng_ready() twice in random_init()
    
    commit 9b29b6b20376ab64e1b043df6301d8a92378e631 upstream.
    
    The current flow expands to:
    
        if (crng_ready())
           ...
        else if (...)
            if (!crng_ready())
                ...
    
    The second crng_ready() call is redundant, but can't so easily be
    optimized out by the compiler.
    
    This commit simplifies that to:
    
        if (crng_ready()
            ...
        else if (...)
            ...
    
    Fixes: 560181c27b58 ("random: move initialization functions out of hot pages")
    Cc: stable@vger.kernel.org
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7764a258356c454fe56b9f56fc07c0e146a3bccb
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jun 7 00:34:56 2022 +1000

    powerpc/32: Fix overread/overwrite of thread_struct via ptrace
    
    commit 8e1278444446fc97778a5e5c99bca1ce0bbc5ec9 upstream.
    
    The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
    to read/write registers of another process.
    
    To get/set a register, the API takes an index into an imaginary address
    space called the "USER area", where the registers of the process are
    laid out in some fashion.
    
    The kernel then maps that index to a particular register in its own data
    structures and gets/sets the value.
    
    The API only allows a single machine-word to be read/written at a time.
    So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels.
    
    The way floating point registers (FPRs) are addressed is somewhat
    complicated, because double precision float values are 64-bit even on
    32-bit CPUs. That means on 32-bit kernels each FPR occupies two
    word-sized locations in the USER area. On 64-bit kernels each FPR
    occupies one word-sized location in the USER area.
    
    Internally the kernel stores the FPRs in an array of u64s, or if VSX is
    enabled, an array of pairs of u64s where one half of each pair stores
    the FPR. Which half of the pair stores the FPR depends on the kernel's
    endianness.
    
    To handle the different layouts of the FPRs depending on VSX/no-VSX and
    big/little endian, the TS_FPR() macro was introduced.
    
    Unfortunately the TS_FPR() macro does not take into account the fact
    that the addressing of each FPR differs between 32-bit and 64-bit
    kernels. It just takes the index into the "USER area" passed from
    userspace and indexes into the fp_state.fpr array.
    
    On 32-bit there are 64 indexes that address FPRs, but only 32 entries in
    the fp_state.fpr array, meaning the user can read/write 256 bytes past
    the end of the array. Because the fp_state sits in the middle of the
    thread_struct there are various fields than can be overwritten,
    including some pointers. As such it may be exploitable.
    
    It has also been observed to cause systems to hang or otherwise
    misbehave when using gdbserver, and is probably the root cause of this
    report which could not be easily reproduced:
      https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@keymile.com/
    
    Rather than trying to make the TS_FPR() macro even more complicated to
    fix the bug, or add more macros, instead add a special-case for 32-bit
    kernels. This is more obvious and hopefully avoids a similar bug
    happening again in future.
    
    Note that because 32-bit kernels never have VSX enabled the code doesn't
    need to consider TS_FPRWIDTH/OFFSET at all. Add a BUILD_BUG_ON() to
    ensure that 32-bit && VSX is never enabled.
    
    Fixes: 87fec0514f61 ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds")
    Cc: stable@vger.kernel.org # v3.13+
    Reported-by: Ariel Miculas <ariel.miculas@belden.com>
    Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8757526018a2bdea711be66f77928fec7945221c
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Jun 8 14:14:22 2022 +0800

    virtio-rng: make device ready before making request
    
    commit 228432551bd8783211e494ab35f42a4344580502 upstream.
    
    Current virtio-rng does a entropy request before DRIVER_OK, this
    violates the spec:
    
    virtio spec requires that all drivers set DRIVER_OK
    before using devices.
    
    Further, kernel will ignore the interrupt after commit
    8b4ec69d7e09 ("virtio: harden vring IRQ").
    
    Fixing this by making device ready before the request.
    
    Cc: stable@vger.kernel.org
    Fixes: 8b4ec69d7e09 ("virtio: harden vring IRQ")
    Fixes: f7f510ec1957 ("virtio: An entropy device, as suggested by hpa.")
    Reported-and-tested-by: syzbot+5b59d6d459306a556f54@syzkaller.appspotmail.com
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20220608061422.38437-1-jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Laurent Vivier <lvivier@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d6d1e0367127084cbf27c364397107c10167e80
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 26 16:34:55 2022 -0400

    drm/amdgpu: update VCN codec support for Yellow Carp
    
    commit 97e50305542f384741a5b45699aba349fe9fca73 upstream.
    
    Supports AV1.  Mesa already has support for this and
    doesn't rely on the kernel caps for yellow carp, so
    this was already working from an application perspective.
    
    Fixes: 554398174d98 ("amdgpu/nv.c - Added video codec support for Yellow Carp")
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2002
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59f8908474ccb5544aec73fb55fba21973482321
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Thu Apr 14 15:48:30 2022 -0400

    drm/amd/display: remove stale config guards
    
    commit fd843d03418ead2bba369159bb19b60e9d4b7b1e upstream.
    
    This code should be executed.
    
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f0d829219ed9aeb7cce9c2797fbf9a3a9fa6c81
Author: Mohammad Zafar Ziya <Mohammadzafar.ziya@amd.com>
Date:   Tue Jun 7 11:38:16 2022 +0800

    drm/amdgpu/jpeg2: Add jpeg vmid update under IB submit
    
    commit 578eb31776df57c81307fb3f96ef0781332c3c7c upstream.
    
    Add jpeg vmid update under IB submit
    
    Signed-off-by: Mohammad Zafar Ziya <Mohammadzafar.ziya@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2449e870b4f604065c9da958fb05ce8070309da
Author: Brian Norris <briannorris@chromium.org>
Date:   Mon Feb 28 12:25:32 2022 -0800

    drm/atomic: Force bridge self-refresh-exit on CRTC switch
    
    commit e54a4424925a27ed94dff046db3ce5caf4b1e748 upstream.
    
    It's possible to change which CRTC is in use for a given
    connector/encoder/bridge while we're in self-refresh without fully
    disabling the connector/encoder/bridge along the way. This can confuse
    the bridge encoder/bridge, because
    (a) it needs to track the SR state (trying to perform "active"
        operations while the panel is still in SR can be Bad(TM)); and
    (b) it tracks the SR state via the CRTC state (and after the switch, the
        previous SR state is lost).
    
    Thus, we need to either somehow carry the self-refresh state over to the
    new CRTC, or else force an encoder/bridge self-refresh transition during
    such a switch.
    
    I choose the latter, so we disable the encoder (and exit PSR) before
    attaching it to the new CRTC (where we can continue to assume a clean
    (non-self-refresh) state).
    
    This fixes PSR issues seen on Rockchip RK3399 systems with
    drivers/gpu/drm/bridge/analogix/analogix_dp_core.c.
    
    Change in v2:
    
    - Drop "->enable" condition; this could possibly be "->active" to
      reflect the intended hardware state, but it also is a little
      over-specific. We want to make a transition through "disabled" any
      time we're exiting PSR at the same time as a CRTC switch.
      (Thanks Liu Ying)
    
    Cc: Liu Ying <victor.liu@oss.nxp.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in drivers")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.2.Ic15a2ef69c540aee8732703103e2cff51fb9c399@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28e8eadd6737c527a0cfec50f752a7ba4fad399c
Author: Brian Norris <briannorris@chromium.org>
Date:   Mon Feb 28 12:25:31 2022 -0800

    drm/bridge: analogix_dp: Support PSR-exit to disable transition
    
    commit ca871659ec1606d33b1e76de8d4cf924cf627e34 upstream.
    
    Most eDP panel functions only work correctly when the panel is not in
    self-refresh. In particular, analogix_dp_bridge_disable() tends to hit
    AUX channel errors if the panel is in self-refresh.
    
    Given the above, it appears that so far, this driver assumes that we are
    never in self-refresh when it comes time to fully disable the bridge.
    Prior to commit 846c7dfc1193 ("drm/atomic: Try to preserve the crtc
    enabled state in drm_atomic_remove_fb, v2."), this tended to be true,
    because we would automatically disable the pipe when framebuffers were
    removed, and so we'd typically disable the bridge shortly after the last
    display activity.
    
    However, that is not guaranteed: an idle (self-refresh) display pipe may
    be disabled, e.g., when switching CRTCs. We need to exit PSR first.
    
    Stable notes: this is definitely a bugfix, and the bug has likely
    existed in some form for quite a while. It may predate the "PSR helpers"
    refactor, but the code looked very different before that, and it's
    probably not worth rewriting the fix.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.1.I161904be17ba14526f78536ccd78b85818449b51@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6139da2064e6d7160f59ba12d3dcfe59628b4a9
Author: Jesse Zhang <Jesse.Zhang@amd.com>
Date:   Tue Jun 7 10:44:57 2022 +0800

    drm/amdkfd:Fix fw version for 10.3.6
    
    commit a956a11ee669d069047525c8ec897b4c21a9cda1 upstream.
    
    fix fw error when loading fw for 10.3.6
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 5.18.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6790a55b78589e903286eb043376938239aee776
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed May 25 13:26:39 2022 +1000

    powerpc: Don't select HAVE_IRQ_EXIT_ON_IRQ_STACK
    
    commit 1346d00e1bdfd4067f92bc14e8a6131a01de4190 upstream.
    
    The HAVE_IRQ_EXIT_ON_IRQ_STACK option tells generic code that irq_exit()
    is called while still running on the hard irq stack (hardirq_ctx[] in
    the powerpc code).
    
    Selecting the option means the generic code will *not* switch to the
    softirq stack before running softirqs, because the code is already
    running on the (mostly empty) hard irq stack.
    
    But since commit 1b1b6a6f4cc0 ("powerpc: handle irq_enter/irq_exit in
    interrupt handler wrappers"), irq_exit() is now called on the regular task
    stack, not the hard irq stack.
    
    That's because previously irq_exit() was called in __do_irq() which is
    run on the hard irq stack, but now it is called in
    interrupt_async_exit_prepare() which is called from do_irq() constructed
    by the wrapper macro, which is after the switch back to the task stack.
    
    So drop HAVE_IRQ_EXIT_ON_IRQ_STACK from the Kconfig. This will mean an
    extra stack switch when processing some interrupts, but should
    significantly reduce the likelihood of stack overflow.
    
    It also means the softirq stack will be used for running softirqs from
    other interrupts that don't use the hard irq stack, eg. timer interrupts.
    
    Fixes: 1b1b6a6f4cc0 ("powerpc: handle irq_enter/irq_exit in interrupt handler wrappers")
    Cc: stable@vger.kernel.org # v5.12+
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220525032639.1947280-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95c8181b4947e000f3b9b8e5918d899fce77b93d
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Wed Jun 8 15:18:34 2022 -0400

    mm/huge_memory: Fix xarray node memory leak
    
    commit 69a37a8ba1b408a1c7616494aa7018e4b3844cbe upstream.
    
    If xas_split_alloc() fails to allocate the necessary nodes to complete the
    xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()
    then interprets as "Please allocate more memory", not as "Please free
    any unnecessary memory" (which was the intended outcome).  It's confusing
    to use xas_nomem() to free memory in this context, so call xas_destroy()
    instead.
    
    Reported-by: syzbot+9e27a75a8c24f3fe75c1@syzkaller.appspotmail.com
    Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86ae8646de48b47678b2209c3429b944404df499
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Jun 8 16:27:27 2022 +0200

    cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
    
    commit 32d4fd5751eadbe1823a37eb38df85ec5c8e6207 upstream.
    
    Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
    Xeons") wrecked intel_idle in two ways:
    
     - must not have tracing in idle functions
     - must return with IRQs disabled
    
    Additionally, it added a branch for no good reason.
    
    Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    [ rjw: Moved the intel_idle() kerneldoc comment next to the function ]
    Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b22fdee17ec62604060fb0fda5e1414b634666e1
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Tue Apr 26 15:36:56 2022 +0800

    vduse: Fix NULL pointer dereference on sysfs access
    
    commit b27ee76c74dc831d6e092eaebc2dfc9c0beed1c9 upstream.
    
    The control device has no drvdata. So we will get a
    NULL pointer dereference when accessing control
    device's msg_timeout attribute via sysfs:
    
    [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8
    [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)
    [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)
    [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)
    [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)
    [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)
    [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)
    [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)
    [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)
    [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))
    [ 132.876319][ T3644] kernel_read (fs/read_write.c:459)
    [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)
    [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)
    [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)
    [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)
    [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)
    [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)
    
    To fix it, don't create the unneeded attribute for
    control device anymore.
    
    Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Message-Id: <20220426073656.229-1-xieyongji@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37d5f35e218814f357a212789a544e8b69100404
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Jun 7 12:11:33 2022 -0700

    Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag
    
    commit c42e65664390be7c1ef3838cd84956d3a2739d60 upstream.
    
    The bcm5974 driver does the allocation and dma mapping of the usb urb
    data buffer, but driver does not set the URB_NO_TRANSFER_DMA_MAP flag
    to let usb core know the buffer is already mapped.
    
    usb core tries to map the already mapped buffer, causing a warning:
    "xhci_hcd 0000:00:14.0: rejecting DMA map of vmalloc memory"
    
    Fix this by setting the URB_NO_TRANSFER_DMA_MAP, letting usb core
    know buffer is already mapped by bcm5974 driver
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215890
    Link: https://lore.kernel.org/r/20220606113636.588955-1-mathias.nyman@linux.intel.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e21c7f349139dfecd94a002ea9130f00bd4bd763
Author: Olivier Matz <olivier.matz@6wind.com>
Date:   Wed Apr 6 11:52:52 2022 +0200

    ixgbe: fix unexpected VLAN Rx in promisc mode on VF
    
    commit 7bb0fb7c63df95d6027dc50d6af3bc3bbbc25483 upstream.
    
    When the promiscuous mode is enabled on a VF, the IXGBE_VMOLR_VPE
    bit (VLAN Promiscuous Enable) is set. This means that the VF will
    receive packets whose VLAN is not the same than the VLAN of the VF.
    
    For instance, in this situation:
    
    ┌────────┐    ┌────────┐    ┌────────┐
    │        │    │        │    │        │
    │        │    │        │    │        │
    │     VF0├────┤VF1  VF2├────┤VF3     │
    │        │    │        │    │        │
    └────────┘    └────────┘    └────────┘
       VM1           VM2           VM3
    
    vf 0:  vlan 1000
    vf 1:  vlan 1000
    vf 2:  vlan 1001
    vf 3:  vlan 1001
    
    If we tcpdump on VF3, we see all the packets, even those transmitted
    on vlan 1000.
    
    This behavior prevents to bridge VF1 and VF2 in VM2, because it will
    create a loop: packets transmitted on VF1 will be received by VF2 and
    vice-versa, and bridged again through the software bridge.
    
    This patch remove the activation of VLAN Promiscuous when a VF enables
    the promiscuous mode. However, the IXGBE_VMOLR_UPE bit (Unicast
    Promiscuous) is kept, so that a VF receives all packets that has the
    same VLAN, whatever the destination MAC address.
    
    Fixes: 8443c1a4b192 ("ixgbe, ixgbevf: Add new mbox API xcast mode")
    Cc: stable@vger.kernel.org
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4c9025bc5d96775d4343b12372366b3bd689ef7
Author: Olivier Matz <olivier.matz@6wind.com>
Date:   Wed Apr 6 11:52:51 2022 +0200

    ixgbe: fix bcast packets Rx on VF after promisc removal
    
    commit 803e9895ea2b0fe80bc85980ae2d7a7e44037914 upstream.
    
    After a VF requested to remove the promiscuous flag on an interface, the
    broadcast packets are not received anymore. This breaks some protocols
    like ARP.
    
    In ixgbe_update_vf_xcast_mode(), we should keep the IXGBE_VMOLR_BAM
    bit (Broadcast Accept) on promiscuous removal.
    
    This flag is already set by default in ixgbe_set_vmolr() on VF reset.
    
    Fixes: 8443c1a4b192 ("ixgbe, ixgbevf: Add new mbox API xcast mode")
    Cc: stable@vger.kernel.org
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a06dd0878897d514812927ced06dc7601af2027
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:29 2022 -0500

    nfc: st21nfca: fix incorrect sizing calculations in EVT_TRANSACTION
    
    commit f2e19b36593caed4c977c2f55aeba7408aeb2132 upstream.
    
    The transaction buffer is allocated by using the size of the packet buf,
    and subtracting two which seem intended to remove the two tags which are
    not present in the target structure. This calculation leads to under
    counting memory because of differences between the packet contents and the
    target structure. The aid_len field is a u8 in the packet, but a u32 in
    the structure, resulting in at least 3 bytes always being under counted.
    Further, the aid data is a variable length field in the packet, but fixed
    in the structure, so if this field is less than the max, the difference is
    added to the under counting.
    
    The last validation check for transaction->params_len is also incorrect
    since it employs the same accounting error.
    
    To fix, perform validation checks progressively to safely reach the
    next field, to determine the size of both buffers and verify both tags.
    Once all validation checks pass, allocate the buffer and copy the data.
    This eliminates freeing memory on the error path, as those checks are
    moved ahead of memory allocation.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55904086041ba4ee4070187b36590f8f8d6df4cd
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:28 2022 -0500

    nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
    
    commit 996419e0594abb311fb958553809f24f38e7abbe upstream.
    
    Error paths do not free previously allocated memory. Add devm_kfree() to
    those failure paths.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c24da513deb5c6582cf2e50b30c7ed4a5ba4b84f
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:27 2022 -0500

    nfc: st21nfca: fix incorrect validating logic in EVT_TRANSACTION
    
    commit 77e5fe8f176a525523ae091d6fd0fbb8834c156d upstream.
    
    The first validation check for EVT_TRANSACTION has two different checks
    tied together with logical AND. One is a check for minimum packet length,
    and the other is for a valid aid_tag. If either condition is true (fails),
    then an error should be triggered.  The fix is to change && to ||.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e5ae583cc6b34a6efce741d1145279fa76e2b70
Author: Jchao Sun <sunjunchao2870@gmail.com>
Date:   Tue May 24 08:05:40 2022 -0700

    writeback: Fix inode->i_io_list not be protected by inode->i_lock error
    
    commit 10e14073107dd0b6d97d9516a02845a8e501c2c9 upstream.
    
    Commit b35250c0816c ("writeback: Protect inode->i_io_list with
    inode->i_lock") made inode->i_io_list not only protected by
    wb->list_lock but also inode->i_lock, but inode_io_list_move_locked()
    was missed. Add lock there and also update comment describing
    things protected by inode->i_lock. This also fixes a race where
    __mark_inode_dirty() could move inode under flush worker's hands
    and thus sync(2) could miss writing some inodes.
    
    Fixes: b35250c0816c ("writeback: Protect inode->i_io_list with inode->i_lock")
    Link: https://lore.kernel.org/r/20220524150540.12552-1-sunjunchao2870@gmail.com
    CC: stable@vger.kernel.org
    Signed-off-by: Jchao Sun <sunjunchao2870@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1e05a0e592f54e2777e8e422e4ca58e12ccc2f0
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Tue Jun 7 00:11:40 2022 +0200

    net: openvswitch: fix misuse of the cached connection on tuple changes
    
    commit 2061ecfdf2350994e5b61c43e50e98a7a70e95ee upstream.
    
    If packet headers changed, the cached nfct is no longer relevant
    for the packet and attempt to re-use it leads to the incorrect packet
    classification.
    
    This issue is causing broken connectivity in OpenStack deployments
    with OVS/OVN due to hairpin traffic being unexpectedly dropped.
    
    The setup has datapath flows with several conntrack actions and tuple
    changes between them:
    
      actions:ct(commit,zone=8,mark=0/0x1,nat(src)),
              set(eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:06)),
              set(ipv4(src=172.18.2.10,dst=192.168.100.6,ttl=62)),
              ct(zone=8),recirc(0x4)
    
    After the first ct() action the packet headers are almost fully
    re-written.  The next ct() tries to re-use the existing nfct entry
    and marks the packet as invalid, so it gets dropped later in the
    pipeline.
    
    Clearing the cached conntrack entry whenever packet tuple is changed
    to avoid the issue.
    
    The flow key should not be cleared though, because we should still
    be able to match on the ct_state if the recirculation happens after
    the tuple change but before the next ct() action.
    
    Cc: stable@vger.kernel.org
    Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
    Reported-by: Frode Nordahl <frode.nordahl@canonical.com>
    Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051829.html
    Link: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/1967856
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Link: https://lore.kernel.org/r/20220606221140.488984-1-i.maximets@ovn.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29ba9ba90a5fce7a5054def194ab409af3b76ea1
Author: Tan Tee Min <tee.min.tan@linux.intel.com>
Date:   Thu May 26 17:03:47 2022 +0800

    net: phy: dp83867: retrigger SGMII AN when link change
    
    commit c76acfb7e19dcc3a0964e0563770b1d11b8d4540 upstream.
    
    There is a limitation in TI DP83867 PHY device where SGMII AN is only
    triggered once after the device is booted up. Even after the PHY TPI is
    down and up again, SGMII AN is not triggered and hence no new in-band
    message from PHY to MAC side SGMII.
    
    This could cause an issue during power up, when PHY is up prior to MAC.
    At this condition, once MAC side SGMII is up, MAC side SGMII wouldn`t
    receive new in-band message from TI PHY with correct link status, speed
    and duplex info.
    
    As suggested by TI, implemented a SW solution here to retrigger SGMII
    Auto-Neg whenever there is a link change.
    
    v2: Add Fixes tag in commit message.
    
    Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy")
    Cc: <stable@vger.kernel.org> # 5.4.x
    Signed-off-by: Sit, Michael Wei Hong <michael.wei.hong.sit@intel.com>
    Reviewed-by: Voon Weifeng <weifeng.voon@intel.com>
    Signed-off-by: Tan Tee Min <tee.min.tan@linux.intel.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220526090347.128742-1-tee.min.tan@linux.intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3967849c295c797462b7ecbb2b2a1bccfd642c26
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue May 31 20:19:22 2022 +0300

    mmc: block: Fix CQE recovery reset success
    
    commit a051246b786af7e4a9d9219cc7038a6e8a411531 upstream.
    
    The intention of the use of mmc_blk_reset_success() in
    mmc_blk_cqe_recovery() was to prevent repeated resets when retrying and
    getting the same error. However, that may not be the case - any amount
    of time and I/O may pass before another recovery is needed, in which
    case there would be no reason to deny it the opportunity to recover via
    a reset if necessary. CQE recovery is expected seldom and failure to
    recover (if the clear tasks command fails), even more seldom, so it is
    better to allow the reset always, which can be done by calling
    mmc_blk_reset_success() always.
    
    Fixes: 1e8e55b67030c6 ("mmc: block: Add CQE support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20220531171922.76080-1-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78ab0efb5a2231767ce3a82a370ab1d31e818b74
Author: Ben Chuang <benchuanggli@gmail.com>
Date:   Fri May 20 19:42:42 2022 +0800

    mmc: sdhci-pci-gli: Fix GL9763E runtime PM when the system resumes from suspend
    
    commit 291e7d52d19f114cad6cbf802f3f19ef12a011f8 upstream.
    
    When the system resumes from suspend (S3 or S4), the power mode is
    MMC_POWER_OFF. In this status, gl9763e_runtime_resume() should not enable
    PLL. Add a condition to this function to enable PLL only when the power
    mode is MMC_POWER_ON.
    
    Fixes: d607667bb8fa (mmc: sdhci-pci-gli: Add runtime PM for GL9763E)
    Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220520114242.150235-1-benchuanggli@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa7e200741058d6370b7185865bc0e06fec3aefd
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Wed Jun 8 22:51:07 2022 +0300

    ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files
    
    commit 72aad489f992871e908ff6d9055b26c6366fb864 upstream.
    
    The {dma|pio}_mode sysfs files are incorrectly documented as having a
    list of the supported DMA/PIO transfer modes, while the corresponding
    fields of the *struct* ata_device hold the transfer mode IDs, not masks.
    
    To match these docs, the {dma|pio}_mode (and even xfer_mode!) sysfs
    files are handled by the ata_bitfield_name_match() macro which leads to
    reading such kind of nonsense from them:
    
    $ cat /sys/class/ata_device/dev3.0/pio_mode
    XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_MW_DMA_4,
    XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2, XFER_PIO_1,
    XFER_PIO_0
    
    Using the correct ata_bitfield_name_search() macro fixes that:
    
    $ cat /sys/class/ata_device/dev3.0/pio_mode
    XFER_PIO_4
    
    While fixing the file documentation, somewhat reword the {dma|pio}_mode
    file doc and add a note about being mostly useful for PATA devices to
    the xfer_mode file doc...
    
    Fixes: d9027470b886 ("[libata] Add ATA transport class")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46557980e54604a5b1f314296031d0c53237bd84
Author: Tyler Erickson <tyler.erickson@seagate.com>
Date:   Thu Jun 2 16:51:12 2022 -0600

    libata: fix translation of concurrent positioning ranges
    
    commit 6d11acd452fd885ef6ace184c9c70bc863a8c72f upstream.
    
    Fixing the page length in the SCSI translation for the concurrent
    positioning ranges VPD page. It was writing starting in offset 3
    rather than offset 2 where the MSB is supposed to start for
    the VPD page length.
    
    Cc: stable@vger.kernel.org
    Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
    Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
    Reviewed-by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
    Tested-by: Michael English <michael.english@seagate.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fff8dad2d0ab0e26e37bf1929dc6912deb423b8
Author: Tyler Erickson <tyler.erickson@seagate.com>
Date:   Thu Jun 2 16:51:11 2022 -0600

    libata: fix reading concurrent positioning ranges log
    
    commit c745dfc541e78428ba3986f1d17fe1dfdaca8184 upstream.
    
    The concurrent positioning ranges log is not a fixed size and may depend
    on how many ranges are supported by the device. This patch uses the size
    reported in the GPL directory to determine the number of pages supported
    by the device before attempting to read this log page.
    
    This resolves this error from the dmesg output:
        ata6.00: Read log 0x47 page 0x00 failed, Emask 0x1
    
    Cc: stable@vger.kernel.org
    Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
    Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
    Reviewed-by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
    Tested-by: Michael English <michael.english@seagate.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 361a0daa25516fa81d66002fa34ef618695b48c6
Author: David Safford <david.safford@gmail.com>
Date:   Tue Jun 7 14:07:57 2022 -0400

    KEYS: trusted: tpm2: Fix migratable logic
    
    commit dda5384313a40ecbaafd8a9a80f47483255e4c4d upstream.
    
    When creating (sealing) a new trusted key, migratable
    trusted keys have the FIXED_TPM and FIXED_PARENT attributes
    set, and non-migratable keys don't. This is backwards, and
    also causes creation to fail when creating a migratable key
    under a migratable parent. (The TPM thinks you are trying to
    seal a non-migratable blob under a migratable parent.)
    
    The following simple patch fixes the logic, and has been
    tested for all four combinations of migratable and non-migratable
    trusted keys and parent storage keys. With this logic, you will
    get a proper failure if you try to create a non-migratable
    trusted key under a migratable parent storage key, and all other
    combinations work correctly.
    
    Cc: stable@vger.kernel.org # v5.13+
    Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable")
    Signed-off-by: David Safford <david.safford@gmail.com>
    Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    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 db58eef8cca9a94ebc115dfdde33b4e3e0e217c6
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Wed May 25 14:23:45 2022 -0400

    filemap: Cache the value of vm_flags
    
    commit dcfa24ba68991ab69a48254a18377b45180ae664 upstream.
    
    After we have unlocked the mmap_lock for I/O, the file is pinned, but
    the VMA is not.  Checking this flag after that can be a use-after-free.
    It's not a terribly interesting use-after-free as it can only read one
    bit, and it's used to decide whether to read 2MB or 4MB.  But it
    upsets the automated tools and it's generally bad practice anyway,
    so let's fix it.
    
    Reported-by: syzbot+5b96d55e5b54924c77ad@syzkaller.appspotmail.com
    Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1021a1bc47668aa715b7f2121086c9598bffcbf
Author: Maxim Levitsky <mlevitsk@redhat.com>
Date:   Mon Jun 6 21:11:49 2022 +0300

    KVM: SVM: fix tsc scaling cache logic
    
    commit 11d39e8cc43e1c6737af19ca9372e590061b5ad2 upstream.
    
    SVM uses a per-cpu variable to cache the current value of the
    tsc scaling multiplier msr on each cpu.
    
    Commit 1ab9287add5e2
    ("KVM: X86: Add vendor callbacks for writing the TSC multiplier")
    broke this caching logic.
    
    Refactor the code so that all TSC scaling multiplier writes go through
    a single function which checks and updates the cache.
    
    This fixes the following scenario:
    
    1. A CPU runs a guest with some tsc scaling ratio.
    
    2. New guest with different tsc scaling ratio starts on this CPU
       and terminates almost immediately.
    
       This ensures that the short running guest had set the tsc scaling ratio just
       once when it was set via KVM_SET_TSC_KHZ. Due to the bug,
       the per-cpu cache is not updated.
    
    3. The original guest continues to run, it doesn't restore the msr
       value back to its own value, because the cache matches,
       and thus continues to run with a wrong tsc scaling ratio.
    
    Fixes: 1ab9287add5e2 ("KVM: X86: Add vendor callbacks for writing the TSC multiplier")
    Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
    Message-Id: <20220606181149.103072-1-mlevitsk@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2609a0c1410de3f62d2e89695df54b0e0fa4850b
Author: Shaoqin Huang <shaoqin.huang@intel.com>
Date:   Mon Jun 6 18:59:05 2022 -0600

    KVM: x86/mmu: Check every prev_roots in __kvm_mmu_free_obsolete_roots()
    
    commit cf4a8693d97a51dccf5a1557248d12d6d8be4b9e upstream.
    
    When freeing obsolete previous roots, check prev_roots as intended, not
    the current root.
    
    Signed-off-by: Shaoqin Huang <shaoqin.huang@intel.com>
    Fixes: 527d5cd7eece ("KVM: x86/mmu: Zap only obsolete roots if a root shadow page is zapped")
    Message-Id: <20220607005905.2933378-1-shaoqin.huang@intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68fcff1127e4995ddbd4b6861892a25c23db3f70
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:24 2022 -0700

    scsi: lpfc: Address NULL pointer dereference after starget_to_rport()
    
    commit 6f808bd78e8296b4ded813b7182988d57e1f6176 upstream.
    
    Calls to starget_to_rport() may return NULL.  Add check for NULL rport
    before dereference.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-5-jsmart2021@gmail.com
    Fixes: bb21fc9911ee ("scsi: lpfc: Use fc_block_rport()")
    Cc: <stable@vger.kernel.org> # v5.18
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a5a226aac567043698fa185577b10379b540bb4
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:23 2022 -0700

    scsi: lpfc: Resolve some cleanup issues following SLI path refactoring
    
    commit e27f05147bff21408c1b8410ad8e90cd286e7952 upstream.
    
    Following refactoring and consolidation in SLI processing, fix up some
    minor issues related to SLI path:
    
     - Correct the setting of LPFC_EXCHANGE_BUSY flag in response IOCB.
    
     - Fix some typographical errors.
    
     - Fix duplicate log messages.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-4-jsmart2021@gmail.com
    Fixes: 1b64aa9eae28 ("scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4")
    Cc: <stable@vger.kernel.org> # v5.18
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dab48081e68cdda482d871d09ab598994d814d6c
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:22 2022 -0700

    scsi: lpfc: Resolve some cleanup issues following abort path refactoring
    
    commit 24e1f056677eefe834d5dcf61905cce857ca4b19 upstream.
    
    Refactoring and consolidation of abort paths:
    
     - lpfc_sli4_abort_fcp_cmpl() and lpfc_sli_abort_fcp_cmpl() are combined
      into a single generic lpfc_sli_abort_fcp_cmpl() routine.  Thus, remove
      extraneous lpfc_sli4_abort_fcp_cmpl() prototype declaration.
    
     - lpfc_nvme_abort_fcreq_cmpl() abort completion routine is called with a
      mismatched argument type.  This may result in misleading log message
      content.  Update to the correct argument type of lpfc_iocbq instead of
      lpfc_wcqe_complete.  The lpfc_wcqe_complete should be derived from the
      lpfc_iocbq structure.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-3-jsmart2021@gmail.com
    Fixes: 31a59f75702f ("scsi: lpfc: SLI path split: Refactor Abort paths")
    Cc: <stable@vger.kernel.org> # v5.18
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e53f4312ac0b6c3196b87488201c4b14a8dbbf08
Author: Tyler Erickson <tyler.erickson@seagate.com>
Date:   Thu Jun 2 16:51:13 2022 -0600

    scsi: sd: Fix interpretation of VPD B9h length
    
    commit f92de9d110429e39929a49240d823251c2fe903e upstream.
    
    Fixing the interpretation of the length of the B9h VPD page (Concurrent
    Positioning Ranges). Adding 4 is necessary as the first 4 bytes of the page
    is the header with page number and length information.  Adding 3 was likely
    a misinterpretation of the SBC-5 specification which sets all offsets
    starting at zero.
    
    This fixes the error in dmesg:
    
    [ 9.014456] sd 1:0:0:0: [sda] Invalid Concurrent Positioning Ranges VPD page
    
    Link: https://lore.kernel.org/r/20220602225113.10218-4-tyler.erickson@seagate.com
    Fixes: e815d36548f0 ("scsi: sd: add concurrent positioning ranges support")
    Cc: stable@vger.kernel.org
    Tested-by: Michael English <michael.english@seagate.com>
    Reviewed-by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
    Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c190bf54360c69e89607255c7ad48db6554888bb
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Mon Jun 6 09:52:46 2022 +0000

    cifs: populate empty hostnames for extra channels
    
    commit 4c14d7043fede258957d7b01da0cad2d9fe3a205 upstream.
    
    Currently, the secondary channels of a multichannel session
    also get hostname populated based on the info in primary channel.
    However, this will end up with a wrong resolution of hostname to
    IP address during reconnect.
    
    This change fixes this by not populating hostname info for all
    secondary channels.
    
    Fixes: 5112d80c162f ("cifs: populate server_hostname for extra channels")
    Cc: stable@vger.kernel.org
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c841ad19170b7ba9f2484ba58e3f9c29b6322cc
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Sun Jun 5 19:54:26 2022 -0300

    cifs: fix reconnect on smb3 mount types
    
    commit c36ee7dab7749f7be21f7a72392744490b2a9a2b upstream.
    
    cifs.ko defines two file system types: cifs & smb3, and
    __cifs_get_super() was not including smb3 file system type when
    looking up superblocks, therefore failing to reconnect tcons in
    cifs_tree_connect().
    
    Fix this by calling iterate_supers_type() on both file system types.
    
    Link: https://lore.kernel.org/r/CAFrh3J9soC36+BVuwHB=g9z_KB5Og2+p2_W+BBoBOZveErz14w@mail.gmail.com
    Cc: stable@vger.kernel.org
    Tested-by: Satadru Pramanik <satadru@gmail.com>
    Reported-by: Satadru Pramanik <satadru@gmail.com>
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e922b1df2672e76d19872831cd6840eeb3b9aacf
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Tue May 31 12:31:05 2022 +0000

    cifs: return errors during session setup during reconnects
    
    commit 8ea21823aa584b55ba4b861307093b78054b0c1b upstream.
    
    During reconnects, we check the return value from
    cifs_negotiate_protocol, and have handlers for both success
    and failures. But if that passes, and cifs_setup_session
    returns any errors other than -EACCES, we do not handle
    that. This fix adds a handler for that, so that we don't
    go ahead and try a tree_connect on a failed session.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7aabf07bb0063452f4c2e973ea39ee0d972aa8ee
Author: Jeremy Soller <jeremy@system76.com>
Date:   Wed Jun 8 08:01:11 2022 -0600

    ALSA: hda/realtek: Add quirk for HP Dev One
    
    commit 5f3d696eea916693b2d4ed7e62794653fcdd6ec0 upstream.
    
    Enables the audio mute LEDs and limits the mic boost to avoid picking up
    noise.
    
    Signed-off-by: Jeremy Soller <jeremy@system76.com>
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220608140111.23170-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab77a478650a153c8941fdca06c69398aee39da7
Author: Cameron Berkenpas <cam@neo-zeon.de>
Date:   Sun Jun 5 17:23:30 2022 -0700

    ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo Yoga DuetITL 2021
    
    commit 85743a847caeab696dafc4ce1a7e1e2b7e29a0f6 upstream.
    
    Enables the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS quirk for the Lenovo
    Yoga DuetITL 2021 laptop to fix speaker output.
    
    [ re-sorted in the SSID order by tiwai ]
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
    Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de>
    Co-authored-by: Songine <donglingluoying@gmail.com>
    Cc: stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606002329.215330-1-cam@neo-zeon.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0047ef32e2c043ae42ae5b06ea650f6d4eac25f
Author: huangwenhui <huangwenhuia@uniontech.com>
Date:   Tue Jun 7 14:56:31 2022 +0800

    ALSA: hda/conexant - Fix loopback issue with CX20632
    
    commit d5ea7544c32ba27c2c5826248e4ff58bd50a2518 upstream.
    
    On a machine with CX20632, Alsamixer doesn't have 'Loopback
    Mixing' and 'Line'.
    
    Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220607065631.10708-1-huangwenhuia@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc68c6a2d80f8b4995aec08f84e08b8d89633877
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 6 18:09:10 2022 +0200

    ALSA: usb-audio: Set up (implicit) sync for Saffire 6
    
    commit e0469d6581aecb0e34e2ec64f39f88e6985cc52f upstream.
    
    Focusrite Saffire 6 has fixed audioformat quirks with multiple
    endpoints assigned to a single altsetting.  Unfortunately the generic
    parser couldn't detect the sync endpoint correctly as the implicit
    sync due to the missing EP attribute bits.  In the former kernels, it
    used to work somehow casually, but it's been broken for a while after
    the large code change in 5.11.
    
    This patch cures the regression by the following:
    - Allow the static quirk table to provide the sync EP information;
      we just need to fill the fields and let the generic parser skipping
      parsing if sync_ep is already set.
    - Add the sync endpoint information to the entry for Saffire 6.
    
    Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks")
    Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606160910.6926-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 368248554afde80b99b05189a1fa2001be9ed600
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 6 18:09:09 2022 +0200

    ALSA: usb-audio: Skip generic sync EP parse for secondary EP
    
    commit efb75df105e82f076a85b9f2d81410428bcb55fc upstream.
    
    When ep_idx is already non-zero, it means usually a capture stream
    that is set up explicity by a fixed-format quirk, and applying the
    check for generic (non-implicit-fb) sync EPs might hit incorrectly,
    resulting in a bogus sync endpoint for the capture stream.
    
    This patch adds a check for the ep_idx and skip if it's a secondary
    endpoint.  It's a part of the fixes for regressions on Saffire 6.
    
    Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks")
    Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606160910.6926-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1b3c926bc06b816315411b0b62e2c99c7a73380
Author: Bedant Patnaik <bedant.patnaik@gmail.com>
Date:   Thu Jun 9 00:58:43 2022 +0530

    platform/x86: hp-wmi: Use zero insize parameter only when supported
    
    [ Upstream commit 65f936f3535950d2643eac5bf34a735a0e428cdd ]
    
    commit be9d73e64957 ("platform/x86: hp-wmi: Fix 0x05 error code reported by
    several WMI calls") and commit 12b19f14a21a ("platform/x86: hp-wmi: Fix
    hp_wmi_read_int() reporting error (0x05)") cause ACPI BIOS Error (bug):
    Attempt to CreateField of length zero (20211217/dsopcode-133) because of
    the ACPI method HWMC, which unconditionally creates a Field of
    size (insize*8) bits:
            CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN)
    In cases where args->insize = 0, the Field size is 0, resulting in
    an error.
    
    Fix this by using zero insize only if 0x5 error code is returned
    
    Tested on Omen 15 AMD (2020) board ID: 8786.
    
    Fixes: be9d73e64957 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls")
    Signed-off-by: Bedant Patnaik <bedant.patnaik@gmail.com>
    Tested-by: Jorge Lopez <jorge.lopez2@hp.com>
    Link: https://lore.kernel.org/r/41be46743d21c78741232a47bbb5f1cdbcc3d21e.camel@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5233018847a8701be733deb77c97cb9851aa2191
Author: Jorge Lopez <jorge.lopez2@hp.com>
Date:   Wed Jun 8 16:29:23 2022 -0500

    platform/x86: hp-wmi: Resolve WMI query failures on some devices
    
    [ Upstream commit dc6a6ab58379f25bf991d8e4a13b001ed806e881 ]
    
    WMI queries fail on some devices where the ACPI method HWMC
    unconditionally attempts to create Fields beyond the buffer
    if the buffer is too small, this breaks essential features
    such as power profiles:
    
             CreateByteField (Arg1, 0x10, D008)
             CreateByteField (Arg1, 0x11, D009)
             CreateByteField (Arg1, 0x12, D010)
             CreateDWordField (Arg1, 0x10, D032)
             CreateField (Arg1, 0x80, 0x0400, D128)
    
    In cases where args->data had zero length, ACPI BIOS Error
    (bug): AE_AML_BUFFER_LIMIT, Field [D008] at bit
    offset/length 128/8 exceeds size of target Buffer (128 bits)
    (20211217/dsopcode-198) was obtained.
    
    ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D009] at bit
    offset/length 136/8 exceeds size of target Buffer (136bits)
    (20211217/dsopcode-198)
    
    The original code created a buffer size of 128 bytes regardless if
    the WMI call required a smaller buffer or not.  This particular
    behavior occurs in older BIOS and reproduced in OMEN laptops.  Newer
    BIOS handles buffer sizes properly and meets the latest specification
    requirements.  This is the reason why testing with a dynamically
    allocated buffer did not uncover any failures with the test systems at
    hand.
    
    This patch was tested on several OMEN, Elite, and Zbooks.  It was
    confirmed the patch resolves HPWMI_FAN GET/SET calls in an OMEN
    Laptop 15-ek0xxx.  No problems were reported when testing on several Elite
    and Zbooks notebooks.
    
    Fixes: 4b4967cbd268 ("platform/x86: hp-wmi: Changing bios_args.data to be dynamically allocated")
    Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220608212923.8585-2-jorge.lopez2@hp.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5894295210037873c59e9781bf1aea61fb5033e9
Author: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Date:   Fri Jun 10 15:14:57 2022 +0800

    scripts/gdb: change kernel config dumping method
    
    [ Upstream commit 1f7a6cf6b07c74a17343c2559cd5f5018a245961 ]
    
    MAGIC_START("IKCFG_ST") and MAGIC_END("IKCFG_ED") are moved out
    from the kernel_config_data variable.
    
    Thus, we parse kernel_config_data directly instead of considering
    offset of MAGIC_START and MAGIC_END.
    
    Fixes: 13610aa908dc ("kernel/configs: use .incbin directive to embed config_data.gz")
    Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3cbbb2b10be9c7387dbb2e490d202a98c2376ecc
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu May 26 17:03:45 2022 +0800

    platform/x86: barco-p50-gpio: Add check for platform_driver_register
    
    [ Upstream commit 011881b80ebe773914b59905bce0f5e0ef93e7ba ]
    
    As platform_driver_register() could fail, it should be better
    to deal with the return value in order to maintain the code
    consisitency.
    
    Fixes: 86af1d02d458 ("platform/x86: Support for EC-connected GPIOs for identify LED/button on Barco P50 board")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Peter Korsgaard <peter.korsgaard@barco.com>
    Link: https://lore.kernel.org/r/20220526090345.1444172-1-jiasheng@iscas.ac.cn
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8df021ccdf956192e7e9cb4325f47ad26dba2cae
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Thu May 5 18:09:10 2022 +0800

    vringh: Fix loop descriptors check in the indirect cases
    
    [ Upstream commit dbd29e0752286af74243cf891accf472b2f3edd8 ]
    
    We should use size of descriptor chain to test loop condition
    in the indirect case. And another statistical count is also introduced
    for indirect descriptors to avoid conflict with the statistical count
    of direct descriptors.
    
    Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.")
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Signed-off-by: Fam Zheng <fam.zheng@bytedance.com>
    Message-Id: <20220505100910.137-1-xieyongji@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2c915b04730b9657cd952b0737adfbabbebe8a9
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:21 2022 -0700

    scsi: lpfc: Correct BDE type for XMIT_SEQ64_WQE in lpfc_ct_reject_event()
    
    [ Upstream commit 44ba9786b67345dc4e5eabe537c9ef2bfd889888 ]
    
    A previous commit assumed all XMIT_SEQ64_WQEs are prepped with the correct
    BDE type in word 0-2.  However, lpfc_ct_reject_event() routine was missed
    and is still filling out the incorrect BDE type.
    
    Fix lpfc_ct_reject_event() routine so that type BUFF_TYPE_BDE_64 is set
    instead of BUFF_TYPE_BLP_64.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-2-jsmart2021@gmail.com
    Fixes: 596fc8adb171 ("scsi: lpfc: Fix dmabuf ptr assignment in lpfc_ct_reject_event()")
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69e14b7a783d239192506ed14be42772e3667d38
Author: Kees Cook <keescook@chromium.org>
Date:   Wed May 18 13:52:23 2022 -0700

    nodemask: Fix return values to be unsigned
    
    [ Upstream commit 0dfe54071d7c828a02917b595456bfde1afdddc9 ]
    
    The nodemask routines had mixed return values that provided potentially
    signed return values that could never happen. This was leading to the
    compiler getting confusing about the range of possible return values
    (it was thinking things could be negative where they could not be). Fix
    all the nodemask routines that should be returning unsigned
    (or bool) values. Silences:
    
     mm/swapfile.c: In function ‘setup_swap_info’:
     mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds of ‘struct plist_node[]’ [-Werror=array-bounds]
      2291 |                                 p->avail_lists[i].prio = 1;
           |                                 ~~~~~~~~~~~~~~^~~
     In file included from mm/swapfile.c:16:
     ./include/linux/swap.h:292:27: note: while referencing ‘avail_lists’
       292 |         struct plist_node avail_lists[]; /*
           |                           ^~~~~~~~~~~
    
    Reported-by: Christophe de Dinechin <dinechin@redhat.com>
    Link: https://lore.kernel.org/lkml/20220414150855.2407137-3-dinechin@redhat.com/
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Yury Norov <yury.norov@gmail.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa6bd4d05e956953abddb5bec5fa7a90173bf7bf
Author: Yury Norov <yury.norov@gmail.com>
Date:   Thu Apr 28 13:51:16 2022 -0700

    drm/amd/pm: use bitmap_{from,to}_arr32 where appropriate
    
    [ Upstream commit 525d6515604eb1373ce5e6372a6b6640953b2d6a ]
    
    The smu_v1X_0_set_allowed_mask() uses bitmap_copy() to convert
    bitmap to 32-bit array. This may be wrong due to endiannes issues.
    Fix it by switching to bitmap_{from,to}_arr32.
    
    CC: Alexander Gordeev <agordeev@linux.ibm.com>
    CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    CC: Christian Borntraeger <borntraeger@linux.ibm.com>
    CC: Claudio Imbrenda <imbrenda@linux.ibm.com>
    CC: David Hildenbrand <david@redhat.com>
    CC: Heiko Carstens <hca@linux.ibm.com>
    CC: Janosch Frank <frankja@linux.ibm.com>
    CC: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    CC: Sven Schnelle <svens@linux.ibm.com>
    CC: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60f3f1c48c456d8f9cc95c09c7ec0edb66150bfa
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Jun 1 22:08:46 2022 -0500

    cifs: version operations for smb20 unneeded when legacy support disabled
    
    [ Upstream commit 7ef93ffccd55fb0ba000ed16ef6a81cd7dee07b5 ]
    
    We should not be including unused smb20 specific code when legacy
    support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
    off).  For example smb2_operations and smb2_values aren't used
    in that case.  Over time we can move more and more SMB1/CIFS and SMB2.0
    code into the insecure legacy ifdefs
    
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc748d55ae36c0d28ea788e711e9cff5f2168722
Author: Christian Borntraeger <borntraeger@linux.ibm.com>
Date:   Mon May 30 11:27:05 2022 +0200

    s390/gmap: voluntarily schedule during key setting
    
    [ Upstream commit 6d5946274df1fff539a7eece458a43be733d1db8 ]
    
    With large and many guest with storage keys it is possible to create
    large latencies or stalls during initial key setting:
    
    rcu: INFO: rcu_sched self-detected stall on CPU
    rcu:   18-....: (2099 ticks this GP) idle=54e/1/0x4000000000000002 softirq=35598716/35598716 fqs=998
           (t=2100 jiffies g=155867385 q=20879)
    Task dump for CPU 18:
    CPU 1/KVM       R  running task        0 1030947 256019 0x06000004
    Call Trace:
    sched_show_task
    rcu_dump_cpu_stacks
    rcu_sched_clock_irq
    update_process_times
    tick_sched_handle
    tick_sched_timer
    __hrtimer_run_queues
    hrtimer_interrupt
    do_IRQ
    ext_int_handler
    ptep_zap_key
    
    The mmap lock is held during the page walking but since this is a
    semaphore scheduling is still possible. Same for the kvm srcu.
    To minimize overhead do this on every segment table entry or large page.
    
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220530092706.11637-2-borntraeger@linux.ibm.com
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dfa95e7ffdb415b061bef6e29e687b21e26f1c34
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Wed Jun 1 00:03:18 2022 -0500

    cifs: fix potential deadlock in direct reclaim
    
    [ Upstream commit cc391b694ff085f62f133e6b8f864d43a8e69dfd ]
    
    The srv_mutex is used during writeback so cifs should ensure that
    allocations done when that mutex is held are done with GFP_NOFS, to
    avoid having direct reclaim ending up waiting for the same mutex and
    causing a deadlock.  This is detected by lockdep with the splat below:
    
     ======================================================
     WARNING: possible circular locking dependency detected
     5.18.0 #70 Not tainted
     ------------------------------------------------------
     kswapd0/49 is trying to acquire lock:
     ffff8880195782e0 (&tcp_ses->srv_mutex){+.+.}-{3:3}, at: compound_send_recv
    
     but task is already holding lock:
     ffffffffa98e66c0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #1 (fs_reclaim){+.+.}-{0:0}:
            fs_reclaim_acquire
            kmem_cache_alloc_trace
            __request_module
            crypto_alg_mod_lookup
            crypto_alloc_tfm_node
            crypto_alloc_shash
            cifs_alloc_hash
            smb311_crypto_shash_allocate
            smb311_update_preauth_hash
            compound_send_recv
            cifs_send_recv
            SMB2_negotiate
            smb2_negotiate
            cifs_negotiate_protocol
            cifs_get_smb_ses
            cifs_mount
            cifs_smb3_do_mount
            smb3_get_tree
            vfs_get_tree
            path_mount
            __x64_sys_mount
            do_syscall_64
            entry_SYSCALL_64_after_hwframe
    
     -> #0 (&tcp_ses->srv_mutex){+.+.}-{3:3}:
            __lock_acquire
            lock_acquire
            __mutex_lock
            mutex_lock_nested
            compound_send_recv
            cifs_send_recv
            SMB2_write
            smb2_sync_write
            cifs_write
            cifs_writepage_locked
            cifs_writepage
            shrink_page_list
            shrink_lruvec
            shrink_node
            balance_pgdat
            kswapd
            kthread
            ret_from_fork
    
     other info that might help us debug this:
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(fs_reclaim);
                                    lock(&tcp_ses->srv_mutex);
                                    lock(fs_reclaim);
       lock(&tcp_ses->srv_mutex);
    
      *** DEADLOCK ***
    
     1 lock held by kswapd0/49:
      #0: ffffffffa98e66c0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat
    
     stack backtrace:
     CPU: 2 PID: 49 Comm: kswapd0 Not tainted 5.18.0 #70
     Call Trace:
      <TASK>
      dump_stack_lvl
      dump_stack
      print_circular_bug.cold
      check_noncircular
      __lock_acquire
      lock_acquire
      __mutex_lock
      mutex_lock_nested
      compound_send_recv
      cifs_send_recv
      SMB2_write
      smb2_sync_write
      cifs_write
      cifs_writepage_locked
      cifs_writepage
      shrink_page_list
      shrink_lruvec
      shrink_node
      balance_pgdat
      kswapd
      kthread
      ret_from_fork
      </TASK>
    
    Fix this by using the memalloc_nofs_save/restore APIs around the places
    where the srv_mutex is held.  Do this in a wrapper function for the
    lock/unlock of the srv_mutex, and rename the srv_mutex to avoid missing
    call sites in the conversion.
    
    Note that there is another lockdep warning involving internal crypto
    locks, which was masked by this problem and is visible after this fix,
    see the discussion in this thread:
    
     https://lore.kernel.org/all/20220523123755.GA13668@axis.com/
    
    Link: https://lore.kernel.org/r/CANT5p=rqcYfYMVHirqvdnnca4Mo+JQSw5Qu12v=kPfpk5yhhmg@mail.gmail.com/
    Reported-by: Shyam Prasad N <nspmangalore@gmail.com>
    Suggested-by: Lars Persson <larper@axis.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fd49d91110f75b57cfcebe6a42efc24c9ef3f34
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:56 2022 -0500

    Revert "PCI: brcmstb: Split brcm_pcie_setup() into two funcs"
    
    [ Upstream commit f4fd559de3434c44bed1d2912bd0c75cfa42898b ]
    
    This reverts commit 830aa6f29f07a4e2f1a947dfa72b3ccddb46dd21.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-5-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8975fc6ad72ceb4f0a789ac4ac22de5dc158908b
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:55 2022 -0500

    Revert "PCI: brcmstb: Add mechanism to turn on subdev regulators"
    
    [ Upstream commit 420be2f7ebe60c9ba3e332f5290017cd168e2bf8 ]
    
    This reverts commit 67211aadcb4b968d0fdc57bc27240fa71500c2d4.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-4-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ba46fe658a7563948d7e24535f9d6c216ca7eee
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:54 2022 -0500

    Revert "PCI: brcmstb: Add control of subdevice voltage regulators"
    
    [ Upstream commit 212942609d83b591f5a2f2691df122d13aa3a87d ]
    
    This reverts commit 93e41f3fca3d4a0f927b784012338c37f80a8a80.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-3-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 101bbb0edae9bdd3200d2be5f33adc3538d5071a
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:53 2022 -0500

    Revert "PCI: brcmstb: Do not turn off WOL regulators on suspend"
    
    [ Upstream commit 7894025c783ca36394d3afe49c8cfb4c830b82fe ]
    
    This reverts commit 11ed8b8624b8085f706864b4addcd304b1e4fc38.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-2-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 141318e62db87105b0103fccc59c9c5940da248d
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:47 2022 +0800

    nbd: fix io hung while disconnecting device
    
    [ Upstream commit 09dadb5985023e27d4740ebd17e6fea4640110e5 ]
    
    In our tests, "qemu-nbd" triggers a io hung:
    
    INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
          Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:qemu-nbd        state:D stack:    0 pid:11445 ppid:     1 flags:0x00000000
    Call Trace:
     <TASK>
     __schedule+0x480/0x1050
     ? _raw_spin_lock_irqsave+0x3e/0xb0
     schedule+0x9c/0x1b0
     blk_mq_freeze_queue_wait+0x9d/0xf0
     ? ipi_rseq+0x70/0x70
     blk_mq_freeze_queue+0x2b/0x40
     nbd_add_socket+0x6b/0x270 [nbd]
     nbd_ioctl+0x383/0x510 [nbd]
     blkdev_ioctl+0x18e/0x3e0
     __x64_sys_ioctl+0xac/0x120
     do_syscall_64+0x35/0x80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7fd8ff706577
    RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577
    RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f
    RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0
    R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d
    R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0
    
    "qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following
    message was found:
    
    block nbd0: Send disconnect failed -32
    
    Which indicate that something is wrong with the server. Then,
    "qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear
    requests after commit 2516ab1543fd("nbd: only clear the queue on device
    teardown"). And in the meantime, request can't complete through timeout
    because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which
    means such request will never be completed in this situation.
    
    Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't
    complete multiple times, switch back to call nbd_clear_sock() in
    nbd_clear_sock_ioctl(), so that inflight requests can be cleared.
    
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-5-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d09525720dd5201756f698bee1076de9aefd4602
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:45 2022 +0800

    nbd: fix race between nbd_alloc_config() and module removal
    
    [ Upstream commit c55b2b983b0fa012942c3eb16384b2b722caa810 ]
    
    When nbd module is being removing, nbd_alloc_config() may be
    called concurrently by nbd_genl_connect(), although try_module_get()
    will return false, but nbd_alloc_config() doesn't handle it.
    
    The race may lead to the leak of nbd_config and its related
    resources (e.g, recv_workq) and oops in nbd_read_stat() due
    to the unload of nbd module as shown below:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000040
      Oops: 0000 [#1] SMP PTI
      CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
      Workqueue: knbd16-recv recv_work [nbd]
      RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd]
      Call Trace:
       recv_work+0x3b/0xb0 [nbd]
       process_one_work+0x1ed/0x390
       worker_thread+0x4a/0x3d0
       kthread+0x12a/0x150
       ret_from_fork+0x22/0x30
    
    Fixing it by checking the return value of try_module_get()
    in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),
    assign nbd->config only when nbd_alloc_config() succeeds to ensure
    the value of nbd->config is binary (valid or NULL).
    
    Also adding a debug message to check the reference counter
    of nbd_config during module removal.
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-3-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d5da1ffba3388c2ae2e6c598855a4d887d3bf79
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:44 2022 +0800

    nbd: call genl_unregister_family() first in nbd_cleanup()
    
    [ Upstream commit 06c4da89c24e7023ea448cadf8e9daf06a0aae6e ]
    
    Otherwise there may be race between module removal and the handling of
    netlink command, which can lead to the oops as shown below:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000098
      Oops: 0002 [#1] SMP PTI
      CPU: 1 PID: 31299 Comm: nbd-client Tainted: G            E     5.14.0-rc4
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
      RIP: 0010:down_write+0x1a/0x50
      Call Trace:
       start_creating+0x89/0x130
       debugfs_create_dir+0x1b/0x130
       nbd_start_device+0x13d/0x390 [nbd]
       nbd_genl_connect+0x42f/0x748 [nbd]
       genl_family_rcv_msg_doit.isra.0+0xec/0x150
       genl_rcv_msg+0xe5/0x1e0
       netlink_rcv_skb+0x55/0x100
       genl_rcv+0x29/0x40
       netlink_unicast+0x1a8/0x250
       netlink_sendmsg+0x21b/0x430
       ____sys_sendmsg+0x2a4/0x2d0
       ___sys_sendmsg+0x81/0xc0
       __sys_sendmsg+0x62/0xb0
       __x64_sys_sendmsg+0x1f/0x30
       do_syscall_64+0x3b/0xc0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      Modules linked in: nbd(E-)
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-2-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eee5b9761b0a5a00a5b3a95fc394f8a36994b51b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon May 2 12:30:20 2022 +0200

    jump_label,noinstr: Avoid instrumentation for JUMP_LABEL=n builds
    
    [ Upstream commit 656d054e0a15ec327bd82801ccd58201e59f6896 ]
    
    When building x86_64 with JUMP_LABEL=n it's possible for
    instrumentation to sneak into noinstr:
    
    vmlinux.o: warning: objtool: exit_to_user_mode+0x14: call to static_key_count.constprop.0() leaves .noinstr.text section
    vmlinux.o: warning: objtool: syscall_exit_to_user_mode+0x2d: call to static_key_count.constprop.0() leaves .noinstr.text section
    vmlinux.o: warning: objtool: irqentry_exit_to_user_mode+0x1b: call to static_key_count.constprop.0() leaves .noinstr.text section
    
    Switch to arch_ prefixed atomic to avoid the explicit instrumentation.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ac122e7dd32359a694b1efe8b1e92641fdbb5c4
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon May 2 12:15:23 2022 +0200

    x86/cpu: Elide KCSAN for cpu_has() and friends
    
    [ Upstream commit a6a5eb269f6f3a2fe392f725a8d9052190c731e2 ]
    
    As x86 uses the <asm-generic/bitops/instrumented-*.h> headers, the
    regular forms of all bitops are instrumented with explicit calls to
    KASAN and KCSAN checks. As these are explicit calls, these are not
    suppressed by the noinstr function attribute.
    
    This can result in calls to those check functions in noinstr code, which
    objtool warns about:
    
    vmlinux.o: warning: objtool: enter_from_user_mode+0x24: call to __kcsan_check_access() leaves .noinstr.text section
    vmlinux.o: warning: objtool: syscall_enter_from_user_mode+0x28: call to __kcsan_check_access() leaves .noinstr.text section
    vmlinux.o: warning: objtool: syscall_enter_from_user_mode_prepare+0x24: call to __kcsan_check_access() leaves .noinstr.text section
    vmlinux.o: warning: objtool: irqentry_enter_from_user_mode+0x24: call to __kcsan_check_access() leaves .noinstr.text section
    
    Prevent this by using the arch_*() bitops, which are the underlying
    bitops without explciit instrumentation.
    
    [null: Changelog]
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20220502111216.290518605@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5cd416def441befd75c39bfa516a4eb4b3c7ff9
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon May 2 11:15:14 2022 +0200

    objtool: Mark __ubsan_handle_builtin_unreachable() as noreturn
    
    [ Upstream commit 385bd430c011a8cb8278e61c32d602d11e06f414 ]
    
      fs/ntfs3/ntfs3.prelink.o: warning: objtool: ni_read_frame() falls through to next function ni_readpage_cmpr.cold()
    
    That is in fact:
    
    000000000000124a <ni_read_frame.cold>:
        124a:       44 89 e0                mov    %r12d,%eax
        124d:       0f b6 55 98             movzbl -0x68(%rbp),%edx
        1251:       48 c7 c7 00 00 00 00    mov    $0x0,%rdi        1254: R_X86_64_32S      .data+0x1380
        1258:       48 89 c6                mov    %rax,%rsi
        125b:       e8 00 00 00 00          call   1260 <ni_read_frame.cold+0x16>   125c: R_X86_64_PLT32    __ubsan_handle_shift_out_of_bounds-0x4
        1260:       48 8d 7d cc             lea    -0x34(%rbp),%rdi
        1264:       e8 00 00 00 00          call   1269 <ni_read_frame.cold+0x1f>   1265: R_X86_64_PLT32    __tsan_read4-0x4
        1269:       8b 45 cc                mov    -0x34(%rbp),%eax
        126c:       e9 00 00 00 00          jmp    1271 <ni_read_frame.cold+0x27>   126d: R_X86_64_PC32     .text+0x19109
        1271:       48 8b 75 a0             mov    -0x60(%rbp),%rsi
        1275:       48 63 d0                movslq %eax,%rdx
        1278:       48 c7 c7 00 00 00 00    mov    $0x0,%rdi        127b: R_X86_64_32S      .data+0x13a0
        127f:       89 45 88                mov    %eax,-0x78(%rbp)
        1282:       e8 00 00 00 00          call   1287 <ni_read_frame.cold+0x3d>   1283: R_X86_64_PLT32    __ubsan_handle_shift_out_of_bounds-0x4
        1287:       8b 45 88                mov    -0x78(%rbp),%eax
        128a:       e9 00 00 00 00          jmp    128f <ni_read_frame.cold+0x45>   128b: R_X86_64_PC32     .text+0x19098
        128f:       48 c7 c7 00 00 00 00    mov    $0x0,%rdi        1292: R_X86_64_32S      .data+0x11f0
        1296:       e8 00 00 00 00          call   129b <ni_readpage_cmpr.cold>     1297: R_X86_64_PLT32    __ubsan_handle_builtin_unreachable-0x4
    
    000000000000129b <ni_readpage_cmpr.cold>:
    
    Tell objtool that __ubsan_handle_builtin_unreachable() is a noreturn.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20220502091514.GB479834@worktop.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 487dc59ce08ab43e535a73014c6a3133db35cbec
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue May 24 01:46:22 2022 +0900

    modpost: fix undefined behavior of is_arm_mapping_symbol()
    
    [ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ]
    
    The return value of is_arm_mapping_symbol() is unpredictable when "$"
    is passed in.
    
    strchr(3) says:
      The strchr() and strrchr() functions return a pointer to the matched
      character or NULL if the character is not found. The terminating null
      byte is considered part of the string, so that if c is specified as
      '\0', these functions return a pointer to the terminator.
    
    When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is
    referenced (i.e. buffer overrun).
    
    Test code
    ---------
    
      char str1[] = "abc";
      char str2[] = "ab";
    
      strcpy(str1, "$");
      strcpy(str2, "$");
    
      printf("test1: %d\n", is_arm_mapping_symbol(str1));
      printf("test2: %d\n", is_arm_mapping_symbol(str2));
    
    Result
    ------
    
      test1: 0
      test2: 1
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf867a0c16ed5090a6b43a6c0de217966f700766
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri May 6 15:46:12 2022 +0200

    um: line: Use separate IRQs per line
    
    [ Upstream commit d5a9597d6916a76663085db984cb8fe97f0a5c56 ]
    
    Today, all possible serial lines (ssl*=) as well as all
    possible consoles (con*=) each share a single interrupt
    (with a fixed number) with others of the same type.
    
    Now, if you have two lines, say ssl0 and ssl1, and one
    of them is connected to an fd you cannot read (e.g. a
    file), but the other gets a read interrupt, then both
    of them get the interrupt since it's shared. Then, the
    read() call will return EOF, since it's a file being
    written and there's nothing to read (at least not at
    the current offset, at the end).
    
    Unfortunately, this is treated as a read error, and we
    close this line, losing all the possible output.
    
    It might be possible to work around this and make the
    IRQ sharing work, however, now that we have dynamically
    allocated IRQs that are easy to use, simply use that to
    achieve separating between the events; then there's no
    interrupt for that line and we never attempt the read
    in the first place, thus not closing the line.
    
    This manifested itself in the wifi hostap/hwsim tests
    where the parallel script communicates via one serial
    console and the kernel messages go to another (a file)
    and sending data on the communication console caused
    the kernel messages to stop flowing into the file.
    
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Acked-By: anton ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11b9a1ee1a3504b1ddf211374f792625257d858b
Author: Evan Quan <evan.quan@amd.com>
Date:   Wed Apr 6 14:14:50 2022 +0800

    drm/amd/pm: correct the metrics version for SMU 11.0.11/12/13
    
    [ Upstream commit 396beb91a9eb86cbfa404e4220cca8f3ada70777 ]
    
    Correct the metrics version used for SMU 11.0.11/12/13.
    Fixes misreported GPU metrics (e.g., fan speed, etc.) depending
    on which version of SMU firmware is loaded.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1925
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1712b06ccb83a3ebc18b707e8baf4137f80bd177
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Thu May 19 10:50:25 2022 +0530

    drm/amd/pm: Fix missing thermal throttler status
    
    [ Upstream commit b0f4d663fce6a4232d3c20ce820f919111b1c60b ]
    
    On aldebaran, when thermal throttling happens due to excessive GPU
    temperature, the reason for throttling event is missed in warning
    message. This patch fixes it.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 359bdb1344e2bfc7f7191a0f15367e3843af3952
Author: Gong Yuanjun <ruc_gongyuanjun@163.com>
Date:   Tue May 17 17:57:46 2022 +0800

    drm/amd/pm: fix a potential gpu_metrics_table memory leak
    
    [ Upstream commit d2f4460a3d9502513419f06cc376c7ade49d5753 ]
    
    gpu_metrics_table is allocated in yellow_carp_init_smc_tables() but
    not freed in yellow_carp_fini_smc_tables().
    
    Signed-off-by: Gong Yuanjun <ruc_gongyuanjun@163.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 140d9807b96e1303f6f2675a7ae8710a2094bd17
Author: Gong Yuanjun <ruc_gongyuanjun@163.com>
Date:   Tue May 17 17:57:00 2022 +0800

    drm/radeon: fix a possible null pointer dereference
    
    [ Upstream commit a2b28708b645c5632dc93669ab06e97874c8244f ]
    
    In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
    is assigned to mode, which will lead to a NULL pointer dereference
    on failure of drm_mode_duplicate(). Add a check to avoid npd.
    
    The failure status of drm_cvt_mode() on the other path is checked too.
    
    Signed-off-by: Gong Yuanjun <ruc_gongyuanjun@163.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cd0db426c6afa28b37e90be29e65c09cc9830e0
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Thu May 5 16:50:42 2022 -0400

    drm/amd/display: Check zero planes for OTG disable W/A on clock change
    
    [ Upstream commit 66a197203794339b028eedfa880bff9367fce783 ]
    
    [Why]
    A display clock change hang can occur when switching between DIO and HPO
    enabled modes during the optimize_bandwidth in dc_commit_state_no_check
    call.
    
    This happens when going from 4k120 8bpc 420 to 4k144 10bpc 444.
    
    Display clock in the DIO case is 1200MHz, but pixel rate is 600MHz
    because the pixel format is 420.
    
    Display clock in the HPO case is less (800MHz?) because of ODM combine
    which results in a smaller divider.
    
    The DIO is still active in prepare but not active in the optimize which
    results in the hang occuring.
    
    During this change there are no planes on the stream so it's safe to
    apply the workaround, but dpms_off = false and signal type is not
    virtual.
    
    [How]
    Check for plane_count == 0, no planes on the stream.
    
    It's easiest to check pipe->plane_state == NULL as an equivalent check
    rather than trying to search for the stream status in the context
    associated with the stream, so let's do that.
    
    The primary, non MPO pipe should not have a NULL plane state.
    
    Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07efce8269a038c37814eb656b4de14aa3015fc6
Author: David Galiffi <David.Galiffi@amd.com>
Date:   Tue May 3 18:30:25 2022 -0400

    drm/amd/display: Check if modulo is 0 before dividing.
    
    [ Upstream commit 49947b906a6bd9668eaf4f9cf691973c25c26955 ]
    
    [How & Why]
    If a value of 0 is read, then this will cause a divide-by-0 panic.
    
    Reviewed-by: Martin Leung <Martin.Leung@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: David Galiffi <David.Galiffi@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9654b440ff503d9e5296c8c84b6f01d9672c1585
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed May 25 00:56:18 2022 +0200

    net, neigh: Set lower cap for neigh_managed_work rearming
    
    [ Upstream commit ed6cd6a17896561b9f51ab4c0d9bbb29e762b597 ]
    
    Yuwei reported that plain reuse of DELAY_PROBE_TIME to rearm work queue
    in neigh_managed_work is problematic if user explicitly configures the
    DELAY_PROBE_TIME to 0 for a neighbor table. Such misconfig can then hog
    CPU to 100% processing the system work queue. Instead, set lower interval
    bound to HZ which is totally sufficient. Yuwei is additionally looking
    into making the interval separately configurable from DELAY_PROBE_TIME.
    
    Reported-by: Yuwei Wang <wangyuweihx@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/netdev/797c3c53-ce1b-9f60-e253-cda615788f4a@iogearbox.net
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/3b8c5aa906c52c3a8c995d1b2e8ccf650ea7c716.1653432794.git.daniel@iogearbox.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 292b7a7275ce535a1abfa4dd0b2e586162aaae1e
Author: Xiubo Li <xiubli@redhat.com>
Date:   Mon Apr 25 16:08:24 2022 +0800

    ceph: fix possible deadlock when holding Fwb to get inline_data
    
    [ Upstream commit 825978fd6a0defc3c29d8a38b6cea76a0938d21e ]
    
    1, mount with wsync.
    2, create a file with O_RDWR, and the request was sent to mds.0:
    
       ceph_atomic_open()-->
         ceph_mdsc_do_request(openc)
         finish_open(file, dentry, ceph_open)-->
           ceph_open()-->
             ceph_init_file()-->
               ceph_init_file_info()-->
                 ceph_uninline_data()-->
                 {
                   ...
                   if (inline_version == 1 || /* initial version, no data */
                       inline_version == CEPH_INLINE_NONE)
                         goto out_unlock;
                   ...
                 }
    
    The inline_version will be 1, which is the initial version for the
    new create file. And here the ci->i_inline_version will keep with 1,
    it's buggy.
    
    3, buffer write to the file immediately:
    
       ceph_write_iter()-->
         ceph_get_caps(file, need=Fw, want=Fb, ...);
         generic_perform_write()-->
           a_ops->write_begin()-->
             ceph_write_begin()-->
               netfs_write_begin()-->
                 netfs_begin_read()-->
                   netfs_rreq_submit_slice()-->
                     netfs_read_from_server()-->
                       rreq->netfs_ops->issue_read()-->
                         ceph_netfs_issue_read()-->
                         {
                           ...
                           if (ci->i_inline_version != CEPH_INLINE_NONE &&
                               ceph_netfs_issue_op_inline(subreq))
                             return;
                           ...
                         }
         ceph_put_cap_refs(ci, Fwb);
    
    The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to
    mds.1.
    
    4, then the mds.1 will request the rd lock for CInode::filelock from
    the auth mds.0, the mds.0 will do the CInode::filelock state transation
    from excl --> sync, but it need to revoke the Fxwb caps back from the
    clients.
    
    While the kernel client has aleady held the Fwb caps and waiting for
    the getattr(Fsr).
    
    It's deadlock!
    
    URL: https://tracker.ceph.com/issues/55377
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62592a3314d1501f67f704aaa9673fb01196dd2c
Author: Xiubo Li <xiubli@redhat.com>
Date:   Tue Apr 19 08:58:49 2022 +0800

    ceph: flush the mdlog for filesystem sync
    
    [ Upstream commit 1b2ba3c5616e17ff951359e25c658a1c3f146f1e ]
    
    Before waiting for a request's safe reply, we will send the mdlog flush
    request to the relevant MDS. And this will also flush the mdlog for all
    the other unsafe requests in the same session, so we can record the last
    session and no need to flush mdlog again in the next loop. But there
    still have cases that it may send the mdlog flush requst twice or more,
    but that should be not often.
    
    Rename wait_unsafe_requests() to
    flush_mdlog_and_wait_mdsc_unsafe_requests() to make it more
    descriptive.
    
    [xiubli: fold in MDS request refcount leak fix from Jeff]
    
    URL: https://tracker.ceph.com/issues/55284
    URL: https://tracker.ceph.com/issues/55411
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 834a63fca3c1db4a152dde7c9ef0583daf519376
Author: Venky Shankar <vshankar@redhat.com>
Date:   Thu Mar 10 09:34:19 2022 -0500

    ceph: allow ceph.dir.rctime xattr to be updatable
    
    [ Upstream commit d7a2dc523085f8b8c60548ceedc696934aefeb0e ]
    
    `rctime' has been a pain point in cephfs due to its buggy
    nature - inconsistent values reported and those sorts.
    Fixing rctime is non-trivial needing an overall redesign
    of the entire nested statistics infrastructure.
    
    As a workaround, PR
    
         http://github.com/ceph/ceph/pull/37938
    
    allows this extended attribute to be manually set. This allows
    users to "fixup" inconsistent rctime values. While this sounds
    messy, its probably the wisest approach allowing users/scripts
    to workaround buggy rctime values.
    
    The above PR enables Ceph MDS to allow manually setting
    rctime extended attribute with the corresponding user-land
    changes. We may as well allow the same to be done via kclient
    for parity.
    
    Signed-off-by: Venky Shankar <vshankar@redhat.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2b90ff1bf3d17d1bda11b6cf7a03149f8ee5972
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Mon May 23 22:05:24 2022 +0200

    Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process"
    
    [ Upstream commit 9c90c9b3e50e16d03c7f87d63e9db373974781e0 ]
    
    This reverts commit 4dc2a5a8f6754492180741facf2a8787f2c415d7.
    
    A non-zero return value from pfkey_broadcast() does not necessarily mean
    an error occurred as this function returns -ESRCH when no registered
    listener received the message. In particular, a call with
    BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return
    zero so that this commit in fact prevents processing any PF_KEY message.
    One visible effect is that racoon daemon fails to find encryption
    algorithms like aes and refuses to start.
    
    Excluding -ESRCH return value would fix this but it's not obvious that
    we really want to bail out here and most other callers of
    pfkey_broadcast() also ignore the return value. Also, as pointed out by
    Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code
    should use netlink instead so that we should only disturb the code for
    really important fixes.
    
    v2: add a comment explaining why is the return value ignored
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a0a85aae3fe6a3c8f00236820bac4529329afe8
Author: Oder Chiou <oder_chiou@realtek.com>
Date:   Mon May 16 18:30:55 2022 +0800

    ASoC: rt5640: Do not manipulate pin "Platform Clock" if the "Platform Clock" is not in the DAPM
    
    [ Upstream commit 832296804bc7171730884e78c761c29f6d258e13 ]
    
    The pin "Platform Clock" was only used by the Intel Byt CR platform. In the
    others, the error log will be informed. The patch will set the flag to
    avoid the pin "Platform Clock" manipulated by the other platforms.
    
    Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
    Reported-by: Sameer Pujar <spujar@nvidia.com>
    Link: https://lore.kernel.org/r/20220516103055.20003-1-oder_chiou@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fa8832e706aae21fc66263578a03dd153f87067
Author: Hannes Reinecke <hare@suse.de>
Date:   Mon May 23 14:02:44 2022 +0200

    scsi: myrb: Fix up null pointer access on myrb_cleanup()
    
    [ Upstream commit f9f0a46141e2e39bedb4779c88380d1b5f018c14 ]
    
    When myrb_probe() fails the callback might not be set, so we need to
    validate the 'disable_intr' callback in myrb_cleanup() to not cause a null
    pointer exception. And while at it do not call myrb_cleanup() if we cannot
    enable the PCI device at all.
    
    Link: https://lore.kernel.org/r/20220523120244.99515-1-hare@suse.de
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Tested-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbf19c05f66e0dcf188616b1c23df055ec749f72
Author: Syed Saba kareem <ssabakar@amd.com>
Date:   Mon May 23 16:59:53 2022 +0530

    ASoC: SOF: amd: Fixed Build error
    
    [ Upstream commit 803a1f7272797faa15a7879cdc70f9adaf3fdcba ]
    
    Add linux/module.h in acp-pci.c to solve the below dependency
    
    All error/warnings (new ones prefixed by >>):
    
    >> sound/soc/amd/acp/acp-pci.c:148:1: warning: data definition has no type or storage class
    148 | MODULE_DEVICE_TABLE(pci, acp_pci_ids);
    | ^~~~~~~~~~~~~~~~~~~
    >> sound/soc/amd/acp/acp-pci.c:148:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
    ...
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Syed Saba Kareem<ssabakar@amd.com>
    Link: https://lore.kernel.org/r/20220523112956.3087604-1-ssabakar@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dca0af9ab1b462aa8f0df3d63e28ddc87faa278
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Fri Apr 29 16:49:09 2022 +0800

    md: protect md_unregister_thread from reentrancy
    
    [ Upstream commit 1e267742283a4b5a8ca65755c44166be27e9aa0f ]
    
    Generally, the md_unregister_thread is called with reconfig_mutex, but
    raid_message in dm-raid doesn't hold reconfig_mutex to unregister thread,
    so md_unregister_thread can be called simulitaneously from two call sites
    in theory.
    
    Then after previous commit which remove the protection of reconfig_mutex
    for md_unregister_thread completely, the potential issue could be worse
    than before.
    
    Let's take pers_lock at the beginning of function to ensure reentrancy.
    
    Reported-by: Donald Buczek <buczek@molgen.mpg.de>
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 451767013c9d3803f4571113e548858597005a7b
Author: Hyunchul Lee <hyc.lee@gmail.com>
Date:   Wed May 18 06:46:08 2022 +0900

    ksmbd: smbd: fix connection dropped issue
    
    [ Upstream commit 5366afc4065075a4456941fbd51c33604d631ee5 ]
    
    When there are bursty connection requests,
    RDMA connection event handler is deferred and
    Negotiation requests are received even if
    connection status is NEW.
    
    To handle it, set the status to CONNECTED
    if Negotiation requests are received.
    
    Reported-by: Yufan Chen <wiz.chen@gmail.com>
    Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com>
    Tested-by: Yufan Chen <wiz.chen@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b50f577b8ed43e6f3590d9357079d5cd541fc855
Author: Liu Xinpeng <liuxp11@chinatelecom.cn>
Date:   Tue Apr 26 22:53:29 2022 +0800

    watchdog: wdat_wdt: Stop watchdog when rebooting the system
    
    [ Upstream commit 27fdf84510a1374748904db43f6755f912736d92 ]
    
    Executing reboot command several times on the machine "Dell
    PowerEdge R740", UEFI security detection stopped machine
    with the following prompt:
    
    UEFI0082: The system was reset due to a timeout from the watchdog
    timer. Check the System Event Log (SEL) or crash dumps from
    Operating Sysstem to identify the source that triggered the
    watchdog timer reset. Update the firmware or driver for the
    identified device.
    
    iDRAC has warning event: "The watchdog timer reset the system".
    
    This patch fixes this issue by adding the reboot notifier.
    
    Signed-off-by: Liu Xinpeng <liuxp11@chinatelecom.cn>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/1650984810-6247-3-git-send-email-liuxp11@chinatelecom.cn
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83fdfae78373a27aa3c886c70c52e8253c37277c
Author: Hao Luo <haoluo@google.com>
Date:   Mon May 16 12:09:51 2022 -0700

    kernfs: Separate kernfs_pr_cont_buf and rename_lock.
    
    [ Upstream commit 1a702dc88e150487c9c173a249b3d236498b9183 ]
    
    Previously the protection of kernfs_pr_cont_buf was piggy backed by
    rename_lock, which means that pr_cont() needs to be protected under
    rename_lock. This can cause potential circular lock dependencies.
    
    If there is an OOM, we have the following call hierarchy:
    
     -> cpuset_print_current_mems_allowed()
       -> pr_cont_cgroup_name()
         -> pr_cont_kernfs_name()
    
    pr_cont_kernfs_name() will grab rename_lock and call printk. So we have
    the following lock dependencies:
    
     kernfs_rename_lock -> console_sem
    
    Sometimes, printk does a wakeup before releasing console_sem, which has
    the dependence chain:
    
     console_sem -> p->pi_lock -> rq->lock
    
    Now, imagine one wants to read cgroup_name under rq->lock, for example,
    printing cgroup_name in a tracepoint in the scheduler code. They will
    be holding rq->lock and take rename_lock:
    
     rq->lock -> kernfs_rename_lock
    
    Now they will deadlock.
    
    A prevention to this circular lock dependency is to separate the
    protection of pr_cont_buf from rename_lock. In principle, rename_lock
    is to protect the integrity of cgroup name when copying to buf. Once
    pr_cont_buf has got its content, rename_lock can be dropped. So it's
    safe to drop rename_lock after kernfs_name_locked (and
    kernfs_path_from_node_locked) and rely on a dedicated pr_cont_lock
    to protect pr_cont_buf.
    
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Hao Luo <haoluo@google.com>
    Link: https://lore.kernel.org/r/20220516190951.3144144-1-haoluo@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de84de3861585cf1880f00220ef7788d09f308da
Author: John Ogness <john.ogness@linutronix.de>
Date:   Fri May 6 23:39:24 2022 +0206

    serial: msm_serial: disable interrupts in __msm_console_write()
    
    [ Upstream commit aabdbb1b7a5819e18c403334a31fb0cc2c06ad41 ]
    
    __msm_console_write() assumes that interrupts are disabled, but
    with threaded console printers it is possible that the write()
    callback of the console is called with interrupts enabled.
    
    Explicitly disable interrupts using local_irq_save() to preserve
    the assumed context.
    
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20220506213324.470461-1-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70df04433fd351ba72bc635bd0b5fe443d9ac964
Author: Wang Cheng <wanngchenng@gmail.com>
Date:   Mon May 16 17:22:41 2022 +0800

    staging: rtl8712: fix uninit-value in r871xu_drv_init()
    
    [ Upstream commit 0458e5428e5e959d201a40ffe71d762a79ecedc4 ]
    
    When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0,
    'mac[6]' will not be initialized.
    
    BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
     r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
     usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
     really_probe+0x653/0x14b0 drivers/base/dd.c:596
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
     usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
     really_probe+0x653/0x14b0 drivers/base/dd.c:596
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566
     hub_port_connect drivers/usb/core/hub.c:5358 [inline]
     hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]
     port_event drivers/usb/core/hub.c:5660 [inline]
     hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742
     process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307
     worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454
     kthread+0x3c7/0x500 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    Local variable mac created at:
     r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394
     usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
    
    KMSAN: uninit-value in r871xu_drv_init
    https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
    
    Reported-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Tested-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Wang Cheng <wanngchenng@gmail.com>
    Link: https://lore.kernel.org/r/14c3886173dfa4597f0704547c414cfdbcd11d16.1652618244.git.wanngchenng@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de075af8c404f7d59ed34df230aedd9f645fb846
Author: Wang Cheng <wanngchenng@gmail.com>
Date:   Mon May 16 17:22:23 2022 +0800

    staging: rtl8712: fix uninit-value in usb_read8() and friends
    
    [ Upstream commit d1b57669732d09da7e13ef86d058dab0cd57f6e0 ]
    
    When r8712_usbctrl_vendorreq() returns negative, 'data' in
    usb_read{8,16,32} will not be initialized.
    
    BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline]
    BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725
     string_nocheck lib/vsprintf.c:643 [inline]
     string+0x4ec/0x6f0 lib/vsprintf.c:725
     vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
     va_format lib/vsprintf.c:1704 [inline]
     pointer+0x18e6/0x1f70 lib/vsprintf.c:2443
     vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810
     vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
     vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
     dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604
     dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615
     __dev_printk+0x3be/0x440 drivers/base/core.c:4627
     _dev_info+0x1ea/0x22f drivers/base/core.c:4673
     r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401
     usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
     really_probe+0x6c7/0x1350 drivers/base/dd.c:621
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
     usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
     really_probe+0x6c7/0x1350 drivers/base/dd.c:621
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566
     hub_port_connect drivers/usb/core/hub.c:5363 [inline]
     hub_port_connect_change drivers/usb/core/hub.c:5507 [inline]
     port_event drivers/usb/core/hub.c:5665 [inline]
     hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747
     process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289
     worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436
     kthread+0x3c7/0x500 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30
    
    Local variable data created at:
     usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
     r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29
    
    KMSAN: uninit-value in r871xu_drv_init
    https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
    
    Reported-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Tested-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Wang Cheng <wanngchenng@gmail.com>
    Link: https://lore.kernel.org/r/b9b7a6ee02c02aa28054f5cf16129977775f3cd9.1652618244.git.wanngchenng@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc30f510dd258bd08bd32fb6fa417881ec02ad2f
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri May 6 17:25:22 2022 +0100

    clocksource/drivers/sp804: Avoid error on multiple instances
    
    [ Upstream commit a98399cbc1e05f7b977419f03905501d566cf54e ]
    
    When a machine sports more than one SP804 timer instance, we only bring
    up the first one, since multiple timers of the same kind are not useful
    to Linux. As this is intentional behaviour, we should not return an
    error message, as we do today:
    ===============
    [    0.000800] Failed to initialize '/bus@8000000/motherboard-bus@8000000/iofpga-bus@300000000/timer@120000': -22
    ===============
    
    Replace the -EINVAL return with a debug message and return 0 instead.
    
    Also we do not reach the init function anymore if the DT node is
    disabled (as this is now handled by OF_DECLARE), so remove the explicit
    check for that case.
    
    This fixes a long standing bogus error when booting ARM's fastmodels.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20220506162522.3675399-1-andre.przywara@arm.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 033ec4e7e59ae5e1ef1e8c10bc6552926044ed1c
Author: bumwoo lee <bw365.lee@samsung.com>
Date:   Wed Apr 27 12:00:05 2022 +0900

    extcon: Modify extcon device to be created after driver data is set
    
    [ Upstream commit 5dcc2afe716d69f5112ce035cb14f007461ff189 ]
    
    Currently, someone can invoke the sysfs such as state_show()
    intermittently before dev_set_drvdata() is done.
    And it can be a cause of kernel Oops because of edev is Null at that time.
    So modified the driver registration to after setting drviver data.
    
    - Oops's backtrace.
    
    Backtrace:
    [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show)
    [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show)
    [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show)
    [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read)
    [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read)
    [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read)
    [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read)
    [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read)
    [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read)
    [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)
    
    Signed-off-by: bumwoo lee <bw365.lee@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7c18d5a53cd9352f44b286df462989a7cd670cd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 17 09:28:46 2021 +0300

    extcon: Fix extcon_get_extcon_dev() error handling
    
    [ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]
    
    The extcon_get_extcon_dev() function returns error pointers on error,
    NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV)
    when the CONFIG_EXTCON option is disabled.  This is very complicated for
    the callers to handle and a number of them had bugs that would lead to
    an Oops.
    
    In real life, there are two things which prevented crashes.  First,
    error pointers would only be returned if there was bug in the caller
    where they passed a NULL "extcon_name" and none of them do that.
    Second, only two out of the eight drivers will build when CONFIG_EXTCON
    is disabled.
    
    The normal way to write this would be to return -EPROBE_DEFER directly
    when appropriate and return NULL when CONFIG_EXTCON is disabled.  Then
    the error handling is simple and just looks like:
    
            dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev));
            if (IS_ERR(dev->edev))
                    return PTR_ERR(dev->edev);
    
    For the two drivers which can build with CONFIG_EXTCON disabled, then
    extcon_get_extcon_dev() will now return NULL which is not treated as an
    error and the probe will continue successfully.  Those two drivers are
    "typec_fusb302" and "max8997-battery".  In the original code, the
    typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but
    now that function is a no-op.  For the max8997-battery driver everything
    should continue working as is.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bcd1901cd008b3b5fc6bd29ccb80bdd0b5ee039
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Fri Apr 29 15:09:13 2022 -0600

    misc: rtsx: set NULL intfdata when probe fails
    
    [ Upstream commit f861d36e021e1ac4a0a2a1f6411d623809975d63 ]
    
    rtsx_usb_probe() doesn't call usb_set_intfdata() to null out the
    interface pointer when probe fails. This leaves a stale pointer.
    Noticed the missing usb_set_intfdata() while debugging an unrelated
    invalid DMA mapping problem.
    
    Fix it with a call to usb_set_intfdata(..., NULL).
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20220429210913.46804-1-skhan@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27cdf39c63839861194e8cc4083777a9d1b5d3ac
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Fri May 6 09:47:05 2022 +0100

    soundwire: qcom: adjust autoenumeration timeout
    
    [ Upstream commit 74da272400b46f2e898f115d1b1cd60828766919 ]
    
    Currently timeout for autoenumeration during probe and bus reset is set to
    2 secs which is really a big value. This can have an adverse effect on
    boot time if the slave device is not ready/reset.
    This was the case with wcd938x which was not reset yet but we spent 2
    secs waiting in the soundwire controller probe. Reduce this time to
    1/10 of Hz which should be good enough time to finish autoenumeration
    if any slaves are available on the bus.
    
    Reported-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220506084705.18525-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd17a708208f3c0ca6654121afd58cd65f3d1988
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Apr 21 19:22:57 2022 -0700

    usb: dwc3: gadget: Only End Transfer for ep0 data phase
    
    [ Upstream commit ace17b6ee4f92ab0375d12a1b42494f8590a96b6 ]
    
    The driver shouldn't be able to issue End Transfer to the control
    endpoint at anytime. Typically we should only do so in error cases such
    as invalid/unexpected direction of Data Phase as described in the
    control transfer flow of the programming guide. It _may_ end started
    data phase during controller deinitialization from soft disconnect or
    driver removal. However, that should not happen because the driver
    should be maintained in EP0_SETUP_PHASE during driver tear-down. On
    soft-connect, the controller should be reset from a soft-reset and there
    should be no issue starting the control endpoint.
    
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/3c6643678863a26702e4115e9e19d7d94a30d49c.1650593829.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c185fde906a48368bd2d2a8c17d4b6fb3d670af
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Apr 28 14:10:56 2022 +0300

    usb: dwc3: host: Stop setting the ACPI companion
    
    [ Upstream commit 7fd069d65da2e20b1caec3b7bcf9dfbe28c04bb2 ]
    
    It is no longer needed. The sysdev pointer is now used when
    assigning the ACPI companions to the xHCI ports and USB
    devices.
    
    Assigning the ACPI companion here resulted in the
    fwnode->secondary pointer to be replaced also for the parent
    dwc3 device since the primary fwnode (the ACPI companion)
    was shared. That was unintentional and it created potential
    side effects like resource leaks.
    
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20220428111056.3558-3-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2159feb9d28ce496d77df98313ab454646372ac
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu May 5 12:46:18 2022 +0200

    usb: dwc2: gadget: don't reset gadget's driver->bus
    
    [ Upstream commit 3120aac6d0ecd9accf56894aeac0e265f74d3d5a ]
    
    UDC driver should not touch gadget's driver internals, especially it
    should not reset driver->bus. This wasn't harmful so far, but since
    commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") gadget
    subsystem got it's own bus and messing with ->bus triggers the
    following NULL pointer dereference:
    
    dwc2 12480000.hsotg: bound driver g_ether
    8<--- cut here ---
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    [00000000] *pgd=00000000
    Internal error: Oops: 5 [#1] SMP ARM
    Modules linked in: ...
    CPU: 0 PID: 620 Comm: modprobe Not tainted 5.18.0-rc5-next-20220504 #11862
    Hardware name: Samsung Exynos (Flattened Device Tree)
    PC is at module_add_driver+0x44/0xe8
    LR is at sysfs_do_create_link_sd+0x84/0xe0
    ...
    Process modprobe (pid: 620, stack limit = 0x(ptrval))
    ...
     module_add_driver from bus_add_driver+0xf4/0x1e4
     bus_add_driver from driver_register+0x78/0x10c
     driver_register from usb_gadget_register_driver_owner+0x40/0xb4
     usb_gadget_register_driver_owner from do_one_initcall+0x44/0x1e0
     do_one_initcall from do_init_module+0x44/0x1c8
     do_init_module from load_module+0x19b8/0x1b9c
     load_module from sys_finit_module+0xdc/0xfc
     sys_finit_module from ret_fast_syscall+0x0/0x54
    Exception stack(0xf1771fa8 to 0xf1771ff0)
    ...
    dwc2 12480000.hsotg: new device is high-speed
    ---[ end trace 0000000000000000 ]---
    
    Fix this by removing driver->bus entry reset.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20220505104618.22729-1-m.szyprowski@samsung.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fb47220593d4b9191914b7d97095628d5b0f940
Author: Changbin Du <changbin.du@intel.com>
Date:   Mon Jan 17 23:43:00 2022 +0800

    sysrq: do not omit current cpu when showing backtrace of all active CPUs
    
    [ Upstream commit 5390e7f46b9d5546d45a83e6463bc656678b1d0e ]
    
    The backtrace of current CPU also should be printed as it is active. This
    change add stack trace for current CPU and print a hint for idle CPU for
    the generic workqueue based printing. (x86 already does this)
    
    Now it looks like below:
    [  279.401567] sysrq: Show backtrace of all active CPUs
    [  279.407234] sysrq: CPU5:
    [  279.407505] Call Trace:
    [  279.408789] [<ffffffff8000606c>] dump_backtrace+0x2c/0x3a
    [  279.411698] [<ffffffff800060ac>] show_stack+0x32/0x3e
    [  279.411809] [<ffffffff80542258>] sysrq_handle_showallcpus+0x4c/0xc6
    [  279.411929] [<ffffffff80542f16>] __handle_sysrq+0x106/0x26c
    [  279.412034] [<ffffffff805436a8>] write_sysrq_trigger+0x64/0x74
    [  279.412139] [<ffffffff8029cd48>] proc_reg_write+0x8e/0xe2
    [  279.412252] [<ffffffff8021a8f8>] vfs_write+0x90/0x2be
    [  279.412362] [<ffffffff8021acd2>] ksys_write+0xa6/0xce
    [  279.412467] [<ffffffff8021ad24>] sys_write+0x2a/0x38
    [  279.412689] [<ffffffff80003ff8>] ret_from_syscall+0x0/0x2
    [  279.417173] sysrq: CPU6: backtrace skipped as idling
    [  279.417185] sysrq: CPU4: backtrace skipped as idling
    [  279.417187] sysrq: CPU0: backtrace skipped as idling
    [  279.417181] sysrq: CPU7: backtrace skipped as idling
    [  279.417190] sysrq: CPU1: backtrace skipped as idling
    [  279.417193] sysrq: CPU3: backtrace skipped as idling
    [  279.417219] sysrq: CPU2:
    [  279.419179] Call Trace:
    [  279.419440] [<ffffffff8000606c>] dump_backtrace+0x2c/0x3a
    [  279.419782] [<ffffffff800060ac>] show_stack+0x32/0x3e
    [  279.420015] [<ffffffff80542b30>] showacpu+0x5c/0x96
    [  279.420317] [<ffffffff800ba71c>] flush_smp_call_function_queue+0xd6/0x218
    [  279.420569] [<ffffffff800bb438>] generic_smp_call_function_single_interrupt+0x14/0x1c
    [  279.420798] [<ffffffff800079ae>] handle_IPI+0xaa/0x13a
    [  279.421024] [<ffffffff804dcb92>] riscv_intc_irq+0x56/0x70
    [  279.421274] [<ffffffff80a05b70>] generic_handle_arch_irq+0x6a/0xfa
    [  279.421518] [<ffffffff80004006>] ret_from_exception+0x0/0x10
    [  279.421750] [<ffffffff80096492>] rcu_idle_enter+0x16/0x1e
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Link: https://lore.kernel.org/r/20220117154300.2808-1-changbin.du@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e277b95acdab84cd5d2f8d537a37aef6d21e988b
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Wed Apr 6 15:57:03 2022 +0800

    char: xillybus: fix a refcount leak in cleanup_dev()
    
    [ Upstream commit b67d19662fdee275c479d21853bc1239600a798f ]
    
    usb_get_dev is called in xillyusb_probe. So it is better to call
    usb_put_dev before xdev is released.
    
    Acked-by: Eli Billauer <eli.billauer@gmail.com>
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220406075703.23464-1-hbh25y@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a9cd0c479e5e524a5ca9baf9bfd0362d183b6ee
Author: Evan Green <evgreen@chromium.org>
Date:   Thu Apr 21 10:39:27 2022 -0700

    USB: hcd-pci: Fully suspend across freeze/thaw cycle
    
    [ Upstream commit 63acaa8e9c65dc34dc249440216f8e977f5d2748 ]
    
    The documentation for the freeze() method says that it "should quiesce
    the device so that it doesn't generate IRQs or DMA". The unspoken
    consequence of not doing this is that MSIs aimed at non-boot CPUs may
    get fully lost if they're sent during the period where the target CPU is
    offline.
    
    The current callbacks for USB HCD do not fully quiesce interrupts,
    specifically on XHCI. Change to use the full suspend/resume flow for
    freeze/thaw to ensure interrupts are fully quiesced. This fixes issues
    where USB devices fail to thaw during hibernation because XHCI misses
    its interrupt and cannot recover.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Evan Green <evgreen@chromium.org>
    Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b97aae8b43b718314012e8170b7e03dbfd2e7677
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 20:03:05 2022 +0800

    drivers: usb: host: Fix deadlock in oxu_bus_suspend()
    
    [ Upstream commit 4d378f2ae58138d4c55684e1d274e7dd94aa6524 ]
    
    There is a deadlock in oxu_bus_suspend(), which is shown below:
    
       (Thread 1)              |      (Thread 2)
                               | timer_action()
    oxu_bus_suspend()          |  mod_timer()
     spin_lock_irq() //(1)     |  (wait a time)
     ...                       | oxu_watchdog()
     del_timer_sync()          |  spin_lock_irq() //(2)
     (wait timer to stop)      |  ...
    
    We hold oxu->lock in position (1) of thread 1, and use
    del_timer_sync() to wait timer to stop, but timer handler
    also need oxu->lock in position (2) of thread 2. As a result,
    oxu_bus_suspend() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irq(), which could let timer handler to obtain
    the needed lock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34d91e555e5582cffdbcbb75517bc9217866823e
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 19:16:26 2022 +0800

    drivers: tty: serial: Fix deadlock in sa1100_set_termios()
    
    [ Upstream commit 62b2caef400c1738b6d22f636c628d9f85cd4c4c ]
    
    There is a deadlock in sa1100_set_termios(), which is shown
    below:
    
       (Thread 1)              |      (Thread 2)
                               | sa1100_enable_ms()
    sa1100_set_termios()       |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | sa1100_timeout()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold sport->port.lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need sport->port.lock in position (2) of thread 2. As a result,
    sa1100_set_termios() will block forever.
    
    This patch moves del_timer_sync() before spin_lock_irqsave()
    in order to prevent the deadlock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417111626.7802-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82a101f14943f479fd190b1e5b40d91c77e2ac1b
Author: Zhen Ni <nizhen@uniontech.com>
Date:   Wed Mar 2 11:37:16 2022 +0800

    USB: host: isp116x: check return value after calling platform_get_resource()
    
    [ Upstream commit 134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Zhen Ni <nizhen@uniontech.com>
    Link: https://lore.kernel.org/r/20220302033716.31272-1-nizhen@uniontech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffd4c4d5293e4985092ea45ba21cad9326e2e434
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 22:16:41 2022 +0800

    drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
    
    [ Upstream commit 9b6bdbd9337de3917945847bde262a34a87a6303 ]
    
    There is a deadlock in rtllib_beacons_stop(), which is shown
    below:
    
       (Thread 1)              |      (Thread 2)
                               | rtllib_send_beacon()
    rtllib_beacons_stop()      |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | rtllib_send_beacon_cb()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold ieee->beacon_lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need ieee->beacon_lock in position (2) of thread 2.
    As a result, rtllib_beacons_stop() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irqsave(), which could let timer handler to obtain
    the needed lock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417141641.124388-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b34cb54923a6e5ddefbaf358c85c922c6ab456e2
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 21:54:07 2022 +0800

    drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()
    
    [ Upstream commit 806c7b53414934ba2a39449b31fd1a038e500273 ]
    
    There is a deadlock in ieee80211_beacons_stop(), which is shown below:
    
       (Thread 1)              |      (Thread 2)
                               | ieee80211_send_beacon()
    ieee80211_beacons_stop()   |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | ieee80211_send_beacon_cb()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold ieee->beacon_lock in position (1) of thread 1 and use
    del_timer_sync() to wait timer to stop, but timer handler
    also need ieee->beacon_lock in position (2) of thread 2.
    As a result, ieee80211_beacons_stop() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irqsave(), which could let timer handler to obtain
    the needed lock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417135407.109536-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8b9b2229ea468e4f8f9a37df9e09df01ca14f19
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Apr 1 17:24:28 2022 +0300

    thunderbolt: Use different lane for second DisplayPort tunnel
    
    [ Upstream commit 9d2d0a5cf0ca063f417681cc33e767ce52615286 ]
    
    Brad reported that on Apple hardware with Light Ridge or Falcon Ridge
    controller, plugging in a chain of Thunderbolt displays (Light Ridge
    based controllers) causes all kinds of tearing and flickering. The
    reason for this is that on Thunderbolt 1 hardware there is no lane
    bonding so we have two independent 10 Gb/s lanes, and currently Linux
    tunnels both displays through the lane 1. This makes the displays to
    share the 10 Gb/s bandwidth which may not be enough for higher
    resolutions.
    
    For this reason make the second tunnel go through the lane 0 instead.
    This seems to match what the macOS connection manager is also doing.
    
    Reported-by: Brad Campbell <lists2009@fnarfbargle.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a8305f357a8d03698fc7bc855ff9c6865d5486b
Author: Huang Guobin <huangguobin4@huawei.com>
Date:   Thu Mar 31 17:10:05 2022 +0800

    tty: Fix a possible resource leak in icom_probe
    
    [ Upstream commit ee157a79e7c82b01ae4c25de0ac75899801f322c ]
    
    When pci_read_config_dword failed, call pci_release_regions() and
    pci_disable_device() to recycle the resource previously allocated.
    
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Huang Guobin <huangguobin4@huawei.com>
    Link: https://lore.kernel.org/r/20220331091005.3290753-1-huangguobin4@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ceb4ca9543a8a788febf6bc8dad2e605e172d5e
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sun Apr 10 19:48:14 2022 +0800

    tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
    
    [ Upstream commit 689ca31c542687709ba21ec2195c1fbce34fd029 ]
    
    When the driver fails at alloc_hdlcdev(), and then we remove the driver
    module, we will get the following splat:
    
    [   25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
    [   25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
    [   25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
    [   25.077709] Call Trace:
    [   25.077924]  <TASK>
    [   25.078108]  unregister_hdlc_device+0x16/0x30
    [   25.078481]  slgt_cleanup+0x157/0x9f0 [synclink_gt]
    
    Fix this by checking whether the 'info->netdev' is a null pointer first.
    
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/20220410114814.3920474-1-zheyuma97@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25cf414b0610fea29d8e045f315648d9007c9a46
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sat Apr 9 15:21:35 2022 +0800

    drivers: staging: rtl8192eu: Fix deadlock in rtw_joinbss_event_prehandle
    
    [ Upstream commit 0fcddf9c7c10202946d5b19409efbdff744fba88 ]
    
    There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below:
    
       (Thread 1)                |      (Thread 2)
                                 | _set_timer()
    rtw_joinbss_event_prehandle()|  mod_timer()
     spin_lock_bh() //(1)        |  (wait a time)
     ...                         | rtw_join_timeout_handler()
                                 |  _rtw_join_timeout_handler()
     del_timer_sync()            |   spin_lock_bh() //(2)
     (wait timer to stop)        |   ...
    
    We hold pmlmepriv->lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need pmlmepriv->lock in position (2) of thread 2.
    As a result, rtw_joinbss_event_prehandle() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_bh(), which could let timer handler to obtain
    the needed lock. What`s more, we change spin_lock_bh() to
    spin_lock_irq() in _rtw_join_timeout_handler() in order to
    prevent deadlock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220409072135.74248-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eca9748d9267a38d532464e3305a38629e9c35a9
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sat Apr 9 14:49:53 2022 +0800

    drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()
    
    [ Upstream commit 041879b12ddb0c6c83ed9c0bdd10dc82a056f2fc ]
    
    There is a deadlock in rtw_joinbss_event_prehandle(), which is shown
    below:
    
       (Thread 1)                |      (Thread 2)
                                 | _set_timer()
    rtw_joinbss_event_prehandle()|  mod_timer()
     spin_lock_bh() //(1)        |  (wait a time)
     ...                         | _rtw_join_timeout_handler()
     del_timer_sync()            |  spin_lock_bh() //(2)
     (wait timer to stop)        |  ...
    
    We hold pmlmepriv->lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need pmlmepriv->lock in position (2) of thread 2.
    As a result, rtw_joinbss_event_prehandle() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_bh(), which could let timer handler to obtain
    the needed lock. What`s more, we change spin_lock_bh() to
    spin_lock_irq() in _rtw_join_timeout_handler() in order to
    prevent deadlock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220409064953.67420-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c41f5c341853f84b7bc2f32605d4e2782e8c279
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sat Apr 9 14:18:35 2022 +0800

    drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()
    
    [ Upstream commit cc7ad0d77b51c872d629bcd98aea463a3c4109e7 ]
    
    There is a deadlock in rtw_surveydone_event_callback(),
    which is shown below:
    
       (Thread 1)                  |      (Thread 2)
                                   | _set_timer()
    rtw_surveydone_event_callback()|  mod_timer()
     spin_lock_bh() //(1)          |  (wait a time)
     ...                           | rtw_scan_timeout_handler()
     del_timer_sync()              |  spin_lock_bh() //(2)
     (wait timer to stop)          |  ...
    
    We hold pmlmepriv->lock in position (1) of thread 1 and use
    del_timer_sync() to wait timer to stop, but timer handler
    also need pmlmepriv->lock in position (2) of thread 2.
    As a result, rtw_surveydone_event_callback() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_bh(), which could let timer handler to obtain
    the needed lock. What`s more, we change spin_lock_bh() in
    rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,
    spin_lock_bh() will also cause deadlock() in timer handler.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220409061836.60529-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c377fb0ee15f0088b7f79c80acf672dc56e48925
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Feb 16 12:15:03 2022 -0800

    lkdtm/usercopy: Expand size of "out of frame" object
    
    [ Upstream commit f387e86d3a74407bdd9c5815820ac9d060962840 ]
    
    To be sufficiently out of range for the usercopy test to see the lifetime
    mismatch, expand the size of the "bad" buffer, which will let it be
    beyond current_stack_pointer regardless of stack growth direction.
    Paired with the recent addition of stack depth checking under
    CONFIG_HARDENED_USERCOPY=y, this will correctly start tripping again.
    
    Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/lkml/762faf1b-0443-5ddf-4430-44a20cf2ec4d@collabora.com/
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9aff39a5637a43d8952e756c0f83b0f9e7da239e
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Mon Feb 7 15:38:33 2022 +0100

    iio: st_sensors: Add a local lock for protecting odr
    
    [ Upstream commit 474010127e2505fc463236470908e1ff5ddb3578 ]
    
    Right now the (framework) mlock lock is (ab)used for multiple purposes:
    1- protecting concurrent accesses over the odr local cache
    2- avoid changing samplig frequency whilst buffer is running
    
    Let's start by handling situation #1 with a local lock.
    
    Suggested-by: Jonathan Cameron <jic23@kernel.org>
    Cc: Denis Ciocca <denis.ciocca@st.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2882b8baad068d21c99fb2ab5a85a2bdbd5b834
Author: Xiaoke Wang <xkernel.wang@foxmail.com>
Date:   Tue Apr 5 12:43:07 2022 +0800

    staging: rtl8712: fix a potential memory leak in r871xu_drv_init()
    
    [ Upstream commit 7288ff561de650d4139fab80e9cb0da9b5b32434 ]
    
    In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory
    allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not
    properly released as there is no action will be performed by
    r8712_usb_dvobj_deinit().
    To properly release it, we should call r8712_free_io_queue() in
    r8712_usb_dvobj_deinit().
    
    Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called
    by r871x_dev_unload() under condition `padapter->bup` and
    r8712_free_io_queue() is called by r8712_free_drv_sw().
    However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and
    calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for
    better understading the code.
    So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove
    r8712_free_io_queue() from r8712_free_drv_sw().
    
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
    Link: https://lore.kernel.org/r/tencent_B8048C592777830380A23A7C4409F9DF1305@qq.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b933111433639ff3ec347b1be938aa420ae3256
Author: Xiaoke Wang <xkernel.wang@foxmail.com>
Date:   Sat Mar 5 11:14:05 2022 +0800

    iio: dummy: iio_simple_dummy: check the return value of kstrdup()
    
    [ Upstream commit ba93642188a6fed754bf7447f638bc410e05a929 ]
    
    kstrdup() is also a memory allocation-related function, it returns NULL
    when some memory errors happen. So it is better to check the return
    value of it so to catch the memory error in time. Besides, there should
    have a kfree() to clear up the allocation if we get a failure later in
    this function to prevent memory leak.
    
    Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
    Link: https://lore.kernel.org/r/tencent_C920CFCC33B9CC1C63141FE1334A39FF8508@qq.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f162d9cc85732190b6ed31de3b9cbaae0c411a2f
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 9 09:07:01 2022 +0100

    iov_iter: Fix iter_xarray_get_pages{,_alloc}()
    
    [ Upstream commit 6c77676645ad42993e0a8bdb8dafa517851a352a ]
    
    The maths at the end of iter_xarray_get_pages() to calculate the actual
    size doesn't work under some circumstances, such as when it's been asked to
    extract a partial single page.  Various terms of the equation cancel out
    and you end up with actual == offset.  The same issue exists in
    iter_xarray_get_pages_alloc().
    
    Fix these to just use min() to select the lesser amount from between the
    amount of page content transcribed into the buffer, minus the offset, and
    the size limit specified.
    
    This doesn't appear to have caused a problem yet upstream because network
    filesystems aren't getting the pages from an xarray iterator, but rather
    passing it directly to the socket, which just iterates over it.  Cachefiles
    *does* do DIO from one to/from ext4/xfs/btrfs/etc. but it always asks for
    whole pages to be written or read.
    
    Fixes: 7ff5062079ef ("iov_iter: Add ITER_XARRAY")
    Reported-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Alexander Viro <viro@zeniv.linux.org.uk>
    cc: Dominique Martinet <asmadeus@codewreck.org>
    cc: Mike Marshall <hubcap@omnibond.com>
    cc: Gao Xiang <xiang@kernel.org>
    cc: linux-afs@lists.infradead.org
    cc: v9fs-developer@lists.sourceforge.net
    cc: devel@lists.orangefs.org
    cc: linux-erofs@lists.ozlabs.org
    cc: linux-cachefs@redhat.com
    cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bde90bb083dde3e26d12d8f4976ea5f79394ad8f
Author: Andrea Mayer <andrea.mayer@uniroma2.it>
Date:   Wed Jun 8 11:19:17 2022 +0200

    net: seg6: fix seg6_lookup_any_nexthop() to handle VRFs using flowi_l3mdev
    
    [ Upstream commit a3bd2102e464202b58d57390a538d96f57ffc361 ]
    
    Commit 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif
    reset for port devices") adds a new entry (flowi_l3mdev) in the common
    flow struct used for indicating the l3mdev index for later rule and
    table matching.
    The l3mdev_update_flow() has been adapted to properly set the
    flowi_l3mdev based on the flowi_oif/flowi_iif. In fact, when a valid
    flowi_iif is supplied to the l3mdev_update_flow(), this function can
    update the flowi_l3mdev entry only if it has not yet been set (i.e., the
    flowi_l3mdev entry is equal to 0).
    
    The SRv6 End.DT6 behavior in VRF mode leverages a VRF device in order to
    force the routing lookup into the associated routing table. This routing
    operation is performed by seg6_lookup_any_nextop() preparing a flowi6
    data structure used by ip6_route_input_lookup() which, in turn,
    (indirectly) invokes l3mdev_update_flow().
    
    However, seg6_lookup_any_nexthop() does not initialize the new
    flowi_l3mdev entry which is filled with random garbage data. This
    prevents l3mdev_update_flow() from properly updating the flowi_l3mdev
    with the VRF index, and thus SRv6 End.DT6 (VRF mode)/DT46 behaviors are
    broken.
    
    This patch correctly initializes the flowi6 instance allocated and used
    by seg6_lookup_any_nexhtop(). Specifically, the entire flowi6 instance
    is wiped out: in case new entries are added to flowi/flowi6 (as happened
    with the flowi_l3mdev entry), we should no longer have incorrectly
    initialized values. As a result of this operation, the value of
    flowi_l3mdev is also set to 0.
    
    The proposed fix can be tested easily. Starting from the commit
    referenced in the Fixes, selftests [1],[2] indicate that the SRv6
    End.DT6 (VRF mode)/DT46 behaviors no longer work correctly. By applying
    this patch, those behaviors are back to work properly again.
    
    [1] - tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
    [2] - tools/testing/selftests/net/srv6_end_dt6_l3vpn_test.sh
    
    Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices")
    Reported-by: Anton Makarov <am@3a-alliance.com>
    Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20220608091917.20345-1-andrea.mayer@uniroma2.it
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6d705660a3257c76f0471902eba547b85997793
Author: Etienne van der Linde <etienne.vanderlinde@corigine.com>
Date:   Wed Jun 8 11:29:01 2022 +0200

    nfp: flower: restructure flow-key for gre+vlan combination
    
    [ Upstream commit a0b843340dae704e17c1ddfad0f85c583c36757f ]
    
    Swap around the GRE and VLAN parts in the flow-key offloaded by
    the driver to fit in with other tunnel types and the firmware.
    Without this change used cases with GRE+VLAN on the outer header
    does not get offloaded as the flow-key mismatches what the
    firmware expect.
    
    Fixes: 0d630f58989a ("nfp: flower: add support to offload QinQ match")
    Fixes: 5a2b93041646 ("nfp: flower-ct: compile match sections of flow_payload")
    Signed-off-by: Etienne van der Linde <etienne.vanderlinde@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89c1e22776a9c294ff5e7967e330cf069ff0e97c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jun 8 16:59:29 2022 -0700

    drm: imx: fix compiler warning with gcc-12
    
    [ Upstream commit 7aefd8b53815274f3ef398d370a3c9b27dd9f00c ]
    
    Gcc-12 correctly warned about this code using a non-NULL pointer as a
    truth value:
    
      drivers/gpu/drm/imx/ipuv3-crtc.c: In function ‘ipu_crtc_disable_planes’:
      drivers/gpu/drm/imx/ipuv3-crtc.c:72:21: error: the comparison will always evaluate as ‘true’ for the address of ‘plane’ will never be NULL [-Werror=address]
         72 |                 if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
            |                     ^
    
    due to the extraneous '&' address-of operator.
    
    Philipp Zabel points out that The mistake had no adverse effect since
    the following condition doesn't actually dereference the NULL pointer,
    but the intent of the code was obviously to check for it, not to take
    the address of the member.
    
    Fixes: eb8c88808c83 ("drm/imx: add deferred plane disabling")
    Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7883c2a056f3f3b80c0f12c3bb2820bbdee4b47b
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Tue Jun 7 15:02:14 2022 +0800

    tcp: use alloc_large_system_hash() to allocate table_perturb
    
    [ Upstream commit e67b72b90b7e19a4be4d9c29f3feea6f58ab43f8 ]
    
    In our server, there may be no high order (>= 6) memory since we reserve
    lots of HugeTLB pages when booting.  Then the system panic.  So use
    alloc_large_system_hash() to allocate table_perturb.
    
    Fixes: e9261476184b ("tcp: dynamically allocate the perturb table used by source ports")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20220607070214.94443-1-songmuchun@bytedance.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30c96f62d6f19fe9be5768f59aa6b68f3516138c
Author: Alvin Šipraga <alsi@bang-olufsen.dk>
Date:   Tue Jun 7 20:46:24 2022 +0200

    net: dsa: realtek: rtl8365mb: fix GMII caps for ports with internal PHY
    
    [ Upstream commit 487994ff75880569d32504d7e70da8b3328e0693 ]
    
    Since commit a18e6521a7d9 ("net: phylink: handle NA interface mode in
    phylink_fwnode_phy_connect()"), phylib defaults to GMII when no phy-mode
    or phy-connection-type property is specified in a DSA port node of the
    device tree. The same commit caused a regression in rtl8365mb whereby
    phylink would fail to connect, because the driver did not advertise
    support for GMII for ports with internal PHY.
    
    It should be noted that the aforementioned regression is not because the
    blamed commit was incorrect: on the contrary, the blamed commit is
    correcting the previous behaviour whereby unspecified phy-mode would
    cause the internal interface mode to be PHY_INTERFACE_MODE_NA. The
    rtl8365mb driver only worked by accident before because it _did_
    advertise support for PHY_INTERFACE_MODE_NA, despite NA being reserved
    for internal use by phylink. With one mistake fixed, the other was
    exposed.
    
    Commit a5dba0f207e5 ("net: dsa: rtl8365mb: add GMII as user port mode")
    then introduced implicit support for GMII mode on ports with internal
    PHY to allow a PHY connection for device trees where the phy-mode is not
    explicitly set to "internal". At this point everything was working OK
    again.
    
    Subsequently, commit 6ff6064605e9 ("net: dsa: realtek: convert to
    phylink_generic_validate()") broke this behaviour again by discarding
    the usage of rtl8365mb_phy_mode_supported() - where this GMII support
    was indicated - while switching to the new .phylink_get_caps API.
    
    With the new API, rtl8365mb_phy_mode_supported() is no longer needed.
    Remove it altogether and add back the GMII capability - this time to
    rtl8365mb_phylink_get_caps() - so that the above default behaviour works
    for ports with internal PHY again.
    
    Fixes: 6ff6064605e9 ("net: dsa: realtek: convert to phylink_generic_validate()")
    Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://lore.kernel.org/r/20220607184624.417641-1-alvin@pqrs.dk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c15ef6c8e590ad973e47412a3217b51e8a4f6f30
Author: Marek Behún <kabel@kernel.org>
Date:   Tue Jun 7 12:28:42 2022 +0100

    net: dsa: mv88e6xxx: use BMSR_ANEGCOMPLETE bit for filling an_complete
    
    [ Upstream commit 47e96930d6e6106d5252e85b868d3c7e29296de0 ]
    
    Commit ede359d8843a ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN
    is bypassed") added the ability to link if AN was bypassed, and added
    filling of state->an_complete field, but set it to true if AN was
    enabled in BMCR, not when AN was reported complete in BMSR.
    
    This was done because for some reason, when I wanted to use BMSR value
    to infer an_complete, I was looking at BMSR_ANEGCAPABLE bit (which was
    always 1), instead of BMSR_ANEGCOMPLETE bit.
    
    Use BMSR_ANEGCOMPLETE for filling state->an_complete.
    
    Fixes: ede359d8843a ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN is bypassed")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f850fe0a32c3f1e19b76996a3b1ca32637a14de
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Jun 7 08:11:43 2022 +0400

    net: altera: Fix refcount leak in altera_tse_mdio_create
    
    [ Upstream commit 11ec18b1d8d92b9df307d31950dcba0b3dd7283c ]
    
    Every iteration of for_each_child_of_node() decrements
    the reference count of the previous node.
    When break from a for_each_child_of_node() loop,
    we need to explicitly call of_node_put() on the child node when
    not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: bbd2190ce96d ("Altera TSE: Add main and header file for Altera Ethernet Driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220607041144.7553-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ffa268724656633af5f37a38c212326d98ebe8c
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Jun 6 09:21:07 2022 -0400

    ip_gre: test csum_start instead of transport header
    
    [ Upstream commit 8d21e9963bec1aad2280cdd034c8993033ef2948 ]
    
    GRE with TUNNEL_CSUM will apply local checksum offload on
    CHECKSUM_PARTIAL packets.
    
    ipgre_xmit must validate csum_start after an optional skb_pull,
    else lco_csum may trigger an overflow. The original check was
    
            if (csum && skb_checksum_start(skb) < skb->data)
                    return -EINVAL;
    
    This had false positives when skb_checksum_start is undefined:
    when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement
    was straightforward
    
            if (csum && skb->ip_summed == CHECKSUM_PARTIAL &&
                skb_checksum_start(skb) < skb->data)
                    return -EINVAL;
    
    But was eventually revised more thoroughly:
    - restrict the check to the only branch where needed, in an
      uncommon GRE path that uses header_ops and calls skb_pull.
    - test skb_transport_header, which is set along with csum_start
      in skb_partial_csum_set in the normal header_ops datapath.
    
    Turns out skbs can arrive in this branch without the transport
    header set, e.g., through BPF redirection.
    
    Revise the check back to check csum_start directly, and only if
    CHECKSUM_PARTIAL. Do leave the check in the updated location.
    Check field regardless of whether TUNNEL_CSUM is configured.
    
    Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/
    Link: https://lore.kernel.org/all/20210902193447.94039-2-willemdebruijn.kernel@gmail.com/T/#u
    Fixes: 8a0ed250f911 ("ip_gre: validate csum_start only on pull")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/20220606132107.3582565-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b0ad6b637a9fb64ce7a501293786dee6fad545f
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Mon May 30 10:46:59 2022 +0300

    net/mlx5: fs, fail conflicting actions
    
    [ Upstream commit 8fa5e7b20e01042b14f8cd684d2da9b638460c74 ]
    
    When combining two steering rules into one check
    not only do they share the same actions but those
    actions are also the same. This resolves an issue where
    when creating two different rules with the same match
    the actions are overwritten and one of the rules is deleted
    a FW syndrome can be seen in dmesg.
    
    mlx5_core 0000:03:00.0: mlx5_cmd_check:819:(pid 2105): DEALLOC_MODIFY_HEADER_CONTEXT(0x941) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0x1ab444)
    
    Fixes: 0d235c3fabb7 ("net/mlx5: Add hash table to search FTEs in a flow-group")
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85966db14ebfa7c8de1f23b73f5ad562925e968c
Author: Feras Daoud <ferasda@nvidia.com>
Date:   Sat Mar 19 21:47:48 2022 +0200

    net/mlx5: Rearm the FW tracer after each tracer event
    
    [ Upstream commit 8bf94e6414c9481bfa28269022688ab445d0081d ]
    
    The current design does not arm the tracer if traces are available before
    the tracer string database is fully loaded, leading to an unfunctional tracer.
    This fix will rearm the tracer every time the FW triggers tracer event
    regardless of the tracer strings database status.
    
    Fixes: c71ad41ccb0c ("net/mlx5: FW tracer, events handling")
    Signed-off-by: Feras Daoud <ferasda@nvidia.com>
    Signed-off-by: Roy Novich <royno@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb4ccd9d26b43984f8001e615ee9242a5fa3c13e
Author: Saeed Mahameed <saeedm@nvidia.com>
Date:   Fri Feb 19 23:10:47 2021 -0800

    net/mlx5: Fix mlx5_get_next_dev() peer device matching
    
    [ Upstream commit 1c5de097bea31760c3f0467ac0c84ba0dc3525d5 ]
    
    In some use-cases, mlx5 instances will need to search for their peer
    device (the other port on the same HCA). For that, mlx5 device matching
    mechanism relied on auxiliary_find_device() to search, and used a bad matching
    callback function.
    
    This approach has two issues:
    
    1) next_phys_dev() the matching function, assumed all devices are
       of the type mlx5_adev (mlx5 auxiliary device) which is wrong and
       could lead to crashes, this worked for a while, since only lately
       other drivers started registering auxiliary devices.
    
    2) using the auxiliary class bus (auxiliary_find_device) to search for
       mlx5_core_dev devices, who are actually PCIe device instances, is wrong.
       This works since mlx5_core always has at least one mlx5_adev instance
       hanging around in the aux bus.
    
    As suggested by others we can fix 1. by comparing device names prefixes
    if they have the string "mlx5_core" in them, which is not a best practice !
    but even with that fixed, still 2. needs fixing, we are trying to
    match pcie device peers so we should look in the right bus (pci bus),
    hence this fix.
    
    The fix:
    1) search the pci bus for mlx5 peer devices, instead of the aux bus
    2) to validated devices are the same type "mlx5_core_dev" compare if
       they have the same driver, which is bulletproof.
    
       This wouldn't have worked with the aux bus since the various mlx5 aux
       device types don't share the same driver, even if they share the same device
       wrapper struct (mlx5_adev) "which helped to find the parent device"
    
    Fixes: a925b5e309c9 ("net/mlx5: Register mlx5 devices to auxiliary virtual bus")
    Reported-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reported-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73dbe69d5ced952d6293878690971afcd2bc832a
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Sun Feb 27 12:40:39 2022 +0000

    net/mlx5: Lag, filter non compatible devices
    
    [ Upstream commit bc4c2f2e017949646b43fdcad005a03462d437c6 ]
    
    When search for a peer lag device we can filter based on that
    device's capabilities.
    
    Downstream patch will be less strict when filtering compatible devices
    and remove the limitation where we require exact MLX5_MAX_PORTS and
    change it to a range.
    
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11bcc79f4bcd244145e6a2c04d5dc755303492a8
Author: Paul Blakey <paulb@nvidia.com>
Date:   Tue Mar 29 18:37:18 2022 +0300

    net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules
    
    [ Upstream commit 15ef9efa855cf405fadd78272e1e5d04e09a1cf3 ]
    
    CT cleanup assumes that all tc rules were deleted first, and so
    is free to delete the CT shared resources (e.g the dr_action
    fwd_action which is shared for all tuples). But currently for
    uplink, this is happens in reverse, causing the below trace.
    
    CT cleanup is called from:
    mlx5e_cleanup_rep_tx()->mlx5e_cleanup_uplink_rep_tx()->
    mlx5e_rep_tc_cleanup()->mlx5e_tc_esw_cleanup()->
    mlx5_tc_ct_clean()
    
    Only afterwards, tc cleanup is called from:
    mlx5e_cleanup_rep_tx()->mlx5e_tc_ht_cleanup()
    which would have deleted all the tc ct rules, and so delete
    all the offloaded tuples.
    
    Fix this reversing the order of init and on cleanup, which
    will result in tc cleanup then ct cleanup.
    
    [ 9443.593347] WARNING: CPU: 2 PID: 206774 at drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]
    [ 9443.593349] Modules linked in: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan bonding geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount nf_nat mst_pciconf(O) dm_multipath sbsa_gwdt uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio mlx_bootctl(O) bluefield_edac sch_fq_codel ip_tables ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 crct10dif_ce i2c_mlxbf gpio_mlxbf2 mlxbf_gige aes_neon_bs aes_neon_blk [last unloaded: mlx5_ib]
    [ 9443.593419] CPU: 2 PID: 206774 Comm: modprobe Tainted: G           O      5.4.0-1023.24.gc14613d-bluefield #1
    [ 9443.593422] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:143ebaf Jan 11 2022
    [ 9443.593424] pstate: 20000005 (nzCv daif -PAN -UAO)
    [ 9443.593489] pc : mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]
    [ 9443.593545] lr : mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]
    [ 9443.593546] sp : ffff8000135dbab0
    [ 9443.593548] x29: ffff8000135dbab0 x28: ffff0003a6ab8e80
    [ 9443.593550] x27: 0000000000000000 x26: ffff0003e07d7000
    [ 9443.593552] x25: ffff800009609de0 x24: ffff000397fb2120
    [ 9443.593554] x23: ffff0003975c0000 x22: 0000000000000000
    [ 9443.593556] x21: ffff0003975f08c0 x20: ffff800009609de0
    [ 9443.593558] x19: ffff0003c8a13380 x18: 0000000000000014
    [ 9443.593560] x17: 0000000067f5f125 x16: 000000006529c620
    [ 9443.593561] x15: 000000000000000b x14: 0000000000000000
    [ 9443.593563] x13: 0000000000000002 x12: 0000000000000001
    [ 9443.593565] x11: ffff800011108868 x10: 0000000000000000
    [ 9443.593567] x9 : 0000000000000000 x8 : ffff8000117fb270
    [ 9443.593569] x7 : ffff0003ebc01288 x6 : 0000000000000000
    [ 9443.593571] x5 : ffff800009591ab8 x4 : fffffe000f6d9a20
    [ 9443.593572] x3 : 0000000080040001 x2 : fffffe000f6d9a20
    [ 9443.593574] x1 : ffff8000095901d8 x0 : 0000000000000025
    [ 9443.593577] Call trace:
    [ 9443.593634]  mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]
    [ 9443.593688]  mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]
    [ 9443.593743]  mlx5_tc_ct_clean+0x34/0xa8 [mlx5_core]
    [ 9443.593797]  mlx5e_tc_esw_cleanup+0x58/0x88 [mlx5_core]
    [ 9443.593851]  mlx5e_rep_tc_cleanup+0x24/0x30 [mlx5_core]
    [ 9443.593905]  mlx5e_cleanup_rep_tx+0x6c/0x78 [mlx5_core]
    [ 9443.593959]  mlx5e_detach_netdev+0x74/0x98 [mlx5_core]
    [ 9443.594013]  mlx5e_netdev_change_profile+0x70/0x180 [mlx5_core]
    [ 9443.594067]  mlx5e_netdev_attach_nic_profile+0x34/0x40 [mlx5_core]
    [ 9443.594122]  mlx5e_vport_rep_unload+0x15c/0x1a8 [mlx5_core]
    [ 9443.594177]  mlx5_eswitch_unregister_vport_reps+0x228/0x298 [mlx5_core]
    [ 9443.594231]  mlx5e_rep_remove+0x2c/0x38 [mlx5_core]
    [ 9443.594236]  auxiliary_bus_remove+0x30/0x50 [auxiliary]
    [ 9443.594246]  device_release_driver_internal+0x108/0x1d0
    [ 9443.594248]  driver_detach+0x5c/0xe8
    [ 9443.594250]  bus_remove_driver+0x64/0xd8
    [ 9443.594253]  driver_unregister+0x38/0x60
    [ 9443.594255]  auxiliary_driver_unregister+0x24/0x38 [auxiliary]
    [ 9443.594311]  mlx5e_rep_cleanup+0x20/0x38 [mlx5_core]
    [ 9443.594365]  mlx5e_cleanup+0x18/0x30 [mlx5_core]
    [ 9443.594419]  cleanup+0xc/0x20cc [mlx5_core]
    [ 9443.594424]  __arm64_sys_delete_module+0x154/0x2b0
    [ 9443.594429]  el0_svc_common.constprop.0+0xf4/0x200
    [ 9443.594432]  el0_svc_handler+0x38/0xa8
    [ 9443.594435]  el0_svc+0x10/0x26c
    
    Fixes: d1a3138f7913 ("net/mlx5e: TC, Move flow hashtable to be per rep")
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Oz Shlomo <ozsh@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ba4416b831eeb4d185e88e73488d1d21288e63a
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:53:55 2022 +0900

    net: ipv6: unexport __init-annotated seg6_hmac_init()
    
    [ Upstream commit 5801f064e35181c71857a80ff18af4dbec3c5f5c ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the caller (net/ipv6/seg6.c)
    and the callee (net/ipv6/seg6_hmac.c) belong to the same module.
    It seems an internal function call in ipv6.ko.
    
    Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b253fbc9f7b5db18d716436bdcf8ecef09fd63d
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:53:54 2022 +0900

    net: xfrm: unexport __init-annotated xfrm4_protocol_init()
    
    [ Upstream commit 4a388f08d8784af48f352193d2b72aaf167a57a1 ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the only in-tree call-site,
    net/ipv4/xfrm4_policy.c is never compiled as modular.
    (CONFIG_XFRM is boolean)
    
    Fixes: 2f32b51b609f ("xfrm: Introduce xfrm_input_afinfo to access the the callbacks properly")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2f0f8c18b60ca64ff50892ed899cf1c77864755
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:53:53 2022 +0900

    net: mdio: unexport __init-annotated mdio_bus_init()
    
    [ Upstream commit 35b42dce619701f1300fb8498dae82c9bb1f0263 ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the only in-tree call-site,
    drivers/net/phy/phy_device.c is never compiled as modular.
    (CONFIG_PHYLIB is boolean)
    
    Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c22fa18fb51500a44f226984e95f6bbee5def4d2
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jun 7 16:47:52 2022 -0400

    SUNRPC: Fix the calculation of xdr->end in xdr_get_next_encode_buffer()
    
    [ Upstream commit 6c254bf3b637dd4ef4f78eb78c7447419c0161d7 ]
    
    I found that NFSD's new NFSv3 READDIRPLUS XDR encoder was screwing up
    right at the end of the page array. xdr_get_next_encode_buffer() does
    not compute the value of xdr->end correctly:
    
     * The check to see if we're on the final available page in xdr->buf
       needs to account for the space consumed by @nbytes.
    
     * The new xdr->end value needs to account for the portion of @nbytes
       that is to be encoded into the previous buffer.
    
    Fixes: 2825a7f90753 ("nfsd4: allow encoding across page boundaries")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Reviewed-by: NeilBrown <neilb@suse.de>
    Reviewed-by: J. Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 073c356b310175a9bd4845ebbd8cda1e186967e9
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Jun 3 12:21:06 2022 +0200

    drm/amdgpu: fix limiting AV1 to the first instance on VCN3
    
    [ Upstream commit 1d2afeb7983081ecf656c2338c7db6fd405c653c ]
    
    The job is not yet initialized here.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2037
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Fixes: cdc7893fc93f ("drm/amdgpu: use job and ib structures directly in CS parsers")
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbbe301dec6885e4adb062af5c16e18a09d64c94
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Tue Jun 7 16:22:00 2022 +0200

    xsk: Fix handling of invalid descriptors in XSK TX batching API
    
    [ Upstream commit d678cbd2f867a564a3c5b276c454e873f43f02f8 ]
    
    xdpxceiver run on a AF_XDP ZC enabled driver revealed a problem with XSK
    Tx batching API. There is a test that checks how invalid Tx descriptors
    are handled by AF_XDP. Each valid descriptor is followed by invalid one
    on Tx side whereas the Rx side expects only to receive a set of valid
    descriptors.
    
    In current xsk_tx_peek_release_desc_batch() function, the amount of
    available descriptors is hidden inside xskq_cons_peek_desc_batch(). This
    can be problematic in cases where invalid descriptors are present due to
    the fact that xskq_cons_peek_desc_batch() returns only a count of valid
    descriptors. This means that it is impossible to properly update XSK
    ring state when calling xskq_cons_release_n().
    
    To address this issue, pull out the contents of
    xskq_cons_peek_desc_batch() so that callers (currently only
    xsk_tx_peek_release_desc_batch()) will always be able to update the
    state of ring properly, as total count of entries is now available and
    use this value as an argument in xskq_cons_release_n(). By
    doing so, xskq_cons_peek_desc_batch() can be dropped altogether.
    
    Fixes: 9349eb3a9d2a ("xsk: Introduce batched Tx descriptor interfaces")
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Link: https://lore.kernel.org/bpf/20220607142200.576735-1-maciej.fijalkowski@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29c94d87aefc9247485565ae91437218a58550b8
Author: Gal Pressman <gal@nvidia.com>
Date:   Mon Jun 6 14:57:18 2022 +0300

    net/mlx4_en: Fix wrong return value on ioctl EEPROM query failure
    
    [ Upstream commit f5826c8c9d57210a17031af5527056eefdc2b7eb ]
    
    The ioctl EEPROM query wrongly returns success on read failures, fix
    that by returning the appropriate error code.
    
    Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20220606115718.14233-1-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e007ac6fa7c9c94ad84da075c5c504afad690a0
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 11:23:34 2022 +0400

    net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list
    
    [ Upstream commit 0737e018a05e2aa352828c52bdeed3b02cff2930 ]
    
    Every iteration of for_each_available_child_of_node() decrements
    the reference count of the previous node.
    when breaking early from a for_each_available_child_of_node() loop,
    we need to explicitly call of_node_put() on the gphy_fw_np.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220605072335.11257-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41f7c4f85d402043687e863627a1a84fa867c62d
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue May 31 14:51:13 2022 -0700

    bpf, arm64: Clear prog->jited_len along prog->jited
    
    [ Upstream commit 10f3b29c65bb2fe0d47c2945cd0b4087be1c5218 ]
    
    syzbot reported an illegal copy_to_user() attempt
    from bpf_prog_get_info_by_fd() [1]
    
    There was no repro yet on this bug, but I think
    that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")
    is exposing a prior bug in bpf arm64.
    
    bpf_prog_get_info_by_fd() looks at prog->jited_len
    to determine if the JIT image can be copied out to user space.
    
    My theory is that syzbot managed to get a prog where prog->jited_len
    has been set to 43, while prog->bpf_func has ben cleared.
    
    It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering
    this particular warning.
    
    I thought find_vma_area(NULL) would not find a vm_struct.
    As we do not hold vmap_area_lock spinlock, it might be possible
    that the found vm_struct was garbage.
    
    [1]
    usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!
    kernel BUG at mm/usercopy.c:101!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0
    Hardware name: linux,dummy-virt (DT)
    pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101
    lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89
    sp : ffff80000b773a20
    x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48
    x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000
    x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001
    x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd
    x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420
    x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031
    x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865
    x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830
    x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000
    x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064
    Call trace:
     usercopy_abort+0x90/0x94 mm/usercopy.c:89
     check_heap_object mm/usercopy.c:186 [inline]
     __check_object_size mm/usercopy.c:252 [inline]
     __check_object_size+0x198/0x36c mm/usercopy.c:214
     check_object_size include/linux/thread_info.h:199 [inline]
     check_copy_size include/linux/thread_info.h:235 [inline]
     copy_to_user include/linux/uaccess.h:159 [inline]
     bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993
     bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253
     __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956
     __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]
     __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019
     __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
     invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52
     el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142
     do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206
     el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624
     el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642
     el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581
    Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
    
    Fixes: db496944fdaa ("bpf: arm64: add JIT support for multi-function programs")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20220531215113.1100754-1-eric.dumazet@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18a53ad128c7a43c8bbf6f2e48713b742d1ab596
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Jun 7 17:00:53 2022 +0200

    x86: drop bogus "cc" clobber from __try_cmpxchg_user_asm()
    
    [ Upstream commit 1df931d95f4dc1c11db1123e85d4e08156e46ef9 ]
    
    As noted (and fixed) a couple of times in the past, "=@cc<cond>" outputs
    and clobbering of "cc" don't work well together. The compiler appears to
    mean to reject such, but doesn't - in its upstream form - quite manage
    to yet for "cc". Furthermore two similar macros don't clobber "cc", and
    clobbering "cc" is pointless in asm()-s for x86 anyway - the compiler
    always assumes status flags to be clobbered there.
    
    Fixes: 989b5db215a2 ("x86/uaccess: Implement macros for CMPXCHG on user addresses")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Message-Id: <485c0c0b-a3a7-0b7c-5264-7d00c01de032@suse.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28a815e3e15cd77f763fe6592e7755eb5a713661
Author: Lina Wang <lina.wang@mediatek.com>
Date:   Mon Jun 6 14:45:17 2022 +0800

    selftests net: fix bpf build error
    
    [ Upstream commit cf67838c4422eab826679b076dad99f96152b4de ]
    
    bpf_helpers.h has been moved to tools/lib/bpf since 5.10, so add more
    including path.
    
    Fixes: edae34a3ed92 ("selftests net: add UDP GRO fraglist + bpf self-tests")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Lina Wang <lina.wang@mediatek.com>
    Acked-by: Song Liu <songliubraving@fb.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/20220606064517.8175-1-lina.wang@mediatek.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sun Jun 5 16:23:25 2022 -0700

    af_unix: Fix a data-race in unix_dgram_peer_wake_me().
    
    [ Upstream commit 662a80946ce13633ae90a55379f1346c10f0c432 ]
    
    unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s
    lock held and check if its receive queue is full.  Here we need to
    use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise
    KCSAN will report a data-race.
    
    Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20220605232325.11804-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59dc41ec8d8fc5be857f5ffa51c8bb6e01ac6f3f
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jun 5 22:50:48 2022 +0200

    stmmac: intel: Fix an error handling path in intel_eth_pci_probe()
    
    [ Upstream commit 5e74a4b3ec1816e3bbfd715d46ae29d2508079cb ]
    
    When the managed API is used, there is no need to explicitly call
    pci_free_irq_vectors().
    
    This looks to be a left-over from the commit in the Fixes tag. Only the
    .remove() function had been updated.
    
    So remove this unused function call and update goto label accordingly.
    
    Fixes: 8accc467758e ("stmmac: intel: use managed PCI function on probe and resume")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
    Link: https://lore.kernel.org/r/1ac9b6787b0db83b0095711882c55c77c8ea8da0.1654462241.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ddb4334f4136cd5c84885032894663a4d57928d
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:59:20 2022 +0900

    xen: unexport __init-annotated xen_xlate_map_ballooned_pages()
    
    [ Upstream commit dbac14a5a05ff8e1ce7c0da0e1f520ce39ec62ea ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because none of the in-tree call-sites
    (arch/arm/xen/enlighten.c, arch/x86/xen/grant-table.c) is compiled as
    modular.
    
    Fixes: 243848fc018c ("xen/grant-table: Move xlated_setup_gnttab_pages to common place")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/20220606045920.4161881-1-masahiroy@kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fb1fe7d9a167205413f1de8db9f7d0f82c78286
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 17:32:38 2022 +0400

    net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register
    
    [ Upstream commit b8d91399775c55162073bb2aca061ec42e3d4bc1 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 55954f3bfdac ("net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220603133238.44114-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebb545a57a0d88729e94e4cef941d93f2909e8bb
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Jun 2 14:01:08 2022 +0000

    amt: fix wrong type string definition
    
    [ Upstream commit d7970039d87c926bb648982e920cb9851c19f3e1 ]
    
    amt message type definition starts from 1, not 0.
    But type_str[] starts from 0.
    So, it prints wrong type information.
    
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55bbdc2d41a8b32ef0ef63ffd0c291e56f804df6
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Jun 2 14:01:07 2022 +0000

    amt: fix possible null-ptr-deref in amt_rcv()
    
    [ Upstream commit d16207f92a4a823c48b4ea953ad51f4483456768 ]
    
    When amt interface receives amt message, it tries to obtain amt private
    data from sock.
    If there is no amt private data, it frees an skb immediately.
    After kfree_skb(), it increases the rx_dropped stats.
    But in order to use rx_dropped, amt private data is needed.
    So, it makes amt_rcv() to do not increase rx_dropped stats when it can
    not obtain amt private data.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 1a1a0e80e005 ("amt: fix possible memory leak in amt_rcv()")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afc48f222b82d12fac523bf4feaf99b0cfcb7e8d
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Jun 2 14:01:06 2022 +0000

    amt: fix wrong usage of pskb_may_pull()
    
    [ Upstream commit f55a07074fdd38cab8c097ac5bd397d68eff733c ]
    
    It adds missing pskb_may_pull() in amt_update_handler() and
    amt_multicast_data_handler().
    And it fixes wrong parameter of pskb_may_pull() in
    amt_advertisement_handler() and amt_membership_query_handler().
    
    Reported-by: Jakub Kicinski <kuba@kernel.org>
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c02559cfea0aed3d685ceceb20e5d95551a1dc39
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jun 6 17:31:29 2022 +0200

    netfilter: nf_tables: bail out early if hardware offload is not supported
    
    [ Upstream commit 3a41c64d9c1185a2f3a184015e2a9b78bfc99c71 ]
    
    If user requests for NFT_CHAIN_HW_OFFLOAD, then check if either device
    provides the .ndo_setup_tc interface or there is an indirect flow block
    that has been registered. Otherwise, bail out early from the preparation
    phase. Moreover, validate that family == NFPROTO_NETDEV and hook is
    NF_NETDEV_INGRESS.
    
    Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab9f34a30c23f656e76f4c5b83125a4e7b53c86e
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jun 6 17:15:57 2022 +0200

    netfilter: nf_tables: memleak flow rule from commit path
    
    [ Upstream commit 9dd732e0bdf538b1b76dc7c157e2b5e560ff30d3 ]
    
    Abort path release flow rule object, however, commit path does not.
    Update code to destroy these objects before releasing the transaction.
    
    Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 783f28b933e8a381c65dc4befeffb986ccced5b6
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Jun 5 13:40:06 2022 +0200

    netfilter: nf_tables: release new hooks on unsupported flowtable flags
    
    [ Upstream commit c271cc9febaaa1bcbc0842d1ee30466aa6148ea8 ]
    
    Release the list of new hooks that are pending to be registered in case
    that unsupported flowtable flags are provided.
    
    Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb2cb409b504bb3a69e65a17f3120328c8e50219
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:59:26 2022 +0400

    ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe
    
    [ Upstream commit 10d6bdf532902be1d8aa5900b3c03c5671612aa2 ]
    
    of_find_device_by_node() takes reference, we should use put_device()
    to release it when not need anymore.
    Add missing put_device() to avoid refcount leak.
    
    Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4043ea452f98c2309bce90a9d96b6e5ce1c6b0cd
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jun 1 17:49:36 2022 +0200

    netfilter: nf_tables: always initialize flowtable hook list in transaction
    
    [ Upstream commit 2c9e4559773c261900c674a86b8e455911675d71 ]
    
    The hook list is used if nft_trans_flowtable_update(trans) == true. However,
    initialize this list for other cases for safety reasons.
    
    Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 659f7568e09593945c221bf20217a82ebdfe1328
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Jun 1 12:46:52 2022 -0400

    SUNRPC: Trap RDMA segment overflows
    
    [ Upstream commit f012e95b377c73c0283f009823c633104dedb337 ]
    
    Prevent svc_rdma_build_writes() from walking off the end of a Write
    chunk's segment array. Caught with KASAN.
    
    The test that this fix replaces is invalid, and might have been left
    over from an earlier prototype of the PCL work.
    
    Fixes: 7a1cbfa18059 ("svcrdma: Use parsed chunk lists to construct RDMA Writes")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 333dcc94ebf53f79f3dc0e7a7c16700bc7ff7e57
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue May 31 19:49:01 2022 -0400

    NFSD: Fix potential use-after-free in nfsd_file_put()
    
    [ Upstream commit b6c71c66b0ad8f2b59d9bc08c7a5079b110bec01 ]
    
    nfsd_file_put_noref() can free @nf, so don't dereference @nf
    immediately upon return from nfsd_file_put_noref().
    
    Suggested-by: Trond Myklebust <trondmy@hammerspace.com>
    Fixes: 999397926ab3 ("nfsd: Clean up nfsd_file_put()")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e2e17a8fbfb9686f8bdf9db565ab0ffe6807b6e
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Jun 2 00:31:14 2022 +1000

    powerpc/kasan: Force thread size increase with KASAN
    
    [ Upstream commit 3e8635fb2e072672cbc650989ffedf8300ad67fb ]
    
    KASAN causes increased stack usage, which can lead to stack overflows.
    
    The logic in Kconfig to suggest a larger default doesn't work if a user
    has CONFIG_EXPERT enabled and has an existing .config with a smaller
    value.
    
    Follow the lead of x86 and arm64, and force the thread size to be
    increased when KASAN is enabled.
    
    That also has the effect of enlarging the stack for 64-bit KASAN builds,
    which is also desirable.
    
    Fixes: edbadaf06710 ("powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT")
    Reported-by: Erhard Furtner <erhard_f@mailbox.org>
    Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Use MIN_THREAD_SHIFT as suggested by Christophe]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220601143114.133524-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99180dec5ae582227219d1fdd0dd5ccf53ec7491
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon May 30 18:40:06 2022 +0200

    netfilter: nf_tables: delete flowtable hooks via transaction list
    
    [ Upstream commit b6d9014a3335194590abdd2a2471ef5147a67645 ]
    
    Remove inactive bool field in nft_hook object that was introduced in
    abadb2f865d7 ("netfilter: nf_tables: delete devices from flowtable").
    Move stale flowtable hooks to transaction list instead.
    
    Deleting twice the same device does not result in ENOENT.
    
    Fixes: abadb2f865d7 ("netfilter: nf_tables: delete devices from flowtable")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13c5b35c5045e6764920413a591cbf82cd593b9a
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jun 1 16:00:00 2022 +0200

    netfilter: nf_tables: use kfree_rcu(ptr, rcu) to release hooks in clean_net path
    
    [ Upstream commit ab5e5c062f67c5ae8cd07f0632ffa62dc0e7d169 ]
    
    Use kfree_rcu(ptr, rcu) variant instead as described by ae089831ff28
    ("netfilter: nf_tables: prefer kfree_rcu(ptr, rcu) variant").
    
    Fixes: f9a43007d3f7 ("netfilter: nf_tables: double hook unregistration in netns path")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e61fa6b027ee6cbfd2da52723fae69c6b779992d
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Jun 1 10:47:35 2022 +0200

    netfilter: nat: really support inet nat without l3 address
    
    [ Upstream commit 282e5f8fe907dc3f2fbf9f2103b0e62ffc3a68a5 ]
    
    When no l3 address is given, priv->family is set to NFPROTO_INET and
    the evaluation function isn't called.
    
    Call it too so l4-only rewrite can work.
    Also add a test case for this.
    
    Fixes: a33f387ecd5aa ("netfilter: nft_nat: allow to specify layer 4 protocol NAT only")
    Reported-by: Yi Chen <yiche@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1295aab2ebcda1c1a9ed342baedc080e5c393e5
Author: Vaibhav Jain <vaibhav@linux.ibm.com>
Date:   Tue May 24 16:53:53 2022 +0530

    powerpc/papr_scm: don't requests stats with '0' sized stats buffer
    
    [ Upstream commit 07bf9431b1590d1cd7a8d62075d0b50b073f0495 ]
    
    Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being
    reported with vPMEM when papr_scm probe is being called. The panic is of the
    form below and is observed only with following option disabled(profile) for the
    said LPAR 'Enable Performance Information Collection' in the HMC:
    
     Kernel attempted to write user page (1c) - exploit attempt? (uid: 0)
     BUG: Kernel NULL pointer dereference on write at 0x0000001c
     Faulting instruction address: 0xc008000001b90844
     Oops: Kernel access of bad area, sig: 11 [#1]
    <snip>
     NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm]
     LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm]
     Call Trace:
           0xc00000000941bca0 (unreliable)
           papr_scm_probe+0x2ac/0x6ec [papr_scm]
           platform_probe+0x98/0x150
           really_probe+0xfc/0x510
           __driver_probe_device+0x17c/0x230
    <snip>
     ---[ end trace 0000000000000000 ]---
     Kernel panic - not syncing: Fatal exception
    
    On investigation looks like this panic was caused due to a 'stat_buffer' of
    size==0 being provided to drc_pmem_query_stats() to fetch all performance
    stats-ids of an NVDIMM. However drc_pmem_query_stats() shouldn't have been called
    since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused
    due to missing check for 'p->stat_buffer_len' at the beginning of
    papr_scm_pmu_check_events() which indicates that the NVDIMM doesn't support
    performance-stats.
    
    Fix this by introducing the check for 'p->stat_buffer_len' at the beginning of
    papr_scm_pmu_check_events().
    
    [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com
    
    Fixes: 0e0946e22f3665d2732 ("powerpc/papr_scm: Fix leaking nvdimm_events_map elements")
    Reported-by: Sachin Sant <sachinp@linux.ibm.com>
    Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
    Tested-by: Sachin Sant <sachinp@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220524112353.1718454-1-vaibhav@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 472dd7ea5e19a1aeabf1711ddc756777e05ee7c2
Author: Steven Price <steven.price@arm.com>
Date:   Thu May 19 16:20:03 2022 +0100

    drm/panfrost: Job should reference MMU not file_priv
    
    [ Upstream commit 6e516faf04317db2c46cbec4e3b78b4653a5b109 ]
    
    For a while now it's been allowed for a MMU context to outlive it's
    corresponding panfrost_priv, however the job structure still references
    panfrost_priv to get hold of the MMU context. If panfrost_priv has been
    freed this is a use-after-free which I've been able to trigger resulting
    in a splat.
    
    To fix this, drop the reference to panfrost_priv in the job structure
    and add a direct reference to the MMU structure which is what's actually
    needed.
    
    Fixes: 7fdc48cc63a3 ("drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv")
    Signed-off-by: Steven Price <steven.price@arm.com>
    Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220519152003.81081-1-steven.price@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c302e5ee2f0e11ff1abe87d4cd77e370c166119e
Author: Marek Vasut <marex@denx.de>
Date:   Thu May 19 01:38:44 2022 +0200

    drm/bridge: ti-sn65dsi83: Handle dsi_lanes == 0 as invalid
    
    [ Upstream commit edbc7960bef7fd71ef1e44d0df15b864784b14c8 ]
    
    Handle empty data-lanes = < >; property, which translates to
    dsi_lanes = 0 as invalid.
    
    Fixes: ceb515ba29ba6 ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Jonas Karlman <jonas@kwiboo.se>
    Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Marek Vasut <marex@denx.de>
    Cc: Maxime Ripard <maxime@cerno.tech>
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Cc: Robert Foss <robert.foss@linaro.org>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220518233844.248504-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91784f3d77b73885e1b2e6b59d3cbf0de0a1126a
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Sun May 22 20:36:48 2022 +0800

    xprtrdma: treat all calls not a bcall when bc_serv is NULL
    
    [ Upstream commit 11270e7ca268e8d61b5d9e5c3a54bd1550642c9c ]
    
    When a rdma server returns a fault format reply, nfs v3 client may
    treats it as a bcall when bc service is not exist.
    
    The debug message at rpcrdma_bc_receive_call are,
    
    [56579.837169] RPC:       rpcrdma_bc_receive_call: callback XID
    00000001, length=20
    [56579.837174] RPC:       rpcrdma_bc_receive_call: 00 00 00 01 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 04
    
    After that, rpcrdma_bc_receive_call will meets NULL pointer as,
    
    [  226.057890] BUG: unable to handle kernel NULL pointer dereference at
    00000000000000c8
    ...
    [  226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20
    ...
    [  226.059732] Call Trace:
    [  226.059878]  rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma]
    [  226.060011]  __ib_process_cq+0x89/0x170 [ib_core]
    [  226.060092]  ib_cq_poll_work+0x26/0x80 [ib_core]
    [  226.060257]  process_one_work+0x1a7/0x360
    [  226.060367]  ? create_worker+0x1a0/0x1a0
    [  226.060440]  worker_thread+0x30/0x390
    [  226.060500]  ? create_worker+0x1a0/0x1a0
    [  226.060574]  kthread+0x116/0x130
    [  226.060661]  ? kthread_flush_work_fn+0x10/0x10
    [  226.060724]  ret_from_fork+0x35/0x40
    ...
    
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d3bba6b1616b0852ffb8384fff8febfa530b8a7
Author: Chao Yu <chao@kernel.org>
Date:   Fri May 27 12:13:30 2022 +0800

    f2fs: fix to tag gcing flag on page during file defragment
    
    [ Upstream commit 2d1fe8a86bf5e0663866fd0da83c2af1e1b0e362 ]
    
    In order to garantee migrated data be persisted during checkpoint,
    otherwise out-of-order persistency between data and node may cause
    data corruption after SPOR.
    
    Signed-off-by: Chao Yu <chao.yu@oppo.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 066aa2a47806a42b36fd851f5844ac380c292cc5
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Fri Apr 29 16:54:58 2022 +0200

    rtla/Makefile: Properly handle dependencies
    
    [ Upstream commit fe4d0d5dde457bb5832b866418b5036f4f0c8d13 ]
    
    Linus had a problem compiling RTLA, saying:
    
    "[...] I wish the tracing tools would do a bit more package
    checking and helpful error messages too, rather than just
    fail with:
    
        fatal error: tracefs.h: No such file or directory"
    
    Which is indeed not a helpful message. Update the Makefile, adding
    proper checks for the dependencies, with useful information about
    how to resolve possible problems.
    
    For example, the previous error is now reported as:
    
        $ make
        ********************************************
        ** NOTICE: libtracefs version 1.3 or higher not found
        **
        ** Consider installing the latest libtracefs from your
        ** distribution, e.g., 'dnf install libtracefs' on Fedora,
        ** or from source:
        **
        **  https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
        **
        ********************************************
    
    These messages are inspired by the ones used on trace-cmd, as suggested
    by Stevel Rostedt.
    
    Link: https://lore.kernel.org/r/CAHk-=whxmA86E=csNv76DuxX_wYsg8mW15oUs3XTabu2Yc80yw@mail.gmail.com/
    
    Changes from V1:
     - Moved the rst2man check to the install phase (when it is used).
     - Removed the procps-ng lib check [1] as it is being removed.
    
    [1] a0f9f8c1030c66305c9b921057c3d483064d5529.1651220820.git.bristot@kernel.org
    
    Link: https://lkml.kernel.org/r/3f1fac776c37e4b67c876a94e5a0e45ed022ff3d.1651238057.git.bristot@kernel.org
    
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c19e6e19ba1363e143400d53240cc2cc385aca14
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Mon May 16 16:36:07 2022 +1000

    m68knommu: fix undefined reference to `mach_get_rtc_pll'
    
    [ Upstream commit 1300eec9e51f23c34c4487d2b06f58ca22e1ad3d ]
    
    Configuring for a nommu classic m68k target and enabling the generic rtc
    driver (CONFIG_RTC_DRV_GENERIC) will result in the following compile
    error:
    
       m68k-linux-ld: arch/m68k/kernel/time.o: in function `rtc_ioctl':
       time.c:(.text+0x82): undefined reference to `mach_get_rtc_pll'
       m68k-linux-ld: time.c:(.text+0xbc): undefined reference to `mach_set_rtc_pll'
       m68k-linux-ld: time.c:(.text+0xf4): undefined reference to `mach_set_rtc_pll'
    
    There are no definitions of "mach_set_rtc_pll" and "mach_get_rtc_pll" in the
    nommu code paths. Move these definitions and the associated "mach_hwclk",
    so that they are around their use case in time.c. This means they will
    always be defined on the builds that require them, and not on those that
    cannot use them - such as ColdFire (both with and without MMU enabled).
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ba83e46b591381e718007f55c9f831fd0cd7ee8
Author: Liao Chang <liaochang1@huawei.com>
Date:   Fri Apr 8 18:09:10 2022 +0800

    RISC-V: use memcpy for kexec_file mode
    
    [ Upstream commit b7fb4d78a6ade6026d9e5cf438c2a46ab962e032 ]
    
    The pointer to buffer loading kernel binaries is in kernel space for
    kexec_fil mode, When copy_from_user copies data from pointer to a block
    of memory, it checkes that the pointer is in the user space range, on
    RISCV-V that is:
    
    static inline bool __access_ok(unsigned long addr, unsigned long size)
    {
            return size <= TASK_SIZE && addr <= TASK_SIZE - size;
    }
    
    and TASK_SIZE is 0x4000000000 for 64-bits, which now causes
    copy_from_user to reject the access of the field 'buf' of struct
    kexec_segment that is in range [CONFIG_PAGE_OFFSET - VMALLOC_SIZE,
    CONFIG_PAGE_OFFSET), is invalid user space pointer.
    
    This patch fixes this issue by skipping access_ok(), use mempcy() instead.
    
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Link: https://lore.kernel.org/r/20220408100914.150110-3-lizhengyu3@huawei.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c49d8b1a6ac8a8ab8fb790a0c2fb102a39ae110
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri May 13 18:05:41 2022 +0800

    video: fbdev: pxa3xx-gcu: release the resources correctly in pxa3xx_gcu_probe/remove()
    
    [ Upstream commit d87ad457f7e1b8d2492ca5b1531eb35030a1cc8f ]
    
    In pxa3xx_gcu_probe(), the sequence of error lable is wrong, it will
    leads some resource leaked, so adjust the sequence to handle the error
    correctly, and if pxa3xx_gcu_add_buffer() fails, pxa3xx_gcu_free_buffers()
    need be called.
    In pxa3xx_gcu_remove(), add missing clk_disable_unpreprare().
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13eb15c0817db49bde456ce38139e7d254ab62ad
Author: Saurabh Sengar <ssengar@linux.microsoft.com>
Date:   Wed Apr 27 06:47:53 2022 -0700

    video: fbdev: hyperv_fb: Allow resolutions with size > 64 MB for Gen1
    
    [ Upstream commit c4b4d7047f16a8d138ce76da65faefb7165736f2 ]
    
    This patch fixes a bug where GEN1 VMs doesn't allow resolutions greater
    than 64 MB size (eg 7680x4320). Unnecessary PCI check limits Gen1 VRAM
    to legacy PCI BAR size only (ie 64MB). Thus any, resolution requesting
    greater then 64MB (eg 7680x4320) would fail. MMIO region assigning this
    memory shouldn't be limited by PCI bar size.
    
    Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea759ae0a9ae5acee677d722129710ac89cc59c1
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat May 14 10:08:14 2022 -0400

    NFSv4: Don't hold the layoutget locks across multiple RPC calls
    
    [ Upstream commit 6949493884fe88500de4af182588e071cf1544ee ]
    
    When doing layoutget as part of the open() compound, we have to be
    careful to release the layout locks before we can call any further RPC
    calls, such as setattr(). The reason is that those calls could trigger
    a recall, which could deadlock.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90aefae2e3a770a6909d339f5d8a988c0b0ceaf0
Author: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Date:   Tue May 10 12:42:40 2022 +0530

    dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type
    
    [ Upstream commit f9a9f43a62a04ec3183fb0da9226c7706eed0115 ]
    
    In zynqmp_dma_alloc/free_chan_resources functions there is a
    potential overflow in the below expressions.
    
    dma_alloc_coherent(chan->dev, (2 * chan->desc_size *
                       ZYNQMP_DMA_NUM_DESCS),
                       &chan->desc_pool_p, GFP_KERNEL);
    
    dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) *
                     ZYNQMP_DMA_NUM_DESCS),
                    chan->desc_pool_v, chan->desc_pool_p);
    
    The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though
    this overflow condition is not observed but it is a potential problem
    in the case of 32-bit multiplication. Hence fix it by changing the
    desc_size data type to size_t.
    
    In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in
    dma_alloc_coherent API argument.
    
    Addresses-Coverity: Event overflow_before_widen.
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Link: https://lore.kernel.org/r/1652166762-18317-2-git-send-email-radhey.shyam.pandey@xilinx.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60a96c785a13a68501edce594e0688ceff528d85
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Fri May 13 17:27:39 2022 +1000

    m68knommu: fix undefined reference to `_init_sp'
    
    [ Upstream commit a71b9e66fee47c59b3ec34e652b5c23bc6550794 ]
    
    When configuring a nommu classic m68k system enabling the uboot parameter
    passing support (CONFIG_UBOOT) will produce the following compile error:
    
       m68k-linux-ld: arch/m68k/kernel/uboot.o: in function `process_uboot_commandline':
       uboot.c:(.init.text+0x32): undefined reference to `_init_sp'
    
    The logic to support this option is only used on ColdFire based platforms
    (in its head.S startup code). So make the selection of this option
    depend on building for a ColdFire based platform.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6138e225721bd5126ffb8b8c4a2a997e58073ff
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Wed Apr 20 23:27:47 2022 +1000

    m68knommu: set ZERO_PAGE() to the allocated zeroed page
    
    [ Upstream commit dc068f46217970d9516f16cd37972a01d50dc055 ]
    
    The non-MMU m68k pagetable ZERO_PAGE() macro is being set to the
    somewhat non-sensical value of "virt_to_page(0)". The zeroth page
    is not in any way guaranteed to be a page full of "0". So the result
    is that ZERO_PAGE() will almost certainly contain random values.
    
    We already allocate a real "empty_zero_page" in the mm setup code shared
    between MMU m68k and non-MMU m68k. It is just not hooked up to the
    ZERO_PAGE() macro for the non-MMU m68k case.
    
    Fix ZERO_PAGE() to use the allocated "empty_zero_page" pointer.
    
    I am not aware of any specific issues caused by the old code.
    
    Link: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#t
    Reported-by: Hugh Dickens <hughd@google.com>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eabb41396a41c79de52e680f5b2f7de29ba19a0a
Author: Lucas Tanure <tanureal@opensource.cirrus.com>
Date:   Wed Apr 13 10:14:10 2022 +0100

    i2c: cadence: Increase timeout per message if necessary
    
    [ Upstream commit 96789dce043f5bff8b7d62aa28d52a7c59403a84 ]
    
    Timeout as 1 second sets an upper limit on the length
    of the transfer executed, but there is no maximum length
    of a write or read message set in i2c_adapter_quirks for
    this controller.
    
    This upper limit affects devices that require sending
    large firmware blobs over I2C.
    
    To remove that limitation, calculate the minimal time
    necessary, plus some wiggle room, for every message and
    use it instead of the default one second, if more than
    one second.
    
    Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
    Acked-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd47ea5d776d8b524fb6f60de3240f95603901dd
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Mar 29 16:25:54 2022 -0700

    f2fs: avoid infinite loop to flush node pages
    
    [ Upstream commit a7b8618aa2f0f926ce85f2486ac835a85c753ca7 ]
    
    xfstests/generic/475 can give EIO all the time which give an infinite loop
    to flush node page like below. Let's avoid it.
    
    [16418.518551] Call Trace:
    [16418.518553]  ? dm_submit_bio+0x48/0x400
    [16418.518574]  ? submit_bio_checks+0x1ac/0x5a0
    [16418.525207]  __submit_bio+0x1a9/0x230
    [16418.525210]  ? kmem_cache_alloc+0x29e/0x3c0
    [16418.525223]  submit_bio_noacct+0xa8/0x2b0
    [16418.525226]  submit_bio+0x4d/0x130
    [16418.525238]  __submit_bio+0x49/0x310 [f2fs]
    [16418.525339]  ? bio_add_page+0x6a/0x90
    [16418.525344]  f2fs_submit_page_bio+0x134/0x1f0 [f2fs]
    [16418.525365]  read_node_page+0x125/0x1b0 [f2fs]
    [16418.525388]  __get_node_page.part.0+0x58/0x3f0 [f2fs]
    [16418.525409]  __get_node_page+0x2f/0x60 [f2fs]
    [16418.525431]  f2fs_get_dnode_of_data+0x423/0x860 [f2fs]
    [16418.525452]  ? asm_sysvec_apic_timer_interrupt+0x12/0x20
    [16418.525458]  ? __mod_memcg_state.part.0+0x2a/0x30
    [16418.525465]  ? __mod_memcg_lruvec_state+0x27/0x40
    [16418.525467]  ? __xa_set_mark+0x57/0x70
    [16418.525472]  f2fs_do_write_data_page+0x10e/0x7b0 [f2fs]
    [16418.525493]  f2fs_write_single_data_page+0x555/0x830 [f2fs]
    [16418.525514]  ? sysvec_apic_timer_interrupt+0x4e/0x90
    [16418.525518]  ? asm_sysvec_apic_timer_interrupt+0x12/0x20
    [16418.525523]  f2fs_write_cache_pages+0x303/0x880 [f2fs]
    [16418.525545]  ? blk_flush_plug_list+0x47/0x100
    [16418.525548]  f2fs_write_data_pages+0xfd/0x320 [f2fs]
    [16418.525569]  do_writepages+0xd5/0x210
    [16418.525648]  filemap_fdatawrite_wbc+0x7d/0xc0
    [16418.525655]  filemap_fdatawrite+0x50/0x70
    [16418.525658]  f2fs_sync_dirty_inodes+0xa4/0x230 [f2fs]
    [16418.525679]  f2fs_write_checkpoint+0x16d/0x1720 [f2fs]
    [16418.525699]  ? ttwu_do_wakeup+0x1c/0x160
    [16418.525709]  ? ttwu_do_activate+0x6d/0xd0
    [16418.525711]  ? __wait_for_common+0x11d/0x150
    [16418.525715]  kill_f2fs_super+0xca/0x100 [f2fs]
    [16418.525733]  deactivate_locked_super+0x3b/0xb0
    [16418.525739]  deactivate_super+0x40/0x50
    [16418.525741]  cleanup_mnt+0x139/0x190
    [16418.525747]  __cleanup_mnt+0x12/0x20
    [16418.525749]  task_work_run+0x6d/0xa0
    [16418.525765]  exit_to_user_mode_prepare+0x1ad/0x1b0
    [16418.525771]  syscall_exit_to_user_mode+0x27/0x50
    [16418.525774]  do_syscall_64+0x48/0xc0
    [16418.525776]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c62c5e26345c34d199b4b8c8e69255ba3d0e751
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Fri Apr 15 21:19:02 2022 +0800

    f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
    
    [ Upstream commit dc2f78e2d4cc844a1458653d57ce1b54d4a29f21 ]
    
    Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and
    __is_bitmap_valid. For example, in f2fs_is_valid_blkaddr,
    if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ,
    it invokes WARN_ON if blkaddr is not in the right range.
    The call trace is as follows:
    
     f2fs_get_node_info+0x45f/0x1070
     read_node_page+0x577/0x1190
     __get_node_page.part.0+0x9e/0x10e0
     __get_node_page
     f2fs_get_node_page+0x109/0x180
     do_read_inode
     f2fs_iget+0x2a5/0x58b0
     f2fs_fill_super+0x3b39/0x7ca0
    
    Fix these two WARNs by replacing WARN_ON with dump_stack.
    
    Reported-by: syzbot+763ae12a2ede1d99d4dc@syzkaller.appspotmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54cf47da0c7532d151d76e5d63f5936191698c44
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Apr 25 19:45:25 2022 +0800

    iommu/arm-smmu-v3: check return value after calling platform_get_resource()
    
    [ Upstream commit b131fa8c1d2afd05d0b7598621114674289c2fbb ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220425114525.2651143-1-yangyingliang@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 449fc4561762ad9ad85362d5f01f0d0df397457a
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Apr 25 19:41:36 2022 +0800

    iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()
    
    [ Upstream commit d9ed8af1dee37f181096631fb03729ece98ba816 ]
    
    It will cause null-ptr-deref when using 'res', if platform_get_resource()
    returns NULL, so move using 'res' after devm_ioremap_resource() that
    will check it to avoid null-ptr-deref.
    And use devm_platform_get_and_ioremap_resource() to simplify code.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220425114136.2649310-1-yangyingliang@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d53272d0e756f727f9899c6dd0d4c4bd227cf6a
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Mon Apr 11 15:21:07 2022 +0200

    i2c: mediatek: Optimize master_xfer() and avoid circular locking
    
    [ Upstream commit 8b4fc246c3fffde96835b2f6d5d0e2a56c70d8f9 ]
    
    Especially (but not only) during probe, it may happen that multiple
    devices are communicating via i2c (or multiple i2c busses) and
    sometimes while others are probing asynchronously.
    For example, a Cr50 TPM may be filling entropy (or userspace may be
    reading random data) while the rt5682 (i2c) codec driver reads/sets
    some registers, like while getting/setting a clock's rate, which
    happens both during probe and during system operation.
    
    In this driver, the mtk_i2c_transfer() function (which is the i2c
    .master_xfer() callback) was granularly managing the clocks by
    performing a clk_bulk_prepare_enable() to start them and its inverse.
    This is not only creating possible circular locking dependencies in
    the some cases (like former explanation), but it's also suboptimal,
    as clk_core prepare/unprepare operations are using mutex locking,
    which creates a bit of unwanted overhead (for example, i2c trackpads
    will call master_xfer() every few milliseconds!).
    
    With this commit, we avoid both the circular locking and additional
    overhead by changing how we handle the clocks in this driver:
    - Prepare the clocks during probe (and PM resume)
    - Enable/disable clocks in mtk_i2c_transfer()
    - Unprepare the clocks only for driver removal (and PM suspend)
    
    For the sake of providing a full explanation: during probe, the
    clocks are not only prepared but also enabled, as this is needed
    for some hardware initialization but, after that, we are disabling
    but not unpreparing them, leaving an expected state for the
    aforementioned clock handling strategy.
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Qii Wang <qii.wang@mediatek.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac40847b9711a0c881396240facfb87e8c78b34e
Author: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Date:   Tue Apr 26 20:24:06 2022 +0800

    tracing: Avoid adding tracer option before update_tracer_options
    
    [ Upstream commit ef9188bcc6ca1d8a2ad83e826b548e6820721061 ]
    
    To prepare for support asynchronous tracer_init_tracefs initcall,
    avoid calling create_trace_option_files before __update_tracer_options.
    Otherwise, create_trace_option_files will show warning because
    some tracers in trace_types list are already in tr->topts.
    
    For example, hwlat_tracer call register_tracer in late_initcall,
    and global_trace.dir is already created in tracing_init_dentry,
    hwlat_tracer will be put into tr->topts.
    Then if the __update_tracer_options is executed after hwlat_tracer
    registered, create_trace_option_files find that hwlat_tracer is
    already in tr->topts.
    
    Link: https://lkml.kernel.org/r/20220426122407.17042-2-mark-pk.tsai@mediatek.com
    
    Link: https://lore.kernel.org/lkml/20220322133339.GA32582@xsang-OptiPlex-9020/
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9abf3db8bdb63ab545034148ef2118f4d088ca59
Author: Jun Miao <jun.miao@intel.com>
Date:   Tue Apr 19 09:39:10 2022 +0800

    tracing: Fix sleeping function called from invalid context on RT kernel
    
    [ Upstream commit 12025abdc8539ed9d5014e2d647a3fd1bd3de5cd ]
    
    When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
    cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
    atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
    these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
    be triggered.
    Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
    tp_printk=1" enabled.
    
     BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
     in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
     preempt_count: 2, expected: 0
     RCU nest depth: 0, expected: 0
     Preemption disabled at:
     [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0
     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
     Call Trace:
      <TASK>
      dump_stack_lvl+0x60/0x8c
      dump_stack+0x10/0x12
      __might_resched.cold+0x11d/0x155
      rt_spin_lock+0x40/0x70
      trace_event_buffer_commit+0x2fa/0x4c0
      ? map_vsyscall+0x93/0x93
      trace_event_raw_event_initcall_start+0xbe/0x110
      ? perf_trace_initcall_finish+0x210/0x210
      ? probe_sched_wakeup+0x34/0x40
      ? ttwu_do_wakeup+0xda/0x310
      ? trace_hardirqs_on+0x35/0x170
      ? map_vsyscall+0x93/0x93
      do_one_initcall+0x217/0x3c0
      ? trace_event_raw_event_initcall_level+0x170/0x170
      ? push_cpu_stop+0x400/0x400
      ? cblist_init_generic+0x241/0x290
      kernel_init_freeable+0x1ac/0x347
      ? _raw_spin_unlock_irq+0x65/0x80
      ? rest_init+0xf0/0xf0
      kernel_init+0x1e/0x150
      ret_from_fork+0x22/0x30
      </TASK>
    
    Link: https://lkml.kernel.org/r/20220419013910.894370-1-jun.miao@intel.com
    
    Signed-off-by: Jun Miao <jun.miao@intel.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d0b367a01ce905c8957f6c8d34b8d1b2f8273c9
Author: Jeff Xie <xiehuan09@gmail.com>
Date:   Sun Apr 10 22:50:25 2022 +0800

    tracing: Make tp_printk work on syscall tracepoints
    
    [ Upstream commit cb1c45fb68b8a4285ccf750842b1136f26cfe267 ]
    
    Currently the tp_printk option has no effect on syscall tracepoint.
    When adding the kernel option parameter tp_printk, then:
    
    echo 1 > /sys/kernel/debug/tracing/events/syscalls/enable
    
    When running any application, no trace information is printed on the
    terminal.
    
    Now added printk for syscall tracepoints.
    
    Link: https://lkml.kernel.org/r/20220410145025.681144-1-xiehuan09@gmail.com
    
    Signed-off-by: Jeff Xie <xiehuan09@gmail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a3163a634dce64e1e7774abee27678ccdeba741
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Apr 6 11:30:59 2022 +0900

    bootconfig: Make the bootconfig.o as a normal object file
    
    [ Upstream commit 6014a23638cdee63a71ef13c51d7c563eb5829ee ]
    
    Since the APIs defined in the bootconfig.o are not individually used,
    it is meaningless to build it as library by lib-y. Use obj-y for that.
    
    Link: https://lkml.kernel.org/r/164921225875.1090670.15565363126983098971.stgit@devnote2
    
    Cc: Padmanabha Srinivasaiah <treasure4paddy@gmail.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Sami Tolvanen <samitolvanen@google.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
    Reported-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aae6b4bb63c694bc91714412718f15468407fe51
Author: Gong Yuanjun <ruc_gongyuanjun@163.com>
Date:   Thu Apr 7 12:26:57 2022 +0800

    mips: cpc: Fix refcount leak in mips_cpc_default_phys_base
    
    [ Upstream commit 4107fa700f314592850e2c64608f6ede4c077476 ]
    
    Add the missing of_node_put() to release the refcount incremented
    by of_find_compatible_node().
    
    Signed-off-by: Gong Yuanjun <ruc_gongyuanjun@163.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4457f3ab77c770a831c31880b61b9ec18b53dbf
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Mon Apr 11 15:09:38 2022 -0700

    dmaengine: idxd: set DMA_INTERRUPT cap bit
    
    [ Upstream commit 4e5a4eb20393b851590b4465f1197a8041c2076b ]
    
    Even though idxd driver has always supported interrupt, it never actually
    set the DMA_INTERRUPT cap bit. Rectify this mistake so the interrupt
    capability is advertised.
    
    Reported-by: Ben Walker <benjamin.walker@intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/164971497859.2201379.17925303210723708961.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b66794db231a32205fc3ebb1660eb34e060ebe2
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jun 5 11:51:48 2022 -0700

    bluetooth: don't use bitmaps for random flag accesses
    
    [ Upstream commit e1cff7002b716bd0b5f5f4afd4273c99aa8644be ]
    
    The bluetooth code uses our bitmap infrastructure for the two bits (!)
    of connection setup flags, and in the process causes odd problems when
    it converts between a bitmap and just the regular values of said bits.
    
    It's completely pointless to do things like bitmap_to_arr32() to convert
    a bitmap into a u32.  It shoudln't have been a bitmap in the first
    place.  The reason to use bitmaps is if you have arbitrary number of
    bits you want to manage (not two!), or if you rely on the atomicity
    guarantees of the bitmap setting and clearing.
    
    The code could use an "atomic_t" and use "atomic_or/andnot()" to set and
    clear the bit values, but considering that it then copies the bitmaps
    around with "bitmap_to_arr32()" and friends, there clearly cannot be a
    lot of atomicity requirements.
    
    So just use a regular integer.
    
    In the process, this avoids the warnings about erroneous use of
    bitmap_from_u64() which were triggered on 32-bit architectures when
    conversion from a u64 would access two words (and, surprise, surprise,
    only one word is needed - and indeed overkill - for a 2-bit bitmap).
    
    That was always problematic, but the compiler seems to notice it and
    warn about the invalid pattern only after commit 0a97953fd221 ("lib: add
    bitmap_{from,to}_arr64") changed the exact implementation details of
    'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell.
    
    Fixes: fe92ee6425a2 ("Bluetooth: hci_core: Rework hci_conn_params flags")
    Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/
    Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/
    Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Reviewed-by: Yury Norov <yury.norov@gmail.com>
    Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5bc2bdeed8eb3555f08de2841b4f076f398537b
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu May 12 15:31:34 2022 -0700

    Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan
    
    [ Upstream commit 3b42055388c30f2761a2d9cd9af2c99611dfe457 ]
    
    When suspending the passive scanning _must_ have its filter_policy set
    to 0x01 to use the accept list otherwise _any_ advertise report would
    end up waking up the system.
    
    In order to fix the filter_policy the code now checks for
    hdev->suspended && HCI_CONN_FLAG_REMOTE_WAKEUP
    first, since the MGMT_OP_SET_DEVICE_FLAGS will reject any attempt to
    set HCI_CONN_FLAG_REMOTE_WAKEUP when it cannot be programmed in the
    acceptlist, so it can return success causing the proper filter_policy
    to be used.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215768
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ecdcf25a9b1f41cbd4b1a68d7dd708b279fadc2
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu May 12 15:31:33 2022 -0700

    Bluetooth: MGMT: Add conditions for setting HCI_CONN_FLAG_REMOTE_WAKEUP
    
    [ Upstream commit a9a347655d224fa2841877957b34fc9d491fc2d7 ]
    
    HCI_CONN_FLAG_REMOTE_WAKEUP can only be set if device can be programmed
    in the allowlist which in case of device using RPA requires LL Privacy
    support to be enabled.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215768
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2821a5de2f5b4f40a8dc91c4bdd9cb40f382da89
Author: Leo Yan <leo.yan@linaro.org>
Date:   Mon May 30 16:42:53 2022 +0800

    perf c2c: Fix sorting in percent_rmt_hitm_cmp()
    
    [ Upstream commit b24192a17337abbf3f44aaa75e15df14a2d0016e ]
    
    The function percent_rmt_hitm_cmp() wrongly uses local HITMs for
    sorting remote HITMs.
    
    Since this function is to sort cache lines for remote HITMs, this patch
    changes to use 'rmt_hitm' field for correct sorting.
    
    Fixes: 9cb3500afc0980c5 ("perf c2c report: Add hitm/store percent related sort keys")
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Joe Mario <jmario@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220530084253.750190-1-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac79391aea8ad342125c7d2189ac2fb677413869
Author: Zhengjun Xing <zhengjun.xing@linux.intel.com>
Date:   Thu Jun 2 23:36:03 2022 +0800

    perf record: Support sample-read topdown metric group for hybrid platforms
    
    [ Upstream commit 151e7d75036b4e2ac0f33730bc1a5b3ff424d9a7 ]
    
    With the hardware TopDown metrics feature, the sample-read feature should
    be supported for a TopDown group, e.g., sample a non-topdown event and read
    a Topdown metric group. But the current perf record code errors are out.
    
    For a TopDown metric group,the slots event must be the leader of the group,
    but the leader slots event doesn't support sampling. To support sample-read
    the TopDown metric group, uses the 2nd event of the group as the "leader"
    for the purposes of sampling.
    
    Only the platform with the TopDown metric feature supports sample-read the
    topdown group. In commit acb65150a47c ("perf record: Support sample-read
    topdown metric group"), it adds arch_topdown_sample_read() to indicate
    whether the TopDown group supports sample-read, it should only work on the
    non-hybrid systems, this patch extends the support for hybrid platforms.
    
    Before:
    
      # ./perf record -e "{cpu_core/slots/,cpu_core/cycles/,cpu_core/topdown-retiring/}:S" -a sleep 1
      Error:
      The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_core/topdown-retiring/).
      /bin/dmesg | grep -i perf may provide additional information.
    
    After:
    
      # ./perf record -e "{cpu_core/slots/,cpu_core/cycles/,cpu_core/topdown-retiring/}:S" -a sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.238 MB perf.data (369 samples) ]
    
    Fixes: acb65150a47c2bae ("perf record: Support sample-read topdown metric group")
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Zhengjun Xing <zhengjun.xing@linux.intel.com>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220602153603.1884710-1-zhengjun.xing@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fd154e8e6a414ed6ec04e6c8f3e6442dad4d0d4
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed May 18 07:39:00 2022 -0700

    perf parse-events: Move slots event for the hybrid platform too
    
    [ Upstream commit e0e14cdff31d326f81e0edbd5140f788c870756c ]
    
    The commit 94dbfd6781a0e87b ("perf parse-events: Architecture specific
    leader override") introduced a feature to reorder the slots event to
    fulfill the restriction of the perf metrics topdown group. But the
    feature doesn't work on the hybrid machine.
    
      $ perf stat -e "{cpu_core/instructions/,cpu_core/slots/,cpu_core/topdown-retiring/}" -a sleep 1
    
       Performance counter stats for 'system wide':
    
           <not counted>      cpu_core/instructions/
           <not counted>      cpu_core/slots/
         <not supported>      cpu_core/topdown-retiring/
    
             1.002871801 seconds time elapsed
    
    A hybrid platform has a different PMU name for the core PMUs, while
    current perf hard code the PMU name "cpu".
    
    Introduce a new function to check whether the system supports the perf
    metrics feature. The result is cached for the future usage.
    
    For X86, the core PMU name always has "cpu" prefix.
    
    With the patch:
    
      $ perf stat -e "{cpu_core/instructions/,cpu_core/slots/,cpu_core/topdown-retiring/}" -a sleep 1
    
       Performance counter stats for 'system wide':
    
              76,337,010      cpu_core/slots/
              10,416,809      cpu_core/instructions/
              11,692,372      cpu_core/topdown-retiring/
    
             1.002805453 seconds time elapsed
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com>
    Link: https://lore.kernel.org/r/20220518143900.1493980-5-kan.liang@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74bea199f3319d6fcc5dac556f6184fe274350bd
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed May 18 07:38:57 2022 -0700

    perf evsel: Fixes topdown events in a weak group for the hybrid platform
    
    [ Upstream commit 39d5f412da84784bcc7f39ed49e55376be526fc7 ]
    
    The patch ("perf evlist: Keep topdown counters in weak group") fixes the
    perf metrics topdown event issue when the topdown events are in a weak
    group on a non-hybrid platform. However, it doesn't work for the hybrid
    platform.
    
      $./perf stat -e '{cpu_core/slots/,cpu_core/topdown-bad-spec/,
      cpu_core/topdown-be-bound/,cpu_core/topdown-fe-bound/,
      cpu_core/topdown-retiring/,cpu_core/branch-instructions/,
      cpu_core/branch-misses/,cpu_core/bus-cycles/,cpu_core/cache-misses/,
      cpu_core/cache-references/,cpu_core/cpu-cycles/,cpu_core/instructions/,
      cpu_core/mem-loads/,cpu_core/mem-stores/,cpu_core/ref-cycles/,
      cpu_core/cache-misses/,cpu_core/cache-references/}:W' -a sleep 1
    
      Performance counter stats for 'system wide':
    
           751,765,068      cpu_core/slots/                        (84.07%)
       <not supported>      cpu_core/topdown-bad-spec/
       <not supported>      cpu_core/topdown-be-bound/
       <not supported>      cpu_core/topdown-fe-bound/
       <not supported>      cpu_core/topdown-retiring/
            12,398,197      cpu_core/branch-instructions/          (84.07%)
             1,054,218      cpu_core/branch-misses/                (84.24%)
           539,764,637      cpu_core/bus-cycles/                   (84.64%)
                14,683      cpu_core/cache-misses/                 (84.87%)
             7,277,809      cpu_core/cache-references/             (77.30%)
           222,299,439      cpu_core/cpu-cycles/                   (77.28%)
            63,661,714      cpu_core/instructions/                 (84.85%)
                     0      cpu_core/mem-loads/                    (77.29%)
            12,271,725      cpu_core/mem-stores/                   (77.30%)
           542,241,102      cpu_core/ref-cycles/                   (84.85%)
                 8,854      cpu_core/cache-misses/                 (76.71%)
             7,179,013      cpu_core/cache-references/             (76.31%)
    
             1.003245250 seconds time elapsed
    
    A hybrid platform has a different PMU name for the core PMUs, while
    the current perf hard code the PMU name "cpu".
    
    The evsel->pmu_name can be used to replace the "cpu" to fix the issue.
    For a hybrid platform, the pmu_name must be non-NULL. Because there are
    at least two core PMUs. The PMU has to be specified.
    For a non-hybrid platform, the pmu_name may be NULL. Because there is
    only one core PMU, "cpu". For a NULL pmu_name, we can safely assume that
    it is a "cpu" PMU.
    
    In case other PMUs also define the "slots" event, checking the PMU type
    as well.
    
    With the patch,
    
      $ perf stat -e '{cpu_core/slots/,cpu_core/topdown-bad-spec/,
      cpu_core/topdown-be-bound/,cpu_core/topdown-fe-bound/,
      cpu_core/topdown-retiring/,cpu_core/branch-instructions/,
      cpu_core/branch-misses/,cpu_core/bus-cycles/,cpu_core/cache-misses/,
      cpu_core/cache-references/,cpu_core/cpu-cycles/,cpu_core/instructions/,
      cpu_core/mem-loads/,cpu_core/mem-stores/,cpu_core/ref-cycles/,
      cpu_core/cache-misses/,cpu_core/cache-references/}:W' -a sleep 1
    
      Performance counter stats for 'system wide':
    
         766,620,266   cpu_core/slots/                                        (84.06%)
          73,172,129   cpu_core/topdown-bad-spec/ #    9.5% bad speculation   (84.06%)
         193,443,341   cpu_core/topdown-be-bound/ #    25.0% backend bound    (84.06%)
         403,940,929   cpu_core/topdown-fe-bound/ #    52.3% frontend bound   (84.06%)
         102,070,237   cpu_core/topdown-retiring/ #    13.2% retiring         (84.06%)
          12,364,429   cpu_core/branch-instructions/                          (84.03%)
           1,080,124   cpu_core/branch-misses/                                (84.24%)
         564,120,383   cpu_core/bus-cycles/                                   (84.65%)
              36,979   cpu_core/cache-misses/                                 (84.86%)
           7,298,094   cpu_core/cache-references/                             (77.30%)
         227,174,372   cpu_core/cpu-cycles/                                   (77.31%)
          63,886,523   cpu_core/instructions/                                 (84.87%)
                   0   cpu_core/mem-loads/                                    (77.31%)
          12,208,782   cpu_core/mem-stores/                                   (77.31%)
         566,409,738   cpu_core/ref-cycles/                                   (84.87%)
              23,118   cpu_core/cache-misses/                                 (76.71%)
           7,212,602   cpu_core/cache-references/                             (76.29%)
    
           1.003228667 seconds time elapsed
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com>
    Link: https://lore.kernel.org/r/20220518143900.1493980-2-kan.liang@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ad6af07efcca85369c21e4897b3020cff2c170b
Author: Saravana Kannan <saravanak@google.com>
Date:   Fri Jun 3 13:31:37 2022 +0200

    driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction
    
    [ Upstream commit 5ee76c256e928455212ab759c51d198fedbe7523 ]
    
    Mounting NFS rootfs was timing out when deferred_probe_timeout was
    non-zero [1].  This was because ip_auto_config() initcall times out
    waiting for the network interfaces to show up when
    deferred_probe_timeout was non-zero. While ip_auto_config() calls
    wait_for_device_probe() to make sure any currently running deferred
    probe work or asynchronous probe finishes, that wasn't sufficient to
    account for devices being deferred until deferred_probe_timeout.
    
    Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits
    until the deferred_probe_timeout fires") tried to fix that by making
    sure wait_for_device_probe() waits for deferred_probe_timeout to expire
    before returning.
    
    However, if wait_for_device_probe() is called from the kernel_init()
    context:
    
    - Before deferred_probe_initcall() [2], it causes the boot process to
      hang due to a deadlock.
    
    - After deferred_probe_initcall() [3], it blocks kernel_init() from
      continuing till deferred_probe_timeout expires and beats the point of
      deferred_probe_timeout that's trying to wait for userspace to load
      modules.
    
    Neither of this is good. So revert the changes to
    wait_for_device_probe().
    
    [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
    [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
    [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
    
    Fixes: 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires")
    Cc: John Stultz <jstultz@google.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Sudeep Holla <sudeep.holla@arm.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    Cc: Basil Eljuse <Basil.Eljuse@arm.com>
    Cc: Ferry Toth <fntoth@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Anders Roxell <anders.roxell@linaro.org>
    Cc: linux-pm@vger.kernel.org
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: John Stultz <jstultz@google.com>
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Link: https://lore.kernel.org/r/20220526034609.480766-2-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3af15272cde28fe5c8489174b8624e232c1775ec
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Thu Jun 2 13:30:53 2022 +0700

    tipc: check attribute length for bearer name
    
    [ Upstream commit 7f36f798f89bf32c0164049cb0e3fd1af613d0bb ]
    
    syzbot reported uninit-value:
    =====================================================
    BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]
    BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725
     string_nocheck lib/vsprintf.c:644 [inline]
     string+0x4f9/0x6f0 lib/vsprintf.c:725
     vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
     vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
     vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
     vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283
     vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50
     _printk+0x18d/0x1cf kernel/printk/printk.c:2293
     tipc_enable_bearer net/tipc/bearer.c:371 [inline]
     __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033
     tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042
     genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
    
    - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.
    - Do not use 'illegal name' in printing message.
    
    Reported-by: syzbot+e820fdc8ce362f2dea51@syzkaller.appspotmail.com
    Fixes: cb30a63384bc ("tipc: refactor function tipc_enable_bearer()")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Link: https://lore.kernel.org/r/20220602063053.5892-1-hoang.h.le@dektech.com.au
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3390d02d819af83b0524473950e7627284ffa940
Author: Fei Qin <fei.qin@corigine.com>
Date:   Wed Jun 1 10:34:49 2022 +0200

    nfp: remove padding in nfp_nfdk_tx_desc
    
    [ Upstream commit c6fbbf1eae8f35e10966826960e154c9596c86dc ]
    
    NFDK firmware supports 48-bit dma addressing and
    parses 16 high bits of dma addresses.
    
    In nfp_nfdk_tx_desc, dma related structure and tso
    related structure are union. When "mss" be filled
    with nonzero value due to enable tso, the memory used
    by "padding" may be also filled. Then, firmware may
    parse wrong dma addresses which causes TX watchdog
    timeout problem.
    
    This patch removes padding and unifies the dma_addr_hi
    bits with the one in firmware. nfp_nfdk_tx_desc_set_dma_addr
    is also added to match this change.
    
    Fixes: c10d12e3dce8 ("nfp: add support for NFDK data path")
    Signed-off-by: Fei Qin <fei.qin@corigine.com>
    Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20220601083449.50556-1-simon.horman@corigine.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae054931a87ec79ebcf32b78c96e6b4550dab95c
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Mon May 30 23:21:58 2022 +0800

    ax25: Fix ax25 session cleanup problems
    
    [ Upstream commit 7d8a3a477b3e25ada8dc71d22048c2ea417209a0 ]
    
    There are session cleanup problems in ax25_release() and
    ax25_disconnect(). If we setup a session and then disconnect,
    the disconnected session is still in "LISTENING" state that
    is shown below.
    
    Active AX.25 sockets
    Dest       Source     Device  State        Vr/Vs    Send-Q  Recv-Q
    DL9SAU-4   DL9SAU-3   ???     LISTENING    000/000  0       0
    DL9SAU-3   DL9SAU-4   ???     LISTENING    000/000  0       0
    
    The first reason is caused by del_timer_sync() in ax25_release().
    The timers of ax25 are used for correct session cleanup. If we use
    ax25_release() to close ax25 sessions and ax25_dev is not null,
    the del_timer_sync() functions in ax25_release() will execute.
    As a result, the sessions could not be cleaned up correctly,
    because the timers have stopped.
    
    In order to solve this problem, this patch adds a device_up flag
    in ax25_dev in order to judge whether the device is up. If there
    are sessions to be cleaned up, the del_timer_sync() in
    ax25_release() will not execute. What's more, we add ax25_cb_del()
    in ax25_kill_by_device(), because the timers have been stopped
    and there are no functions that could delete ax25_cb if we do not
    call ax25_release(). Finally, we reorder the position of
    ax25_list_lock in ax25_cb_del() in order to synchronize among
    different functions that call ax25_cb_del().
    
    The second reason is caused by improper check in ax25_disconnect().
    The incoming ax25 sessions which ax25->sk is null will close
    heartbeat timer, because the check "if(!ax25->sk || ..)" is
    satisfied. As a result, the session could not be cleaned up properly.
    
    In order to solve this problem, this patch changes the improper
    check to "if(ax25->sk && ..)" in ax25_disconnect().
    
    What`s more, the ax25_disconnect() may be called twice, which is
    not necessary. For example, ax25_kill_by_device() calls
    ax25_disconnect() and sets ax25->state to AX25_STATE_0, but
    ax25_release() calls ax25_disconnect() again.
    
    In order to solve this problem, this patch add a check in
    ax25_release(). If the flag of ax25->sk equals to SOCK_DEAD,
    the ax25_disconnect() in ax25_release() should not be executed.
    
    Fixes: 82e31755e55f ("ax25: Fix UAF bugs in ax25 timers")
    Fixes: 8a367e74c012 ("ax25: Fix segfault after sock connection timeout")
    Reported-and-tested-by: Thomas Osterried <thomas@osterried.de>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220530152158.108619-1-duoming@zju.edu.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3733439593ad12f7b54ae35c273ea6f15d692de3
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Wed Jun 1 15:25:43 2022 +0900

    scsi: sd: Fix potential NULL pointer dereference
    
    [ Upstream commit 05fbde3a77a4f1d62e4c4428f384288c1f1a0be5 ]
    
    If sd_probe() sees an early error before sdkp->device is initialized,
    sd_zbc_release_disk() is called. This causes a NULL pointer dereference
    when sd_is_zoned() is called inside that function. Avoid this by removing
    the call to sd_zbc_release_disk() in sd_probe() error path.
    
    This change is safe and does not result in zone information memory leakage
    because the zone information for a zoned disk is allocated only when
    sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set,
    resulting in sd_disk_release() being called when needed to cleanup a disk
    zone information using sd_zbc_release_disk().
    
    Link: https://lore.kernel.org/r/20220601062544.905141-2-damien.lemoal@opensource.wdc.com
    Fixes: 89d947561077 ("sd: Implement support for ZBC devices")
    Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 593c854fc0fa73d092b8b99a9d785d86e47383c6
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Tue May 17 09:21:34 2022 -0700

    drm/msm/dp: Always clear mask bits to disable interrupts at dp_ctrl_reset_irq_ctrl()
    
    [ Upstream commit 993a2adc6e2e94a0a7b5bfc054eda90ac95f62c3 ]
    
    dp_catalog_ctrl_reset() will software reset DP controller. But it will
    not reset programmable registers to default value. DP driver still have
    to clear mask bits to interrupt status registers to disable interrupts
    after software reset of controller.
    
    At current implementation, dp_ctrl_reset_irq_ctrl() will software reset dp
    controller but did not call dp_catalog_ctrl_enable_irq(false) to clear hpd
    related interrupt mask bits to disable hpd related interrupts due to it
    mistakenly think hpd related interrupt mask bits will be cleared by software
    reset of dp controller automatically. This mistake may cause system to crash
    during suspending procedure due to unexpected irq fired and trigger event
    thread to access dp controller registers with controller clocks are disabled.
    
    This patch fixes system crash during suspending problem by removing "enable"
    flag condition checking at dp_ctrl_reset_irq_ctrl() so that hpd related
    interrupt mask bits are cleared to prevent unexpected from happening.
    
    Changes in v2:
    -- add more details commit text
    
    Changes in v3:
    -- add synchrons_irq()
    -- add atomic_t suspended
    
    Changes in v4:
    -- correct Fixes's commit ID
    -- remove synchrons_irq()
    
    Changes in v5:
    -- revise commit text
    
    Changes in v6:
    -- add event_lock to protect "suspended"
    
    Changes in v7:
    -- delete "suspended" flag
    
    Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt received")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/486591/
    Link: https://lore.kernel.org/r/1652804494-19650-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 432b38ccc05d12a92f9d0ba003320c5e95645c75
Author: David Howells <dhowells@redhat.com>
Date:   Tue May 31 09:30:40 2022 +0100

    afs: Fix infinite loop found by xfstest generic/676
    
    [ Upstream commit 17eabd42560f4636648ad65ba5b20228071e2363 ]
    
    In AFS, a directory is handled as a file that the client downloads and
    parses locally for the purposes of performing lookup and getdents
    operations.  The in-kernel afs filesystem has a number of functions that
    do this.
    
    A directory file is arranged as a series of 2K blocks divided into
    32-byte slots, where a directory entry occupies one or more slots, plus
    each block starts with one or more metadata blocks.
    
    When parsing a block, if the last slots are occupied by a dirent that
    occupies more than a single slot and the file position points at a slot
    that's not the initial one, the logic in afs_dir_iterate_block() that
    skips over it won't advance the file pointer to the end of it.  This
    will cause an infinite loop in getdents() as it will keep retrying that
    block and failing to advance beyond the final entry.
    
    Fix this by advancing the file pointer if the next entry will be beyond
    it when we skip a block.
    
    This was found by the generic/676 xfstest but can also be triggered with
    something like:
    
            ~/xfstests-dev/src/t_readdir_3 /xfstest.test/z 4000 1
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Tested-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: http://lore.kernel.org/r/165391973497.110268.2939296942213894166.stgit@warthog.procyon.org.uk/
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef717ee7a38d2fdfeb2e25789b515730703f7eb8
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Mon May 30 18:48:48 2022 +0800

    gpio: pca953x: use the correct register address to do regcache sync
    
    [ Upstream commit 43624eda86c98b0de726d0b6f2516ccc3ef7313f ]
    
    For regcache_sync_region, need to use pca953x_recalc_addr() to get
    the real register address.
    
    Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 781599730b1bf4f98cf12aabd5eccbf766c6ae07
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 31 15:10:05 2022 +0300

    net/sched: act_api: fix error code in tcf_ct_flow_table_fill_tuple_ipv6()
    
    [ Upstream commit 86360030cc5117596626bef1d937277cd2bebe05 ]
    
    The tcf_ct_flow_table_fill_tuple_ipv6() function is supposed to return
    false on failure.  It should not return negatives because that means
    succes/true.
    
    Fixes: fcb6aa86532c ("act_ct: Support GRE offload")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Toshiaki Makita <toshiaki.makita1@gmail.com>
    Link: https://lore.kernel.org/r/YpYFnbDxFl6tQ3Bn@kili
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 704e3036643c95bb83f4917ef545743255f6a469
Author: Aya Levin <ayal@nvidia.com>
Date:   Tue May 31 11:45:44 2022 +0300

    net: ping6: Fix ping -6 with interface name
    
    [ Upstream commit e6652a8ef3e64d953168a95878fe29b934ad78ac ]
    
    When passing interface parameter to ping -6:
    $ ping -6 ::11:141:84:9 -I eth2
    Results in:
    PING ::11:141:84:10(::11:141:84:10) from ::11:141:84:9 eth2: 56 data bytes
    ping: sendmsg: Invalid argument
    ping: sendmsg: Invalid argument
    
    Initialize the fl6's outgoing interface (OIF) before triggering
    ip6_datagram_send_ctl. Don't wipe fl6 after ip6_datagram_send_ctl() as
    changes in fl6 that may happen in the function are overwritten explicitly.
    Update comment accordingly.
    
    Fixes: 13651224c00b ("net: ping6: support setting basic SOL_IPV6 options via cmsg")
    Signed-off-by: Aya Levin <ayal@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20220531084544.15126-1-tariqt@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94d4c04f0c6422d6cdc5e67b8fc780f475f9686f
Author: Fabien Parent <fparent@baylibre.com>
Date:   Sun May 29 17:46:13 2022 +0200

    regulator: mt6315-regulator: fix invalid allowed mode
    
    [ Upstream commit 28cbc2d4c54c09a427b18a1604740efb6b2cc2d6 ]
    
    In the binding example, the regulator mode 4 is shown as a valid mode,
    but the driver actually only support mode 0 to 2:
    
    This generates an error in dmesg when copy/pasting the binding example:
    [    0.306080] vbuck1: invalid regulator-allowed-modes element 4
    [    0.307290] vbuck2: invalid regulator-allowed-modes element 4
    
    This commit fixes this error by removing the invalid mode from the
    examples.
    
    Fixes: 977fb5b58469 ("regulator: document binding for MT6315 regulator")
    Signed-off-by: Fabien Parent <fparent@baylibre.com>
    Link: https://lore.kernel.org/r/20220529154613.337559-1-fparent@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 399ac91401003256b0edf17a39066292386ef291
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Mon May 23 12:38:14 2022 +0200

    s390/mcck: isolate SIE instruction when setting CIF_MCCK_GUEST flag
    
    [ Upstream commit 29ccaa4b35ea874ddd50518e5c2c746b9238a792 ]
    
    Commit d768bd892fc8 ("s390: add options to change branch prediction
    behaviour for the kernel") introduced .Lsie_exit label - supposedly
    to fence off SIE instruction. However, the corresponding address
    range length .Lsie_crit_mcck_length was not updated, which led to
    BPON code potentionally marked with CIF_MCCK_GUEST flag.
    
    Both .Lsie_exit and .Lsie_crit_mcck_length were removed with commit
    0b0ed657fe00 ("s390: remove critical section cleanup from entry.S"),
    but the issue persisted - currently BPOFF and BPENTER macros might
    get wrongly considered by the machine check handler as a guest.
    
    Fixes: d768bd892fc8 ("s390: add options to change branch prediction behaviour for the kernel")
    Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f8a1b516768e3f7018b6127a21cc9f7df6bcd5c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 31 10:28:45 2022 +0300

    octeontx2-af: fix error code in is_valid_offset()
    
    [ Upstream commit f3d671c711097a133bc36bd2bde52f1fcca783a6 ]
    
    The is_valid_offset() function returns success/true if the call to
    validate_and_get_cpt_blkaddr() fails.
    
    Fixes: ecad2ce8c48f ("octeontx2-af: cn10k: Add mailbox to configure reassembly timeout")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YpXDrTPb8qV01JSP@kili
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ec85a264914bb33abe34f62b920a11889ba4fdc
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Tue May 31 14:37:27 2022 +0800

    bonding: guard ns_targets by CONFIG_IPV6
    
    [ Upstream commit c4caa500ffebf64795d1c0f6f9d6f179b502c6b7 ]
    
    Guard ns_targets in struct bond_params by CONFIG_IPV6, which could save
    256 bytes if IPv6 not configed. Also add this protection for function
    bond_is_ip6_target_ok() and bond_get_targets_ip6().
    
    Remove the IS_ENABLED() check for bond_opts[] as this will make
    BOND_OPT_NS_TARGETS uninitialized if CONFIG_IPV6 not enabled. Add
    a dummy bond_option_ns_ip6_targets_set() for this situation.
    
    Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Jonathan Toppins <jtoppins@redhat.com>
    Link: https://lore.kernel.org/r/20220531063727.224043-1-liuhangbin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a246644e81cc039540a2fa7675027c6d59d13da
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue May 24 13:55:57 2022 +0800

    vdpa: ifcvf: set pci driver data in probe
    
    [ Upstream commit bd8bb9aed56b1814784a975e2dfea12a9adcee92 ]
    
    We should set the pci driver data in probe instead of the vdpa device
    adding callback. Otherwise if no vDPA device is created we will lose
    the pointer to the management device.
    
    Fixes: 6b5df347c6482 ("vDPA/ifcvf: implement management netlink framework for ifcvf")
    Tested-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20220524055557.1938-1-jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8e1bc6029acac796293310aacef7b7336f35b6a
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 30 14:37:13 2022 -0700

    tcp: tcp_rtx_synack() can be called from process context
    
    [ Upstream commit 0a375c822497ed6ad6b5da0792a12a6f1af10c0b ]
    
    Laurent reported the enclosed report [1]
    
    This bug triggers with following coditions:
    
    0) Kernel built with CONFIG_DEBUG_PREEMPT=y
    
    1) A new passive FastOpen TCP socket is created.
       This FO socket waits for an ACK coming from client to be a complete
       ESTABLISHED one.
    2) A socket operation on this socket goes through lock_sock()
       release_sock() dance.
    3) While the socket is owned by the user in step 2),
       a retransmit of the SYN is received and stored in socket backlog.
    4) At release_sock() time, the socket backlog is processed while
       in process context.
    5) A SYNACK packet is cooked in response of the SYN retransmit.
    6) -> tcp_rtx_synack() is called in process context.
    
    Before blamed commit, tcp_rtx_synack() was always called from BH handler,
    from a timer handler.
    
    Fix this by using TCP_INC_STATS() & NET_INC_STATS()
    which do not assume caller is in non preemptible context.
    
    [1]
    BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
    caller is tcp_rtx_synack.part.0+0x36/0xc0
    CPU: 10 PID: 2180 Comm: epollpep Tainted: G           OE     5.16.0-0.bpo.4-amd64 #1  Debian 5.16.12-1~bpo11+1
    Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
    Call Trace:
     <TASK>
     dump_stack_lvl+0x48/0x5e
     check_preemption_disabled+0xde/0xe0
     tcp_rtx_synack.part.0+0x36/0xc0
     tcp_rtx_synack+0x8d/0xa0
     ? kmem_cache_alloc+0x2e0/0x3e0
     ? apparmor_file_alloc_security+0x3b/0x1f0
     inet_rtx_syn_ack+0x16/0x30
     tcp_check_req+0x367/0x610
     tcp_rcv_state_process+0x91/0xf60
     ? get_nohz_timer_target+0x18/0x1a0
     ? lock_timer_base+0x61/0x80
     ? preempt_count_add+0x68/0xa0
     tcp_v4_do_rcv+0xbd/0x270
     __release_sock+0x6d/0xb0
     release_sock+0x2b/0x90
     sock_setsockopt+0x138/0x1140
     ? __sys_getsockname+0x7e/0xc0
     ? aa_sk_perm+0x3e/0x1a0
     __sys_setsockopt+0x198/0x1e0
     __x64_sys_setsockopt+0x21/0x30
     do_syscall_64+0x38/0xc0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Laurent Fasnacht <laurent.fasnacht@proton.ch>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Link: https://lore.kernel.org/r/20220530213713.601888-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e659b396823de142624e0e172079e1dcc185454
Author: Guoju Fang <gjfang@linux.alibaba.com>
Date:   Sat May 28 18:16:28 2022 +0800

    net: sched: add barrier to fix packet stuck problem for lockless qdisc
    
    [ Upstream commit 2e8728c955ce0624b958eee6e030a37aca3a5d86 ]
    
    In qdisc_run_end(), the spin_unlock() only has store-release semantic,
    which guarantees all earlier memory access are visible before it. But
    the subsequent test_bit() has no barrier semantics so may be reordered
    ahead of the spin_unlock(). The store-load reordering may cause a packet
    stuck problem.
    
    The concurrent operations can be described as below,
             CPU 0                      |          CPU 1
       qdisc_run_end()                  |     qdisc_run_begin()
              .                         |           .
     ----> /* may be reorderd here */   |           .
    |         .                         |           .
    |     spin_unlock()                 |         set_bit()
    |         .                         |         smp_mb__after_atomic()
     ---- test_bit()                    |         spin_trylock()
              .                         |          .
    
    Consider the following sequence of events:
        CPU 0 reorder test_bit() ahead and see MISSED = 0
        CPU 1 calls set_bit()
        CPU 1 calls spin_trylock() and return fail
        CPU 0 executes spin_unlock()
    
    At the end of the sequence, CPU 0 calls spin_unlock() and does nothing
    because it see MISSED = 0. The skb on CPU 1 has beed enqueued but no one
    take it, until the next cpu pushing to the qdisc (if ever ...) will
    notice and dequeue it.
    
    This patch fix this by adding one explicit barrier. As spin_unlock() and
    test_bit() ordering is a store-load ordering, a full memory barrier
    smp_mb() is needed here.
    
    Fixes: a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc")
    Signed-off-by: Guoju Fang <gjfang@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220528101628.120193-1-gjfang@linux.alibaba.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3e82d328f3d41145cead1514b3b3b8d3d806cf3
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Mon May 23 15:39:13 2022 +0300

    net/mlx5e: Update netdev features after changing XDP state
    
    [ Upstream commit f6279f113ad593971999c877eb69dc3d36a75894 ]
    
    Some features (LRO, HW GRO) conflict with XDP. If there is an attempt to
    enable such features while XDP is active, they will be set to `off
    [requested on]`. In order to activate these features after XDP is turned
    off, the driver needs to call netdev_update_features(). This commit adds
    this missing call after XDP state changes.
    
    Fixes: cf6e34c8c22f ("net/mlx5e: Properly block LRO when XDP is enabled")
    Fixes: b0617e7b3500 ("net/mlx5e: Properly block HW GRO when XDP is enabled")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fef1600d7a9f1aa9a042ad275da8356e3a694ca
Author: Changcheng Liu <jerrliu@nvidia.com>
Date:   Tue Apr 26 21:28:14 2022 +0800

    net/mlx5: correct ECE offset in query qp output
    
    [ Upstream commit 3fc2a9e89b3508a5cc0c324f26d7b4740ba8c456 ]
    
    ECE field should be after opt_param_mask in query qp output.
    
    Fixes: 6b646a7e4af6 ("net/mlx5: Add ability to read and write ECE options")
    Signed-off-by: Changcheng Liu <jerrliu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 449357caff4f4d4b536615670ce9849d1ca9df91
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Fri Apr 15 16:19:15 2022 +0300

    net/mlx5e: Disable softirq in mlx5e_activate_rq to avoid race condition
    
    [ Upstream commit 2e642afb61b24401a7ec819d27ddcd69c7c29784 ]
    
    When the driver activates the channels, it assumes NAPI isn't running
    yet. mlx5e_activate_rq posts a NOP WQE to ICOSQ to trigger a hardware
    interrupt and start NAPI, which will run mlx5e_alloc_rx_mpwqe and post
    UMR WQEs to ICOSQ to be able to receive packets with striding RQ.
    
    Unfortunately, a race condition is possible if NAPI is triggered by
    something else (for example, TX) at a bad timing, before
    mlx5e_activate_rq finishes. In this case, mlx5e_alloc_rx_mpwqe may post
    UMR WQEs to ICOSQ, and with the bad timing, the wqe_info of the first
    UMR may be overwritten by the wqe_info of the NOP posted by
    mlx5e_activate_rq.
    
    The consequence is that icosq->db.wqe_info[0].num_wqebbs will be changed
    from MLX5E_UMR_WQEBBS to 1, disrupting the integrity of the array-based
    linked list in wqe_info[]. mlx5e_poll_ico_cq will hang in an infinite
    loop after processing wqe_info[0], because after the corruption, the
    next item to be processed will be wqe_info[1], which is filled with
    zeros, and `sqcc += wi->num_wqebbs` will never move further.
    
    This commit fixes this race condition by using async_icosq to post the
    NOP and trigger the interrupt. async_icosq is always protected with a
    spinlock, eliminating the race condition.
    
    Fixes: bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reported-by: Karsten Nielsen <karsten@foo-bar.dk>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27d58bf44de9fe48914fe131f5a26142aed8f48e
Author: Paul Blakey <paulb@nvidia.com>
Date:   Mon May 23 19:12:21 2022 +0300

    net/mlx5: CT: Fix header-rewrite re-use for tupels
    
    [ Upstream commit 1f2856cde64baa78475e6d3c601fb7b7f693a161 ]
    
    Tuple entries that don't have nat configured for them
    which are added to the ct nat table will always create
    a new modify header, as we don't check for possible
    re-use on them. The same for tuples that have nat configured
    for them but are added to ct table.
    
    Fix the above by only avoiding wasteful re-use lookup
    for actually natted entries in ct nat table.
    
    Fixes: 7fac5c2eced3 ("net/mlx5: CT: Avoid reusing modify header context for natted entries")
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Ariel Levkovich <lariel@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2adaac7ba5b28d2abd1a938dd8de429189a3d462
Author: Maor Dickman <maord@nvidia.com>
Date:   Mon May 2 10:51:30 2022 +0300

    net/mlx5e: TC NIC mode, fix tc chains miss table
    
    [ Upstream commit 66cb64e292d21588bdb831f08a7ec0ff04d6380d ]
    
    The cited commit changed promisc table to be created on demand with the
    highest priority in the NIC table replacing the vlan table, this caused
    tc NIC tables miss flow to skip the prmoisc table because it use vlan
    table as miss table.
    
    OVS offload in NIC mode use promisc by default so any unicast packet
    which will be handled by tc NIC tables miss flow will skip the promisc
    rule and will be dropped.
    
    Fix this by adding new empty table in new tc level with low priority and
    point the nic tc chain miss to it, the new table is managed so it will
    point to vlan table if promisc is disabled and to promisc table if enabled.
    
    Fixes: 1c46d7409f30 ("net/mlx5e: Optimize promiscuous mode")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Ariel Levkovich <lariel@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79caa98f736f17a2a957b3ae1a75265a916a37c5
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue May 24 15:59:27 2022 +0300

    net/mlx5: Don't use already freed action pointer
    
    [ Upstream commit 80b2bd737d0e833e6a2b77e482e5a714a79c86a4 ]
    
    The call to mlx5dr_action_destroy() releases "action" memory. That
    pointer is set to miss_action later and generates the following smatch
    error:
    
     drivers/net/ethernet/mellanox/mlx5/core/steering/fs_dr.c:53 set_miss_action()
     warn: 'action' was already freed.
    
    Make sure that the pointer is always valid by setting NULL after destroy.
    
    Fixes: 6a48faeeca10 ("net/mlx5: Add direct rule fs_cmd implementation")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7680f2b502466900e33bc010144af98ed465d38
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Apr 3 11:11:14 2022 +0200

    virtio: pci: Fix an error handling path in vp_modern_probe()
    
    [ Upstream commit 7a836a2aba09479c8e71fa43249eecc4af945f61 ]
    
    If an error occurs after a successful pci_request_selected_regions() call,
    it should be undone by a corresponding pci_release_selected_regions() call,
    as already done in vp_modern_remove().
    
    Fixes: fd502729fbbf ("virtio-pci: introduce modern device module")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Message-Id: <237109725aad2c3c03d14549f777b1927c84b045.1648977064.git.christophe.jaillet@wanadoo.fr>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1714361c2d6e063fb4dd68be14363455ddee226a
Author: Eli Cohen <elic@nvidia.com>
Date:   Wed May 18 16:37:59 2022 +0300

    vdpa: Fix error logic in vdpa_nl_cmd_dev_get_doit
    
    [ Upstream commit 7a6691f1f89784f775fa0c54be57533445726068 ]
    
    In vdpa_nl_cmd_dev_get_doit(), if the call to genlmsg_reply() fails we
    must not call nlmsg_free() since this is done inside genlmsg_reply().
    
    Fix it.
    
    Fixes: bc0d90ee021f ("vdpa: Enable user to query vdpa device info")
    Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Message-Id: <20220518133804.1075129-2-elic@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b2df9a86864680299e2b463dc737560ef69331d
Author: Weizhao Ouyang <o451686892@gmail.com>
Date:   Mon May 30 15:51:14 2022 +0800

    erofs: fix 'backmost' member of z_erofs_decompress_frontend
    
    [ Upstream commit 4398d3c31b582db0d640b23434bf344a6c8df57c ]
    
    Initialize 'backmost' to true in DECOMPRESS_FRONTEND_INIT.
    
    Fixes: 5c6dcc57e2e5 ("erofs: get rid of `struct z_erofs_collector'")
    Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Yue Hu <huyue2@coolpad.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20220530075114.918874-1-o451686892@gmail.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86ee0a5910afe88c0ed9de0e9390114d84f86bef
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Mon May 30 14:26:39 2022 +0800

    bonding: show NS IPv6 targets in proc master info
    
    [ Upstream commit 4a1f14df55d1e9ecdfa797a87a80131207cbd66f ]
    
    When adding bond new parameter ns_targets. I forgot to print this
    in bond master proc info. After updating, the bond master info will look
    like:
    
    ARP IP target/s (n.n.n.n form): 192.168.1.254
    NS IPv6 target/s (XX::XX form): 2022::1, 2022::2
    
    Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
    Reported-by: Li Liang <liali@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://lore.kernel.org/r/20220530062639.37179-1-liuhangbin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08a4fc1350fb62ca34805be06b84fae336dbacf6
Author: Viorel Suman <viorel.suman@nxp.com>
Date:   Fri May 27 11:49:34 2022 +0300

    net: phy: at803x: disable WOL at probe
    
    [ Upstream commit d7cd5e06c9dd70a82f1461c7b5f676bc03f5cd61 ]
    
    Before 7beecaf7d507b ("net: phy: at803x: improve the WOL feature") patch
    "at803x_get_wol" implementation used AT803X_INTR_ENABLE_WOL value to set
    WAKE_MAGIC flag, and now AT803X_WOL_EN value is used for the same purpose.
    The problem here is that the values of these two bits are different after
    hardware reset: AT803X_INTR_ENABLE_WOL=0 after hardware reset, but
    AT803X_WOL_EN=1. So now, if called right after boot, "at803x_get_wol" will
    set WAKE_MAGIC flag, even if WOL function is not enabled by calling
    "at803x_set_wol" function. The patch disables WOL function on probe thus
    the behavior is consistent.
    
    Fixes: 7beecaf7d507b ("net: phy: at803x: improve the WOL feature")
    Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
    Link: https://lore.kernel.org/r/20220527084935.235274-1-viorel.suman@oss.nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33271e8cbea09413abb212f4d26566db6039f565
Author: Haisu Wang <haisuwang@tencent.com>
Date:   Mon May 30 14:40:59 2022 +0800

    blk-mq: do not update io_ticks with passthrough requests
    
    [ Upstream commit b81c14ca14b631aa1abae32fb5ae75b5e9251012 ]
    
    Flush or passthrough requests are not accounted as normal IO in completion.
    To reflect iostat for slow IO, io_ticks is updated when stat show called
    based on inflight numbers.
    It may cause inconsistent io_ticks calculation result.
    
    So do not account non-passthrough request when check inflight.
    
    Fixes: 86d7331299fd ("block: update io_ticks when io hang")
    Signed-off-by: Haisu Wang <haisuwang@tencent.com>
    Reviewed-by: samuelliao <samuelliao@tencent.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220530064059.1120058-1-haisuwang@tencent.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1c4f31df197cc4fda6a992967d943954cf23d1b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon May 30 09:45:38 2022 +0200

    sched/autogroup: Fix sysctl move
    
    [ Upstream commit 82f586f923e3ac6062bc7867717a7f8afc09e0ff ]
    
    Ivan reported /proc/sys/kernel/sched_autogroup_enabled went walk-about
    and using the noautogroup command line parameter would result in a
    boot error message.
    
    Turns out the sysctl move placed the init function wrong.
    
    Fixes: c8eaf6ac76f4 ("sched: move autogroup sysctls into its own file")
    Reported-by: Ivan Kozik <ivan@ludios.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Ivan Kozik <ivan@ludios.org>
    Link: https://lkml.kernel.org/r/YpR2IqndgsyMzN00@worktop.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b79f0b14a54d86fcb1b8e0127fd15d28f048374a
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun May 29 07:13:09 2022 -0600

    block: make bioset_exit() fully resilient against being called twice
    
    [ Upstream commit 605f7415ecfb426610195dd6c7577b30592b3369 ]
    
    Most of bioset_exit() is fine being called twice, as it clears the
    various allocations etc when they are freed. The exception is
    bio_alloc_cache_destroy(), which does not clear ->cache when it has
    freed it.
    
    This isn't necessarily a bug, but can be if buggy users does call the
    exit path more then once, or with just a memset() bioset which has
    never been initialized. dm appears to be one such user.
    
    Fixes: be4d234d7aeb ("bio: add allocation cache abstraction")
    Link: https://lore.kernel.org/linux-block/YpK7m+14A+pZKs5k@casper.infradead.org/
    Reported-by: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2d60329a0b88c4e35017436ee29c43be59d46a5
Author: Íñigo Huguet <ihuguet@redhat.com>
Date:   Fri May 27 10:05:29 2022 +0200

    sfc: fix wrong tx channel offset with efx_separate_tx_channels
    
    [ Upstream commit c308dfd1b43ef0d4c3e57b741bb3462eb7a7f4a2 ]
    
    tx_channel_offset is calculated in efx_allocate_msix_channels, but it is
    also calculated again in efx_set_channels because it was originally done
    there, and when efx_allocate_msix_channels was introduced it was
    forgotten to be removed from efx_set_channels.
    
    Moreover, the old calculation is wrong when using
    efx_separate_tx_channels because now we can have XDP channels after the
    TX channels, so n_channels - n_tx_channels doesn't point to the first TX
    channel.
    
    Remove the old calculation from efx_set_channels, and add the
    initialization of this variable if MSI or legacy interrupts are used,
    next to the initialization of the rest of the related variables, where
    it was missing.
    
    Fixes: 3990a8fffbda ("sfc: allocate channels for XDP tx queues")
    Reported-by: Tianhao Zhao <tizhao@redhat.com>
    Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 913d45f02d346ce41c4aad057eaf53a8ed449dc3
Author: Martin Habets <habetsm.xilinx@gmail.com>
Date:   Fri May 27 10:05:28 2022 +0200

    sfc: fix considering that all channels have TX queues
    
    [ Upstream commit 2e102b53f8a778f872dc137f4c7ac548705817aa ]
    
    Normally, all channels have RX and TX queues, but this is not true if
    modparam efx_separate_tx_channels=1 is used. In that cases, some
    channels only have RX queues and others only TX queues (or more
    preciselly, they have them allocated, but not initialized).
    
    Fix efx_channel_has_tx_queues to return the correct value for this case
    too.
    
    Messages shown at probe time before the fix:
     sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0
     ------------[ cut here ]------------
     netdevice: ens6f0np0: failed to initialise TXQ -1
     WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]
     [...] stripped
     RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]
     [...] stripped
     Call Trace:
      efx_init_tx_queue+0xaa/0xf0 [sfc]
      efx_start_channels+0x49/0x120 [sfc]
      efx_start_all+0x1f8/0x430 [sfc]
      efx_net_open+0x5a/0xe0 [sfc]
      __dev_open+0xd0/0x190
      __dev_change_flags+0x1b3/0x220
      dev_change_flags+0x21/0x60
     [...] stripped
    
    Messages shown at remove time before the fix:
     sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues
     sfc 0000:03:00.0 ens6f0np0: failed to flush queues
    
    Fixes: 8700aff08984 ("sfc: fix channel allocation with brute force")
    Reported-by: Tianhao Zhao <tizhao@redhat.com>
    Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com>
    Tested-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdff9f7c55975652d0d57f383a955082bdcff63d
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Fri May 27 14:44:39 2022 +0800

    bonding: NS target should accept link local address
    
    [ Upstream commit 5e1eeef69c0fef6249b794bda5d68f95a65d062f ]
    
    When setting bond NS target, we use bond_is_ip6_target_ok() to check
    if the address valid. The link local address was wrongly rejected in
    bond_changelink(), as most time the user just set the ARP/NS target to
    gateway, while the IPv6 gateway is always a link local address when user
    set up interface via SLAAC.
    
    So remove the link local addr check when setting bond NS target.
    
    Fixes: 129e3c1bab24 ("bonding: add new option ns_ip6_target")
    Reported-by: Li Liang <liali@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Jonathan Toppins <jtoppins@redhat.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c90322fc9badf8facf70d4256f254f8e5e6b87bf
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon May 23 14:43:02 2022 +0200

    block: use bio_queue_enter instead of blk_queue_enter in bio_poll
    
    [ Upstream commit ebd076bf7d5deef488ec7ebc3fdbf781eafae269 ]
    
    We want to have a valid live gendisk to call ->poll and not just a
    request_queue, so call the right helper.
    
    Fixes: 3e08773c3841 ("block: switch polling to be bio based")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220523124302.526186-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebbd33392d28444fdf26e6dedb9f027786ca9115
Author: Yu Xiao <yu.xiao@corigine.com>
Date:   Fri May 27 20:24:24 2022 +0200

    nfp: only report pause frame configuration for physical device
    
    [ Upstream commit 0649e4d63420ebc8cbebef3e9d39e12ffc5eb9fa ]
    
    Only report pause frame configuration for physical device. Logical
    port of both PCI PF and PCI VF do not support it.
    
    Fixes: 9fdc5d85a8fe ("nfp: update ethtool reporting of pauseframe control")
    Signed-off-by: Yu Xiao <yu.xiao@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41e191fe72282e193a7744e2fc1786b23156c9e4
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 5 16:35:38 2022 -0700

    tcp: add accessors to read/set tp->snd_cwnd
    
    [ Upstream commit 40570375356c874b1578e05c1dcc3ff7c1322dbe ]
    
    We had various bugs over the years with code
    breaking the assumption that tp->snd_cwnd is greater
    than zero.
    
    Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) added
    in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")
    can trigger, and without a repro we would have to spend
    considerable time finding the bug.
    
    Instead of complaining too late, we want to catch where
    and when tp->snd_cwnd is set to an illegal value.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Suggested-by: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Link: https://lore.kernel.org/r/20220405233538.947344-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5831e434e8f1532a3e9d1a35c4fe6c320b33a8b9
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Date:   Sat May 28 14:54:57 2022 +0800

    net/smc: fixes for converting from "struct smc_cdc_tx_pend **" to "struct smc_wr_tx_pend_priv *"
    
    [ Upstream commit e225c9a5a74b12e9ef8516f30a3db2c7eb866ee1 ]
    
    "struct smc_cdc_tx_pend **" can not directly convert
    to "struct smc_wr_tx_pend_priv *".
    
    Fixes: 2bced6aefa3d ("net/smc: put slot when connection is killed")
    Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d610e2c4ffc1de63c3b14d021d2710ada2784a7a
Author: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Date:   Sat May 28 03:41:32 2022 +0200

    riscv: read-only pages should not be writable
    
    [ Upstream commit 630f972d76d6460235e84e1aa034ee06f9c8c3a9 ]
    
    If EFI pages are marked as read-only,
    we should remove the _PAGE_WRITE flag.
    
    The current code overwrites an unused value.
    
    Fixes: b91540d52a08b ("RISC-V: Add EFI runtime services")
    Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
    Link: https://lore.kernel.org/r/20220528014132.91052-1-heinrich.schuchardt@canonical.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f128a4ad1dc9d67219c0ea75ff99acba1f6552a3
Author: Zhang Wensheng <zhangwensheng5@huawei.com>
Date:   Sat May 21 15:37:48 2022 +0800

    nbd: fix possible overflow on 'first_minor' in nbd_dev_add()
    
    [ Upstream commit 858f1bf65d3d9c00b5e2d8ca87dc79ed88267c98 ]
    
    When 'index' is a big numbers, it may become negative which forced
    to 'int'. then 'index << part_shift' might overflow to a positive
    value that is not greater than '0xfffff', then sysfs might complains
    about duplicate creation. Because of this, move the 'index' judgment
    to the front will fix it and be better.
    
    Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices")
    Fixes: 940c264984fd ("nbd: fix possible overflow for 'first_minor' in nbd_dev_add()")
    Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-6-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5171ef20bae852ff38f4cfdb368bcdcc744776d0
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:46 2022 +0800

    nbd: don't clear 'NBD_CMD_INFLIGHT' flag if request is not completed
    
    [ Upstream commit 2895f1831e911ca87d4efdf43e35eb72a0c7e66e ]
    
    Otherwise io will hung because request will only be completed if the
    cmd has the flag 'NBD_CMD_INFLIGHT'.
    
    Fixes: 07175cb1baf4 ("nbd: make sure request completion won't concurrent")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-4-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be7c76c47fc5fff767f1e027b3d8d54f9d5f7b4f
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue May 24 16:39:19 2022 +0200

    block: take destination bvec offsets into account in bio_copy_data_iter
    
    [ Upstream commit 403d50341cce6b5481a92eb481e6df60b1f49b55 ]
    
    Appartly bcache can copy into bios that do not just contain fresh
    pages but can have offsets into the bio_vecs.  Restore support for tht
    in bio_copy_data_iter.
    
    Fixes: f8b679a070c5 ("block: rewrite bio_copy_data_iter to use bvec_kmap_local and memcpy_to_bvec")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220524143919.1155501-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 819d7d136b373b4686a82510b9550ebd79dc5cbb
Author: Menglong Dong <imagedong@tencent.com>
Date:   Tue May 24 10:12:27 2022 +0800

    bpf: Fix probe read error in ___bpf_prog_run()
    
    [ Upstream commit caff1fa4118cec4dfd4336521ebd22a6408a1e3e ]
    
    I think there is something wrong with BPF_PROBE_MEM in ___bpf_prog_run()
    in big-endian machine. Let's make a test and see what will happen if we
    want to load a 'u16' with BPF_PROBE_MEM.
    
    Let's make the src value '0x0001', the value of dest register will become
    0x0001000000000000, as the value will be loaded to the first 2 byte of
    DST with following code:
    
      bpf_probe_read_kernel(&DST, SIZE, (const void *)(long) (SRC + insn->off));
    
    Obviously, the value in DST is not correct. In fact, we can compare
    BPF_PROBE_MEM with LDX_MEM_H:
    
      DST = *(SIZE *)(unsigned long) (SRC + insn->off);
    
    If the memory load is done by LDX_MEM_H, the value in DST will be 0x1 now.
    
    And I think this error results in the test case 'test_bpf_sk_storage_map'
    failing:
    
      test_bpf_sk_storage_map:PASS:bpf_iter_bpf_sk_storage_map__open_and_load 0 nsec
      test_bpf_sk_storage_map:PASS:socket 0 nsec
      test_bpf_sk_storage_map:PASS:map_update 0 nsec
      test_bpf_sk_storage_map:PASS:socket 0 nsec
      test_bpf_sk_storage_map:PASS:map_update 0 nsec
      test_bpf_sk_storage_map:PASS:socket 0 nsec
      test_bpf_sk_storage_map:PASS:map_update 0 nsec
      test_bpf_sk_storage_map:PASS:attach_iter 0 nsec
      test_bpf_sk_storage_map:PASS:create_iter 0 nsec
      test_bpf_sk_storage_map:PASS:read 0 nsec
      test_bpf_sk_storage_map:FAIL:ipv6_sk_count got 0 expected 3
      $10/26 bpf_iter/bpf_sk_storage_map:FAIL
    
    The code of the test case is simply, it will load sk->sk_family to the
    register with BPF_PROBE_MEM and check if it is AF_INET6. With this patch,
    now the test case 'bpf_iter' can pass:
    
      $10  bpf_iter:OK
    
    Fixes: 2a02759ef5f8 ("bpf: Add support for BTF pointers to interpreter")
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Jiang Biao <benbjiang@tencent.com>
    Reviewed-by: Hao Peng <flyingpeng@tencent.com>
    Cc: Ilya Leoshkevich <iii@linux.ibm.com>
    Link: https://lore.kernel.org/bpf/20220524021228.533216-1-imagedong@tencent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8ad3a0007f26d28bf015c3ba5e3bd814b301eea
Author: Song Liu <song@kernel.org>
Date:   Thu May 26 12:16:08 2022 -0700

    selftests/bpf: fix stacktrace_build_id with missing kprobe/urandom_read
    
    [ Upstream commit 59ed76fe2f981bccde37bdddb465f260a96a2404 ]
    
    Kernel function urandom_read is replaced with urandom_read_iter.
    Therefore, kprobe on urandom_read is not working any more:
    
    [root@eth50-1 bpf]# ./test_progs -n 161
    test_stacktrace_build_id:PASS:skel_open_and_load 0 nsec
    libbpf: kprobe perf_event_open() failed: No such file or directory
    libbpf: prog 'oncpu': failed to create kprobe 'urandom_read+0x0' \
            perf event: No such file or directory
    libbpf: prog 'oncpu': failed to auto-attach: -2
    test_stacktrace_build_id:FAIL:attach_tp err -2
    161     stacktrace_build_id:FAIL
    
    Fix this by replacing urandom_read with urandom_read_iter in the test.
    
    Fixes: 1b388e7765f2 ("random: convert to using fops->read_iter()")
    Reported-by: Mykola Lysenko <mykolal@fb.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Acked-by: David Vernet <void@manifault.com>
    Link: https://lore.kernel.org/r/20220526191608.2364049-1-song@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1174ab8ba36a48025b68b5ff1085000b1e510217
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue May 10 20:31:26 2022 +0800

    ubi: ubi_create_volume: Fix use-after-free when volume creation failed
    
    [ Upstream commit 8c03a1c21d72210f81cb369cc528e3fde4b45411 ]
    
    There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s
    error handling path:
    
      ubi_eba_replace_table(vol, eba_tbl)
        vol->eba_tbl = tbl
    out_mapping:
      ubi_eba_destroy_table(eba_tbl)   // Free 'eba_tbl'
    out_unlock:
      put_device(&vol->dev)
        vol_release
          kfree(tbl->entries)         // UAF
    
    Fix it by removing redundant 'eba_tbl' releasing.
    Fetch a reproducer in [Link].
    
    Fixes: 493cfaeaa0c9b ("mtd: utilize new cdev_device_add helper function")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215965
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edb8693702ed4ace20ab6506b2e8c7660542629f
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue May 10 20:31:24 2022 +0800

    ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty
    
    [ Upstream commit d09e9a2bddba6c48e0fddb16c4383172ac593251 ]
    
    There at least 6 PEBs reserved on UBI device:
    1. EBA_RESERVED_PEBS[1]
    2. WL_RESERVED_PEBS[1]
    3. UBI_LAYOUT_VOLUME_EBS[2]
    4. MIN_FASTMAP_RESERVED_PEBS[2]
    
    When all ubi volumes take all their PEBs, there are 3 (EBA_RESERVED_PEBS +
    WL_RESERVED_PEBS + MIN_FASTMAP_RESERVED_PEBS - MIN_FASTMAP_TAKEN_PEBS[1])
    free PEBs. Since commit f9c34bb529975fe ("ubi: Fix producing anchor PEBs")
    and commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering
    wear level rules") applied, there is only 1 (3 - FASTMAP_ANCHOR_PEBS[1] -
    FASTMAP_NEXT_ANCHOR_PEBS[1]) free PEB to fill pool and wl_pool, after
    filling pool, wl_pool is always empty. So, UBI could be stuck in an
    infinite loop:
    
            ubi_thread         system_wq
    wear_leveling_worker <--------------------------------------------------
      get_peb_for_wl                                                        |
        // fm_wl_pool, used = size = 0                                      |
        schedule_work(&ubi->fm_work)                                        |
                                                                            |
                        update_fastmap_work_fn                              |
                          ubi_update_fastmap                                |
                            ubi_refill_pools                                |
                            // ubi->free_count - ubi->beb_rsvd_pebs < 5     |
                            // wl_pool is not filled with any PEBs          |
                            schedule_erase(old_fm_anchor)                   |
                            ubi_ensure_anchor_pebs                          |
                              __schedule_ubi_work(wear_leveling_worker)     |
                                                                            |
    __erase_worker                                                          |
      ensure_wear_leveling                                                  |
        __schedule_ubi_work(wear_leveling_worker) --------------------------
    
    , which cause high cpu usage of ubi_bgt:
    top - 12:10:42 up 5 min,  2 users,  load average: 1.76, 0.68, 0.27
    Tasks: 123 total,   3 running,  54 sleeping,   0 stopped,   0 zombie
    
      PID USER PR   NI VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
     1589 root 20   0   0      0      0 R  45.0  0.0   0:38.86 ubi_bgt0d
      319 root 20   0   0      0      0 I  15.2  0.0   0:15.29 kworker/0:3-eve
      371 root 20   0   0      0      0 I  14.9  0.0   0:12.85 kworker/3:3-eve
       20 root 20   0   0      0      0 I  11.3  0.0   0:05.33 kworker/1:0-eve
      202 root 20   0   0      0      0 I  11.3  0.0   0:04.93 kworker/2:3-eve
    
    In commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering
    wear level rules"), there are three key changes:
      1) Choose the fastmap anchor when the most free PEBs are available.
      2) Enable anchor move within the anchor area again as it is useful
         for distributing wear.
      3) Import a candidate fm anchor and check this PEB's erase count during
         wear leveling. If the wear leveling limit is exceeded, use the used
         anchor area PEB with the lowest erase count to replace it.
    
    The anchor candidate can be removed, we can check fm_anchor PEB's erase
    count during wear leveling. Fix it by:
      1) Removing 'fm_next_anchor' and check 'fm_anchor' during wear leveling.
      2) Preferentially filling one free peb into fm_wl_pool in condition of
         ubi->free_count > ubi->beb_rsvd_pebs, then try to reserve enough
         free count for fastmap non anchor pebs after the above prerequisites
         are met.
    Then, there are at least 1 PEB in pool and 1 PEB in wl_pool after calling
    ubi_refill_pools() with all erase works done.
    
    Fetch a reproducer in [Link].
    
    Fixes: 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs ... rules")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215407
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69295267c481545f636b69ff341b8db75aa136b9
Author: Baokun Li <libaokun1@huawei.com>
Date:   Tue Apr 12 17:38:16 2022 +0800

    jffs2: fix memory leak in jffs2_do_fill_super
    
    [ Upstream commit c14adb1cf70a984ed081c67e9d27bc3caad9537c ]
    
    If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
    an error, we can observe the following kmemleak report:
    
    --------------------------------------------
    unreferenced object 0xffff888105a65340 (size 64):
      comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0
        [<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0
        [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
        [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
        [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
        [...]
    unreferenced object 0xffff8881bd7f0000 (size 65536):
      comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
      hex dump (first 32 bytes):
        bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
        bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
      backtrace:
        [<ffffffff858579ba>] kmalloc_order+0xda/0x110
        [<ffffffff85857a11>] kmalloc_order_trace+0x21/0x130
        [<ffffffff859c2ed1>] __kmalloc+0x711/0x8a0
        [<ffffffff86160189>] jffs2_sum_init+0xd9/0x1a0
        [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
        [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
        [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
        [...]
    --------------------------------------------
    
    This is because the resources allocated in jffs2_sum_init() are not
    released. Call jffs2_sum_exit() to release these resources to solve
    the problem.
    
    Fixes: e631ddba5887 ("[JFFS2] Add erase block summary support (mount time improvement)")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69a3378524497dfae0626810c6039130cf72ef4e
Author: Genjian Zhang <zhanggenjian123@gmail.com>
Date:   Tue May 17 15:39:46 2022 +0800

    ep93xx: clock: Do not return the address of the freed memory
    
    [ Upstream commit 8a7322a3a05f75e8a4902bdf8129aecd37d54fe9 ]
    
    Avoid return freed memory addresses,Modified to the actual error
    return value of clk_register().
    
    Fixes: 9645ccc7bd7a ("ep93xx: clock: convert in-place to COMMON_CLK")
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c10e26c35634bf9e9b625e4dd48d21d26c7ed1d
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri May 27 07:58:06 2022 +0200

    block, loop: support partitions without scanning
    
    [ Upstream commit b9684a71fca793213378dd410cd11675d973eaa1 ]
    
    Historically we did distinguish between a flag that surpressed partition
    scanning, and a combinations of the minors variable and another flag if
    any partitions were supported.  This was generally confusing and doesn't
    make much sense, but some corner case uses of the loop driver actually
    do want to support manually added partitions on a device that does not
    actively scan for partitions.  To make things worsee the loop driver
    also wants to dynamically toggle the scanning for partitions on a live
    gendisk, which makes the disk->flags updates non-atomic.
    
    Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
    just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
    in the loop driver.
    
    Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
    Reported-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9707b276487492d9e1481b9288511e8922990868
Author: Alexander Lobakin <alexandr.lobakin@intel.com>
Date:   Tue May 24 17:27:18 2022 +0200

    modpost: fix removing numeric suffixes
    
    [ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ]
    
    With the `-z unique-symbol` linker flag or any similar mechanism,
    it is possible to trigger the following:
    
    ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL
    
    The reason is that for now the condition from remove_dot():
    
    if (m && (s[n + m] == '.' || s[n + m] == 0))
    
    which was designed to test if it's a dot or a '\0' after the suffix
    is never satisfied.
    This is due to that `s[n + m]` always points to the last digit of a
    numeric suffix, not on the symbol next to it (from a custom debug
    print added to modpost):
    
    param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0'
    
    So it's off-by-one and was like that since 2014.
    
    Fix this for the sake of any potential upcoming features, but don't
    bother stable-backporting, as it's well hidden -- apart from that
    LD flag, it can be triggered only with GCC LTO which never landed
    upstream.
    
    Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning")
    Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a1a1255152da4fb934290e7ababc66f24985520
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 18:52:08 2022 +0400

    net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register
    
    [ Upstream commit 02ded5a173619b11728b8bf75a3fd995a2c1ff28 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    
    mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().
    We don't need the device node after it.
    
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e44f21c384503562713b7d3b673c40bed20af3d
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 12:52:08 2022 +0400

    net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks
    
    [ Upstream commit 5dd89d2fc438457811cbbec07999ce0d80051ff5 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release
    the refcount in error case.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: b1f66a5bee07 ("net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support")
    Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 26 11:02:42 2022 +0300

    net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()
    
    [ Upstream commit e7e7104e2d5ddf3806a28695670f21bef471f1e1 ]
    
    The "fsp->location" variable comes from user via ethtool_get_rxnfc().
    Check that it is valid to prevent an out of bounds read.
    
    Fixes: 7aab747e5563 ("net: ethernet: mediatek: add ethtool functions to configure RX flows of HW LRO")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ce6a502eb967b9ca532a8b1d0f1db2fcef55c2c
Author: Vincent Ray <vray@kalrayinc.com>
Date:   Wed May 25 17:17:46 2022 -0700

    net: sched: fixed barrier to prevent skbuff sticking in qdisc backlog
    
    [ Upstream commit a54ce3703613e41fe1d98060b62ec09a3984dc28 ]
    
    In qdisc_run_begin(), smp_mb__before_atomic() used before test_bit()
    does not provide any ordering guarantee as test_bit() is not an atomic
    operation. This, added to the fact that the spin_trylock() call at
    the beginning of qdisc_run_begin() does not guarantee acquire
    semantics if it does not grab the lock, makes it possible for the
    following statement :
    
    if (test_bit(__QDISC_STATE_MISSED, &qdisc->state))
    
    to be executed before an enqueue operation called before
    qdisc_run_begin().
    
    As a result the following race can happen :
    
               CPU 1                             CPU 2
    
          qdisc_run_begin()               qdisc_run_begin() /* true */
            set(MISSED)                            .
          /* returns false */                      .
              .                            /* sees MISSED = 1 */
              .                            /* so qdisc not empty */
              .                            __qdisc_run()
              .                                    .
              .                              pfifo_fast_dequeue()
     ----> /* may be done here */                  .
    |         .                                clear(MISSED)
    |         .                                    .
    |         .                                smp_mb __after_atomic();
    |         .                                    .
    |         .                                /* recheck the queue */
    |         .                                /* nothing => exit   */
    |   enqueue(skb1)
    |         .
    |   qdisc_run_begin()
    |         .
    |     spin_trylock() /* fail */
    |         .
    |     smp_mb__before_atomic() /* not enough */
    |         .
     ---- if (test_bit(MISSED))
            return false;   /* exit */
    
    In the above scenario, CPU 1 and CPU 2 both try to grab the
    qdisc->seqlock at the same time. Only CPU 2 succeeds and enters the
    bypass code path, where it emits its skb then calls __qdisc_run().
    
    CPU1 fails, sets MISSED and goes down the traditionnal enqueue() +
    dequeue() code path. But when executing qdisc_run_begin() for the
    second time, after enqueuing its skbuff, it sees the MISSED bit still
    set (by itself) and consequently chooses to exit early without setting
    it again nor trying to grab the spinlock again.
    
    Meanwhile CPU2 has seen MISSED = 1, cleared it, checked the queue
    and found it empty, so it returned.
    
    At the end of the sequence, we end up with skb1 enqueued in the
    backlog, both CPUs out of __dev_xmit_skb(), the MISSED bit not set,
    and no __netif_schedule() called made. skb1 will now linger in the
    qdisc until somebody later performs a full __qdisc_run(). Associated
    to the bypass capacity of the qdisc, and the ability of the TCP layer
    to avoid resending packets which it knows are still in the qdisc, this
    can lead to serious traffic "holes" in a TCP connection.
    
    We fix this by replacing the smp_mb__before_atomic() / test_bit() /
    set_bit() / smp_mb__after_atomic() sequence inside qdisc_run_begin()
    by a single test_and_set_bit() call, which is more concise and
    enforces the needed memory barriers.
    
    Fixes: 89837eb4b246 ("net: sched: add barrier to ensure correct ordering for lockless qdisc")
    Signed-off-by: Vincent Ray <vray@kalrayinc.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20220526001746.2437669-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00c041773a33d72e4f875c764c1691aead53cff5
Author: Michael Walle <michael@walle.cc>
Date:   Thu May 26 01:12:39 2022 +0200

    net: lan966x: check devm_of_phy_get() for -EDEFER_PROBE
    
    [ Upstream commit b58cdd4388b1d8f5bee9f5a3897a7e780d1eaa48 ]
    
    At the moment, if devm_of_phy_get() returns an error the serdes
    simply isn't set. While it is bad to ignore an error in general, there
    is a particular bug that network isn't working if the serdes driver is
    compiled as a module. In that case, devm_of_phy_get() returns
    -EDEFER_PROBE and the error is silently ignored.
    
    The serdes is optional, it is not there if the port is using RGMII, in
    which case devm_of_phy_get() returns -ENODEV. Rearrange the error
    handling so that -ENODEV will be handled but other error codes will
    abort the probing.
    
    Fixes: d28d6d2e37d1 ("net: lan966x: add port module support")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Link: https://lore.kernel.org/r/20220525231239.1307298-1-michael@walle.cc
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 607c5cd1a08e196d9f2bd3b25a8083ed27ad7ceb
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 16 10:05:48 2022 +0300

    drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()
    
    [ Upstream commit a35faec3db0e13aac8ea720bc1a3503081dd5a3d ]
    
    The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
    access.
    
    Fixes: e27c41d5b068 ("drm/amd/display: Support for DMUB HPD interrupt handling")
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    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 119b7d548029ed3a6369fd08303413ab7f1e2c63
Author: Eddie James <eajames@linux.ibm.com>
Date:   Wed May 25 11:58:51 2022 -0500

    spi: fsi: Fix spurious timeout
    
    [ Upstream commit 61bf40ef51aa73f6216b33563271b6acf7ea8d70 ]
    
    The driver may return a timeout error even if the status register
    indicates that the transfer may proceed. Fix this by restructuring
    the polling loop.
    
    Fixes: 89b35e3f2851 ("spi: fsi: Implement a timeout for polling status")
    Signed-off-by: Eddie James <eajames@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220525165852.33167-2-eajames@linux.ibm.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 776fcaf8601d283a867d664e68bbd53ff40e332f
Author: liuyacan <liuyacan@corp.netease.com>
Date:   Wed May 25 16:54:08 2022 +0800

    net/smc: set ini->smcrv2.ib_dev_v2 to NULL if SMC-Rv2 is unavailable
    
    [ Upstream commit b3b1a17538d3ef6a9667b2271216fd16d7678ab5 ]
    
    In the process of checking whether RDMAv2 is available, the current
    implementation first sets ini->smcrv2.ib_dev_v2, and then allocates
    smc buf desc and register rmb, but the latter may fail. In this case,
    the pointer should be reset.
    
    Fixes: e49300a6bf62 ("net/smc: add listen processing for SMC-Rv2")
    Signed-off-by: liuyacan <liuyacan@corp.netease.com>
    Reviewed-by: Karsten Graul <kgraul@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220525085408.812273-1-liuyacan@corp.netease.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1808f7c9f2c60cbc28d362360faf5e87e3766e0d
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Tue May 24 11:55:58 2022 +0530

    net: ethernet: ti: am65-cpsw: Fix fwnode passed to phylink_create()
    
    [ Upstream commit 0b7180072a9df5e18af5b58410fec38230848a8d ]
    
    am65-cpsw-nuss driver incorrectly uses fwnode member of common
    ethernet device's "struct device_node" instead of using fwnode
    member of the port's "struct device_node" in phylink_create().
    This results in all ports having the same phy data when there
    are multiple ports with their phy properties populated in their
    respective nodes rather than the common ethernet device node.
    
    Fix it here by using fwnode member of the port's node.
    
    Fixes: e8609e69470f ("net: ethernet: ti: am65-cpsw: Convert to PHYLINK")
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Link: https://lore.kernel.org/r/20220524062558.19296-1-s-vadapalli@ti.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b8032d39b276c52db57ff834c300405b9da2691
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon May 23 16:17:08 2022 +0000

    amt: fix possible memory leak in amt_rcv()
    
    [ Upstream commit 1a1a0e80e005cbdc2c250fc858e1d8570f4e4acb ]
    
    If an amt receives packets and it finds socket.
    If it can't find a socket, it should free a received skb.
    But it doesn't.
    So, a memory leak would possibly occur.
    
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5559f47604c69623fae85db994492b65a0ce9bcf
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon May 23 16:17:07 2022 +0000

    amt: fix return value of amt_update_handler()
    
    [ Upstream commit ac1dbf55981b88d64312858ea06e3e63001f085d ]
    
    If a relay receives an update message, it lookup a tunnel.
    and if there is no tunnel for that message, it should be treated
    as an error, not a success.
    But amt_update_handler() returns false, which means success.
    
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c15d5277f0a7b84f0ca4ab53b103608db3456ee6
Author: Jann Horn <jannh@google.com>
Date:   Tue May 17 16:30:47 2022 +0200

    s390/crypto: fix scatterwalk_unmap() callers in AES-GCM
    
    [ Upstream commit bd52cd5e23f134019b23f0c389db0f9a436e4576 ]
    
    The argument of scatterwalk_unmap() is supposed to be the void* that was
    returned by the previous scatterwalk_map() call.
    The s390 AES-GCM implementation was instead passing the pointer to the
    struct scatter_walk.
    
    This doesn't actually break anything because scatterwalk_unmap() only uses
    its argument under CONFIG_HIGHMEM and ARCH_HAS_FLUSH_ON_KUNMAP.
    
    Fixes: bf7fa038707c ("s390/crypto: add s390 platform specific aes gcm support.")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Harald Freudenberger <freude@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220517143047.3054498-1-jannh@google.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6033ae24430c55290049db0532005d2f58f0e5d7
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Apr 22 12:41:01 2022 +0200

    clocksource/drivers/oxnas-rps: Fix irq_of_parse_and_map() return value
    
    [ Upstream commit 9c04a8ff03def4df3f81219ffbe1ec9b44ff5348 ]
    
    The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO.
    
    Fixes: 89355274e1f7 ("clocksource/drivers/oxnas-rps: Add Oxford Semiconductor RPS Dual Timer")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20220422104101.55754-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a9cd23d2993ac107940ecde63694dcf9f19dc7f
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon May 23 10:38:13 2022 +0200

    scsi: sd: Don't call blk_cleanup_disk() in sd_probe()
    
    [ Upstream commit 7274ce0558adb4b9b1f5c5b613fb4fe331c18911 ]
    
    In SCSI the midlayer has ownership of the request_queue, so on probe
    failure we must only put the gendisk, but leave the request_queue alone.
    
    Link: https://lore.kernel.org/r/20220523083813.227935-1-hch@lst.de
    Fixes: 03252259e18e ("scsi: sd: Clean up gendisk if device_add_disk() failed")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27efaafff23c7280cb3a96df7098f98864813d32
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Mon May 23 13:44:21 2022 +0800

    ASoC: fsl_sai: Fix FSL_SAI_xDR/xFR definition
    
    [ Upstream commit e4dd748dc87cf431af7b3954963be0d9f6150217 ]
    
    There are multiple xDR and xFR registers, the index is
    from 0 to 7. FSL_SAI_xDR and FSL_SAI_xFR is abandoned,
    replace them with FSL_SAI_xDR0 and FSL_SAI_xFR0.
    
    Fixes: 4f7a0728b530 ("ASoC: fsl_sai: Add support for SAI new version")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1653284661-18964-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70fdd922c7bf8949f8df109cf2635dff64c90392
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sun May 22 20:23:50 2022 +0800

    blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
    
    [ Upstream commit 5d05426e2d5fd7df8afc866b78c36b37b00188b7 ]
    
    blk_mq_run_hw_queues() could be run when there isn't queued request and
    after queue is cleaned up, at that time tagset is freed, because tagset
    lifetime is covered by driver, and often freed after blk_cleanup_queue()
    returns.
    
    So don't touch ->tagset for figuring out current default hctx by the mapping
    built in request queue, so use-after-free on tagset can be avoided. Meantime
    this way should be fast than retrieving mapping from tagset.
    
    Cc: "yukuai (C)" <yukuai3@huawei.com>
    Cc: Jan Kara <jack@suse.cz>
    Fixes: b6e68ee82585 ("blk-mq: Improve performance of non-mq IO schedulers with multiple HW queues")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220522122350.743103-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f067b5286edfd83d2d3903e8578b561599d62539
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 11 15:42:03 2022 +0400

    watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe
    
    [ Upstream commit 5d24df3d690809952528e7a19a43d84bc5b99d44 ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    Add  missing of_node_put() in some error paths.
    
    Fixes: bf9006399939 ("watchdog: ts4800: add driver for TS-4800 watchdog")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220511114203.47420-1-linmq006@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 952e309f377a3db83f0150fee761d87776be8957
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Apr 12 07:08:23 2022 +0000

    watchdog: rti-wdt: Fix pm_runtime_get_sync() error checking
    
    [ Upstream commit b3ac0c58fa8934926360268f3d89ec7680644d7b ]
    
    If the device is already in a runtime PM enabled state
    pm_runtime_get_sync() will return 1, so a test for negative
    value should be used to check for errors.
    
    Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220412070824.23708-1-linmq006@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e
Author: Zhang Wensheng <zhangwensheng5@huawei.com>
Date:   Wed May 18 15:45:16 2022 +0800

    driver core: fix deadlock in __device_attach
    
    [ Upstream commit b232b02bf3c205b13a26dcec08e53baddd8e59ed ]
    
    In __device_attach function, The lock holding logic is as follows:
    ...
    __device_attach
    device_lock(dev)      // get lock dev
      async_schedule_dev(__device_attach_async_helper, dev); // func
        async_schedule_node
          async_schedule_node_domain(func)
            entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
            /* when fail or work limit, sync to execute func, but
               __device_attach_async_helper will get lock dev as
               well, which will lead to A-A deadlock.  */
            if (!entry || atomic_read(&entry_count) > MAX_WORK) {
              func;
            else
              queue_work_node(node, system_unbound_wq, &entry->work)
      device_unlock(dev)
    
    As shown above, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __device_attach_async_helper getting lock dev.
    
    To fix the deadlock, move the async_schedule_dev outside device_lock,
    as we can see, in async_schedule_node_domain, the parameter of
    queue_work_node is system_unbound_wq, so it can accept concurrent
    operations. which will also not change the code logic, and will
    not lead to deadlock.
    
    Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
    Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
    Link: https://lore.kernel.org/r/20220518074516.1225580-1-zhangwensheng5@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c059665c84feab46b7173d3a1bf36c2fb7f9df86
Author: Schspa Shi <schspa@gmail.com>
Date:   Fri May 13 19:24:44 2022 +0800

    driver: base: fix UAF when driver_attach failed
    
    [ Upstream commit 310862e574001a97ad02272bac0fd13f75f42a27 ]
    
    When driver_attach(drv); failed, the driver_private will be freed.
    But it has been added to the bus, which caused a UAF.
    
    To fix it, we need to delete it from the bus when failed.
    
    Fixes: 190888ac01d0 ("driver core: fix possible missing of device probe")
    Signed-off-by: Schspa Shi <schspa@gmail.com>
    Link: https://lore.kernel.org/r/20220513112444.45112-1-schspa@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4b068b4bfad7561d96277463bb1396ec7e5cfbe
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu May 12 08:30:21 2022 +0300

    bus: ti-sysc: Fix warnings for unbind for serial
    
    [ Upstream commit c337125b8834f9719dfda0e40b25eaa266f1b8cf ]
    
    We can get "failed to disable" clock_unprepare warnings on unbind at least
    for the serial console device if the unbind is done before the device has
    been idled.
    
    As some devices are using deferred idle, we must check the status for
    pending idle work to idle the device.
    
    Fixes: 76f0f772e469 ("bus: ti-sysc: Improve handling for no-reset-on-init and no-idle-on-init")
    Cc: Romain Naour <romain.naour@smile.fr>
    Reviewed-by: Romain Naour <romain.naour@smile.fr>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220512053021.61650-1-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec752973aa721ee281d5441e497364637c626c7b
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 11 11:14:19 2022 +0400

    firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle
    
    [ Upstream commit 660ba678f9998aca6db74f2dd912fa5124f0fa31 ]
    
    kobject_init_and_add() takes reference even when it fails.
    According to the doc of kobject_init_and_add()
    
       If this function returns an error, kobject_put() must be called to
       properly clean up the memory associated with the object.
    
    Fix this issue by calling kobject_put().
    
    Fixes: 948af1f0bbc8 ("firmware: Basic dmi-sysfs support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220511071421.9769-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b35b9942205177f9ad15cccccfb746530f53100
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:07 2022 +0300

    serial: stm32-usart: Correct CSIZE, bits, and parity
    
    [ Upstream commit 1deeda8d2877c18bc2b9eeee10dd6d2628852848 ]
    
    Add CSIZE sanitization for unsupported CSIZE configurations. In
    addition, if parity is asked for but CSx was unsupported, the sensible
    result is CS8+parity which requires setting USART_CR1_M0 like with 9
    bits.
    
    Incorrect CSIZE results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: c8a9d043947b (serial: stm32: fix word length configuration)
    Cc: Erwan Le Ray <erwan.leray@st.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-9-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 749b163a21e96562808e53ea465e60aa47ddeccc
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:06 2022 +0300

    serial: st-asc: Sanitize CSIZE and correct PARENB for CS7
    
    [ Upstream commit 52bb1cb7118564166b04d52387bd8403632f5190 ]
    
    Only CS7 and CS8 seem supported but CSIZE is not sanitized from CS5 or
    CS6 to CS8. In addition, ASC_CTL_MODE_7BIT_PAR suggests that CS7 has
    to have parity, thus add PARENB.
    
    Incorrect CSIZE results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: c4b058560762 (serial:st-asc: Add ST ASC driver.)
    Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-8-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0d3ef1cdb02e4c3d76989b83519f32ce0f11f45
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:05 2022 +0300

    serial: sifive: Sanitize CSIZE and c_iflag
    
    [ Upstream commit c069d2756c01ed36121fae6a42c14fdf1325c71d ]
    
    Only CS8 is supported but CSIZE was not sanitized to CS8.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Similarly, INPCK, PARMRK, and BRKINT are reported textually unsupported
    but were not cleared in termios c_iflag which is the machine-readable
    format.
    
    Fixes: 45c054d0815b (tty: serial: add driver for the SiFive UART)
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-7-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd22a62be3f4f768ba777be288b200b8fb5b0e06
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:04 2022 +0300

    serial: sh-sci: Don't allow CS5-6
    
    [ Upstream commit 9b87162de8be26bf3156460b37deee6399fd0fcb ]
    
    Only CS7 and CS8 seem supported but CSIZE is not sanitized from
    CS5 or CS6 to CS8.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-6-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf9e1acf627ef9310bc8f16216dbb9b001e411f6
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:03 2022 +0300

    serial: txx9: Don't allow CS5-6
    
    [ Upstream commit 79ac88655dc0551e3571ad16bdabdbe65d61553e ]
    
    Only CS7 and CS8 are supported but CSIZE is not sanitized with
    CS5 or CS6 to CS8.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-5-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c40253c928eaa575b8b206c6721b930f9202430
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:02 2022 +0300

    serial: rda-uart: Don't allow CS5-6
    
    [ Upstream commit 098333a9c7d12bb3ce44c82f08b4d810c44d31b0 ]
    
    Only CS7 and CS8 are supported but CSIZE is not sanitized after
    fallthrough from CS5 or CS6 to CS7.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: c10b13325ced (tty: serial: Add RDA8810PL UART driver)
    Cc: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-4-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01ea0940e9a6bda318d1b3e843addbe429bbfab5
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:01 2022 +0300

    serial: digicolor-usart: Don't allow CS5-6
    
    [ Upstream commit fd63031b8c0763addcecdefe0e0c59d49646204e ]
    
    Only CS7 and CS8 seem supported but CSIZE is not sanitized to CS8 in
    the default: block.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: 5930cb3511df (serial: driver for Conexant Digicolor USART)
    Acked-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-3-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca34aaff8eb61a0595fcd4e287e8193485b4748a
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:00 2022 +0300

    serial: uartlite: Fix BRKINT clearing
    
    [ Upstream commit 3f7fed405c118607d4d42255f2572072db728399 ]
    
    BRKINT is within c_iflag rather than c_cflag.
    
    Fixes: ea017f5853e9 (tty: serial: uartlite: Prevent changing fixed parameters)
    Reviewed-by: Sean Anderson <sean.anderson@seco.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a4ebbe0f0f076305fcceed92a46c593738deaaf
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed May 18 21:54:52 2022 +0800

    serial: cpm_uart: Fix build error without CONFIG_SERIAL_CPM_CONSOLE
    
    [ Upstream commit 0258502f11a4f6036b5f8b34b09027c8a92def3a ]
    
    drivers/tty/serial/cpm_uart/cpm_uart_core.c: In function ‘cpm_uart_init_port’:
    drivers/tty/serial/cpm_uart/cpm_uart_core.c:1251:7: error: ‘udbg_port’ undeclared (first use in this function); did you mean ‘uart_port’?
      if (!udbg_port)
           ^~~~~~~~~
           uart_port
    
    commit d142585bceb3 leave this corner, wrap it with #ifdef block
    
    Fixes: d142585bceb3 ("serial: cpm_uart: Protect udbg definitions by CONFIG_SERIAL_CPM_CONSOLE")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20220518135452.39480-1-yuehaibing@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 440669d2f0c2d3ded8c8f07f210dd37df55dad2b
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri May 13 16:46:43 2022 +0300

    serial: 8250_fintek: Check SER_RS485_RTS_* only with RS485
    
    [ Upstream commit af0179270977508df6986b51242825d7edd59caf ]
    
    SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND relate to behavior
    within RS485 operation. The driver checks if they have the same value
    which is not possible to realize with the hardware. The check is taken
    regardless of SER_RS485_ENABLED flag and -EINVAL is returned when the
    check fails, which creates problems.
    
    This check makes it unnecessarily complicated to turn RS485 mode off as
    simple zeroed serial_rs485 struct will trigger that equal values check.
    In addition, the driver itself memsets its rs485 structure to zero when
    RS485 is disabled but if userspace would try to make an TIOCSRS485
    ioctl() call with the very same struct, it would end up failing with
    -EINVAL which doesn't make much sense.
    
    Resolve the problem by moving the check inside SER_RS485_ENABLED block.
    
    Fixes: 7ecc77011c6f ("serial: 8250_fintek: Return -EINVAL on invalid configuration")
    Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/035c738-8ea5-8b17-b1d7-84a7b3aeaa51@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0196fa56b68ece153d0a1f1327e42ffd091260d
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Tue May 10 14:26:20 2022 +0200

    Revert "serial: 8250_mtk: Make sure to select the right FEATURE_SEL"
    
    [ Upstream commit f0136f65285bcfb7e8f90d1013723076a35acd51 ]
    
    It was found that some MediaTek SoCs are incompatible with this
    change. Also, this register was mistakenly understood as it was
    related to the 16550A register layout selection but, at least
    on some IPs, if not all, it's related to something else unknown.
    
    This reverts commit 6f81fdded0d024c7d4084d434764f30bca1cd6b1.
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Fixes: 6f81fdded0d0 ("serial: 8250_mtk: Make sure to select the right FEATURE_SEL")
    Reported-by: "kernelci.org bot" <bot@kernelci.org>
    Link: https://lore.kernel.org/r/20220510122620.150342-1-angelogioacchino.delregno@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb927300a2152e19992802f037b52dbdf4354f5f
Author: John Ogness <john.ogness@linutronix.de>
Date:   Sun May 8 12:41:47 2022 +0206

    serial: meson: acquire port->lock in startup()
    
    [ Upstream commit 589f892ac8ef244e47c5a00ffd8605daa1eaef8e ]
    
    The uart_ops startup() callback is called without interrupts
    disabled and without port->lock locked, relatively late during the
    boot process (from the call path of console_on_rootfs()). If the
    device is a console, it was already previously registered and could
    be actively printing messages.
    
    Since the startup() callback is reading/writing registers used by
    the console write() callback (AML_UART_CONTROL), its access must
    be synchronized using the port->lock. Currently it is not.
    
    The startup() callback is the only function that explicitly enables
    interrupts. Without the synchronization, it is possible that
    interrupts become accidentally permanently disabled.
    
    CPU0                           CPU1
    meson_serial_console_write     meson_uart_startup
    --------------------------     ------------------
    spin_lock(port->lock)
    val = readl(AML_UART_CONTROL)
    uart_console_write()
                                   writel(INT_EN, AML_UART_CONTROL)
    writel(val, AML_UART_CONTROL)
    spin_unlock(port->lock)
    
    Add port->lock synchronization to meson_uart_startup() to avoid
    racing with meson_serial_console_write().
    
    Also add detailed comments to meson_uart_reset() explaining why it
    is *not* using port->lock synchronization.
    
    Link: https://lore.kernel.org/lkml/2a82eae7-a256-f70c-fd82-4e510750906e@samsung.com
    Fixes: ff7693d079e5 ("ARM: meson: serial: add MesonX SoC on-chip uart driver")
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20220508103547.626355-1-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba6c278b3364ceef05e63a93787fb01081e2b263
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Wed May 18 15:59:57 2022 +0800

    staging: r8188eu: add check for kzalloc
    
    [ Upstream commit f94b47c6bde624d6c07f43054087607c52054a95 ]
    
    As kzalloc() may return null pointer, it should be better to
    check the return value and return error if fails in order
    to avoid dereference of null pointer.
    Moreover, the return value of rtw_alloc_hwxmits() should also
    be dealt with.
    
    Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver")
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20220518075957.514603-1-jiasheng@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a787b363159968c54d27991ed4d33146a1d50c3
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Apr 3 05:49:12 2022 +0000

    rtc: ftrtc010: Fix error handling in ftrtc010_rtc_probe
    
    [ Upstream commit b520cbe5be37b1b9b401c0b6ecbdae32575273db ]
    
    In the error handling path, the clk_prepare_enable() function
    call should be balanced by a corresponding 'clk_disable_unprepare()'
    call , as already done in the remove function.
    
    clk_disable_unprepare calls clk_disable() and clk_unprepare().
    They will use IS_ERR_OR_NULL to check the argument.
    
    Fixes: ac05fba39cc5 ("rtc: gemini: Add optional clock handling")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20220403054912.31739-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da38e86d6cf6dd3bc65c602d998f357145aa1a0b
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu May 5 20:50:43 2022 +0800

    rtc: mt6397: check return value after calling platform_get_resource()
    
    [ Upstream commit d3b43eb505bffb8e4cdf6800c15660c001553fe6 ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20220505125043.1594771-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3c6a3ef8078d931c3d4f1d77b331187ad920844
Author: Howard Chiu <howard_chiu@aspeedtech.com>
Date:   Fri Apr 1 06:59:06 2022 +0000

    ARM: dts: aspeed: ast2600-evb: Enable RX delay for MAC0/MAC1
    
    [ Upstream commit 4d338ee40ba89e508c5d3e1b4af956af7cb5e12e ]
    
    Since mac0/1 and mac2/3 are physically located on different die,
    they have different properties by nature, which is mac0/1 has smaller delay step.
    
    The property 'phy-mode' on ast2600 mac0 and mac1 is recommended to set to 'rgmii-rxid'
    which enables the RX interface delay from the PHY chip.
    Refer page 45 of SDK User Guide v08.00
    https://github.com/AspeedTech-BMC/openbmc/releases/download/v08.00/SDK_User_Guide_v08.00.pdf
    
    Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB")
    Signed-off-by: Howard Chiu <howard_chiu@aspeedtech.com>
    Link: https://lore.kernel.org/r/SG2PR06MB23152A548AAE81140B57DD69E6E09@SG2PR06MB2315.apcprd06.prod.outlook.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 579a8a2c173492a1d2aa4cae8ddbad5287c615c5
Author: Samuel Holland <samuel@sholland.org>
Date:   Sun May 8 20:21:21 2022 -0500

    clocksource/drivers/riscv: Events are stopped during CPU suspend
    
    [ Upstream commit 232ccac1bd9b5bfe73895f527c08623e7fa0752d ]
    
    Some implementations of the SBI time extension depend on hart-local
    state (for example, CSRs) that are lost or hardware that is powered
    down when a CPU is suspended. To be safe, the clockevents driver
    cannot assume that timer IRQs will be received during CPU suspend.
    
    Fixes: 62b019436814 ("clocksource: new RISC-V SBI timer driver")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    Link: https://lore.kernel.org/r/20220509012121.40031-1-samuel@sholland.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f64e84924604bb969ee1fbc4b8d7d09b9214889
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 16 11:20:10 2022 +0400

    soc: rockchip: Fix refcount leak in rockchip_grf_init
    
    [ Upstream commit 9b59588d8be91c96bfb0371e912ceb4f16315dbf ]
    
    of_find_matching_node_and_match returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 4c58063d4258 ("soc: rockchip: add driver handling grf setup")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220516072013.19731-1-linmq006@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c763e67cc8471288d3459a760346559aee7a9808
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed May 11 15:54:51 2022 -0400

    dt-bindings: remoteproc: mediatek: Make l1tcm reg exclusive to mt819x
    
    [ Upstream commit 6bbe1065121b8cd3b3e734ef8cd99f142bdab241 ]
    
    Commit ca23ecfdbd44 ("remoteproc/mediatek: support L1TCM") added support
    for the l1tcm memory region on the MT8192 SCP, adding a new da_to_va
    callback that handles l1tcm while keeping the old one for
    back-compatibility with MT8183. However, since the mt8192 compatible was
    missing from the dt-binding, the accompanying dt-binding commit
    503c64cc42f1 ("dt-bindings: remoteproc: mediatek: add L1TCM memory region")
    mistakenly added this reg as if it were for mt8183. And later
    it became common to all platforms as their compatibles were added.
    
    Fix the dt-binding so that the l1tcm reg can be present only on the
    supported platforms: mt8192 and mt8195.
    
    Fixes: 503c64cc42f1 ("dt-bindings: remoteproc: mediatek: add L1TCM memory region")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220511195452.871897-2-nfraprado@collabora.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3bb777a485cadd848613085c8839e12f3d431cf6
Author: Li Jun <jun.li@nxp.com>
Date:   Tue Apr 19 20:44:08 2022 +0800

    extcon: ptn5150: Add queue work sync before driver release
    
    [ Upstream commit 782cd939cbe0f569197cd1c9b0477ee213167f04 ]
    
    Add device managed action to sync pending queue work, otherwise
    the queued work may run after the work is destroyed.
    
    Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver")
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9758a6653c27867d810de02b4e5697163dda9883
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Fri Apr 29 16:11:22 2022 +0800

    ksmbd: fix reference count leak in smb_check_perm_dacl()
    
    [ Upstream commit d21a580dafc69aa04f46e6099616146a536b0724 ]
    
    The issue happens in a specific path in smb_check_perm_dacl(). When
    "id" and "uid" have the same value, the function simply jumps out of
    the loop without decrementing the reference count of the object
    "posix_acls", which is increased by get_acl() earlier. This may
    result in memory leaks.
    
    Fix it by decreasing the reference count of "posix_acls" before
    jumping to label "check_access_bits".
    
    Fixes: 777cad1604d6 ("ksmbd: remove select FS_POSIX_ACL in Kconfig")
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0a39ce74080b4cfc276c22b03626fb4df398e37
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Wed Apr 27 19:49:03 2022 -0300

    coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier
    
    [ Upstream commit 1adff542d67a2ed1120955cb219bfff8a9c53f59 ]
    
    The panic notifier infrastructure executes registered callbacks when
    a panic event happens - such callbacks are executed in atomic context,
    with interrupts and preemption disabled in the running CPU and all other
    CPUs disabled. That said, mutexes in such context are not a good idea.
    
    This patch replaces a regular mutex with a mutex_trylock safer approach;
    given the nature of the mutex used in the driver, it should be pretty
    uncommon being unable to acquire such mutex in the panic path, hence
    no functional change should be observed (and if it is, that would be
    likely a deadlock with the regular mutex).
    
    Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20220427224924.592546-10-gpiccoli@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 205b1545cc56d689ddae26488a7f85d699704c01
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Wed Apr 27 07:56:19 2022 +0800

    soundwire: qcom: return error when pm_runtime_get_sync fails
    
    [ Upstream commit f6ee6c8499226eb158ca30457d346511f5e329ce ]
    
    For some reason there's a missing error return in two places.
    
    Fixes: 74e79da9fd46a ("soundwire: qcom: add runtime pm support")
    Fixes: 04d46a7b38375 ("soundwire: qcom: add in-band wake up interrupt support")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220426235623.4253-2-yung-chuan.liao@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f379504c7215f97e0365e9442d9dac059c097b67
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Wed Apr 20 10:32:39 2022 +0800

    soundwire: intel: prevent pm_runtime resume prior to system suspend
    
    [ Upstream commit 6d9f2dadba698114fed97b224578c5338a36b0d9 ]
    
    commit e38f9ff63e6d ("ACPI: scan: Do not add device IDs from _CID if _HID is not valid")
    exposes a race condition on a TGL RVP device leading to a timeout.
    
    The detailed analysis shows the RT711 codec driver scheduling a jack
    detection workqueue while attaching during a spurious pm_runtime
    resume, and the work function happens to be scheduled after the
    manager device is suspended.
    
    The direct link between this ACPI patch and a spurious pm_runtime
    resume is not obvious; the most likely explanation is that a change in
    the ACPI device linked list management modifies the order in which the
    pm_runtime device status is checked and exposes a race condition that
    was probably present for a very long time, but was not identified.
    
    We already have a check in the .prepare stage, where we will resume to
    full power from specific clock-stop modes. In all other cases, we
    don't need to resume to full power by default. Adding the
    SMART_SUSPEND flag prevents the spurious resume from happening.
    
    BugLink: https://github.com/thesofproject/linux/issues/3459
    Fixes: 029bfd1cd53cd ("soundwire: intel: conditionally exit clock stop mode on system suspend")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Link: https://lore.kernel.org/r/20220420023241.14335-2-yung-chuan.liao@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99f6f08eed25f097ee5358fe36c16dcef5d2db34
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:17 2022 +0000

    watchdog: rzg2l_wdt: Fix reset control imbalance
    
    [ Upstream commit 33d04d0fdba9fae18c7d58364643d2c606a43dba ]
    
    Both rzg2l_wdt_probe() and rzg2l_wdt_start() calls reset_control_
    deassert() which results in a reset control imbalance.
    
    This patch fixes reset control imbalance by removing reset_control_
    deassert() from rzg2l_wdt_start() and replaces reset_control_assert with
    reset_control_reset in rzg2l_wdt_stop() as watchdog module can be stopped
    only by a module reset. This change will allow us to restart WDT after
    stop() by configuring WDT timeout and enable registers.
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220225175320.11041-5-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a635239cd5484d8f2e702713ccc49ec82aa7594
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:16 2022 +0000

    watchdog: rzg2l_wdt: Fix 'BUG: Invalid wait context'
    
    [ Upstream commit e4cf89596c1f1e33309556699f910ced4abbaf44 ]
    
    This patch fixes the issue 'BUG: Invalid wait context' during restart()
    callback by using clk_prepare_enable() instead of pm_runtime_get_sync()
    for turning on the clocks during restart.
    
    This issue is noticed when testing with renesas_defconfig.
    
    [   42.213802] reboot: Restarting system
    [   42.217860]
    [   42.219364] =============================
    [   42.223368] [ BUG: Invalid wait context ]
    [   42.227372] 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 Not tainted
    [   42.234153] -----------------------------
    [   42.238155] systemd-shutdow/1 is trying to lock:
    [   42.242766] ffff00000a650828 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x14/0x20
    [   42.250709] other info that might help us debug this:
    [   42.255753] context-{4:4}
    [   42.258368] 2 locks held by systemd-shutdow/1:
    [   42.262806]  #0: ffff80000944e1c8 (system_transition_mutex#2){+.+.}-{3:3}, at: __do_sys_reboot+0xd0/0x250
    [   42.272388]  #1: ffff8000094c4e40 (rcu_read_lock){....}-{1:2}, at: atomic_notifier_call_chain+0x0/0x150
    [   42.281795] stack backtrace:
    [   42.284672] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522
    [   42.294577] Hardware name: Renesas SMARC EVK based on r9a07g044c2 (DT)
    [   42.301096] Call trace:
    [   42.303538]  dump_backtrace+0xcc/0xd8
    [   42.307203]  show_stack+0x14/0x30
    [   42.310517]  dump_stack_lvl+0x88/0xb0
    [   42.314180]  dump_stack+0x14/0x2c
    [   42.317492]  __lock_acquire+0x1b24/0x1b50
    [   42.321502]  lock_acquire+0x120/0x3a8
    [   42.325162]  __mutex_lock+0x84/0x8f8
    [   42.328737]  mutex_lock_nested+0x30/0x58
    [   42.332658]  genpd_lock_mtx+0x14/0x20
    [   42.336319]  genpd_runtime_resume+0xc4/0x228
    [   42.340587]  __rpm_callback+0x44/0x170
    [   42.344337]  rpm_callback+0x64/0x70
    [   42.347824]  rpm_resume+0x4e0/0x6b8
    [   42.351310]  __pm_runtime_resume+0x50/0x78
    [   42.355404]  rzg2l_wdt_restart+0x28/0x68
    [   42.359329]  watchdog_restart_notifier+0x1c/0x30
    [   42.363943]  atomic_notifier_call_chain+0x94/0x150
    [   42.368732]  do_kernel_restart+0x24/0x30
    [   42.372652]  machine_restart+0x44/0x70
    [   42.376399]  kernel_restart+0x3c/0x60
    [   42.380058]  __do_sys_reboot+0x228/0x250
    [   42.383977]  __arm64_sys_reboot+0x20/0x28
    [   42.387983]  invoke_syscall+0x40/0xf8
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220225175320.11041-4-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e74f142b56d01b0778ea23b2f17c3fb86598f9c4
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:15 2022 +0000

    watchdog: rzg2l_wdt: Fix Runtime PM usage
    
    [ Upstream commit 95abafe76297fa057de6c3486ef844bd446bdf18 ]
    
    Both rzg2l_wdt_probe() and rzg2l_wdt_start() calls pm_runtime_get() which
    results in a usage counter imbalance. This patch fixes this issue by
    removing pm_runtime_get() call from probe.
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220225175320.11041-3-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b95a47667d34e76c2c9013f8e3b1e5039a5a0b76
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:14 2022 +0000

    watchdog: rzg2l_wdt: Fix 32bit overflow issue
    
    [ Upstream commit ea2949df22a533cdf75e4583c00b1ce94cd5a83b ]
    
    The value of timer_cycle_us can be 0 due to 32bit overflow.
    For eg:- If we assign the counter value "0xfff" for computing
    maxval.
    
    This patch fixes this issue by appending ULL to 1024, so that
    it is promoted to 64bit.
    
    This patch also fixes the warning message, 'watchdog: Invalid min and
    max timeout values, resetting to 0!'.
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20220225175320.11041-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0de79aca652bbb315dc0be924585b3eff328586
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 27 11:04:42 2022 +0200

    export: fix string handling of namespace in EXPORT_SYMBOL_NS
    
    [ Upstream commit d143b9db8069f0e2a0fa34484e806a55a0dd4855 ]
    
    Commit c3a6cf19e695 ("export: avoid code duplication in
    include/linux/export.h") broke the ability for a defined string to be
    used as a namespace value.  Fix this up by using stringify to properly
    encode the namespace name.
    
    Fixes: c3a6cf19e695 ("export: avoid code duplication in include/linux/export.h")
    Cc: Miroslav Benes <mbenes@suse.cz>
    Cc: Emil Velikov <emil.l.velikov@gmail.com>
    Cc: Jessica Yu <jeyu@kernel.org>
    Cc: Quentin Perret <qperret@google.com>
    Cc: Matthias Maennich <maennich@google.com>
    Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
    Link: https://lore.kernel.org/r/20220427090442.2105905-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 245b3fa3db821af190c212ea618f8c71b050ee20
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Fri Apr 29 21:40:18 2022 +0100

    serial: sifive: Report actual baud base rather than fixed 115200
    
    [ Upstream commit 0a7ff843d507ce2cca2c3b7e169ee56e28133530 ]
    
    The base baud value reported is supposed to be the highest baud rate
    that can be set for a serial port.  The SiFive FU740-C000 SOC's on-chip
    UART supports baud rates of up to 1/16 of the input clock rate, which is
    the bus clock `tlclk'[1], often at 130MHz in the case of the HiFive
    Unmatched board.
    
    However the sifive UART driver reports a fixed value of 115200 instead:
    
    10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 115200) is a SiFive UART v0
    10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 115200) is a SiFive UART v0
    
    even though we already support setting higher baud rates, e.g.:
    
    $ tty
    /dev/ttySIF1
    $ stty speed
    230400
    
    The baud base value is computed by the serial core by dividing the UART
    clock recorded in `struct uart_port' by 16, which is also the minimum
    value of the clock divider supported, so correct the baud base value
    reported by setting the UART clock recorded to the input clock rate
    rather than 115200:
    
    10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 8125000) is a SiFive UART v0
    10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 8125000) is a SiFive UART v0
    
    References:
    
    [1] "SiFive FU740-C000 Manual", v1p3, SiFive, Inc., August 13, 2021,
        Section 16.9 "Baud Rate Divisor Register (div)", pp.143-144
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Fixes: 1f1496a923b6 ("riscv: Fix sifive serial driver")
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204291656280.9383@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 684bf5fac124000ff020a7759f6ef635410ca511
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sat Apr 23 19:27:27 2022 +0200

    power: supply: ab8500_fg: Allocate wq in probe
    
    [ Upstream commit 010ddb813f3554cbbf8bd13b731452236a2c8017 ]
    
    The workqueue is allocated in bind() but all interrupts are
    registered in probe().
    
    Some interrupts put work on the workqueue, which can have
    bad side effects.
    
    Allocate the workqueue in probe() instead, destroy it in
    .remove() and make unbind() simply flush the workqueue.
    
    Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87b8576875f39abbf60146524a7a33c01e0fa8d6
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 2 13:12:35 2022 +0200

    power: supply: axp288_fuel_gauge: Drop BIOS version check from "T3 MRD" DMI quirk
    
    [ Upstream commit f61509a6f0b70f5bedea34efaf8065621689bd7a ]
    
    Some "T3 MRD" mini-PCs / HDMI-sticks without a battery use a different
    value then "5.11" for their DMI BIOS version field.
    
    Drop the BIOS version check so that the no-battery "T3 MRD" DMI quirk
    applies to these too.
    
    Fixes: 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4e6d69bcd0bd80526dd093dd8c25fc624b48945
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 2 13:12:34 2022 +0200

    power: supply: axp288_fuel_gauge: Fix battery reporting on the One Mix 1
    
    [ Upstream commit 34f243e9fb5ace1ca760c72e366247eaeff430c0 ]
    
    Commit 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD"
    no_battery_list DMI entry more generic") added a generic no-battery DMI
    match for many mini-PCs / HDMI-sticks which use "T3 MRD" as their DMI
    board-name.
    
    It turns out that the One Mix 1 mini laptop also uses "T3 MRD" for its
    DMI boardname and it also has its chassis-type wrongly set to a value
    of "3" (desktop). This was causing the axp288_fuel_gauge driver to
    disable battery reporting because this matches the no-battery DMI
    list entry for generic "T3 MRD" mini-PCs.
    
    Change the no-battery DMI list into a quirks DMI list and add a
    specific match for the One Mix 1 mini laptop before the generic
    "T3 MRD" no-battery quirk entry to fix this.
    
    Fixes: 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b5fedfef0452672300d77dfa2467e465694673e
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Mon Apr 25 00:13:01 2022 +0200

    power: supply: core: Initialize struct to zero
    
    [ Upstream commit e56a4be2843c95c08cf8421dc1f8e880cafbaf91 ]
    
    As we rely on pointers in the battery info to be zero-initialized
    such as in the helper function power_supply_supports_vbat2ri()
    we certainly need to allocate the struct power_supply_battery_info
    with kzalloc() as well. Else this happens:
    
    Unable to handle kernel paging request at virtual address 00280000
    (...)
    PC is at power_supply_vbat2ri+0x50/0x12c
    LR is at ab8500_fg_battery_resistance+0x34/0x108
    
    Fixes: e9e7d165b4b0 ("power: supply: Support VBAT-to-Ri lookup tables")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32759f27edfee0f4ab4747b20a190f8d532b2d3a
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon May 2 15:31:29 2022 +0200

    phy: qcom-qmp: fix pipe-clock imbalance on power-on failure
    
    [ Upstream commit 5e73b2d9867998278479ccc065a8a8227a5513ef ]
    
    Make sure to disable the pipe clock also if ufs-reset deassertion fails
    during power on.
    
    Note that the ufs-reset is asserted in qcom_qmp_phy_com_exit().
    
    Fixes: c9b589791fc1 ("phy: qcom: Utilize UFS reset controller")
    Cc: Evan Green <evgreen@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20220502133130.4125-2-johan+linaro@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 694dac3405a35597ab492ee3580d0e61b4d683e1
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Wed Apr 27 19:48:59 2022 -0300

    misc/pvpanic: Convert regular spinlock into trylock on panic path
    
    [ Upstream commit e918c10265ef2bc82ce8a6fed6d8123d09ec1db3 ]
    
    The pvpanic driver relies on panic notifiers to execute a callback
    on panic event. Such function is executed in atomic context - the
    panic function disables local IRQs, preemption and all other CPUs
    that aren't running the panic code.
    
    With that said, it's dangerous to use regular spinlocks in such path,
    as introduced by commit b3c0f8774668 ("misc/pvpanic: probe multiple instances").
    This patch fixes that by replacing regular spinlocks with the trylock
    safer approach.
    
    It also fixes an old comment (about a long gone framebuffer code) and
    the notifier priority - we should execute hypervisor notifiers early,
    deferring this way the panic action to the hypervisor, as expected by
    the users that are setting up pvpanic.
    
    Fixes: b3c0f8774668 ("misc/pvpanic: probe multiple instances")
    Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: Mihai Carabas <mihai.carabas@oracle.com>
    Cc: Shile Zhang <shile.zhang@linux.alibaba.com>
    Cc: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Cc: zhenwei pi <pizhenwei@bytedance.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Link: https://lore.kernel.org/r/20220427224924.592546-6-gpiccoli@igalia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ba35efbf0efde93f80c46a4b6c8ade4b1feca20
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat Apr 23 11:39:32 2022 +0200

    rpmsg: qcom_smd: Fix returning 0 if irq_of_parse_and_map() fails
    
    [ Upstream commit 59d6f72f6f9c92fec8757d9e29527da828e9281f ]
    
    irq_of_parse_and_map() returns 0 on failure, so this should not be
    passed further as error return code.
    
    Fixes: 1a358d350664 ("rpmsg: qcom_smd: Fix irq_of_parse_and_map() return value")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220423093932.32136-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eedb0265487c81fc68f819feb9f2024202f01731
Author: Cixi Geng <cixi.geng1@unisoc.com>
Date:   Tue Apr 19 22:24:54 2022 +0800

    iio: adc: sc27xx: Fine tune the scale calibration values
    
    [ Upstream commit 5a7a184b11c6910f47600ff5cbbee34168f701a8 ]
    
    Small adjustment the scale calibration value for the sc2731,
    use new name sc2731_[big|small]_scale_graph_calib, and remove
    the origin [big|small]_scale_graph_calib struct for unused.
    
    Fixes: 8ba0dbfd07a35 (iio: adc: sc27xx: Add ADC scale calibration)
    Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com>
    Link: https://lore.kernel.org/r/20220419142458.884933-4-gengcixi@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f70f857376db3d3c288d6f40a5f534c128ff3ca8
Author: Cixi Geng <cixi.geng1@unisoc.com>
Date:   Tue Apr 19 22:24:53 2022 +0800

    iio: adc: sc27xx: fix read big scale voltage not right
    
    [ Upstream commit ad930a75613282400179361e220e58b87386b8c7 ]
    
    Fix wrong configuration value of SC27XX_ADC_SCALE_MASK and
    SC27XX_ADC_SCALE_SHIFT by spec documetation.
    
    Fixes: 5df362a6cf49c (iio: adc: Add Spreadtrum SC27XX PMICs ADC support)
    Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com>
    Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
    Link: https://lore.kernel.org/r/20220419142458.884933-3-gengcixi@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a7d38246c9035926e6f72266d10471c655ae9f3
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Apr 12 06:42:09 2022 +0000

    iio: proximity: vl53l0x: Fix return value check of wait_for_completion_timeout
    
    [ Upstream commit 50f2959113cb6756ffd73c4fedc712cf2661f711 ]
    
    wait_for_completion_timeout() returns unsigned long not int.
    It returns 0 if timed out, and positive if completed.
    The check for <= 0 is ambiguous and should be == 0 here
    indicating timeout which is the only error case.
    
    Fixes: 3cef2e31b54b ("iio: proximity: vl53l0x: Add IRQ support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220412064210.10734-1-linmq006@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b73103d50096fc993e6440c3a36bc2caf039062
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Apr 12 06:51:45 2022 +0000

    iio: adc: stmpe-adc: Fix wait_for_completion_timeout return value check
    
    [ Upstream commit d345b23200bcdbd2bd3582213d738c258b77718f ]
    
    wait_for_completion_timeout() returns unsigned long not long.
    it returns 0 if timed out, and positive if completed.
    The check for <= 0 is ambiguous and should be == 0 here
    indicating timeout which is the only error case
    
    Fixes: e813dde6f833 ("iio: stmpe-adc: Use wait_for_completion_timeout")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Philippe Schenker <philippe.schenker@toradex.com>
    Link: https://lore.kernel.org/r/20220412065150.14486-1-linmq006@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d041a3fb0fc22cd33382a9aa6f83958ac12aa76
Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Date:   Tue Apr 26 14:05:36 2022 +0800

    rpmsg: virtio: Fix the unregistration of the device rpmsg_ctrl
    
    [ Upstream commit df191796985922488e4e6b64f7bd79c3934412f2 ]
    
    Unregister the rpmsg_ctrl device instead of just freeing the
    the virtio_rpmsg_channel structure.
    This will properly unregister the device and call
    virtio_rpmsg_release_device() that frees the structure.
    
    Fixes: c486682ae1e2 ("rpmsg: virtio: Register the rpmsg_char device")
    Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Reviewed-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220426060536.15594-4-hbh25y@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d51720ac069d465101d937273acecde1f71ea411
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Apr 26 14:05:35 2022 +0800

    rpmsg: virtio: Fix possible double free in rpmsg_virtio_add_ctrl_dev()
    
    [ Upstream commit 1680939e9ecf7764fba8689cfb3429c2fe2bb23c ]
    
    vch will be free in virtio_rpmsg_release_device() when
    rpmsg_ctrldev_register_device() fails. There is no need to call
    kfree() again.
    
    Fixes: c486682ae1e2 ("rpmsg: virtio: Register the rpmsg_char device")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Tested-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20220426060536.15594-3-hbh25y@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7e88e4bb41dea89b1dadf7a985d7aff53720629
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Apr 26 14:05:34 2022 +0800

    rpmsg: virtio: Fix possible double free in rpmsg_probe()
    
    [ Upstream commit c2eecefec5df1306eafce28ccdf1ca159a552ecc ]
    
    vch will be free in virtio_rpmsg_release_device() when
    rpmsg_ns_register_device() fails. There is no need to call kfree() again.
    
    Fix this by changing error path from free_vch to free_ctrldev.
    
    Fixes: c486682ae1e2 ("rpmsg: virtio: Register the rpmsg_char device")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Tested-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20220426060536.15594-2-hbh25y@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 956dfacefe1c1b32b6702513d06df1706fe04e91
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Fri Apr 22 15:23:47 2022 -0700

    usb: typec: mux: Check dev_set_name() return value
    
    [ Upstream commit b9fa0292490db39d6542f514117333d366ec0011 ]
    
    It's possible that dev_set_name() returns -ENOMEM, catch and handle this.
    
    Fixes: 3370db35193b ("usb: typec: Registering real device entries for the muxes")
    Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220422222351.1297276-4-bjorn.andersson@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57b91504b5d72799fbd7620bcd9e2927fc470dac
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Thu Apr 14 11:56:09 2022 +0800

    firmware: stratix10-svc: fix a missing check on list iterator
    
    [ Upstream commit 5a0793ac66ac0e254d292f129a4d6c526f9f2aff ]
    
    The bug is here:
            pmem->vaddr = NULL;
    
    The list iterator 'pmem' will point to a bogus position containing
    HEAD if the list is empty or no element is found. This case must
    be checked before any use of the iterator, otherwise it will
    lead to a invalid memory access.
    
    To fix this bug, just gen_pool_free/set NULL/list_del() and return
    when found, otherwise list_del HEAD and return;
    
    Fixes: 7ca5ce896524f ("firmware: add Intel Stratix10 service layer driver")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Link: https://lore.kernel.org/r/20220414035609.2239-1-xiam0nd.tong@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d166cee50a381297d6d9c5883123feef3101bed3
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Sun Mar 27 14:22:02 2022 +0800

    misc: fastrpc: fix an incorrect NULL check on list iterator
    
    [ Upstream commit 5ac11fe03a0a83042d1a040dbce4fa2fb5521e23 ]
    
    The bug is here:
            if (!buf) {
    
    The list iterator value 'buf' will *always* be set and non-NULL
    by list_for_each_entry(), so it is incorrect to assume that the
    iterator value will be NULL if the list is empty (in this case, the
    check 'if (!buf) {' will always be false and never exit expectly).
    
    To fix the bug, use a new variable 'iter' as the list iterator,
    while use the original variable 'buf' as a dedicated pointer to
    point to the found element.
    
    Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Link: https://lore.kernel.org/r/20220327062202.5720-1-xiam0nd.tong@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f22f150c92adf350f4d84f03fa979ab0656f7129
Author: SeongJae Park <sj@kernel.org>
Date:   Tue Apr 19 12:16:36 2022 +0000

    scripts/get_abi: Fix wrong script file name in the help message
    
    [ Upstream commit 5b5bfecaa333fb6a0cce1bfc4852a622dacfed1d ]
    
    The help message of 'get_abi.pl' is mistakenly saying it's
    'abi_book.pl'.  This commit fixes the wrong name in the help message.
    
    Fixes: bbc249f2b859 ("scripts: add an script to parse the ABI files")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Link: https://lore.kernel.org/r/20220419121636.290407-1-sj@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75b7b7f22292f98b67c43426e30c2a86c28f66ad
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Fri Apr 22 06:26:52 2022 +0000

    usb: dwc3: pci: Fix pm_runtime_get_sync() error checking
    
    [ Upstream commit a03e2ddab8e735e2cc315609b297b300e9cc60d2 ]
    
    If the device is already in a runtime PM enabled state
    pm_runtime_get_sync() will return 1, so a test for negative
    value should be used to check for errors.
    
    Fixes: 8eed00b237a28 ("usb: dwc3: pci: Runtime resume child device from wq")
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Link: https://lore.kernel.org/r/20220422062652.10575-1-zhengyongjun3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26a7e6832afe9d9a991cfd9015177f083cf959cc
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Thu Apr 14 11:35:21 2022 -0700

    usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback
    
    [ Upstream commit bf594d1d0c1d7b895954018043536ffd327844f9 ]
    
    The list_for_each_entry_safe() macro saves the current item (n) and
    the item after (n+1), so that n can be safely removed without
    corrupting the list.  However, when traversing the list and removing
    items using gadget giveback, the DWC3 lock is briefly released,
    allowing other routines to execute.  There is a situation where, while
    items are being removed from the cancelled_list using
    dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
    routine is running in parallel (due to UDC unbind).  As the cleanup
    routine removes n, and the pullup disable removes n+1, once the
    cleanup retakes the DWC3 lock, it references a request who was already
    removed/handled.  With list debug enabled, this leads to a panic.
    Ensure all instances of the macro are replaced where gadget giveback
    is used.
    
    Example call stack:
    
    Thread#1:
    __dwc3_gadget_ep_set_halt() - CLEAR HALT
      -> dwc3_gadget_ep_cleanup_cancelled_requests()
        ->list_for_each_entry_safe()
        ->dwc3_gadget_giveback(n)
          ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
          ->spin_unlock
          ->Thread#2 executes
          ...
        ->dwc3_gadget_giveback(n+1)
          ->Already removed!
    
    Thread#2:
    dwc3_gadget_pullup()
      ->waiting for dwc3 spin_lock
      ...
      ->Thread#1 released lock
      ->dwc3_stop_active_transfers()
        ->dwc3_remove_requests()
          ->fetches n+1 item from cancelled_list (n removed by Thread#1)
          ->dwc3_gadget_giveback()
            ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]
            ->spin_unlock
    
    Fixes: d4f1afe5e896 ("usb: dwc3: gadget: move requests to cancelled_list")
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220414183521.23451-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d4b932ec1478a6c39d88102db844677713488fd
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Apr 22 12:53:26 2022 +0200

    rpmsg: qcom_smd: Fix irq_of_parse_and_map() return value
    
    [ Upstream commit 1a358d35066487d228a68303d808bc4721c6b1b9 ]
    
    The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO.
    
    Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220422105326.78713-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20555f098e487b98ee04bb33d8189e953275f8ae
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Apr 8 17:38:46 2022 +0200

    pwm: raspberrypi-poe: Fix endianness in firmware struct
    
    [ Upstream commit 09f688f0718f57f9cf68ee1aa94490f641e759ba ]
    
    The reg member of struct raspberrypi_pwm_prop is a little endian 32 bit
    quantity. Explicitly convert the (native endian) value to little endian
    on assignment as is already done in raspberrypi_pwm_set_property().
    
    This fixes the following sparse warning:
    
            drivers/pwm/pwm-raspberrypi-poe.c:69:24: warning: incorrect type in initializer (different base types)
            drivers/pwm/pwm-raspberrypi-poe.c:69:24:    expected restricted __le32 [usertype] reg
            drivers/pwm/pwm-raspberrypi-poe.c:69:24:    got unsigned int [usertype] reg
    
    Fixes: 79caa362eab6 ("pwm: Add Raspberry Pi Firmware based PWM bus")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3551e7097aee769ec513b363028caeff2062036
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Apr 8 17:22:38 2022 +0200

    pwm: lp3943: Fix duty calculation in case period was clamped
    
    [ Upstream commit 5e3b07ca5cc78cd4a987e78446849e41288d87cb ]
    
    The hardware only supports periods <= 1.6 ms and if a bigger period is
    requested it is clamped to 1.6 ms. In this case duty_cycle might be bigger
    than 1.6 ms and then the duty cycle register is written with a value
    bigger than LP3943_MAX_DUTY. So clamp duty_cycle accordingly.
    
    Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebd59cea8f6ee71d0b8904dc0b0b2235ddc33193
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Apr 22 08:48:18 2022 +0200

    staging: fieldbus: Fix the error handling path in anybuss_host_common_probe()
    
    [ Upstream commit 7079b3483a17be2cfba64cbd4feb1b7ae07f1ea7 ]
    
    If device_register() fails, device_unregister() should not be called
    because it will free some resources that are not allocated.
    put_device() should be used instead.
    
    Fixes: 308ee87a2f1e ("staging: fieldbus: anybus-s: support HMS Anybus-S bus")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/5401a519608d6e1a4e7435c20f4f20b0c5c36c23.1650610082.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae0fce56519edc43d9a36aea9ef44ba62df7a3f1
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Mar 9 11:10:33 2022 +0000

    usb: musb: Fix missing of_node_put() in omap2430_probe
    
    [ Upstream commit 424bef51fa530389b0b9008c9e144e40c10e8458 ]
    
    The device_node pointer is returned by of_parse_phandle() with refcount
    incremented. We should use of_node_put() on it when done.
    
    Fixes: 8934d3e4d0e7 ("usb: musb: omap2430: Don't use omap_get_control_dev()")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220309111033.24487-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f92b53ab70e042fb905eb5520b9cc26235efd05
Author: Lin Ma <linma@zju.edu.cn>
Date:   Tue Apr 12 22:43:59 2022 +0800

    USB: storage: karma: fix rio_karma_init return
    
    [ Upstream commit b92ffb1eddd9a66a90defc556dcbf65a43c196c7 ]
    
    The function rio_karam_init() should return -ENOMEM instead of
    value 0 (USB_STOR_TRANSPORT_GOOD) when allocation fails.
    
    Similarly, it should return -EIO when rio_karma_send_command() fails.
    
    Fixes: dfe0d3ba20e8 ("USB Storage: add rio karma eject support")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220412144359.28447-1-linma@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16e638ddabf19508d40e4ff4ac4a08b4a170c8c7
Author: Niels Dossche <dossche.niels@gmail.com>
Date:   Tue Apr 12 18:50:55 2022 +0200

    usb: usbip: add missing device lock on tweak configuration cmd
    
    [ Upstream commit d088fabace2ca337b275d1d4b36db4fe7771e44f ]
    
    The function documentation of usb_set_configuration says that its
    callers should hold the device lock. This lock is held for all
    callsites except tweak_set_configuration_cmd. The code path can be
    executed for example when attaching a remote USB device.
    The solution is to surround the call by the device lock.
    
    This bug was found using my experimental own-developed static analysis
    tool, which reported the missing lock on v5.17.2. I manually verified
    this bug report by doing code review as well. I runtime checked that
    the required lock is not held. I compiled and runtime tested this on
    x86_64 with a USB mouse. After applying this patch, my analyser no
    longer reports this potential bug.
    
    Fixes: 2c8c98158946 ("staging: usbip: let client choose device configuration")
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
    Link: https://lore.kernel.org/r/20220412165055.257113-1-dossche.niels@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11c65408bd0ba1d9cd1307caa38169292de9cdfb
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Apr 12 10:02:57 2022 +0800

    usb: usbip: fix a refcount leak in stub_probe()
    
    [ Upstream commit 9ec4cbf1cc55d126759051acfe328d489c5d6e60 ]
    
    usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails
    after that, usb_put_dev() needs to be called to release the reference.
    
    Fix this by moving usb_put_dev() to sdev_free error path handling.
    
    Find this by code review.
    
    Fixes: 3ff67445750a ("usbip: fix error handling in stub_probe()")
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220412020257.9767-1-hbh25y@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a5c0cd5be3023034fade5e0b086fbe5e2fa5f19
Author: Michael Straube <straube.linux@gmail.com>
Date:   Sun Apr 17 19:54:34 2022 +0200

    staging: r8188eu: fix struct rt_firmware_hdr
    
    [ Upstream commit fbfdc1b6f80abc40cb1f7bac68248b899754d8be ]
    
    The size of struct rt_firmware_hdr is 36 bytes.
    
    $ pahole -C rt_firmware_hdr drivers/staging/r8188eu/r8188eu.o
    struct rt_firmware_hdr {
            __le16                     Signature;            /*     0     2 */
            u8                         Category;             /*     2     1 */
            u8                         Function;             /*     3     1 */
            __le16                     Version;              /*     4     2 */
            u8                         Subversion;           /*     6     1 */
    
            /* XXX 1 byte hole, try to pack */
    
            u16                        Rsvd1;                /*     8     2 */
            u8                         Month;                /*    10     1 */
            u8                         Date;                 /*    11     1 */
            u8                         Hour;                 /*    12     1 */
            u8                         Minute;               /*    13     1 */
            __le16                     RamCodeSize;          /*    14     2 */
            u8                         Foundry;              /*    16     1 */
            u8                         Rsvd2;                /*    17     1 */
    
            /* XXX 2 bytes hole, try to pack */
    
            __le32                     SvnIdx;               /*    20     4 */
            u32                        Rsvd3;                /*    24     4 */
            u32                        Rsvd4;                /*    28     4 */
            u32                        Rsvd5;                /*    32     4 */
    
            /* size: 36, cachelines: 1, members: 17 */
            /* sum members: 33, holes: 2, sum holes: 3 */
            /* last cacheline: 36 bytes */
    };
    
    But the header in the firmware file is only 32 bytes long.
    
    The hexdump of rtl8188eufw.bin shows that the field Rsvd1 should be u8
    instead of __le16.
    
    OFFSET      rtl8188eufw.bin
    -----------------------------------------------------------
    0x00000000  E1 88 10 00 0B 00 01 00 01 21 11 27 30 36 00 00
    0x00000010  2D 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    0x00000000  E1 88 10 00 0B 00 01  00     01     21    11    27 30 36 00 00
                                  ^   ^      ^      ^     ^     ^
                         Subversion   Rsvd1  Month  Date  Hour  Minute
    
    With the change of field Rsvd1 from __le16 to u8 the structure has the
    correct size 32.
    
    $ pahole -C rt_firmware_hdr drivers/staging/r8188eu/r8188eu.o
    struct rt_firmware_hdr {
            __le16                     Signature;            /*     0     2 */
            u8                         Category;             /*     2     1 */
            u8                         Function;             /*     3     1 */
            __le16                     Version;              /*     4     2 */
            u8                         Subversion;           /*     6     1 */
            u8                         Rsvd1;                /*     7     1 */
            u8                         Month;                /*     8     1 */
            u8                         Date;                 /*     9     1 */
            u8                         Hour;                 /*    10     1 */
            u8                         Minute;               /*    11     1 */
            __le16                     RamCodeSize;          /*    12     2 */
            u8                         Foundry;              /*    14     1 */
            u8                         Rsvd2;                /*    15     1 */
            __le32                     SvnIdx;               /*    16     4 */
            u32                        Rsvd3;                /*    20     4 */
            u32                        Rsvd4;                /*    24     4 */
            u32                        Rsvd5;                /*    28     4 */
    
            /* size: 32, cachelines: 1, members: 17 */
            /* last cacheline: 32 bytes */
    
    The wrong size had no effect because the header size is hardcoded to
    32 where it is used in the code and the fields after Subversion are
    not used.
    
    Fixes: 7884fc0a1473 ("staging: r8188eu: introduce new include dir for RTL8188eu driver")
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Michael Straube <straube.linux@gmail.com>
    Link: https://lore.kernel.org/r/20220417175441.13830-2-straube.linux@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bc9dd160de1055bf313b66ad5419c20a8e3624f
Author: Samuel Holland <samuel@sholland.org>
Date:   Wed Apr 13 22:22:52 2022 -0500

    phy: rockchip-inno-usb2: Fix muxed interrupt support
    
    [ Upstream commit 6a98df08ccd55e87947d253b19925691763e755c ]
    
    This commit fixes two issues with the muxed interrupt handler. First,
    the OTG port has the "bvalid" interrupt enabled, not "linestate". Since
    only the linestate interrupt was handled, and not the bvalid interrupt,
    plugging in a cable to the OTG port caused an interrupt storm.
    
    Second, the return values from the individual port IRQ handlers need to
    be OR-ed together. Otherwise, the lack of an interrupt from the last
    port would cause the handler to erroneously return IRQ_NONE.
    
    Fixes: ed2b5a8e6b98 ("phy: phy-rockchip-inno-usb2: support muxed interrupts")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
    Link: https://lore.kernel.org/r/20220414032258.40984-2-samuel@sholland.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82740b4f0c7be7ee790af42c9645b19807d329ec
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Apr 15 10:57:37 2022 +0800

    remoteproc: imx_rproc: Ignore create mem entry for resource table
    
    [ Upstream commit 58b7c856519fe946620ee68dd0c37bd3c695484a ]
    
    Resource table is used by Linux to get information published by
    remote processor. It should be not be used for memory allocation, so
    not create rproc mem entry.
    
    Fixes: b29b4249f8f0 ("remoteproc: imx_rproc: add i.MX specific parse fw hook")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20220415025737.1561976-1-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f19b1befc16ccf77e7d74a97c7057daceb69a019
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Mon Mar 21 19:22:11 2022 +0800

    tty: serial: fsl_lpuart: fix potential bug when using both of_alias_get_id and ida_simple_get
    
    [ Upstream commit f398e0aa325c61fa20903833a5b534ecb8e6e418 ]
    
    Now fsl_lpuart driver use both of_alias_get_id() and ida_simple_get() in
    .probe(), which has the potential bug. For example, when remove the
    lpuart7 alias in dts, of_alias_get_id() will return error, then call
    ida_simple_get() to allocate the id 0 for lpuart7, this may confilct
    with the lpuart4 which has alias 0.
    
        aliases {
            ...
            serial0 = &lpuart4;
            serial1 = &lpuart5;
            serial2 = &lpuart6;
            serial3 = &lpuart7;
        }
    
    So remove the ida_simple_get() in .probe(), return an error directly
    when calling of_alias_get_id() fails, which is consistent with other
    uart drivers behavior.
    
    Fixes: 3bc3206e1c0f ("serial: fsl_lpuart: Remove the alias node dependence")
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Link: https://lore.kernel.org/r/20220321112211.8895-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5f1275f101e0e8a172d300d897f5a12e87e3485
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Apr 4 14:38:40 2022 +0000

    serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe
    
    [ Upstream commit 0e0fd55719fa081de6f9e5d9e6cef48efb04d34a ]
    
    platform_get_resource() may fail and return NULL, so we should
    better check it's return value to avoid a NULL pointer dereference.
    
    Fixes: 54da3e381c2b ("serial: 8250_aspeed_vuart: use UPF_IOREMAP to set up register mapping")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220404143842.16960-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9820355c6766f38c97156eb38a1f3dac86ce1103
Author: Daniel Gibson <daniel@gibson.sh>
Date:   Wed Mar 30 01:58:10 2022 +0200

    tty: n_tty: Restore EOF push handling behavior
    
    [ Upstream commit 65a8b287023da68c4550deab5c764e6891cf1caf ]
    
    TTYs in ICANON mode have a special case that allows "pushing" a line
    without a regular EOL character (like newline), by using EOF (the EOT
    character - ASCII 0x4) as a pseudo-EOL. It is silently discarded, so
    the reader of the PTS will receive the line *without* EOF or any other
    terminating character.
    
    This special case has an edge case: What happens if the readers buffer
    is the same size as the line (without EOF)? Will they be able to tell
    if the whole line is received, i.e. if the next read() will return more
    of the same line or the next line?
    
    There are two possibilities,  that both have (dis)advantages:
    
    1. The next read() returns 0. FreeBSD (13.0) and OSX (10.11) do this.
       Advantage: The reader can interpret this as "the line is over".
       Disadvantage: read() returning 0 means EOF, the reader could also
       interpret it as "there's no more data" and stop reading or even
       close the PT.
    
    2. The next read() returns the next line, the EOF is silently discarded.
       Solaris (or at least OpenIndiana 2021.10) does this, Linux has done
       do this since commit 40d5e0905a03 ("n_tty: Fix EOF push handling");
       this behavior was recently broken by commit 359303076163 ("tty:
       n_tty: do not look ahead for EOL character past the end of the buffer").
       Advantage: read() won't return 0 (EOF), reader less likely to be
       confused (and things like `while(read(..)>0)` don't break)
       Disadvantage: The reader can't really know if the read() continues
       the last line (that filled the whole read buffer) or starts a
       new line.
    
    As both options are defensible (and are used by other Unix-likes), it's
    best to stick to the "old" behavior since "n_tty: Fix EOF push handling"
    of 2013, i.e. silently discard that EOF.
    
    This patch - that I actually got from Linus for testing and only
    modified slightly - restores that behavior by skipping an EOF
    character if it's the next character after reading is done.
    
    Based on a patch from Linus Torvalds.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215611
    Fixes: 359303076163 ("tty: n_tty: do not look ahead for EOL character past the end of the buffer")
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Reviewed-and-tested-by: Daniel Gibson <daniel@gibson.sh>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Daniel Gibson <daniel@gibson.sh>
    Link: https://lore.kernel.org/r/20220329235810.452513-2-daniel@gibson.sh
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89bae2936d89589fd93c71c8d7d135b7f84c6a2b
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Mar 7 10:51:35 2022 +0000

    tty: serial: owl: Fix missing clk_disable_unprepare() in owl_uart_probe
    
    [ Upstream commit bcea0f547ec1a2ee44d429aaf0334633e386e67c ]
    
    Fix the missing clk_disable_unprepare() before return
    from owl_uart_probe() in the error handling case.
    
    Fixes: abf42d2f333b ("tty: serial: owl: add "much needed" clk_prepare_enable()")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220307105135.11698-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4639d1b992de8f37d66f698056875c274efcd45f
Author: Wang Weiyang <wangweiyang2@huawei.com>
Date:   Mon Mar 28 19:58:44 2022 +0800

    tty: goldfish: Use tty_port_destroy() to destroy port
    
    [ Upstream commit 507b05063d1b7a1fcb9f7d7c47586fc4f3508f98 ]
    
    In goldfish_tty_probe(), the port initialized through tty_port_init()
    should be destroyed in error paths.In goldfish_tty_remove(), qtty->port
    also should be destroyed or else might leak resources.
    
    Fix the above by calling tty_port_destroy().
    
    Fixes: 666b7793d4bf ("goldfish: tty driver")
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Wang Weiyang <wangweiyang2@huawei.com>
    Link: https://lore.kernel.org/r/20220328115844.86032-1-wangweiyang2@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22d840b639f77c8bec74e27a265173250e931dd6
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Apr 11 21:13:39 2022 +0200

    lkdtm/bugs: Don't expect thread termination without CONFIG_UBSAN_TRAP
    
    [ Upstream commit 8bfdbddd68249e0d8598777cca8249619ee51df0 ]
    
    When you don't select CONFIG_UBSAN_TRAP, you get:
    
      # echo ARRAY_BOUNDS > /sys/kernel/debug/provoke-crash/DIRECT
    [  102.265827] ================================================================================
    [  102.278433] UBSAN: array-index-out-of-bounds in drivers/misc/lkdtm/bugs.c:342:16
    [  102.287207] index 8 is out of range for type 'char [8]'
    [  102.298722] ================================================================================
    [  102.313712] lkdtm: FAIL: survived array bounds overflow!
    [  102.318770] lkdtm: Unexpected! This kernel (5.16.0-rc1-s3k-dev-01884-g720dcf79314a ppc) was built with CONFIG_UBSAN_BOUNDS=y
    
    It is not correct because when CONFIG_UBSAN_TRAP is not selected
    you can't expect array bounds overflow to kill the thread.
    
    Modify the logic so that when the kernel is built with
    CONFIG_UBSAN_BOUNDS but without CONFIG_UBSAN_TRAP, you get a warning
    about CONFIG_UBSAN_TRAP not been selected instead.
    
    This also require a fix of pr_expected_config(), otherwise the
    following error is encountered.
    
      CC      drivers/misc/lkdtm/bugs.o
    drivers/misc/lkdtm/bugs.c: In function 'lkdtm_ARRAY_BOUNDS':
    drivers/misc/lkdtm/bugs.c:351:2: error: 'else' without a previous 'if'
      351 |  else
          |  ^~~~
    
    Fixes: c75be56e35b2 ("lkdtm/bugs: Add ARRAY_BOUNDS to selftests")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/363b58690e907c677252467a94fe49444c80ea76.1649704381.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce12f7f6b19596edd6b250716930a4ce38bd1f96
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu Jan 20 17:29:36 2022 +0800

    lkdtm/bugs: Check for the NULL pointer after calling kmalloc
    
    [ Upstream commit 4a9800c81d2f34afb66b4b42e0330ae8298019a2 ]
    
    As the possible failure of the kmalloc(), the not_checked and checked
    could be NULL pointer.
    Therefore, it should be better to check it in order to avoid the
    dereference of the NULL pointer.
    Also, we need to kfree the 'not_checked' and 'checked' to avoid
    the memory leak if fails.
    And since it is just a test, it may directly return without error
    number.
    
    Fixes: ae2e1aad3e48 ("drivers/misc/lkdtm/bugs.c: add arithmetic overflow and array bounds checks")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220120092936.1874264-1-jiasheng@iscas.ac.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adc02700236613b344a947a897fc2741d52a43b9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Apr 9 08:27:54 2022 +0200

    remoteproc: mtk_scp: Fix a potential double free
    
    [ Upstream commit eac3e5b1c12f85732e60f5f8b985444d273866bb ]
    
    'scp->rproc' is allocated using devm_rproc_alloc(), so there is no need
    to free it explicitly in the remove function.
    
    Fixes: c1407ac1099a ("remoteproc: mtk_scp: Use devm variant of rproc_alloc()")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/1d15023b4afb94591435c48482fe1276411b9a07.1648981531.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ec7b203499ff35f4383d8e8741327e197d45af7
Author: Tinghan Shen <tinghan.shen@mediatek.com>
Date:   Mon Mar 21 14:03:40 2022 +0800

    remoteproc: mediatek: Fix side effect of mt8195 sram power on
    
    [ Upstream commit f20e232d74ee0ace386be0b7db1ff993ea69b4c4 ]
    
    The definition of L1TCM_SRAM_PDN bits on mt8195 is different to mt8192.
    
    L1TCM_SRAM_PDN bits[3:0] control the power of mt8195 L1TCM SRAM.
    
    L1TCM_SRAM_PDN bits[7:4] control the access path to EMI for SCP.
    These bits have to be powered on to allow EMI access for SCP.
    
    Bits[7:4] also affect audio DSP because audio DSP and SCP are
    placed on the same hardware bus. If SCP cannot access EMI, audio DSP is
    blocked too.
    
    L1TCM_SRAM_PDN bits[31:8] are not used.
    
    This fix removes modification of bits[7:4] when power on/off mt8195 SCP
    L1TCM. It's because the modification introduces a short period of time
    blocking audio DSP to access EMI. This was not a problem until we have
    to load both SCP module and audio DSP module. audio DSP needs to access
    EMI because it has source/data on DRAM. Audio DSP will have unexpected
    behavior when it accesses EMI and the SCP driver blocks the EMI path at
    the same time.
    
    Fixes: 79111df414fc ("remoteproc: mediatek: Support mt8195 scp")
    Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Link: https://lore.kernel.org/r/20220321060340.10975-1-tinghan.shen@mediatek.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83cc8ed8053b5621ee29edeec6e58c234a5b7b50
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Mar 7 15:58:15 2022 +0300

    soundwire: qcom: fix an error message in swrm_wait_for_frame_gen_enabled()
    
    [ Upstream commit d146de3430d2b21054f6dc8a890f84062515f4d2 ]
    
    The logical AND && is supposed to be bitwise AND & so it will sometimes
    print "connected" instead of "disconnected".
    
    Fixes: 74e79da9fd46 ("soundwire: qcom: add runtime pm support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20220307125814.GD16710@kili
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 871ffe1ab7c76c8388829ab5644691393afd022f
Author: Alexandru Tachici <alexandru.tachici@analog.com>
Date:   Tue Mar 22 12:50:24 2022 +0200

    iio: adc: ad7124: Remove shift from scan_type
    
    [ Upstream commit fe78ccf79b0e29fd6d8dc2e2c3b0dbeda4ce3ad8 ]
    
    The 24 bits data is stored in 32 bits in BE. There
    is no need to shift it. This confuses user-space apps.
    
    Fixes: b3af341bbd966 ("iio: adc: Add ad7124 support")
    Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
    Link: https://lore.kernel.org/r/20220322105029.86389-2-alexandru.tachici@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bafccf697ed28df3994eec051f188aada504fef0
Author: Jakob Koschel <jakobkoschel@gmail.com>
Date:   Mon Mar 21 13:36:26 2022 +0100

    staging: greybus: codecs: fix type confusion of list iterator variable
    
    [ Upstream commit 84ef256550196bc06e6849a34224c998b45bd557 ]
    
    If the list does not exit early then data == NULL and 'module' does not
    point to a valid list element.
    Using 'module' in such a case is not valid and was therefore removed.
    
    Fixes: 6dd67645f22c ("greybus: audio: Use single codec driver registration")
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Vaibhav Agarwal <vaibhav.sr@gmail.com>
    Reviewed-by: Mark Greer <mgreer@animalcreek.com>
    Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
    Link: https://lore.kernel.org/r/20220321123626.3068639-1-jakobkoschel@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44e9cab0d180da7c142f666f88c5ed44adc0b10f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jan 23 09:40:31 2022 -0800

    pcmcia: db1xxx_ss: restrict to MIPS_DB1XXX boards
    
    [ Upstream commit 3928cf08334ed895a31458cbebd8d4ec6d84c080 ]
    
    When the MIPS_ALCHEMY board selection is MIPS_XXS1500 instead of
    MIPS_DB1XXX, the PCMCIA driver 'db1xxx_ss' has build errors due
    to missing DB1XXX symbols. The PCMCIA driver should be restricted
    to MIPS_DB1XXX instead of MIPS_ALCHEMY to fix this build error.
    
    ERROR: modpost: "bcsr_read" [drivers/pcmcia/db1xxx_ss.ko] undefined!
    ERROR: modpost: "bcsr_mod" [drivers/pcmcia/db1xxx_ss.ko] undefined!
    
    Fixes: 42a4f17dc356 ("MIPS: Alchemy: remove SOC_AU1X00 in favor of MIPS_ALCHEMY")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Acked-by: Manuel Lauss <manuel.lauss@gmail.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>