commit 3b17187f5ca1f5d0c641fdc90a6a7e38afdf8fae
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Nov 18 19:17:21 2021 +0100

    Linux 5.15.3
    
    Link: https://lore.kernel.org/r/20211115165428.722074685@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Link: https://lore.kernel.org/r/20211116142631.571909964@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Link: https://lore.kernel.org/r/20211117101657.463560063@linuxfoundation.org
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/r/20211118081919.507743013@linuxfoundation.org
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-By: Scott Bruce <smbruce@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 712cb7ee75bc3bb025c00e043098114a747cf097
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Nov 1 14:53:55 2021 +0000

    media: videobuf2-dma-sg: Fix buf->vb NULL pointer dereference
    
    commit d55c3ee6b4c7b76326eb257403762f8bd7cc48c2 upstream.
    
    Commit a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API")
    added a new vb member to struct vb2_dma_sg_buf, but it only added
    code setting this to the vb2_dma_sg_alloc() function and not to the
    vb2_dma_sg_get_userptr() and vb2_dma_sg_attach_dmabuf() which also
    create vb2_dma_sg_buf objects.
    
    This is causing a crash due to a NULL pointer deref when using
    libcamera on devices with an Intel IPU3 (qcam app).
    
    Fix these crashes by assigning buf->vb in the other 2 functions too,
    note libcamera tests the vb2_dma_sg_get_userptr() path, the change
    to the vb2_dma_sg_attach_dmabuf() path is untested.
    
    Fixes: a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API")
    Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8b0f8beb56641bb986024a8f17012793e2fd9c9
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date:   Tue Sep 28 04:46:34 2021 +0100

    media: videobuf2: always set buffer vb2 pointer
    
    commit 67f85135c57c8ea20b5417b28ae65e53dc2ec2c3 upstream.
    
    We need to always link allocated vb2_dc_buf back to vb2_buffer because
    we dereference vb2 in prepare() and finish() callbacks.
    
    Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Acked-by: Tomasz Figa <tfiga@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c087b0fbfe9da991552c258190b4f1e3975db93
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Oct 1 21:41:20 2021 +0200

    x86/sev: Make the #VC exception stacks part of the default stacks storage
    
    commit 541ac97186d9ea88491961a46284de3603c914fd upstream.
    
    The size of the exception stacks was increased by the commit in Fixes,
    resulting in stack sizes greater than a page in size. The #VC exception
    handling was only mapping the first (bottom) page, resulting in an
    SEV-ES guest failing to boot.
    
    Make the #VC exception stacks part of the default exception stacks
    storage and allocate them with a CONFIG_AMD_MEM_ENCRYPT=y .config. Map
    them only when a SEV-ES guest has been detected.
    
    Rip out the custom VC stacks mapping and storage code.
    
     [ bp: Steal and adapt Tom's commit message. ]
    
    Fixes: 7fae4c24a2b8 ("x86: Increase exception stack sizes")
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
    Tested-by: Brijesh Singh <brijesh.singh@amd.com>
    Link: https://lkml.kernel.org/r/YVt1IMjIs7pIZTRR@zn.tnic
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 411d939db1d05be79f29cdeef87b1f9a46a54121
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Wed Sep 8 17:58:34 2021 -0500

    x86/sev: Add an x86 version of cc_platform_has()
    
    commit aa5a461171f98fde0df78c4f6b5018a1e967cf81 upstream.
    
    Introduce an x86 version of the cc_platform_has() function. This will be
    used to replace vendor specific calls like sme_active(), sev_active(),
    etc.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20210928191009.32551-4-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1568346180023918716cc23cc58ba0ab7ca80cf
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Wed Sep 8 17:58:33 2021 -0500

    arch/cc: Introduce a function to check for confidential computing features
    
    commit 46b49b12f3fc5e1347dba37d4639e2165f447871 upstream.
    
    In preparation for other confidential computing technologies, introduce
    a generic helper function, cc_platform_has(), that can be used to
    check for specific active confidential computing attributes, like
    memory encryption. This is intended to eliminate having to add multiple
    technology-specific checks to the code (e.g. if (sev_active() ||
    tdx_active() || ... ).
    
     [ bp: s/_CC_PLATFORM_H/_LINUX_CC_PLATFORM_H/g ]
    
    Co-developed-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Co-developed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20210928191009.32551-3-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03fbc935ac6216ccb87f274d642d0607bf1915d0
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Nov 1 16:01:18 2021 -0700

    selftests/bpf: Fix also no-alu32 strobemeta selftest
    
    commit a20eac0af02810669e187cb623bc904908c423af upstream.
    
    Previous fix aded bpf_clamp_umax() helper use to re-validate boundaries.
    While that works correctly, it introduces more branches, which blows up
    past 1 million instructions in no-alu32 variant of strobemeta selftests.
    
    Switching len variable from u32 to u64 also fixes the issue and reduces
    the number of validated instructions, so use that instead. Fix this
    patch and bpf_clamp_umax() removed, both alu32 and no-alu32 selftests
    pass.
    
    Fixes: 0133c20480b1 ("selftests/bpf: Fix strobemeta selftest regression")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211101230118.1273019-1-andrii@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60e73f7e75cfe4b98f338e88dca729a3d33485c7
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Oct 29 19:27:32 2021 +0200

    selftests/x86/iopl: Adjust to the faked iopl CLI/STI usage
    
    commit a72fdfd21e01c626273ddcf5ab740d4caef4be54 upstream.
    
    Commit in Fixes changed the iopl emulation to not #GP on CLI and STI
    because it would break some insane luserspace tools which would toggle
    interrupts.
    
    The corresponding selftest would rely on the fact that executing CLI/STI
    would trigger a #GP and thus detect it this way but since that #GP is
    not happening anymore, the detection is now wrong too.
    
    Extend the test to actually look at the IF flag and whether executing
    those insns had any effect on it. The STI detection needs to have the
    fact that interrupts were previously disabled, passed in so do that from
    the previous CLI test, i.e., STI test needs to follow a previous CLI one
    for it to make sense.
    
    Fixes: b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20211030083939.13073-1-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32d126ac68f574432959fe938f06e257678b2ae5
Author: Colin Ian King <colin.king@intel.com>
Date:   Wed Oct 13 11:00:52 2021 +0100

    mmc: moxart: Fix null pointer dereference on pointer host
    
    commit 0eab756f8821d255016c63bb55804c429ff4bdb1 upstream.
    
    There are several error return paths that dereference the null pointer
    host because the pointer has not yet been set to a valid value.
    Fix this by adding a new out_mmc label and exiting via this label
    to avoid the host clean up and hence the null pointer dereference.
    
    Addresses-Coverity: ("Explicit null dereference")
    Fixes: 8105c2abbf36 ("mmc: moxart: Fix reference count leaks in moxart_probe")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20211013100052.125461-1-colin.king@canonical.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f11f2096b2c752aea7e5c72d602626e893867ef
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 20 11:59:07 2021 +0300

    ath10k: fix invalid dma_addr_t token assignment
    
    commit 937e79c67740d1d84736730d679f3cb2552f990e upstream.
    
    Using a kernel pointer in place of a dma_addr_t token can
    lead to undefined behavior if that makes it into cache
    management functions. The compiler caught one such attempt
    in a cast:
    
    drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface':
    drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
     5586 |                         arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf;
          |                                               ^
    
    Looking through how this gets used down the way, I'm fairly
    sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL
    devices, and if it was accessed, that would be a bug.
    
    Change the assignment to use a known-invalid address token
    instead, which avoids the warning and makes it easier to catch
    bugs if it does end up getting used.
    
    Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ebaafec97fb6c0c816f0f355976aaa0811008d4
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Fri Nov 12 14:53:36 2021 -0300

    cifs: fix memory leak of smb3_fs_context_dup::server_hostname
    
    commit 869da64d071142d4ed562a3e909deb18e4e72c4e upstream.
    
    Fix memory leak of smb3_fs_context_dup::server_hostname when parsing
    and duplicating fs contexts during mount(2) as reported by kmemleak:
    
      unreferenced object 0xffff888125715c90 (size 16):
        comm "mount.cifs", pid 3832, jiffies 4304535868 (age 190.094s)
        hex dump (first 16 bytes):
          7a 65 6c 64 61 2e 74 65 73 74 00 6b 6b 6b 6b a5  zelda.test.kkkk.
        backtrace:
          [<ffffffff8168106e>] kstrdup+0x2e/0x60
          [<ffffffffa027a362>] smb3_fs_context_dup+0x392/0x8d0 [cifs]
          [<ffffffffa0136353>] cifs_smb3_do_mount+0x143/0x1700 [cifs]
          [<ffffffffa02795e8>] smb3_get_tree+0x2e8/0x520 [cifs]
          [<ffffffff817a19aa>] vfs_get_tree+0x8a/0x2d0
          [<ffffffff8181e3e3>] path_mount+0x423/0x1a10
          [<ffffffff8181fbca>] __x64_sys_mount+0x1fa/0x270
          [<ffffffff83ae364b>] do_syscall_64+0x3b/0x90
          [<ffffffff83c0007c>] entry_SYSCALL_64_after_hwframe+0x44/0xae
      unreferenced object 0xffff888111deed20 (size 32):
        comm "mount.cifs", pid 3832, jiffies 4304536044 (age 189.918s)
        hex dump (first 32 bytes):
          44 46 53 52 4f 4f 54 31 2e 5a 45 4c 44 41 2e 54  DFSROOT1.ZELDA.T
          45 53 54 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  EST.kkkkkkkkkkk.
        backtrace:
          [<ffffffff8168118d>] kstrndup+0x2d/0x90
          [<ffffffffa027ab2e>] smb3_parse_devname+0x9e/0x360 [cifs]
          [<ffffffffa01870c8>] cifs_setup_volume_info+0xa8/0x470 [cifs]
          [<ffffffffa018c469>] connect_dfs_target+0x309/0xc80 [cifs]
          [<ffffffffa018d6cb>] cifs_mount+0x8eb/0x17f0 [cifs]
          [<ffffffffa0136475>] cifs_smb3_do_mount+0x265/0x1700 [cifs]
          [<ffffffffa02795e8>] smb3_get_tree+0x2e8/0x520 [cifs]
          [<ffffffff817a19aa>] vfs_get_tree+0x8a/0x2d0
          [<ffffffff8181e3e3>] path_mount+0x423/0x1a10
          [<ffffffff8181fbca>] __x64_sys_mount+0x1fa/0x270
          [<ffffffff83ae364b>] do_syscall_64+0x3b/0x90
          [<ffffffff83c0007c>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 7be3248f3139 ("cifs: To match file servers, make sure the server hostname matches")
    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 855eba695ddc400955064ec5ffcb1bae65c9b615
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Sep 14 08:21:25 2021 +0100

    media: vidtv: move kfree(dvb) to vidtv_bridge_dev_release()
    
    commit 112024a3b6dcfc62ec36ea0cf58b897f2ce54c59 upstream.
    
    Adding kfree(dvb) to vidtv_bridge_remove() will remove the memory
    too soon: if an application still has an open filehandle to the device
    when the driver is unloaded, then when that filehandle is closed, a
    use-after-free access takes place to the freed memory.
    
    Move the kfree(dvb) to vidtv_bridge_dev_release() instead.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 76e21bb8be4f ("media: vidtv: Fix memory leak in remove")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb7e50b476abb8fc94a9891bb7f08ab21801fec5
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Tue Nov 2 10:04:37 2021 -0500

    drm/amd/display: Look at firmware version to determine using dmub on dcn21
    
    commit 91adec9e07097e538691daed5d934e7886dd1dc3 upstream.
    
    commit 652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21
    asics") switched over to using dmub on Renoir to fix Gitlab 1735, but this
    implied a new dependency on newer firmware which might not be met on older
    kernel versions.
    
    Since sw_init runs before hw_init, there is an opportunity to determine
    whether or not the firmware version is new to adjust the behavior.
    
    Cc: Roman.Li@amd.com
    BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1772
    BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1735
    Fixes: 652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21 asics")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Roman Li <Roman.Li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e1e7e4a6b54b9ed9a633a9faeb8f0dafd6dd7fb
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Jul 12 09:52:59 2021 -0400

    SUNRPC: Partial revert of commit 6f9f17287e78
    
    commit ea7a1019d8baf8503ecd6e3ec8436dec283569e6 upstream.
    
    The premise of commit 6f9f17287e78 ("SUNRPC: Mitigate cond_resched() in
    xprt_transmit()") was that cond_resched() is expensive and unnecessary
    when there has been just a single send.
    The point of cond_resched() is to ensure that tasks that should pre-empt
    this one get a chance to do so when it is safe to do so. The code prior
    to commit 6f9f17287e78 failed to take into account that it was keeping a
    rpc_task pinned for longer than it needed to, and so rather than doing a
    full revert, let's just move the cond_resched.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f837109586eb86d236f13cfdea7e23affd1636a
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:41 2021 +0200

    PCI: aardvark: Fix PCIe Max Payload Size setting
    
    commit a4e17d65dafdd3513042d8f00404c9b6068a825c upstream.
    
    Change PCIe Max Payload Size setting in PCIe Device Control register to 512
    bytes to align with PCIe Link Initialization sequence as defined in Marvell
    Armada 3700 Functional Specification. According to the specification,
    maximal Max Payload Size supported by this device is 512 bytes.
    
    Without this kernel prints suspicious line:
    
        pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 16384, max 512)
    
    With this change it changes to:
    
        pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 512, max 512)
    
    Link: https://lore.kernel.org/r/20211005180952.6812-3-kabel@kernel.org
    Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b86872ba468e6ddfe001abe70ff88000262451f
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:40 2021 +0200

    PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros
    
    commit 460275f124fb072dca218a6b43b6370eebbab20d upstream.
    
    Define a macro PCI_EXP_DEVCTL_PAYLOAD_* for every possible Max Payload
    Size in linux/pci_regs.h, in the same style as PCI_EXP_DEVCTL_READRQ_*.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-2-kabel@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfc6f0bec09c2953294dfe207126f12faed59163
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Tue Aug 31 20:48:19 2021 +0200

    drm/sun4i: Fix macros in sun8i_csc.h
    
    commit c302c98da646409d657a473da202f10f417f3ff1 upstream.
    
    Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
    recommendation of having arguments enclosed in parenthesis. While that
    didn't change anything for quite sometime, it actually become important
    after CSC code rework with commit ea067aee45a8 ("drm/sun4i: de2/de3:
    Remove redundant CSC matrices").
    
    Without this fix, colours are completely off for supported YVU formats
    on SoCs with DE2 (A64, H3, R40, etc.).
    
    Fix the issue by enclosing macro arguments in parenthesis.
    
    Cc: stable@vger.kernel.org # 5.12+
    Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
    Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210831184819.93670-1-jernej.skrabec@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0084aaaec2d1bbf7d1510a2601644c19b39fe5f7
Author: Xiaoming Ni <nixiaoming@huawei.com>
Date:   Wed Sep 29 11:36:46 2021 +0800

    powerpc/85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n
    
    commit c45361abb9185b1e172bd75eff51ad5f601ccae4 upstream.
    
    When CONFIG_SMP=y, timebase synchronization is required when the second
    kernel is started.
    
    arch/powerpc/kernel/smp.c:
      int __cpu_up(unsigned int cpu, struct task_struct *tidle)
      {
            ...
            if (smp_ops->give_timebase)
                    smp_ops->give_timebase();
            ...
      }
    
      void start_secondary(void *unused)
      {
            ...
            if (smp_ops->take_timebase)
                    smp_ops->take_timebase();
            ...
      }
    
    When CONFIG_HOTPLUG_CPU=n and CONFIG_KEXEC_CORE=n,
     smp_85xx_ops.give_timebase is NULL,
     smp_85xx_ops.take_timebase is NULL,
    As a result, the timebase is not synchronized.
    
    Timebase  synchronization does not depend on CONFIG_HOTPLUG_CPU.
    
    Fixes: 56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations")
    Cc: stable@vger.kernel.org # v4.6+
    Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210929033646.39630-3-nixiaoming@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 310b6f976c74a540ca413e518102eae7e0f2fc4e
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Wed Oct 20 14:47:03 2021 -0500

    powerpc/pseries/mobility: ignore ibm, platform-facilities updates
    
    commit 319fa1a52e438a6e028329187783a25ad498c4e6 upstream.
    
    On VMs with NX encryption, compression, and/or RNG offload, these
    capabilities are described by nodes in the ibm,platform-facilities device
    tree hierarchy:
    
      $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
      /sys/firmware/devicetree/base/ibm,platform-facilities/
      ├── ibm,compression-v1
      ├── ibm,random-v1
      └── ibm,sym-encryption-v1
    
      3 directories
    
    The acceleration functions that these nodes describe are not disrupted by
    live migration, not even temporarily.
    
    But the post-migration ibm,update-nodes sequence firmware always sends
    "delete" messages for this hierarchy, followed by an "add" directive to
    reconstruct it via ibm,configure-connector (log with debugging statements
    enabled in mobility.c):
    
      mobility: removing node /ibm,platform-facilities/ibm,random-v1:4294967285
      mobility: removing node /ibm,platform-facilities/ibm,compression-v1:4294967284
      mobility: removing node /ibm,platform-facilities/ibm,sym-encryption-v1:4294967283
      mobility: removing node /ibm,platform-facilities:4294967286
      ...
      mobility: added node /ibm,platform-facilities:4294967286
    
    Note we receive a single "add" message for the entire hierarchy, and what
    we receive from the ibm,configure-connector sequence is the top-level
    platform-facilities node along with its three children. The debug message
    simply reports the parent node and not the whole subtree.
    
    Also, significantly, the nodes added are almost completely equivalent to
    the ones removed; even phandles are unchanged. ibm,shared-interrupt-pool in
    the leaf nodes is the only property I've observed to differ, and Linux does
    not use that. So in practice, the sum of update messages Linux receives for
    this hierarchy is equivalent to minor property updates.
    
    We succeed in removing the original hierarchy from the device tree. But the
    vio bus code is ignorant of this, and does not unbind or relinquish its
    references. The leaf nodes, still reachable through sysfs, of course still
    refer to the now-freed ibm,platform-facilities parent node, which makes
    use-after-free possible:
    
      refcount_t: addition on 0; use-after-free.
      WARNING: CPU: 3 PID: 1706 at lib/refcount.c:25 refcount_warn_saturate+0x164/0x1f0
      refcount_warn_saturate+0x160/0x1f0 (unreliable)
      kobject_get+0xf0/0x100
      of_node_get+0x30/0x50
      of_get_parent+0x50/0xb0
      of_fwnode_get_parent+0x54/0x90
      fwnode_count_parents+0x50/0x150
      fwnode_full_name_string+0x30/0x110
      device_node_string+0x49c/0x790
      vsnprintf+0x1c0/0x4c0
      sprintf+0x44/0x60
      devspec_show+0x34/0x50
      dev_attr_show+0x40/0xa0
      sysfs_kf_seq_show+0xbc/0x200
      kernfs_seq_show+0x44/0x60
      seq_read_iter+0x2a4/0x740
      kernfs_fop_read_iter+0x254/0x2e0
      new_sync_read+0x120/0x190
      vfs_read+0x1d0/0x240
    
    Moreover, the "new" replacement subtree is not correctly added to the
    device tree, resulting in ibm,platform-facilities parent node without the
    appropriate leaf nodes, and broken symlinks in the sysfs device hierarchy:
    
      $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
      /sys/firmware/devicetree/base/ibm,platform-facilities/
    
      0 directories
    
      $ cd /sys/devices/vio ; find . -xtype l -exec file {} +
      ./ibm,sym-encryption-v1/of_node: broken symbolic link to
        ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,sym-encryption-v1
      ./ibm,random-v1/of_node:         broken symbolic link to
        ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,random-v1
      ./ibm,compression-v1/of_node:    broken symbolic link to
        ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,compression-v1
    
    This is because add_dt_node() -> dlpar_attach_node() attaches only the
    parent node returned from configure-connector, ignoring any children. This
    should be corrected for the general case, but fixing that won't help with
    the stale OF node references, which is the more urgent problem.
    
    One way to address that would be to make the drivers respond to node
    removal notifications, so that node references can be dropped
    appropriately. But this would likely force the drivers to disrupt active
    clients for no useful purpose: equivalent nodes are immediately re-added.
    And recall that the acceleration capabilities described by the nodes remain
    available throughout the whole process.
    
    The solution I believe to be robust for this situation is to convert
    remove+add of a node with an unchanged phandle to an update of the node's
    properties in the Linux device tree structure. That would involve changing
    and adding a fair amount of code, and may take several iterations to land.
    
    Until that can be realized we have a confirmed use-after-free and the
    possibility of memory corruption. So add a limited workaround that
    discriminates on the node type, ignoring adds and removes. This should be
    amenable to backporting in the meantime.
    
    Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211020194703.2613093-1-nathanl@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d05dc4bdc3332b487fcda21f70eb70ad42c2e2cc
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Oct 26 22:25:31 2021 +1000

    powerpc/64s/interrupt: Fix check_return_regs_valid() false positive
    
    commit 4a5cb51f3db4be547225a4bce7a43d41b231382b upstream.
    
    The check_return_regs_valid() can cause a false positive if the return
    regs are marked as norestart and they are an HSRR type interrupt,
    because the low bit in the bottom of regs->trap causes interrupt type
    matching to fail.
    
    This can occcur for example on bare metal with a HV privileged doorbell
    interrupt that causes a signal, but do_signal returns early because
    get_signal() fails, and takes the "No signal to deliver" path. In this
    case no signal was delivered so the return location is not changed so
    return SRRs are not invalidated, yet set_trap_norestart is called, which
    messes up the match. Building go-1.16.6 is known to reproduce this.
    
    Fix it by using the TRAP() accessor which masks out the low bit.
    
    Fixes: 6eaaf9de3599 ("powerpc/64s/interrupt: Check and fix srr_valid without crashing")
    Cc: stable@vger.kernel.org # v5.14+
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211026122531.3599918-1-npiggin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02da363241047ca18108914226cc9e7c02fa8388
Author: Russell Currey <ruscur@russell.cc>
Date:   Wed Oct 27 17:24:10 2021 +1000

    powerpc/security: Use a mutex for interrupt exit code patching
    
    commit 3c12b4df8d5e026345a19886ae375b3ebc33c0b6 upstream.
    
    The mitigation-patching.sh script in the powerpc selftests toggles
    all mitigations on and off simultaneously, revealing that rfi_flush
    and stf_barrier cannot safely operate at the same time due to races
    in updating the static key.
    
    On some systems, the static key code throws a warning and the kernel
    remains functional.  On others, the kernel will hang or crash.
    
    Fix this by slapping on a mutex.
    
    Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt")
    Cc: stable@vger.kernel.org # v5.14+
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    Acked-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211027072410.40950-1-ruscur@russell.cc
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c8ad3fc644a0bf3ed99c0b6d13bba94e857136a
Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Date:   Thu Oct 28 22:27:16 2021 +0530

    powerpc/powernv/prd: Unregister OPAL_MSG_PRD2 notifier during module unload
    
    commit 52862ab33c5d97490f3fa345d6529829e6d6637b upstream.
    
    Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and
    added opal notifier. But I missed to unregister the notifier during
    module unload path. This results in below call trace if you try to
    unload and load opal_prd module.
    
    Also add new notifier_block for OPAL_MSG_PRD2 message.
    
    Sample calltrace (modprobe -r opal_prd; modprobe opal_prd)
      BUG: Unable to handle kernel data access on read at 0xc0080000192200e0
      Faulting instruction address: 0xc00000000018d1cc
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
      CPU: 66 PID: 7446 Comm: modprobe Kdump: loaded Tainted: G            E     5.14.0prd #759
      NIP:  c00000000018d1cc LR: c00000000018d2a8 CTR: c0000000000cde10
      REGS: c0000003c4c0f0a0 TRAP: 0300   Tainted: G            E      (5.14.0prd)
      MSR:  9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE>  CR: 24224824  XER: 20040000
      CFAR: c00000000018d2a4 DAR: c0080000192200e0 DSISR: 40000000 IRQMASK: 1
      ...
      NIP notifier_chain_register+0x2c/0xc0
      LR  atomic_notifier_chain_register+0x48/0x80
      Call Trace:
        0xc000000002090610 (unreliable)
        atomic_notifier_chain_register+0x58/0x80
        opal_message_notifier_register+0x7c/0x1e0
        opal_prd_probe+0x84/0x150 [opal_prd]
        platform_probe+0x78/0x130
        really_probe+0x110/0x5d0
        __driver_probe_device+0x17c/0x230
        driver_probe_device+0x60/0x130
        __driver_attach+0xfc/0x220
        bus_for_each_dev+0xa8/0x130
        driver_attach+0x34/0x50
        bus_add_driver+0x1b0/0x300
        driver_register+0x98/0x1a0
        __platform_driver_register+0x38/0x50
        opal_prd_driver_init+0x34/0x50 [opal_prd]
        do_one_initcall+0x60/0x2d0
        do_init_module+0x7c/0x320
        load_module+0x3394/0x3650
        __do_sys_finit_module+0xd4/0x160
        system_call_exception+0x140/0x290
        system_call_common+0xf4/0x258
    
    Fixes: 587164cd593c ("powerpc/powernv: Add new opal message type")
    Cc: stable@vger.kernel.org # v5.4+
    Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211028165716.41300-1-hegdevasant@linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 317cc5bacf69ededbd97d38d6f3bdfa1b9dd3c6b
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Thu Oct 28 23:30:43 2021 +1000

    powerpc/32e: Ignore ESR in instruction storage interrupt handler
    
    commit 81291383ffde08b23bce75e7d6b2575ce9d3475c upstream.
    
    A e5500 machine running a 32-bit kernel sometimes hangs at boot,
    seemingly going into an infinite loop of instruction storage interrupts.
    
    The ESR (Exception Syndrome Register) has a value of 0x800000 (store)
    when this happens, which is likely set by a previous store. An
    instruction TLB miss interrupt would then leave ESR unchanged, and if no
    PTE exists it calls directly to the instruction storage interrupt
    handler without changing ESR.
    
    access_error() does not cause a segfault due to a store to a read-only
    vma because is_exec is true. Most subsequent fault handling does not
    check for a write fault on a read-only vma, and might do strange things
    like create a writeable PTE or call page_mkwrite on a read only vma or
    file. It's not clear what happens here to cause the infinite faulting in
    this case, a fault handler failure or low level PTE or TLB handling.
    
    In any case this can be fixed by having the instruction storage
    interrupt zero regs->dsisr rather than storing the ESR value to it.
    
    Fixes: a01a3f2ddbcd ("powerpc: remove arguments from fault handler functions")
    Cc: stable@vger.kernel.org # v5.12+
    Reported-by: Jacques de Laval <jacques.delaval@protonmail.com>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Tested-by: Jacques de Laval <jacques.delaval@protonmail.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211028133043.4159501-1-npiggin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f657bb66f1e873c74f6ca023a26b329779778f5
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Mon Oct 25 11:26:49 2021 +0530

    powerpc/bpf: Fix write protecting JIT code
    
    commit 44a8214de96bafb5210e43bfa2c97c19bf75af3d upstream.
    
    Running program with bpf-to-bpf function calls results in data access
    exception (0x300) with the below call trace:
    
      bpf_int_jit_compile+0x238/0x750 (unreliable)
      bpf_check+0x2008/0x2710
      bpf_prog_load+0xb00/0x13a0
      __sys_bpf+0x6f4/0x27c0
      sys_bpf+0x2c/0x40
      system_call_exception+0x164/0x330
      system_call_vectored_common+0xe8/0x278
    
    as bpf_int_jit_compile() tries writing to write protected JIT code
    location during the extra pass.
    
    Fix it by holding off write protection of JIT code until the extra
    pass, where branch target addresses fixup happens.
    
    Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code")
    Cc: stable@vger.kernel.org # v5.14+
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211025055649.114728-1-hbathini@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0356cc5d27c239892809dcb97464850d6badbad8
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Oct 15 00:03:45 2021 -0500

    powerpc/vas: Fix potential NULL pointer dereference
    
    commit 61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36 upstream.
    
    (!ptr && !ptr->foo) strikes again. :)
    
    The expression (!ptr && !ptr->foo) is bogus and in case ptr is NULL,
    it leads to a NULL pointer dereference: ptr->foo.
    
    Fix this by converting && to ||
    
    This issue was detected with the help of Coccinelle, and audited and
    fixed manually.
    
    Fixes: 1a0d0d5ed5e3 ("powerpc/vas: Add platform specific user window operations")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211015050345.GA1161918@embeddedor
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b75b27e4e6405a5c96ba4ea93c349168a56a0e99
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:41 2021 +0200

    mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines
    
    commit 7e3cdba176ba59eaf4d463d273da0718e3626140 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac4e55c17cba7ba962d2846dbbf8706e5b6a5bb2
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:46 2021 +0200

    mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines
    
    commit 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 768e8c3b9850780dbffc7c3d3bece2f1829cee1d
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:44 2021 +0200

    mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines
    
    commit 194ac63de6ff56d30c48e3ac19c8a412f9c1408e upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b33e01948fdb5806b73abd25c27d23ff851c98e
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:45 2021 +0200

    mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines
    
    commit f16b7d2a5e810fcf4b15d096246d0d445da9cc88 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9d3d38049d5b91b4a5cd60ea080629214c350a3
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:42 2021 +0200

    mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines
    
    commit b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 365b3fefe51e53ffe1cdaa7d990a6d58990dc932
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:43 2021 +0200

    mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines
    
    commit f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7e59ebde2ece1f0fb87321424916acbe5e313c0
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:48 2021 +0200

    mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines
    
    commit 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Cc: Jan Hoffmann <jan@3e8.eu>
    Cc: Kestrel seventyfour <kestrelseventyfour@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Tested-by: Jan Hoffmann <jan@3e8.eu>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bfee3cd5eb129340fa2e059b661ff15813bae26
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:40 2021 +0200

    mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines
    
    commit d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bedb039360b2a1d7b5d8663ec253ecad68740877
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:15:00 2021 +0200

    mtd: rawnand: fsmc: Fix use of SM ORDER
    
    commit 9be1446ece291a1f08164bd056bed3d698681f8b upstream.
    
    The introduction of the generic ECC engine API lead to a number of
    changes in various drivers which broke some of them. Here is a typical
    example: I expected the SM_ORDER option to be handled by the Hamming ECC
    engine internals. Problem: the fsmc driver does not instantiate (yet) a
    real ECC engine object so we had to use a 'bare' ECC helper instead of
    the shiny rawnand functions. However, when not intializing this engine
    properly and using the bare helpers, we do not get the SM ORDER feature
    handled automatically. It looks like this was lost in the process so
    let's ensure we use the right SM ORDER now.
    
    Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcd526c98adb959f59c8991f1ac2aa95bdf0ea38
Author: Dong Aisheng <aisheng.dong@nxp.com>
Date:   Fri Sep 10 17:06:20 2021 +0800

    remoteproc: imx_rproc: Fix rsc-table name
    
    commit e90547d59d4e29e269e22aa6ce590ed0b41207d2 upstream.
    
    Usually the dash '-'  is preferred in node name.
    So far, not dts in upstream kernel, so we just update node name
    in driver.
    
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Fixes: 5e4c1243071d ("remoteproc: imx_rproc: support remote cores booted before Linux Kernel")
    Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210910090621.3073540-6-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cd861213e11702ba5a5b89c2b8301581f168a8d
Author: Dong Aisheng <aisheng.dong@nxp.com>
Date:   Fri Sep 10 17:06:19 2021 +0800

    remoteproc: imx_rproc: Fix ignoring mapping vdev regions
    
    commit afe670e23af91d8a74a8d7049f6e0984bbf6ea11 upstream.
    
    vdev regions are typically named vdev0buffer, vdev0ring0, vdev0ring1 and
    etc. Change to strncmp to cover them all.
    
    Fixes: 8f2d8961640f ("remoteproc: imx_rproc: ignore mapping vdev regions")
    Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210910090621.3073540-5-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ff5812f164e583bc6621fcd0587030fcd9143b1
Author: Dong Aisheng <aisheng.dong@nxp.com>
Date:   Fri Sep 10 17:06:17 2021 +0800

    remoteproc: Fix the wrong default value of is_iomem
    
    commit 970675f61bf5761d7e5326f6e4df995ecdba5e11 upstream.
    
    Currently the is_iomem is a random value in the stack which may
    be default to true even on those platforms that not use iomem to
    store firmware.
    
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va")
    Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210910090621.3073540-3-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b8ea5da3be52eca04fe2b219c1367841684402b
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Sep 10 17:06:16 2021 +0800

    remoteproc: elf_loader: Fix loading segment when is_iomem true
    
    commit 24acbd9dc934f5d9418a736c532d3970a272063e upstream.
    
    It seems luckliy work on i.MX platform, but it is wrong.
    Need use memcpy_toio, not memcpy_fromio.
    
    Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va")
    Tested-by: Dong Aisheng <aisheng.dong@nxp.com> (i.MX8MQ)
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dong Aisheng <aisheng.dong@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210910090621.3073540-2-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed8b06a0eb8e9a83d7535520d040dcc5a7ebe448
Author: Halil Pasic <pasic@linux.ibm.com>
Date:   Wed Sep 8 17:36:23 2021 +0200

    s390/cio: make ccw_device_dma_* more robust
    
    commit ad9a14517263a16af040598c7920c09ca9670a31 upstream.
    
    Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
    classic notifiers") we were supposed to make sure that
    virtio_ccw_release_dev() completes before the ccw device and the
    attached dma pool are torn down, but unfortunately we did not.  Before
    that commit it used to be OK to delay cleaning up the memory allocated
    by virtio-ccw indefinitely (which isn't really intuitive for guys used
    to destruction happens in reverse construction order), but now we
    trigger a BUG_ON if the genpool is destroyed before all memory allocated
    from it is deallocated. Which brings down the guest. We can observe this
    problem, when unregister_virtio_device() does not give up the last
    reference to the virtio_device (e.g. because a virtio-scsi attached scsi
    disk got removed without previously unmounting its previously mounted
    partition).
    
    To make sure that the genpool is only destroyed after all the necessary
    freeing is done let us take a reference on the ccw device on each
    ccw_device_dma_zalloc() and give it up on each ccw_device_dma_free().
    
    Actually there are multiple approaches to fixing the problem at hand
    that can work. The upside of this one is that it is the safest one while
    remaining simple. We don't crash the guest even if the driver does not
    pair allocations and frees. The downside is the reference counting
    overhead, that the reference counting for ccw devices becomes more
    complex, in a sense that we need to pair the calls to the aforementioned
    functions for it to be correct, and that if we happen to leak, we leak
    more than necessary (the whole ccw device instead of just the genpool).
    
    Some alternatives to this approach are taking a reference in
    virtio_ccw_online() and giving it up in virtio_ccw_release_dev() or
    making sure virtio_ccw_release_dev() completes its work before
    virtio_ccw_remove() returns. The downside of these approaches is that
    these are less safe against programming errors.
    
    Cc: <stable@vger.kernel.org> # v5.3
    Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
    Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and classic notifiers")
    Reported-by: bfu@redhat.com
    Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Acked-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ef2272417f49edcecd349151345378c24ad7b04
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Thu Oct 14 09:58:24 2021 +0200

    s390/ap: Fix hanging ioctl caused by orphaned replies
    
    commit 3826350e6dd435e244eb6e47abad5a47c169ebc2 upstream.
    
    When a queue is switched to soft offline during heavy load and later
    switched to soft online again and now used, it may be that the caller
    is blocked forever in the ioctl call.
    
    The failure occurs because there is a pending reply after the queue(s)
    have been switched to offline. This orphaned reply is received when
    the queue is switched to online and is accidentally counted for the
    outstanding replies. So when there was a valid outstanding reply and
    this orphaned reply is received it counts as the outstanding one thus
    dropping the outstanding counter to 0. Voila, with this counter the
    receive function is not called any more and the real outstanding reply
    is never received (until another request comes in...) and the ioctl
    blocks.
    
    The fix is simple. However, instead of readjusting the counter when an
    orphaned reply is detected, I check the queue status for not empty and
    compare this to the outstanding counter. So if the queue is not empty
    then the counter must not drop to 0 but at least have a value of 1.
    
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3134c317b1b3403adee2cddc39c09e05f4d425c2
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Tue Nov 2 10:55:30 2021 +0100

    s390/tape: fix timer initialization in tape_std_assign()
    
    commit 213fca9e23b59581c573d558aa477556f00b8198 upstream.
    
    commit 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor
    of timer_setup_on_stack()") changed the timer setup from
    init_timer_on_stack(() to timer_setup(), but missed to change the
    mod_timer() call. And while at it, use msecs_to_jiffies() instead
    of the open coded timeout calculation.
    
    Cc: stable@vger.kernel.org
    Fixes: 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()")
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f33bf6015eaff631456e172b3836a622fa01306b
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Fri Nov 5 16:44:51 2021 +0100

    s390/cio: check the subchannel validity for dev_busid
    
    commit a4751f157c194431fae9e9c493f456df8272b871 upstream.
    
    Check the validity of subchanel before reading other fields in
    the schib.
    
    Fixes: d3683c055212 ("s390/cio: add dev_busid sysfs entry for each subchannel")
    CC: <stable@vger.kernel.org>
    Reported-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Link: https://lore.kernel.org/r/20211105154451.847288-1-vneethv@linux.ibm.com
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32f71f36808612dd829bc20957b802dd698c2e27
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Wed Nov 3 13:13:04 2021 +0100

    s390/cpumf: cpum_cf PMU displays invalid value after hotplug remove
    
    commit 9d48c7afedf91a02d03295837ec76b2fb5e7d3fe upstream.
    
    When a CPU is hotplugged while the perf stat -e cycles command is
    running, a wrong (very large) value is displayed immediately after the
    CPU removal:
    
      Check the values, shouldn't be too high as in
                time             counts unit events
         1.001101919           29261846      cycles
         2.002454499           17523405      cycles
         3.003659292           24361161      cycles
         4.004816983 18446744073638406144      cycles
         5.005671647      <not counted>      cycles
         ...
    
    The CPU hotplug off took place after 3 seconds.
    The issue is the read of the event count value after 4 seconds when
    the CPU is not available and the read of the counter returns an
    error. This is treated as a counter value of zero. This results
    in a very large value (0 - previous_value).
    
    Fix this by detecting the hotplugged off CPU and report 0 instead
    of a very large number.
    
    Cc: stable@vger.kernel.org
    Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility")
    Reported-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 051d89f4dec2bce37a8d5471b0b1ef2796901858
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Nov 4 18:26:26 2021 +0100

    PM: sleep: Avoid calling put_device() under dpm_list_mtx
    
    commit 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 upstream.
    
    It is generally unsafe to call put_device() with dpm_list_mtx held,
    because the given device's release routine may carry out an action
    depending on that lock which then may deadlock, so modify the
    system-wide suspend and resume of devices to always drop dpm_list_mtx
    before calling put_device() (and adjust white space somewhat while
    at it).
    
    For instance, this prevents the following splat from showing up in
    the kernel log after a system resume in certain configurations:
    
    [ 3290.969514] ======================================================
    [ 3290.969517] WARNING: possible circular locking dependency detected
    [ 3290.969519] 5.15.0+ #2420 Tainted: G S
    [ 3290.969523] ------------------------------------------------------
    [ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
    [ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
    [ 3290.969554]
                   but task is already holding lock:
    [ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
    [ 3290.969571]
                   which lock already depends on the new lock.
    
    [ 3290.969573]
                   the existing dependency chain (in reverse order) is:
    [ 3290.969575]
                   -> #3 (dpm_list_mtx){+.+.}-{3:3}:
    [ 3290.969583]        __mutex_lock+0x9d/0xa30
    [ 3290.969591]        device_pm_add+0x2e/0xe0
    [ 3290.969597]        device_add+0x4d5/0x8f0
    [ 3290.969605]        hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
    [ 3290.969689]        hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
    [ 3290.969747]        hci_event_packet+0xd6c/0x28a0 [bluetooth]
    [ 3290.969798]        hci_rx_work+0x213/0x640 [bluetooth]
    [ 3290.969842]        process_one_work+0x2aa/0x650
    [ 3290.969851]        worker_thread+0x39/0x400
    [ 3290.969859]        kthread+0x142/0x170
    [ 3290.969865]        ret_from_fork+0x22/0x30
    [ 3290.969872]
                   -> #2 (&hdev->lock){+.+.}-{3:3}:
    [ 3290.969881]        __mutex_lock+0x9d/0xa30
    [ 3290.969887]        hci_event_packet+0xba/0x28a0 [bluetooth]
    [ 3290.969935]        hci_rx_work+0x213/0x640 [bluetooth]
    [ 3290.969978]        process_one_work+0x2aa/0x650
    [ 3290.969985]        worker_thread+0x39/0x400
    [ 3290.969993]        kthread+0x142/0x170
    [ 3290.969999]        ret_from_fork+0x22/0x30
    [ 3290.970004]
                   -> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
    [ 3290.970013]        process_one_work+0x27d/0x650
    [ 3290.970020]        worker_thread+0x39/0x400
    [ 3290.970028]        kthread+0x142/0x170
    [ 3290.970033]        ret_from_fork+0x22/0x30
    [ 3290.970038]
                   -> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
    [ 3290.970047]        __lock_acquire+0x15cb/0x1b50
    [ 3290.970054]        lock_acquire+0x26c/0x300
    [ 3290.970059]        flush_workqueue+0xae/0x4a0
    [ 3290.970066]        drain_workqueue+0xa1/0x130
    [ 3290.970073]        destroy_workqueue+0x34/0x1f0
    [ 3290.970081]        hci_release_dev+0x49/0x180 [bluetooth]
    [ 3290.970130]        bt_host_release+0x1d/0x30 [bluetooth]
    [ 3290.970195]        device_release+0x33/0x90
    [ 3290.970201]        kobject_release+0x63/0x160
    [ 3290.970211]        dpm_resume+0x164/0x3e0
    [ 3290.970215]        dpm_resume_end+0xd/0x20
    [ 3290.970220]        suspend_devices_and_enter+0x1a4/0xba0
    [ 3290.970229]        pm_suspend+0x26b/0x310
    [ 3290.970236]        state_store+0x42/0x90
    [ 3290.970243]        kernfs_fop_write_iter+0x135/0x1b0
    [ 3290.970251]        new_sync_write+0x125/0x1c0
    [ 3290.970257]        vfs_write+0x360/0x3c0
    [ 3290.970263]        ksys_write+0xa7/0xe0
    [ 3290.970269]        do_syscall_64+0x3a/0x80
    [ 3290.970276]        entry_SYSCALL_64_after_hwframe+0x44/0xae
    [ 3290.970284]
                   other info that might help us debug this:
    
    [ 3290.970285] Chain exists of:
                     (wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
    
    [ 3290.970297]  Possible unsafe locking scenario:
    
    [ 3290.970299]        CPU0                    CPU1
    [ 3290.970300]        ----                    ----
    [ 3290.970302]   lock(dpm_list_mtx);
    [ 3290.970306]                                lock(&hdev->lock);
    [ 3290.970310]                                lock(dpm_list_mtx);
    [ 3290.970314]   lock((wq_completion)hci0#2);
    [ 3290.970319]
                    *** DEADLOCK ***
    
    [ 3290.970321] 7 locks held by systemd-sleep/4553:
    [ 3290.970325]  #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
    [ 3290.970341]  #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
    [ 3290.970355]  #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
    [ 3290.970369]  #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
    [ 3290.970384]  #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
    [ 3290.970399]  #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
    [ 3290.970416]  #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
    [ 3290.970428]
                   stack backtrace:
    [ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S                5.15.0+ #2420
    [ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
    [ 3290.970441] Call Trace:
    [ 3290.970446]  dump_stack_lvl+0x44/0x57
    [ 3290.970454]  check_noncircular+0x105/0x120
    [ 3290.970468]  ? __lock_acquire+0x15cb/0x1b50
    [ 3290.970474]  __lock_acquire+0x15cb/0x1b50
    [ 3290.970487]  lock_acquire+0x26c/0x300
    [ 3290.970493]  ? flush_workqueue+0x87/0x4a0
    [ 3290.970503]  ? __raw_spin_lock_init+0x3b/0x60
    [ 3290.970510]  ? lockdep_init_map_type+0x58/0x240
    [ 3290.970519]  flush_workqueue+0xae/0x4a0
    [ 3290.970526]  ? flush_workqueue+0x87/0x4a0
    [ 3290.970544]  ? drain_workqueue+0xa1/0x130
    [ 3290.970552]  drain_workqueue+0xa1/0x130
    [ 3290.970561]  destroy_workqueue+0x34/0x1f0
    [ 3290.970572]  hci_release_dev+0x49/0x180 [bluetooth]
    [ 3290.970624]  bt_host_release+0x1d/0x30 [bluetooth]
    [ 3290.970687]  device_release+0x33/0x90
    [ 3290.970695]  kobject_release+0x63/0x160
    [ 3290.970705]  dpm_resume+0x164/0x3e0
    [ 3290.970710]  ? dpm_resume_early+0x251/0x3b0
    [ 3290.970718]  dpm_resume_end+0xd/0x20
    [ 3290.970723]  suspend_devices_and_enter+0x1a4/0xba0
    [ 3290.970737]  pm_suspend+0x26b/0x310
    [ 3290.970746]  state_store+0x42/0x90
    [ 3290.970755]  kernfs_fop_write_iter+0x135/0x1b0
    [ 3290.970764]  new_sync_write+0x125/0x1c0
    [ 3290.970777]  vfs_write+0x360/0x3c0
    [ 3290.970785]  ksys_write+0xa7/0xe0
    [ 3290.970794]  do_syscall_64+0x3a/0x80
    [ 3290.970803]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [ 3290.970811] RIP: 0033:0x7f41b1328164
    [ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
    [ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
    [ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
    [ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
    [ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
    [ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
    
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac8ffb5d9dfbdb965f72732a0e214cfcdc8eb44c
Author: Coly Li <colyli@suse.de>
Date:   Wed Nov 3 23:10:41 2021 +0800

    bcache: Revert "bcache: use bvec_virt"
    
    commit 2878feaed543c35f9dbbe6d8ce36fb67ac803eef upstream.
    
    This reverts commit 2fd3e5efe791946be0957c8e1eed9560b541fe46.
    
    The above commit replaces page_address(bv->bv_page) by bvec_virt(bv) to
    avoid directly access to bv->bv_page, but in situation bv->bv_offset is
    not zero and page_address(bv->bv_page) is not equal to bvec_virt(bv). In
    such case a memory corruption may happen because memory in next page is
    tainted by following line in do_btree_node_write(),
            memcpy(bvec_virt(bv), addr, PAGE_SIZE);
    
    This patch reverts the mentioned commit to avoid the memory corruption.
    
    Fixes: 2fd3e5efe791 ("bcache: use bvec_virt")
    Signed-off-by: Coly Li <colyli@suse.de>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: stable@vger.kernel.org # 5.15
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20211103151041.70516-1-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6a300977ac9fd714303049a37e0f5f74ef5e6c9
Author: Coly Li <colyli@suse.de>
Date:   Wed Nov 3 14:49:17 2021 +0800

    bcache: fix use-after-free problem in bcache_device_free()
    
    commit 8468f45091d2866affed6f6a7aecc20779139173 upstream.
    
    In bcache_device_free(), pointer disk is referenced still in
    ida_simple_remove() after blk_cleanup_disk() gets called on this
    pointer. This may cause a potential panic by use-after-free on the
    disk pointer.
    
    This patch fixes the problem by calling blk_cleanup_disk() after
    ida_simple_remove().
    
    Fixes: bc70852fd104 ("bcache: convert to blk_alloc_disk/blk_cleanup_disk")
    Signed-off-by: Coly Li <colyli@suse.de>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Ulf Hansson <ulf.hansson@linaro.org>
    Cc: stable@vger.kernel.org # v5.14+
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20211103064917.67383-1-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a958d144754e6090ef321b2ec4e53c51048bc35f
Author: Marek Vasut <marex@denx.de>
Date:   Tue Sep 21 19:35:06 2021 +0200

    video: backlight: Drop maximum brightness override for brightness zero
    
    commit 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa upstream.
    
    The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
    in backlight.c") says that gpio-backlight uses brightness as power state.
    This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight:
    Correct initial power state handling") and other backlight drivers do not
    require this workaround. Drop the workaround.
    
    This fixes the case where e.g. pwm-backlight can perfectly well be set to
    brightness 0 on boot in DT, which without this patch leads to the display
    brightness to be max instead of off.
    
    Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c")
    Cc: <stable@vger.kernel.org> # 5.4+
    Cc: <stable@vger.kernel.org> # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling
    Signed-off-by: Marek Vasut <marex@denx.de>
    Acked-by: Noralf Trønnes <noralf@tronnes.org>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9dad32cb55e179cd424c0ca55c836db35eac991
Author: Jack Andersen <jackoalan@gmail.com>
Date:   Mon Oct 18 13:25:41 2021 +0200

    mfd: dln2: Add cell for initializing DLN2 ADC
    
    commit 313c84b5ae4104e48c661d5d706f9f4c425fd50f upstream.
    
    This patch extends the DLN2 driver; adding cell for adc_dln2 module.
    
    The original patch[1] fell through the cracks when the driver was added
    so ADC has never actually been usable. That patch did not have ACPI
    support which was added in v5.9, so the oldest supported version this
    current patch can be backported to is 5.10.
    
    [1] https://www.spinics.net/lists/linux-iio/msg33975.html
    
    Cc: <stable@vger.kernel.org> # 5.10+
    Signed-off-by: Jack Andersen <jackoalan@gmail.com>
    Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20211018112541.25466-1-noralf@tronnes.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ea871f0d8e0008d0707763af2bcf55689994d64
Author: Rongwei Wang <rongwei.wang@linux.alibaba.com>
Date:   Fri Nov 5 13:43:44 2021 -0700

    mm, thp: fix incorrect unmap behavior for private pages
    
    commit 8468e937df1f31411d1e127fa38db064af051fe5 upstream.
    
    When truncating pagecache on file THP, the private pages of a process
    should not be unmapped mapping.  This incorrect behavior on a dynamic
    shared libraries which will cause related processes to happen core dump.
    
    A simple test for a DSO (Prerequisite is the DSO mapped in file THP):
    
        int main(int argc, char *argv[])
        {
            int fd;
    
            fd = open(argv[1], O_WRONLY);
            if (fd < 0) {
                    perror("open");
            }
    
            close(fd);
            return 0;
        }
    
    The test only to open a target DSO, and do nothing.  But this operation
    will lead one or more process to happen core dump.  This patch mainly to
    fix this bug.
    
    Link: https://lkml.kernel.org/r/20211025092134.18562-3-rongwei.wang@linux.alibaba.com
    Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs")
    Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
    Tested-by: Xu Yu <xuyu@linux.alibaba.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Song Liu <song@kernel.org>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Collin Fijalkovich <cfijalkovich@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd8e972dc4277638ff19e7dd9c595ebb6961c5d2
Author: Rongwei Wang <rongwei.wang@linux.alibaba.com>
Date:   Fri Nov 5 13:43:41 2021 -0700

    mm, thp: lock filemap when truncating page cache
    
    commit 55fc0d91746759c71bc165bba62a2db64ac98e35 upstream.
    
    Patch series "fix two bugs for file THP".
    
    This patch (of 2):
    
    Transparent huge page has supported read-only non-shmem files.  The
    file- backed THP is collapsed by khugepaged and truncated when written
    (for shared libraries).
    
    However, there is a race when multiple writers truncate the same page
    cache concurrently.
    
    In that case, subpage(s) of file THP can be revealed by find_get_entry
    in truncate_inode_pages_range, which will trigger PageTail BUG_ON in
    truncate_inode_page, as follows:
    
        page:000000009e420ff2 refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff pfn:0x50c3ff
        head:0000000075ff816d order:9 compound_mapcount:0 compound_pincount:0
        flags: 0x37fffe0000010815(locked|uptodate|lru|arch_1|head)
        raw: 37fffe0000000000 fffffe0013108001 dead000000000122 dead000000000400
        raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
        head: 37fffe0000010815 fffffe001066bd48 ffff000404183c20 0000000000000000
        head: 0000000000000600 0000000000000000 00000001ffffffff ffff000c0345a000
        page dumped because: VM_BUG_ON_PAGE(PageTail(page))
        ------------[ cut here ]------------
        kernel BUG at mm/truncate.c:213!
        Internal error: Oops - BUG: 0 [#1] SMP
        Modules linked in: xfs(E) libcrc32c(E) rfkill(E) ...
        CPU: 14 PID: 11394 Comm: check_madvise_d Kdump: ...
        Hardware name: ECS, BIOS 0.0.0 02/06/2015
        pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
        Call trace:
         truncate_inode_page+0x64/0x70
         truncate_inode_pages_range+0x550/0x7e4
         truncate_pagecache+0x58/0x80
         do_dentry_open+0x1e4/0x3c0
         vfs_open+0x38/0x44
         do_open+0x1f0/0x310
         path_openat+0x114/0x1dc
         do_filp_open+0x84/0x134
         do_sys_openat2+0xbc/0x164
         __arm64_sys_openat+0x74/0xc0
         el0_svc_common.constprop.0+0x88/0x220
         do_el0_svc+0x30/0xa0
         el0_svc+0x20/0x30
         el0_sync_handler+0x1a4/0x1b0
         el0_sync+0x180/0x1c0
        Code: aa0103e0 900061e1 910ec021 9400d300 (d4210000)
    
    This patch mainly to lock filemap when one enter truncate_pagecache(),
    avoiding truncating the same page cache concurrently.
    
    Link: https://lkml.kernel.org/r/20211025092134.18562-1-rongwei.wang@linux.alibaba.com
    Link: https://lkml.kernel.org/r/20211025092134.18562-2-rongwei.wang@linux.alibaba.com
    Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs")
    Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
    Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
    Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Tested-by: Song Liu <song@kernel.org>
    Cc: Collin Fijalkovich <cfijalkovich@google.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c15aeead2488b3b28db6863f9f2ba2338e3c9838
Author: Michal Hocko <mhocko@suse.com>
Date:   Fri Nov 5 13:38:06 2021 -0700

    mm, oom: do not trigger out_of_memory from the #PF
    
    commit 60e2793d440a3ec95abb5d6d4fc034a4b480472d upstream.
    
    Any allocation failure during the #PF path will return with VM_FAULT_OOM
    which in turn results in pagefault_out_of_memory.  This can happen for 2
    different reasons.  a) Memcg is out of memory and we rely on
    mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
    normal allocation fails.
    
    The latter is quite problematic because allocation paths already trigger
    out_of_memory and the page allocator tries really hard to not fail
    allocations.  Anyway, if the OOM killer has been already invoked there
    is no reason to invoke it again from the #PF path.  Especially when the
    OOM condition might be gone by that time and we have no way to find out
    other than allocate.
    
    Moreover if the allocation failed and the OOM killer hasn't been invoked
    then we are unlikely to do the right thing from the #PF context because
    we have already lost the allocation context and restictions and
    therefore might oom kill a task from a different NUMA domain.
    
    This all suggests that there is no legitimate reason to trigger
    out_of_memory from pagefault_out_of_memory so drop it.  Just to be sure
    that no #PF path returns with VM_FAULT_OOM without allocation print a
    warning that this is happening before we restart the #PF.
    
    [VvS: #PF allocation can hit into limit of cgroup v1 kmem controller.
    This is a local problem related to memcg, however, it causes unnecessary
    global OOM kills that are repeated over and over again and escalate into a
    real disaster.  This has been broken since kmem accounting has been
    introduced for cgroup v1 (3.8).  There was no kmem specific reclaim for
    the separate limit so the only way to handle kmem hard limit was to return
    with ENOMEM.  In upstream the problem will be fixed by removing the
    outdated kmem limit, however stable and LTS kernels cannot do it and are
    still affected.  This patch fixes the problem and should be backported
    into stable/LTS.]
    
    Link: https://lkml.kernel.org/r/f5fd8dd8-0ad4-c524-5f65-920b01972a42@virtuozzo.com
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Cc: Uladzislau Rezki <urezki@gmail.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 487a4c60c5937e1ef8614ce0e1c604b5251132c1
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Fri Nov 5 13:38:02 2021 -0700

    mm, oom: pagefault_out_of_memory: don't force global OOM for dying tasks
    
    commit 0b28179a6138a5edd9d82ad2687c05b3773c387b upstream.
    
    Patch series "memcg: prohibit unconditional exceeding the limit of dying tasks", v3.
    
    Memory cgroup charging allows killed or exiting tasks to exceed the hard
    limit.  It can be misused and allowed to trigger global OOM from inside
    a memcg-limited container.  On the other hand if memcg fails allocation,
    called from inside #PF handler it triggers global OOM from inside
    pagefault_out_of_memory().
    
    To prevent these problems this patchset:
     (a) removes execution of out_of_memory() from
         pagefault_out_of_memory(), becasue nobody can explain why it is
         necessary.
     (b) allow memcg to fail allocation of dying/killed tasks.
    
    This patch (of 3):
    
    Any allocation failure during the #PF path will return with VM_FAULT_OOM
    which in turn results in pagefault_out_of_memory which in turn executes
    out_out_memory() and can kill a random task.
    
    An allocation might fail when the current task is the oom victim and
    there are no memory reserves left.  The OOM killer is already handled at
    the page allocator level for the global OOM and at the charging level
    for the memcg one.  Both have much more information about the scope of
    allocation/charge request.  This means that either the OOM killer has
    been invoked properly and didn't lead to the allocation success or it
    has been skipped because it couldn't have been invoked.  In both cases
    triggering it from here is pointless and even harmful.
    
    It makes much more sense to let the killed task die rather than to wake
    up an eternally hungry oom-killer and send him to choose a fatter victim
    for breakfast.
    
    Link: https://lkml.kernel.org/r/0828a149-786e-7c06-b70a-52d086818ea3@virtuozzo.com
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Suggested-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Cc: Uladzislau Rezki <urezki@gmail.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1e83db27ad5b3558caee86a38faf0501902931f
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Fri Nov 5 13:38:09 2021 -0700

    memcg: prohibit unconditional exceeding the limit of dying tasks
    
    commit a4ebf1b6ca1e011289677239a2a361fde4a88076 upstream.
    
    Memory cgroup charging allows killed or exiting tasks to exceed the hard
    limit.  It is assumed that the amount of the memory charged by those
    tasks is bound and most of the memory will get released while the task
    is exiting.  This is resembling a heuristic for the global OOM situation
    when tasks get access to memory reserves.  There is no global memory
    shortage at the memcg level so the memcg heuristic is more relieved.
    
    The above assumption is overly optimistic though.  E.g.  vmalloc can
    scale to really large requests and the heuristic would allow that.  We
    used to have an early break in the vmalloc allocator for killed tasks
    but this has been reverted by commit b8c8a338f75e ("Revert "vmalloc:
    back off when the current task is killed"").  There are likely other
    similar code paths which do not check for fatal signals in an
    allocation&charge loop.  Also there are some kernel objects charged to a
    memcg which are not bound to a process life time.
    
    It has been observed that it is not really hard to trigger these
    bypasses and cause global OOM situation.
    
    One potential way to address these runaways would be to limit the amount
    of excess (similar to the global OOM with limited oom reserves).  This
    is certainly possible but it is not really clear how much of an excess
    is desirable and still protects from global OOMs as that would have to
    consider the overall memcg configuration.
    
    This patch is addressing the problem by removing the heuristic
    altogether.  Bypass is only allowed for requests which either cannot
    fail or where the failure is not desirable while excess should be still
    limited (e.g.  atomic requests).  Implementation wise a killed or dying
    task fails to charge if it has passed the OOM killer stage.  That should
    give all forms of reclaim chance to restore the limit before the failure
    (ENOMEM) and tell the caller to back off.
    
    In addition, this patch renames should_force_charge() helper to
    task_is_dying() because now its use is not associated witch forced
    charging.
    
    This patch depends on pagefault_out_of_memory() to not trigger
    out_of_memory(), because then a memcg failure can unwind to VM_FAULT_OOM
    and cause a global OOM killer.
    
    Link: https://lkml.kernel.org/r/8f5cebbb-06da-4902-91f0-6566fc4b4203@virtuozzo.com
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Suggested-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Uladzislau Rezki <urezki@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6560e8cd869b643f674d8fa3ae9243af1d8ba29a
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Fri Nov 5 13:37:10 2021 -0700

    mm/filemap.c: remove bogus VM_BUG_ON
    
    commit d417b49fff3e2f21043c834841e8623a6098741d upstream.
    
    It is not safe to check page->index without holding the page lock.  It
    can be changed if the page is moved between the swap cache and the page
    cache for a shmem file, for example.  There is a VM_BUG_ON below which
    checks page->index is correct after taking the page lock.
    
    Link: https://lkml.kernel.org/r/20210818144932.940640-1-willy@infradead.org
    Fixes: 5c211ba29deb ("mm: add and use find_lock_entries")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reported-by: <syzbot+c87be4f669d920c76330@syzkaller.appspotmail.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6847c42862972538de4b002de5e82945743d6e35
Author: Dominique Martinet <asmadeus@codewreck.org>
Date:   Tue Nov 2 19:47:47 2021 +0900

    9p/net: fix missing error check in p9_check_errors
    
    commit 27eb4c3144f7a5ebef3c9a261d80cb3e1fa784dc upstream.
    
    Link: https://lkml.kernel.org/r/99338965-d36c-886e-cd0e-1d8fff2b4746@gmail.com
    Reported-by: syzbot+06472778c97ed94af66d@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f03911876ab9c0bc6f149d4b4d6ea2ac43bc194
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Mon Oct 11 14:12:36 2021 +0200

    net, neigh: Enable state migration between NUD_PERMANENT and NTF_USE
    
    [ Upstream commit 3dc20f4762c62d3b3f0940644881ed818aa7b2f5 ]
    
    Currently, it is not possible to migrate a neighbor entry between NUD_PERMANENT
    state and NTF_USE flag with a dynamic NUD state from a user space control plane.
    Similarly, it is not possible to add/remove NTF_EXT_LEARNED flag from an existing
    neighbor entry in combination with NTF_USE flag.
    
    This is due to the latter directly calling into neigh_event_send() without any
    meta data updates as happening in __neigh_update(). Thus, to enable this use
    case, extend the latter with a NEIGH_UPDATE_F_USE flag where we break the
    NUD_PERMANENT state in particular so that a latter neigh_event_send() is able
    to re-resolve a neighbor entry.
    
    Before fix, NUD_PERMANENT -> NUD_* & NTF_USE:
    
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT
      [...]
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT
      [...]
    
    As can be seen, despite the admin-triggered replace, the entry remains in the
    NUD_PERMANENT state.
    
    After fix, NUD_PERMANENT -> NUD_* & NTF_USE:
    
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT
      [...]
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE
      [...]
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn STALE
      [...]
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT
      [...]
    
    After the fix, the admin-triggered replace switches to a dynamic state from
    the NTF_USE flag which triggered a new neighbor resolution. Likewise, we can
    transition back from there, if needed, into NUD_PERMANENT.
    
    Similar before/after behavior can be observed for below transitions:
    
    Before fix, NTF_USE -> NTF_USE | NTF_EXT_LEARNED -> NTF_USE:
    
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
      [...]
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
      [...]
    
    After fix, NTF_USE -> NTF_USE | NTF_EXT_LEARNED -> NTF_USE:
    
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
      [...]
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE
      [...]
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
      [..]
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Roopa Prabhu <roopa@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a85f01a89efbedcc217997129eff404b9870078
Author: Anatolij Gustschin <agust@denx.de>
Date:   Thu Oct 14 11:40:12 2021 +0200

    dmaengine: bestcomm: fix system boot lockups
    
    commit adec566b05288f2787a1f88dbaf77ed8b0c644fa upstream.
    
    memset() and memcpy() on an MMIO region like here results in a
    lockup at startup on mpc5200 platform (since this first happens
    during probing of the ATA and Ethernet drivers). Use memset_io()
    and memcpy_toio() instead.
    
    Fixes: 2f9ea1bde0d1 ("bestcomm: core bestcomm support for Freescale MPC5200")
    Cc: stable@vger.kernel.org # v5.14+
    Signed-off-by: Anatolij Gustschin <agust@denx.de>
    Link: https://lore.kernel.org/r/20211014094012.21286-1-agust@denx.de
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4cd9e5acc34735e344b0cc03a8f27cc0b4fa0b3
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Sun Oct 31 08:54:11 2021 +0530

    dmaengine: ti: k3-udma: Set r/tchan or rflow to NULL if request fail
    
    commit eb91224e47ec33a0a32c9be0ec0fcb3433e555fd upstream.
    
    udma_get_*() checks if rchan/tchan/rflow is already allocated by checking
    if it has a NON NULL value. For the error cases, rchan/tchan/rflow will
    have error value and udma_get_*() considers this as already allocated
    (PASS) since the error values are NON NULL. This results in NULL pointer
    dereference error while de-referencing rchan/tchan/rflow.
    
    Reset the value of rchan/tchan/rflow to NULL if a channel request fails.
    
    CC: stable@vger.kernel.org
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Link: https://lore.kernel.org/r/20211031032411.27235-3-kishon@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68ae6ae1431f0fb6af514b97aec0792e61c55d34
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Sun Oct 31 08:54:10 2021 +0530

    dmaengine: ti: k3-udma: Set bchan to NULL if a channel request fail
    
    commit 5c6c6d60e4b489308ae4da8424c869f7cc53cd12 upstream.
    
    bcdma_get_*() checks if bchan is already allocated by checking if it
    has a NON NULL value. For the error cases, bchan will have error value
    and bcdma_get_*() considers this as already allocated (PASS) since the
    error values are NON NULL. This results in NULL pointer dereference
    error while de-referencing bchan.
    
    Reset the value of bchan to NULL if a channel request fails.
    
    CC: stable@vger.kernel.org
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Link: https://lore.kernel.org/r/20211031032411.27235-2-kishon@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dd578e985604d317756349a8f2b71959aeea324
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Fri Oct 29 08:09:50 2021 +0900

    ksmbd: don't need 8byte alignment for request length in ksmbd_check_message
    
    commit b53ad8107ee873795ecb5039d46b5d5502d404f2 upstream.
    
    When validating request length in ksmbd_check_message, 8byte alignment
    is not needed for compound request. It can cause wrong validation
    of request length.
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org # v5.15
    Acked-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aacb2ddb67fb3f235ec7582497f870a58962273b
Author: Marios Makassikis <mmakassikis@freebox.fr>
Date:   Thu Oct 28 21:01:27 2021 +0200

    ksmbd: Fix buffer length check in fsctl_validate_negotiate_info()
    
    commit 78f1688a64cca77758ceb9b183088cf0054bfc82 upstream.
    
    The validate_negotiate_info_req struct definition includes an extra
    field to access the data coming after the header. This causes the check
    in fsctl_validate_negotiate_info() to count the first element of the
    array twice. This in turn makes some valid requests fail, depending on
    whether they include padding or not.
    
    Fixes: f7db8fd03a4b ("ksmbd: add validation in smb2_ioctl")
    Cc: stable@vger.kernel.org # v5.15
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Acked-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Marios Makassikis <mmakassikis@freebox.fr>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e84e9d61dba1f3f91a979b4e510bdea80ece17e
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date:   Thu Nov 11 17:52:38 2021 +0900

    block: Hold invalidate_lock in BLKRESETZONE ioctl
    
    commit 86399ea071099ec8ee0a83ac9ad67f7df96a50ad upstream.
    
    When BLKRESETZONE ioctl and data read race, the data read leaves stale
    page cache. The commit e5113505904e ("block: Discard page cache of zone
    reset target range") added page cache truncation to avoid stale page
    cache after the ioctl. However, the stale page cache still can be read
    during the reset zone operation for the ioctl. To avoid the stale page
    cache completely, hold invalidate_lock of the block device file mapping.
    
    Fixes: e5113505904e ("block: Discard page cache of zone reset target range")
    Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Cc: stable@vger.kernel.org # v5.15
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20211111085238.942492-1-shinichiro.kawasaki@wdc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 373c2bfecb064f0e5bb7f7fffa5d1f2e5f9e5571
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date:   Tue Nov 9 19:47:23 2021 +0900

    block: Hold invalidate_lock in BLKZEROOUT ioctl
    
    commit 35e4c6c1a2fc2eb11b9306e95cda1fa06a511948 upstream.
    
    When BLKZEROOUT ioctl and data read race, the data read leaves stale
    page cache. To avoid the stale page cache, hold invalidate_lock of the
    block device file mapping. The stale page cache is observed when
    blktests test case block/009 is modified to call "blkdiscard -z" command
    and repeated hundreds of times.
    
    This patch can be applied back to the stable kernel version v5.15.y.
    Rework is required for older stable kernels.
    
    Fixes: 22dd6d356628 ("block: invalidate the page cache when issuing BLKZEROOUT")
    Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Cc: stable@vger.kernel.org # v5.15
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20211109104723.835533-3-shinichiro.kawasaki@wdc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9bed86a35a0cbc72196fe966644876d4279624f
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date:   Tue Nov 9 19:47:22 2021 +0900

    block: Hold invalidate_lock in BLKDISCARD ioctl
    
    commit 7607c44c157d343223510c8ffdf7206fdd2a6213 upstream.
    
    When BLKDISCARD ioctl and data read race, the data read leaves stale
    page cache. To avoid the stale page cache, hold invalidate_lock of the
    block device file mapping. The stale page cache is observed when
    blktests test case block/009 is repeated hundreds of times.
    
    This patch can be applied back to the stable kernel version v5.15.y
    with slight patch edit. Rework is required for older stable kernels.
    
    Fixes: 351499a172c0 ("block: Invalidate cache on discard v2")
    Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Cc: stable@vger.kernel.org # v5.15
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20211109104723.835533-2-shinichiro.kawasaki@wdc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 876d6242d225f6be20e70746dfe7c4baabe99158
Author: Matthew Brost <matthew.brost@intel.com>
Date:   Thu Sep 9 09:47:22 2021 -0700

    drm/i915/guc: Fix blocked context accounting
    
    commit fc30a6764a54dea42291aeb7009bef7aa2fc1cd4 upstream.
    
    Prior to this patch the blocked context counter was cleared on
    init_sched_state (used during registering a context & resets) which is
    incorrect. This state needs to be persistent or the counter can read the
    incorrect value resulting in scheduling never getting enabled again.
    
    Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-2-matthew.brost@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6097896991072ca91c5c36e5de7d3b3db74ba79
Author: Gao Xiang <hsiangkao@linux.alibaba.com>
Date:   Thu Nov 4 02:20:06 2021 +0800

    erofs: fix unsafe pagevec reuse of hooked pclusters
    
    commit 86432a6dca9bed79111990851df5756d3eb5f57c upstream.
    
    There are pclusters in runtime marked with Z_EROFS_PCLUSTER_TAIL
    before actual I/O submission. Thus, the decompression chain can be
    extended if the following pcluster chain hooks such tail pcluster.
    
    As the related comment mentioned, if some page is made of a hooked
    pcluster and another followed pcluster, it can be reused for in-place
    I/O (since I/O should be submitted anyway):
     _______________________________________________________________
    |  tail (partial) page |          head (partial) page           |
    |_____PRIMARY_HOOKED___|____________PRIMARY_FOLLOWED____________|
    
    However, it's by no means safe to reuse as pagevec since if such
    PRIMARY_HOOKED pclusters finally move into bypass chain without I/O
    submission. It's somewhat hard to reproduce with LZ4 and I just found
    it (general protection fault) by ro_fsstressing a LZMA image for long
    time.
    
    I'm going to actively clean up related code together with multi-page
    folio adaption in the next few months. Let's address it directly for
    easier backporting for now.
    
    Call trace for reference:
      z_erofs_decompress_pcluster+0x10a/0x8a0 [erofs]
      z_erofs_decompress_queue.isra.36+0x3c/0x60 [erofs]
      z_erofs_runqueue+0x5f3/0x840 [erofs]
      z_erofs_readahead+0x1e8/0x320 [erofs]
      read_pages+0x91/0x270
      page_cache_ra_unbounded+0x18b/0x240
      filemap_get_pages+0x10a/0x5f0
      filemap_read+0xa9/0x330
      new_sync_read+0x11b/0x1a0
      vfs_read+0xf1/0x190
    
    Link: https://lore.kernel.org/r/20211103182006.4040-1-xiang@kernel.org
    Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
    Cc: <stable@vger.kernel.org> # 4.19+
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11a102de53a7403252d50de4acdfafd47d734fad
Author: Xiubo Li <xiubli@redhat.com>
Date:   Fri Nov 5 17:34:18 2021 +0800

    ceph: fix mdsmap decode when there are MDS's beyond max_mds
    
    commit 0e24421ac431e7af62d4acef6c638b85aae51728 upstream.
    
    If the max_mds is decreased in a cephfs cluster, there is a window
    of time before the MDSs are removed. If a map goes out during this
    period, the mdsmap may show the decreased max_mds but still shows
    those MDSes as in or in the export target list.
    
    Ensure that we don't fail the map decode in that case.
    
    Cc: stable@vger.kernel.org
    URL: https://tracker.ceph.com/issues/52436
    Fixes: d517b3983dd3 ("ceph: reconnect to the export targets on new mdsmaps")
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e1b901dd470659bcfeaa76811d2af9165579d77
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Thu Nov 4 16:22:01 2021 +0800

    f2fs: fix UAF in f2fs_available_free_memory
    
    commit 5429c9dbc9025f9a166f64e22e3a69c94fd5b29b upstream.
    
    if2fs_fill_super
    -> f2fs_build_segment_manager
       -> create_discard_cmd_control
          -> f2fs_start_discard_thread
    
    It invokes kthread_run to create a thread and run issue_discard_thread.
    
    However, if f2fs_build_node_manager fails, the control flow goes to
    free_nm and calls f2fs_destroy_node_manager. This function will free
    sbi->nm_info. However, if issue_discard_thread accesses sbi->nm_info
    after the deallocation, but before the f2fs_stop_discard_thread, it will
    cause UAF(Use-after-free).
    
    -> f2fs_destroy_segment_manager
       -> destroy_discard_cmd_control
          -> f2fs_stop_discard_thread
    
    Fix this by stopping discard thread before f2fs_destroy_node_manager.
    
    Note that, the commit d6d2b491a82e1 introduces the call of
    f2fs_available_free_memory into issue_discard_thread.
    
    Cc: stable@vger.kernel.org
    Fixes: d6d2b491a82e ("f2fs: allow to change discard policy based on cached discard cmds")
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fd542665e701179b946b1cb4e4f21593ea8ec7a
Author: Daeho Jeong <daehojeong@google.com>
Date:   Wed Oct 6 10:49:10 2021 -0700

    f2fs: include non-compressed blocks in compr_written_block
    
    commit 09631cf3234d32156e7cae32275f5a4144c683c5 upstream.
    
    Need to include non-compressed blocks in compr_written_block to
    estimate average compression ratio more accurately.
    
    Fixes: 5ac443e26a09 ("f2fs: add sysfs nodes to get runtime compression stat")
    Cc: stable@vger.kernel.org
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 035302003ccadf0c62ac0ec27d3382eadba0f407
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Sep 7 10:24:21 2021 -0700

    f2fs: should use GFP_NOFS for directory inodes
    
    commit 92d602bc7177325e7453189a22e0c8764ed3453e upstream.
    
    We use inline_dentry which requires to allocate dentry page when adding a link.
    If we allow to reclaim memory from filesystem, we do down_read(&sbi->cp_rwsem)
    twice by f2fs_lock_op(). I think this should be okay, but how about stopping
    the lockdep complaint [1]?
    
    f2fs_create()
     - f2fs_lock_op()
     - f2fs_do_add_link()
      - __f2fs_find_entry
       - f2fs_get_read_data_page()
       -> kswapd
        - shrink_node
         - f2fs_evict_inode
          - f2fs_lock_op()
    
    [1]
    
    fs_reclaim
    ){+.+.}-{0:0}
    :
    kswapd0:        lock_acquire+0x114/0x394
    kswapd0:        __fs_reclaim_acquire+0x40/0x50
    kswapd0:        prepare_alloc_pages+0x94/0x1ec
    kswapd0:        __alloc_pages_nodemask+0x78/0x1b0
    kswapd0:        pagecache_get_page+0x2e0/0x57c
    kswapd0:        f2fs_get_read_data_page+0xc0/0x394
    kswapd0:        f2fs_find_data_page+0xa4/0x23c
    kswapd0:        find_in_level+0x1a8/0x36c
    kswapd0:        __f2fs_find_entry+0x70/0x100
    kswapd0:        f2fs_do_add_link+0x84/0x1ec
    kswapd0:        f2fs_mkdir+0xe4/0x1e4
    kswapd0:        vfs_mkdir+0x110/0x1c0
    kswapd0:        do_mkdirat+0xa4/0x160
    kswapd0:        __arm64_sys_mkdirat+0x24/0x34
    kswapd0:        el0_svc_common.llvm.17258447499513131576+0xc4/0x1e8
    kswapd0:        do_el0_svc+0x28/0xa0
    kswapd0:        el0_svc+0x24/0x38
    kswapd0:        el0_sync_handler+0x88/0xec
    kswapd0:        el0_sync+0x1c0/0x200
    kswapd0:
    -> #1
    (
    &sbi->cp_rwsem
    ){++++}-{3:3}
    :
    kswapd0:        lock_acquire+0x114/0x394
    kswapd0:        down_read+0x7c/0x98
    kswapd0:        f2fs_do_truncate_blocks+0x78/0x3dc
    kswapd0:        f2fs_truncate+0xc8/0x128
    kswapd0:        f2fs_evict_inode+0x2b8/0x8b8
    kswapd0:        evict+0xd4/0x2f8
    kswapd0:        iput+0x1c0/0x258
    kswapd0:        do_unlinkat+0x170/0x2a0
    kswapd0:        __arm64_sys_unlinkat+0x4c/0x68
    kswapd0:        el0_svc_common.llvm.17258447499513131576+0xc4/0x1e8
    kswapd0:        do_el0_svc+0x28/0xa0
    kswapd0:        el0_svc+0x24/0x38
    kswapd0:        el0_sync_handler+0x88/0xec
    kswapd0:        el0_sync+0x1c0/0x200
    
    Cc: stable@vger.kernel.org
    Fixes: bdbc90fa55af ("f2fs: don't put dentry page in pagecache into highmem")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
    Reviewed-by: Light Hsieh <light.hsieh@mediatek.com>
    Tested-by: Light Hsieh <light.hsieh@mediatek.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 910ea7dd1e62e1021f7c511a036154fc736b742c
Author: Guo Ren <guoren@linux.alibaba.com>
Date:   Fri Nov 5 17:47:48 2021 +0800

    irqchip/sifive-plic: Fixup EOI failed when masked
    
    commit 69ea463021be0d159ab30f96195fb0dd18ee2272 upstream.
    
    When using "devm_request_threaded_irq(,,,,IRQF_ONESHOT,,)" in a driver,
    only the first interrupt is handled, and following interrupts are never
    delivered (initially reported in [1]).
    
    That's because the RISC-V PLIC cannot EOI masked interrupts, as explained
    in the description of Interrupt Completion in the PLIC spec [2]:
    
    <quote>
    The PLIC signals it has completed executing an interrupt handler by
    writing the interrupt ID it received from the claim to the claim/complete
    register. The PLIC does not check whether the completion ID is the same
    as the last claim ID for that target. If the completion ID does not match
    an interrupt source that *is currently enabled* for the target, the
    completion is silently ignored.
    </quote>
    
    Re-enable the interrupt before completion if it has been masked during
    the handling, and remask it afterwards.
    
    [1] http://lists.infradead.org/pipermail/linux-riscv/2021-July/007441.html
    [2] https://github.com/riscv/riscv-plic-spec/blob/8bc15a35d07c9edf7b5d23fec9728302595ffc4d/riscv-plic.adoc
    
    Fixes: bb0fed1c60cc ("irqchip/sifive-plic: Switch to fasteoi flow")
    Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
    Tested-by: Nikita Shubin <nikita.shubin@maquefel.me>
    Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
    Cc: stable@vger.kernel.org
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Atish Patra <atish.patra@wdc.com>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    [maz: amended commit message]
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20211105094748.3894453-1-guoren@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5d21724af2304361cdc7d3f4c8bb917a1d3334e
Author: Michael Pratt <mpratt@google.com>
Date:   Mon Nov 1 17:06:15 2021 -0400

    posix-cpu-timers: Clear task::posix_cputimers_work in copy_process()
    
    commit ca7752caeaa70bd31d1714af566c9809688544af upstream.
    
    copy_process currently copies task_struct.posix_cputimers_work as-is. If a
    timer interrupt arrives while handling clone and before dup_task_struct
    completes then the child task will have:
    
    1. posix_cputimers_work.scheduled = true
    2. posix_cputimers_work.work queued.
    
    copy_process clears task_struct.task_works, so (2) will have no effect and
    posix_cpu_timers_work will never run (not to mention it doesn't make sense
    for two tasks to share a common linked list).
    
    Since posix_cpu_timers_work never runs, posix_cputimers_work.scheduled is
    never cleared. Since scheduled is set, future timer interrupts will skip
    scheduling work, with the ultimate result that the task will never receive
    timer expirations.
    
    Together, the complete flow is:
    
    1. Task 1 calls clone(), enters kernel.
    2. Timer interrupt fires, schedules task work on Task 1.
       2a. task_struct.posix_cputimers_work.scheduled = true
       2b. task_struct.posix_cputimers_work.work added to
           task_struct.task_works.
    3. dup_task_struct() copies Task 1 to Task 2.
    4. copy_process() clears task_struct.task_works for Task 2.
    5. Future timer interrupts on Task 2 see
       task_struct.posix_cputimers_work.scheduled = true and skip scheduling
       work.
    
    Fix this by explicitly clearing contents of task_struct.posix_cputimers_work
    in copy_process(). This was never meant to be shared or inherited across
    tasks in the first place.
    
    Fixes: 1fb497dd0030 ("posix-cpu-timers: Provide mechanisms to defer timer handling to task_work")
    Reported-by: Rhys Hiltner <rhys@justin.tv>
    Signed-off-by: Michael Pratt <mpratt@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211101210615.716522-1-mpratt@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb58e9a26c3ce0278d8118fc2a70e6d528967f42
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Nov 12 02:53:41 2021 -0500

    KVM: x86: move guest_pv_has out of user_access section
    
    commit 3e067fd8503d6205aa0c1c8f48f6b209c592d19c upstream.
    
    When UBSAN is enabled, the code emitted for the call to guest_pv_has
    includes a call to __ubsan_handle_load_invalid_value.  objtool
    complains that this call happens with UACCESS enabled; to avoid
    the warning, pull the calls to user_access_begin into both arms
    of the "if" statement, after the check for guest_pv_has.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5e79d872babb12a1376bc07b4abae68d752f66d
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Nov 9 14:53:57 2021 +0100

    PCI/MSI: Destroy sysfs before freeing entries
    
    commit 3735459037114d31e5acd9894fad9aed104231a0 upstream.
    
    free_msi_irqs() frees the MSI entries before destroying the sysfs entries
    which are exposing them. Nothing prevents a concurrent free while a sysfs
    file is read and accesses the possibly freed entry.
    
    Move the sysfs release ahead of freeing the entries.
    
    Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Bjorn Helgaas <helgaas@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87sfw5305m.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab40a2e5e29e684794ffba0609b0c378500f02e0
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Nov 4 00:27:29 2021 +0100

    PCI/MSI: Move non-mask check back into low level accessors
    
    commit 9c8e9c9681a0f3f1ae90a90230d059c7a1dece5a upstream.
    
    The recent rework of PCI/MSI[X] masking moved the non-mask checks from the
    low level accessors into the higher level mask/unmask functions.
    
    This missed the fact that these accessors can be invoked from other places
    as well. The missing checks break XEN-PV which sets pci_msi_ignore_mask and
    also violates the virtual MSIX and the msi_attrib.maskbit protections.
    
    Instead of sprinkling checks all over the place, lift them back into the
    low level accessor functions. To avoid checking three different conditions
    combine them into one property of msi_desc::msi_attrib.
    
    [ josef: Fixed the missed conversion in the core code ]
    
    Fixes: fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask functions")
    Reported-by: Josef Johansson <josef@oderland.se>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Josef Johansson <josef@oderland.se>
    Cc: Bjorn Helgaas <helgaas@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit affa1361642f670adff1b9f2f8582677f4b55c52
Author: Dave Jones <davej@codemonkey.org.uk>
Date:   Fri Oct 29 16:57:59 2021 -0400

    x86/mce: Add errata workaround for Skylake SKX37
    
    commit e629fc1407a63dbb748f828f9814463ffc2a0af0 upstream.
    
    Errata SKX37 is word-for-word identical to the other errata listed in
    this workaround.   I happened to notice this after investigating a CMCI
    storm on a Skylake host.  While I can't confirm this was the root cause,
    spurious corrected errors does sound like a likely suspect.
    
    Fixes: 2976908e4198 ("x86/mce: Do not log spurious corrected mce errors")
    Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20211029205759.GA7385@codemonkey.org.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cd12b61c37fed15d064fa1b1ab115ae55597d16
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Fri Oct 22 00:58:23 2021 +0200

    MIPS: Fix assembly error from MIPSr2 code used within MIPS_ISA_ARCH_LEVEL
    
    commit a923a2676e60683aee46aa4b93c30aff240ac20d upstream.
    
    Fix assembly errors like:
    
    {standard input}: Assembler messages:
    {standard input}:287: Error: opcode not supported on this processor: mips3 (mips3) `dins $10,$7,32,32'
    {standard input}:680: Error: opcode not supported on this processor: mips3 (mips3) `dins $10,$7,32,32'
    {standard input}:1274: Error: opcode not supported on this processor: mips3 (mips3) `dins $12,$9,32,32'
    {standard input}:2175: Error: opcode not supported on this processor: mips3 (mips3) `dins $10,$7,32,32'
    make[1]: *** [scripts/Makefile.build:277: mm/highmem.o] Error 1
    
    with code produced from `__cmpxchg64' for MIPS64r2 CPU configurations
    using CONFIG_32BIT and CONFIG_PHYS_ADDR_T_64BIT.
    
    This is due to MIPS_ISA_ARCH_LEVEL downgrading the assembly architecture
    to `r4000' i.e. MIPS III for MIPS64r2 configurations, while there is a
    block of code containing a DINS MIPS64r2 instruction conditionalized on
    MIPS_ISA_REV >= 2 within the scope of the downgrade.
    
    The assembly architecture override code pattern has been put there for
    LL/SC instructions, so that code compiles for configurations that select
    a processor to build for that does not support these instructions while
    still providing run-time support for processors that do, dynamically
    switched by non-constant `cpu_has_llsc'.  It went in with linux-mips.org
    commit aac8aa7717a2 ("Enable a suitable ISA for the assembler around
    ll/sc so that code builds even for processors that don't support the
    instructions. Plus minor formatting fixes.") back in 2005.
    
    Fix the problem by wrapping these instructions along with the adjacent
    SYNC instructions only, following the practice established with commit
    cfd54de3b0e4 ("MIPS: Avoid move psuedo-instruction whilst using
    MIPS_ISA_LEVEL") and commit 378ed6f0e3c5 ("MIPS: Avoid using .set mips0
    to restore ISA").  Strictly speaking the SYNC instructions do not have
    to be wrapped as they are only used as a Loongson3 erratum workaround,
    so they will be enabled in the assembler by default, but do this so as
    to keep code consistent with other places.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Fixes: c7e2d71dda7a ("MIPS: Fix set_pte() for Netlogic XLR using cmpxchg64()")
    Cc: stable@vger.kernel.org # v5.1+
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b1b68eaad2acc099c6d1ab00e8652de5b33dd15
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed Nov 10 00:01:45 2021 +0900

    MIPS: fix *-pkg builds for loongson2ef platform
    
    commit 0706f74f719e6e72c3a862ab2990796578fa73cc upstream.
    
    Since commit 805b2e1d427a ("kbuild: include Makefile.compiler only when
    compiler is needed"), package builds for the loongson2f platform fail.
    
      $ make ARCH=mips CROSS_COMPILE=mips64-linux- lemote2f_defconfig bindeb-pkg
        [ snip ]
      sh ./scripts/package/builddeb
      arch/mips/loongson2ef//Platform:36: *** only binutils >= 2.20.2 have needed option -mfix-loongson2f-nop.  Stop.
      cp: cannot stat '': No such file or directory
      make[5]: *** [scripts/Makefile.package:87: intdeb-pkg] Error 1
      make[4]: *** [Makefile:1558: intdeb-pkg] Error 2
      make[3]: *** [debian/rules:13: binary-arch] Error 2
      dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
      make[2]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
      make[1]: *** [Makefile:1558: bindeb-pkg] Error 2
      make: *** [Makefile:350: __build_one_by_one] Error 2
    
    The reason is because "make image_name" fails.
    
      $ make ARCH=mips CROSS_COMPILE=mips64-linux- image_name
      arch/mips/loongson2ef//Platform:36: *** only binutils >= 2.20.2 have needed option -mfix-loongson2f-nop.  Stop.
    
    In general, adding $(error ...) in the parse stage is troublesome,
    and it is pointless to check toolchains even if we are not building
    anything. Do not include Kbuild.platform in such cases.
    
    Fixes: 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler is needed")
    Reported-by: Jason Self <jason@bluehome.net>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70895879357f3ec34e2ab2d278fcd8d8d36ad01f
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed Nov 10 00:01:46 2021 +0900

    MIPS: fix duplicated slashes for Platform file path
    
    commit cca2aac8acf470b01066f559acd7146fc4c32ae8 upstream.
    
    platform-y accumulates platform names with a slash appended.
    The current $(patsubst ...) ends up with doubling slashes.
    
    GNU Make still include Platform files, but in case of an error,
    a clumsy file path is displayed:
    
      arch/mips/loongson2ef//Platform:36: *** only binutils >= 2.20.2 have needed option -mfix-loongson2f-nop.  Stop.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Jason Self <jason@bluehome.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8301503a728a5f578b472f82f1fa773885b6cd0e
Author: John David Anglin <dave.anglin@bell.net>
Date:   Mon Nov 8 16:48:16 2021 -0500

    parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page
    
    commit 38860b2c8bb1b92f61396eb06a63adff916fc31d upstream.
    
    For years, there have been random segmentation faults in userspace on
    SMP PA-RISC machines.  It occurred to me that this might be a problem in
    set_pte_at().  MIPS and some other architectures do cache flushes when
    installing PTEs with the present bit set.
    
    Here I have adapted the code in update_mmu_cache() to flush the kernel
    mapping when the kernel flush is deferred, or when the kernel mapping
    may alias with the user mapping.  This simplifies calls to
    update_mmu_cache().
    
    I also changed the barrier in set_pte() from a compiler barrier to a
    full memory barrier.  I know this change is not sufficient to fix the
    problem.  It might not be needed.
    
    I have had a few days of operation with 5.14.16 to 5.15.1 and haven't
    seen any random segmentation faults on rp3440 or c8000 so far.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@kernel.org # 5.12+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dc7ce007aef5ce907764b8c78c15863e2b3b67f
Author: Helge Deller <deller@gmx.de>
Date:   Thu Nov 4 20:19:00 2021 +0100

    parisc: Fix backtrace to always include init funtion names
    
    commit 279917e27edc293eb645a25428c6ab3f3bca3f86 upstream.
    
    I noticed that sometimes at kernel startup the backtraces did not
    included the function names of init functions. Their address were not
    resolved to function names and instead only the address was printed.
    
    Debugging shows that the culprit is is_ksym_addr() which is called
    by the backtrace functions to check if an address belongs to a function in
    the kernel. The problem occurs only for CONFIG_KALLSYMS_ALL=y.
    
    When looking at is_ksym_addr() one can see that for CONFIG_KALLSYMS_ALL=y
    the function only tries to resolve the address via is_kernel() function,
    which checks like this:
            if (addr >= _stext && addr <= _end)
                    return 1;
    On parisc the init functions are located before _stext, so this check fails.
    Other platforms seem to have all functions (including init functions)
    behind _stext.
    
    The following patch moves the _stext symbol at the beginning of the
    kernel and thus includes the init section. This fixes the check and does
    not seem to have any negative side effects on where the kernel mapping
    happens in the map_pages() function in arch/parisc/mm/init.c.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@kernel.org # 5.4+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca8f29dc8b1b6d0d64d957c19936d4b3fe53a9b4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat Nov 6 19:42:29 2021 +0100

    ARM: 9156/1: drop cc-option fallbacks for architecture selection
    
    commit 418ace9992a7647c446ed3186df40cf165b67298 upstream.
    
    Naresh and Antonio ran into a build failure with latest Debian
    armhf compilers, with lots of output like
    
     tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode
    
    As it turns out, $(cc-option) fails early here when the FPU is not
    selected before CPU architecture is selected, as the compiler
    option check runs before enabling -msoft-float, which causes
    a problem when testing a target architecture level without an FPU:
    
    cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
    
    Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this
    issue, but the fallback logic is already broken because all supported
    compilers (gcc-5 and higher) are much more recent than these options,
    and building with -march=armv5t as a fallback no longer works.
    
    The best way forward that I see is to just remove all the checks, which
    also has the nice side-effect of slightly improving the startup time for
    'make'.
    
    The -mtune=marvell-f option was apparently never supported by any mainline
    compiler, and the custom Codesourcery gcc build that did support is
    now too old to build kernels, so just use -mtune=xscale unconditionally
    for those.
    
    This should be safe to apply on all stable kernels, and will be required
    in order to keep building them with gcc-11 and higher.
    
    Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419
    
    Reported-by: Antonio Terceiro <antonio.terceiro@linaro.org>
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
    Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com>
    Cc: Matthias Klose <doko@debian.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12f0dc47f2741124a4feab68e8f5b1736bef77e9
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Thu Nov 4 17:28:28 2021 +0100

    ARM: 9155/1: fix early early_iounmap()
    
    commit 0d08e7bf0d0d1a29aff7b16ef516f7415eb1aa05 upstream.
    
    Currently __set_fixmap() bails out with a warning when called in early boot
    from early_iounmap(). Fix it, and while at it, make the comment a bit easier
    to understand.
    
    Cc: <stable@vger.kernel.org>
    Fixes: b089c31c519c ("ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap")
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93114d5b3af04be24e77cf771268955a89c4ba01
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Nov 10 01:47:48 2021 -0600

    smb3: do not error on fsync when readonly
    
    commit 71e6864eacbef0b2645ca043cdfbac272cb6cea3 upstream.
    
    Linux allows doing a flush/fsync on a file open for read-only,
    but the protocol does not allow that.  If the file passed in
    on the flush is read-only try to find a writeable handle for
    the same inode, if that is not possible skip sending the
    fsync call to the server to avoid breaking the apps.
    
    Reported-by: Julian Sikorski <belegdol@gmail.com>
    Tested-by: Julian Sikorski <belegdol@gmail.com>
    Suggested-by: Jeremy Allison <jra@samba.org>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3f2809643ad5aec73dafa5f69f172c80846ae0f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Nov 12 10:56:25 2021 -0800

    thermal: int340x: fix build on 32-bit targets
    
    [ Upstream commit d9c8e52ff9e84ff1a406330f9ea4de7c5eb40282 ]
    
    Commit aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot
    64 bit RFIM responses") started using 'readq()' to read 64-bit status
    responses from the int340x hardware.
    
    That's all fine and good, but on 32-bit targets a 64-bit 'readq()' is
    ambiguous, since it's no longer an atomic access.  Some hardware might
    require 64-bit accesses, and other hardware might want low word first or
    high word first.
    
    It's quite likely that the driver isn't relevant in a 32-bit environment
    any more, and there's a patch floating around to just make it depend on
    X86_64, but let's make it buildable on x86-32 anyway.
    
    The driver previously just read the low 32 bits, so the hardware
    certainly is ok with 32-bit reads, and in a little-endian environment
    the low word first model is the natural one.
    
    So just add the include for the 'io-64-nonatomic-lo-hi.h' version.
    
    Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses")
    Reported-by: Jakub Kicinski <kuba@kernel.org>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cc4450b5327cecfad53c342f5dda42623d416e0
Author: Willem de Bruijn <willemb@google.com>
Date:   Thu Nov 11 06:57:17 2021 -0500

    selftests/net: udpgso_bench_rx: fix port argument
    
    [ Upstream commit d336509cb9d03970911878bb77f0497f64fda061 ]
    
    The below commit added optional support for passing a bind address.
    It configures the sockaddr bind arguments before parsing options and
    reconfigures on options -b and -4.
    
    This broke support for passing port (-p) on its own.
    
    Configure sockaddr after parsing all arguments.
    
    Fixes: 3327a9c46352 ("selftests: add functionals test for UDP GRO")
    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ce70c345537ccf6acf63003f675f84374e117d4
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Thu Nov 11 15:55:16 2021 +0530

    cxgb4: fix eeprom len when diagnostics not implemented
    
    [ Upstream commit 4ca110bf8d9b31a60f8f8ff6706ea147d38ad97c ]
    
    Ensure diagnostics monitoring support is implemented for the SFF 8472
    compliant port module and set the correct length for ethtool port
    module eeprom read.
    
    Fixes: f56ec6766dcf ("cxgb4: Add support for ethtool i2c dump")
    Signed-off-by: Manoj Malviya <manojmalviya@chelsio.com>
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed8b7355e38b3817ed6a23bd6932d25f579bb6e7
Author: Dust Li <dust.li@linux.alibaba.com>
Date:   Wed Nov 10 15:02:34 2021 +0800

    net/smc: fix sk_refcnt underflow on linkdown and fallback
    
    [ Upstream commit e5d5aadcf3cd59949316df49c27cb21788d7efe4 ]
    
    We got the following WARNING when running ab/nginx
    test with RDMA link flapping (up-down-up).
    The reason is when smc_sock fallback and at linkdown
    happens simultaneously, we may got the following situation:
    
    __smc_lgr_terminate()
     --> smc_conn_kill()
        --> smc_close_active_abort()
               smc_sock->sk_state = SMC_CLOSED
               sock_put(smc_sock)
    
    smc_sock was set to SMC_CLOSED and sock_put() been called
    when terminate the link group. But later application call
    close() on the socket, then we got:
    
    __smc_release():
        if (smc_sock->fallback)
            smc_sock->sk_state = SMC_CLOSED
            sock_put(smc_sock)
    
    Again we set the smc_sock to CLOSED through it's already
    in CLOSED state, and double put the refcnt, so the following
    warning happens:
    
    refcount_t: underflow; use-after-free.
    WARNING: CPU: 5 PID: 860 at lib/refcount.c:28 refcount_warn_saturate+0x8d/0xf0
    Modules linked in:
    CPU: 5 PID: 860 Comm: nginx Not tainted 5.10.46+ #403
    Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014
    RIP: 0010:refcount_warn_saturate+0x8d/0xf0
    Code: 05 5c 1e b5 01 01 e8 52 25 bc ff 0f 0b c3 80 3d 4f 1e b5 01 00 75 ad 48
    
    RSP: 0018:ffffc90000527e50 EFLAGS: 00010286
    RAX: 0000000000000026 RBX: ffff8881300df2c0 RCX: 0000000000000027
    RDX: 0000000000000000 RSI: ffff88813bd58040 RDI: ffff88813bd58048
    RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000001
    R10: ffff8881300df2c0 R11: ffffc90000527c78 R12: ffff8881300df340
    R13: ffff8881300df930 R14: ffff88810b3dad80 R15: ffff8881300df4f8
    FS:  00007f739de8fb80(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000a01b008 CR3: 0000000111b64003 CR4: 00000000003706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     smc_release+0x353/0x3f0
     __sock_release+0x3d/0xb0
     sock_close+0x11/0x20
     __fput+0x93/0x230
     task_work_run+0x65/0xa0
     exit_to_user_mode_prepare+0xf9/0x100
     syscall_exit_to_user_mode+0x27/0x190
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    This patch adds check in __smc_release() to make
    sure we won't do an extra sock_put() and set the
    socket to CLOSED when its already in CLOSED state.
    
    Fixes: 51f1de79ad8e (net/smc: replace sock_put worker by socket refcounting)
    Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
    Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
    Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
    Acked-by: Karsten Graul <kgraul@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 244048220c043aa6d7afe476e4f2994d94d77d3c
Author: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
Date:   Tue Nov 9 00:15:02 2021 +0000

    vsock: prevent unnecessary refcnt inc for nonblocking connect
    
    [ Upstream commit c7cd82b90599fa10915f41e3dd9098a77d0aa7b6 ]
    
    Currently vosck_connect() increments sock refcount for nonblocking
    socket each time it's called, which can lead to memory leak if
    it's called multiple times because connect timeout function decrements
    sock refcount only once.
    
    Fixes it by making vsock_connect() return -EALREADY immediately when
    sock state is already SS_CONNECTING.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8234e6086c1beedc49fd04d7156da15dc5784b4
Author: Marek Behún <kabel@kernel.org>
Date:   Mon Nov 8 22:49:18 2021 +0100

    net: marvell: mvpp2: Fix wrong SerDes reconfiguration order
    
    [ Upstream commit bb7bbb6e36474933540c24ae1f1ad651b843981f ]
    
    Commit bfe301ebbc94 ("net: mvpp2: convert to use
    mac_prepare()/mac_finish()") introduced a bug wherein it leaves the MAC
    RESET register asserted after mac_finish(), due to wrong order of
    function calls.
    
    Before it was:
      .mac_config()
        mvpp22_mode_reconfigure()
          assert reset
        mvpp2_xlg_config()
          deassert reset
    
    Now it is:
      .mac_prepare()
      .mac_config()
        mvpp2_xlg_config()
          deassert reset
      .mac_finish()
        mvpp2_xlg_config()
          assert reset
    
    Obviously this is wrong.
    
    This bug is triggered when phylink tries to change the PHY interface
    mode from a GMAC mode (sgmii, 1000base-x, 2500base-x) to XLG mode
    (10gbase-r, xaui). The XLG mode does not work since reset is left
    asserted. Only after
      ifconfig down && ifconfig up
    is called will the XLG mode work.
    
    Move the call to mvpp22_mode_reconfigure() to .mac_prepare()
    implementation. Since some of the subsequent functions need to know
    whether the interface is being changed, we unfortunately also need to
    pass around the new interface mode before setting port->phy_interface.
    
    Fixes: bfe301ebbc94 ("net: mvpp2: convert to use mac_prepare()/mac_finish()")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fb190ff57166148ba7db70ca3d544b07f207dc8
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Nov 8 22:28:55 2021 +0100

    net: ethernet: ti: cpsw_ale: Fix access to un-initialized memory
    
    [ Upstream commit 7a166854b4e24c57d56b3eba9fe1594985ee0a2c ]
    
    It is spurious to allocate a bitmap without initializing it.
    So, better safe than sorry, initialize it to 0 at least to have some known
    values.
    
    While at it, switch to the devm_bitmap_ API which is less verbose.
    
    Fixes: 4b41d3436796 ("net: ethernet: ti: cpsw: allow untagged traffic on host port")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c8ee89e351c6095cf3210df252f625279e1fd70
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Mon Nov 8 22:28:54 2021 +0200

    net: stmmac: allow a tc-taprio base-time of zero
    
    [ Upstream commit f64ab8e4f368f48afb08ae91928e103d17b235e9 ]
    
    Commit fe28c53ed71d ("net: stmmac: fix taprio configuration when
    base_time is in the past") allowed some base time values in the past,
    but apparently not all, the base-time value of 0 (Jan 1st 1970) is still
    explicitly denied by the driver.
    
    Remove the bogus check.
    
    Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb85093e0c8eb3a926fe350f9506542ff86fd09c
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Wed Nov 10 21:42:56 2021 +0800

    net: hns3: allow configure ETS bandwidth of all TCs
    
    [ Upstream commit 688db0c7a4a69ddc8b8143a1cac01eb20082a3aa ]
    
    Currently, driver only allow configuring ETS bandwidth of TCs according
    to the max TC number queried from firmware. However, the hardware actually
    supports 8 TCs and users may need to configure ETS bandwidth of all TCs,
    so remove the restriction.
    
    Fixes: 330baff5423b ("net: hns3: add ETS TC weight setting in SSU module")
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d3f131b4032d682d37d5279c540fb3535269e2d
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Wed Nov 10 21:42:53 2021 +0800

    net: hns3: fix kernel crash when unload VF while it is being reset
    
    [ Upstream commit e140c7983e3054be0652bf914f4454f16c5520b0 ]
    
    When fully configure VLANs for a VF, then unload the VF while
    triggering a reset to PF, will cause a kernel crash because the
    irq is already uninit.
    
    [ 293.177579] ------------[ cut here ]------------
    [ 293.183502] kernel BUG at drivers/pci/msi.c:352!
    [ 293.189547] Internal error: Oops - BUG: 0 [#1] SMP
    ......
    [ 293.390124] Workqueue: hclgevf hclgevf_service_task [hclgevf]
    [ 293.402627] pstate: 80c00009 (Nzcv daif +PAN +UAO)
    [ 293.414324] pc : free_msi_irqs+0x19c/0x1b8
    [ 293.425429] lr : free_msi_irqs+0x18c/0x1b8
    [ 293.436545] sp : ffff00002716fbb0
    [ 293.446950] x29: ffff00002716fbb0 x28: 0000000000000000
    [ 293.459519] x27: 0000000000000000 x26: ffff45b91ea16b00
    [ 293.472183] x25: 0000000000000000 x24: ffffa587b08f4700
    [ 293.484717] x23: ffffc591ac30e000 x22: ffffa587b08f8428
    [ 293.497190] x21: ffffc591ac30e300 x20: 0000000000000000
    [ 293.509594] x19: ffffa58a062a8300 x18: 0000000000000000
    [ 293.521949] x17: 0000000000000000 x16: ffff45b91dcc3f48
    [ 293.534013] x15: 0000000000000000 x14: 0000000000000000
    [ 293.545883] x13: 0000000000000040 x12: 0000000000000228
    [ 293.557508] x11: 0000000000000020 x10: 0000000000000040
    [ 293.568889] x9 : ffff45b91ea1e190 x8 : ffffc591802d0000
    [ 293.580123] x7 : ffffc591802d0148 x6 : 0000000000000120
    [ 293.591190] x5 : ffffc591802d0000 x4 : 0000000000000000
    [ 293.602015] x3 : 0000000000000000 x2 : 0000000000000000
    [ 293.612624] x1 : 00000000000004a4 x0 : ffffa58a1e0c6b80
    [ 293.623028] Call trace:
    [ 293.630340] free_msi_irqs+0x19c/0x1b8
    [ 293.638849] pci_disable_msix+0x118/0x140
    [ 293.647452] pci_free_irq_vectors+0x20/0x38
    [ 293.656081] hclgevf_uninit_msi+0x44/0x58 [hclgevf]
    [ 293.665309] hclgevf_reset_rebuild+0x1ac/0x2e0 [hclgevf]
    [ 293.674866] hclgevf_reset+0x358/0x400 [hclgevf]
    [ 293.683545] hclgevf_reset_service_task+0xd0/0x1b0 [hclgevf]
    [ 293.693325] hclgevf_service_task+0x4c/0x2e8 [hclgevf]
    [ 293.702307] process_one_work+0x1b0/0x448
    [ 293.710034] worker_thread+0x54/0x468
    [ 293.717331] kthread+0x134/0x138
    [ 293.724114] ret_from_fork+0x10/0x18
    [ 293.731324] Code: f940b000 b4ffff00 a903e7b8 f90017b6 (d4210000)
    
    This patch fixes the problem by waiting for the VF reset done
    while unloading the VF.
    
    Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c051366908b7fa3653679db76b3cfabb4f07a43
Author: Jie Wang <wangjie125@huawei.com>
Date:   Wed Nov 10 21:42:51 2021 +0800

    net: hns3: fix pfc packet number incorrect after querying pfc parameters
    
    [ Upstream commit 0b653a81a26d66ffe526a54c2177e24fb1400301 ]
    
    Currently, driver will send command to firmware to query pfc packet number
    when user uses dcb tool to get pfc parameters. However, the periodic
    service task will also periodically query and record MAC statistics,
    including pfc packet number.
    
    As the hardware registers of statistics is cleared after reading, it will
    cause pfc packet number of MAC statistics are not correct after using dcb
    tool to get pfc parameters.
    
    To fix this problem, when user uses dcb tool to get pfc parameters, driver
    updates MAC statistics firstly and then get pfc packet number from MAC
    statistics.
    
    Fixes: 64fd2300fcc1 ("net: hns3: add support for querying pfc puase packets statistic")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcbee7cf14a61828c53b3e39fa7997756689ebc4
Author: Jie Wang <wangjie125@huawei.com>
Date:   Wed Nov 10 21:42:50 2021 +0800

    net: hns3: fix ROCE base interrupt vector initialization bug
    
    [ Upstream commit beb27ca451a57a1c0e52b5268703f3c3173c1f8c ]
    
    Currently, NIC init ROCE interrupt vector with MSIX interrupt. But ROCE use
    pci_irq_vector() to get interrupt vector, which adds the relative interrupt
    vector again and gets wrong interrupt vector.
    
    So fixes it by assign relative interrupt vector to ROCE instead of MSIX
    interrupt vector and delete the unused struct member base_msi_vector
    declaration of hclgevf_dev.
    
    Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e13ce88a3c8cc4d5579409a650a3753cf4fac17
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 8 10:08:15 2021 -0800

    net/sched: sch_taprio: fix undefined behavior in ktime_mono_to_any
    
    [ Upstream commit 6dc25401cba4d428328eade8ceae717633fdd702 ]
    
    1) if q->tk_offset == TK_OFFS_MAX, then get_tcp_tstamp() calls
       ktime_mono_to_any() with out-of-bound value.
    
    2) if q->tk_offset is changed in taprio_parse_clockid(),
       taprio_get_time() might also call ktime_mono_to_any()
       with out-of-bound value as sysbot found:
    
    UBSAN: array-index-out-of-bounds in kernel/time/timekeeping.c:908:27
    index 3 is out of range for type 'ktime_t *[3]'
    CPU: 1 PID: 25668 Comm: kworker/u4:0 Not tainted 5.15.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     ubsan_epilogue+0xb/0x5a lib/ubsan.c:151
     __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:291
     ktime_mono_to_any+0x1d4/0x1e0 kernel/time/timekeeping.c:908
     get_tcp_tstamp net/sched/sch_taprio.c:322 [inline]
     get_packet_txtime net/sched/sch_taprio.c:353 [inline]
     taprio_enqueue_one+0x5b0/0x1460 net/sched/sch_taprio.c:420
     taprio_enqueue+0x3b1/0x730 net/sched/sch_taprio.c:485
     dev_qdisc_enqueue+0x40/0x300 net/core/dev.c:3785
     __dev_xmit_skb net/core/dev.c:3869 [inline]
     __dev_queue_xmit+0x1f6e/0x3630 net/core/dev.c:4194
     batadv_send_skb_packet+0x4a9/0x5f0 net/batman-adv/send.c:108
     batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline]
     batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline]
     batadv_iv_send_outstanding_bat_ogm_packet+0x6d7/0x8e0 net/batman-adv/bat_iv_ogm.c:1701
     process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298
     worker_thread+0x658/0x11f0 kernel/workqueue.c:2445
     kthread+0x405/0x4f0 kernel/kthread.c:327
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
    
    Fixes: 7ede7b03484b ("taprio: make clock reference conversions easier")
    Fixes: 54002066100b ("taprio: Adjust timestamps for TCP packets")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vedang Patel <vedang.patel@intel.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Link: https://lore.kernel.org/r/20211108180815.1822479-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 422fb879961f6c1a91b04e5ef0c67cb4b8b9e5e6
Author: Marek Behún <kabel@kernel.org>
Date:   Thu Nov 4 18:17:47 2021 +0100

    net: dsa: mv88e6xxx: Don't support >1G speeds on 6191X on ports other than 10
    
    [ Upstream commit dc2fc9f03c5c410d8f01c2206b3d529f80b13733 ]
    
    Model 88E6191X only supports >1G speeds on port 10. Port 0 and 9 are
    only 1G.
    
    Fixes: de776d0d316f ("net: dsa: mv88e6xxx: add support for mv88e6393x family")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20211104171747.10509-1-kabel@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f17e9e81004e197161956213e0c4f9bc3787d6b9
Author: Evan Quan <evan.quan@amd.com>
Date:   Sat Oct 9 17:35:36 2021 +0800

    drm/amdgpu: fix uvd crash on Polaris12 during driver unloading
    
    [ Upstream commit 4fc30ea780e0a5c1c019bc2e44f8523e1eed9051 ]
    
    There was a change(below) target for such issue:
    d82e2c249c8f ("drm/amdgpu: Fix crash on device remove/driver unload")
    But the fix for VI ASICs was missing there. This is a supplement for
    that.
    
    Fixes: d82e2c249c8f ("drm/amdgpu: Fix crash on device remove/driver unload")
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f00e054b299cbd44a266bbe32f42ffe9aff8a684
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Mon Nov 8 18:35:19 2021 -0800

    seq_file: fix passing wrong private data
    
    [ Upstream commit 10a6de19cad6efb9b49883513afb810dc265fca2 ]
    
    DEFINE_PROC_SHOW_ATTRIBUTE() is supposed to be used to define a series
    of functions and variables to register proc file easily. And the users
    can use proc_create_data() to pass their own private data and get it
    via seq->private in the callback. Unfortunately, the proc file system
    use PDE_DATA() to get private data instead of inode->i_private. So fix
    it. Fortunately, there only one user of it which does not pass any
    private data, so this bug does not break any in-tree codes.
    
    Link: https://lkml.kernel.org/r/20211029032638.84884-1-songmuchun@bytedance.com
    Fixes: 97a32539b956 ("proc: convert everything to "struct proc_ops"")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Florent Revest <revest@chromium.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acdc5065d9678cc361041cd213da8693ebc26c44
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Mon Nov 8 18:34:27 2021 -0800

    init: make unknown command line param message clearer
    
    [ Upstream commit 8bc2b3dca7292347d8e715fb723c587134abe013 ]
    
    The prior message is confusing users, which is the exact opposite of the
    goal.  If the message is being seen, one of the following situations is
    happening:
    
     1. the param is misspelled
     2. the param is not valid due to the kernel configuration
     3. the param is intended for init but isn't after the '--'
        delineator on the command line
    
    To make that more clear to the user, explicitly mention "kernel command
    line" and also note that the params are still passed to user space to
    avoid causing any alarm over params intended for init.
    
    Link: https://lkml.kernel.org/r/20211013223502.96756-1-ahalaney@redhat.com
    Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Borislav Petkov <bp@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cf82ea0a46d2b962652ad7aa9f0581a3bf284e3
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Oct 27 01:50:59 2021 +0300

    drm/i915/fb: Fix rounding error in subsampled plane size calculation
    
    [ Upstream commit 90ab96f3872eae816f4e07deaa77322a91237960 ]
    
    For NV12 FBs with odd main surface tile-row height the CCS surface
    height was incorrectly calculated 1 less than the actual value. Fix this
    by rounding up the result of divison. For consistency do the same for
    the CCS surface width calculation.
    
    Fixes: b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression")
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-2-imre.deak@intel.com
    (cherry picked from commit 2ee5ef9c934ad26376c9282171e731e6c0339815)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fea0b9507bb7e03a9414301fe8c09e44f7f70a13
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Nov 9 14:47:36 2021 +0300

    gve: Fix off by one in gve_tx_timeout()
    
    [ Upstream commit 1c360cc1cc883fbdf0a258b4df376571fbeac5ee ]
    
    The priv->ntfy_blocks[] has "priv->num_ntfy_blks" elements so this >
    needs to be >= to prevent an off by one bug.  The priv->ntfy_blocks[]
    array is allocated in gve_alloc_notify_blocks().
    
    Fixes: 87a7f321bb6a ("gve: Recover from queue stall due to missed IRQ")
    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 0bf8323e2c74012d38a61d4f9470fe7f33376bd4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 3 16:33:12 2021 +0100

    dmaengine: stm32-dma: avoid 64-bit division in stm32_dma_get_max_width
    
    [ Upstream commit 2498363310e9b5e5de0e104709adc35c9f3ff7d9 ]
    
    Using the % operator on a 64-bit variable is expensive and can
    cause a link failure:
    
    arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_get_max_width':
    stm32-dma.c:(.text+0x170): undefined reference to `__aeabi_uldivmod'
    arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_set_xfer_param':
    stm32-dma.c:(.text+0x1cd4): undefined reference to `__aeabi_uldivmod'
    
    As we know that we just want to check the alignment in
    stm32_dma_get_max_width(), there is no need for a full division, and
    using a simple mask is a faster replacement.
    
    Same in stm32_dma_set_xfer_param(), change this to only allow burst
    transfers if the address is a multiple of the length.
    stm32_dma_get_best_burst just after will take buf_len into account to fix
    burst in case of misalignment.
    
    Fixes: b20fd5fa310c ("dmaengine: stm32-dma: fix stm32_dma_get_max_width")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20211103153312.41483-1-amelie.delaunay@foss.st.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ee1ac7f3cf56b2e9f629208bdf28d81397a48dd
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Mon Oct 11 11:42:59 2021 +0200

    dmaengine: stm32-dma: fix burst in case of unaligned memory address
    
    [ Upstream commit af229d2c2557b5cf2a3b1eb39847ec1de7446873 ]
    
    Theorically, address pointers used by STM32 DMA must be chosen so as to
    ensure that all transfers within a burst block are aligned on the address
    boundary equal to the size of the transfer.
    If this is always the case for peripheral addresses on STM32, it is not for
    memory addresses if the user doesn't respect this alignment constraint.
    To avoid a weird behavior of the DMA controller in this case (no error
    triggered but data are not transferred as expected), force no burst.
    
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20211011094259.315023-4-amelie.delaunay@foss.st.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bff34d6712a6cedee6a4360268768836a1e4738
Author: Jussi Maki <joamaki@gmail.com>
Date:   Wed Nov 3 13:47:36 2021 -0700

    bpf, sockmap: sk_skb data_end access incorrect when src_reg = dst_reg
    
    [ Upstream commit b2c4618162ec615a15883a804cce7e27afecfa58 ]
    
    The current conversion of skb->data_end reads like this:
    
      ; data_end = (void*)(long)skb->data_end;
       559: (79) r1 = *(u64 *)(r2 +200)   ; r1  = skb->data
       560: (61) r11 = *(u32 *)(r2 +112)  ; r11 = skb->len
       561: (0f) r1 += r11
       562: (61) r11 = *(u32 *)(r2 +116)
       563: (1f) r1 -= r11
    
    But similar to the case in 84f44df664e9 ("bpf: sock_ops sk access may stomp
    registers when dst_reg = src_reg"), the code will read an incorrect skb->len
    when src == dst. In this case we end up generating this xlated code:
    
      ; data_end = (void*)(long)skb->data_end;
       559: (79) r1 = *(u64 *)(r1 +200)   ; r1  = skb->data
       560: (61) r11 = *(u32 *)(r1 +112)  ; r11 = (skb->data)->len
       561: (0f) r1 += r11
       562: (61) r11 = *(u32 *)(r1 +116)
       563: (1f) r1 -= r11
    
    ... where line 560 is the reading 4B of (skb->data + 112) instead of the
    intended skb->len Here the skb pointer in r1 gets set to skb->data and the
    later deref for skb->len ends up following skb->data instead of skb.
    
    This fixes the issue similarly to the patch mentioned above by creating an
    additional temporary variable and using to store the register when dst_reg =
    src_reg. We name the variable bpf_temp_reg and place it in the cb context for
    sk_skb. Then we restore from the temp to ensure nothing is lost.
    
    Fixes: 16137b09a66f2 ("bpf: Compute data_end dynamically with JIT code")
    Signed-off-by: Jussi Maki <joamaki@gmail.com>
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20211103204736.248403-6-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a8dba02a8883b65944949a865d9040cbe3eed8e
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Wed Nov 3 13:47:35 2021 -0700

    bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and colliding
    
    [ Upstream commit e0dc3b93bd7bcff8c3813d1df43e0908499c7cf0 ]
    
    Strparser is reusing the qdisc_skb_cb struct to stash the skb message handling
    progress, e.g. offset and length of the skb. First this is poorly named and
    inherits a struct from qdisc that doesn't reflect the actual usage of cb[] at
    this layer.
    
    But, more importantly strparser is using the following to access its metadata.
    
      (struct _strp_msg *)((void *)skb->cb + offsetof(struct qdisc_skb_cb, data))
    
    Where _strp_msg is defined as:
    
      struct _strp_msg {
            struct strp_msg            strp;                 /*     0     8 */
            int                        accum_len;            /*     8     4 */
    
            /* size: 12, cachelines: 1, members: 2 */
            /* last cacheline: 12 bytes */
      };
    
    So we use 12 bytes of ->data[] in struct. However in BPF code running parser
    and verdict the user has read capabilities into the data[] array as well. Its
    not too problematic, but we should not be exposing internal state to BPF
    program. If its really needed then we can use the probe_read() APIs which allow
    reading kernel memory. And I don't believe cb[] layer poses any API breakage by
    moving this around because programs can't depend on cb[] across layers.
    
    In order to fix another issue with a ctx rewrite we need to stash a temp
    variable somewhere. To make this work cleanly this patch builds a cb struct
    for sk_skb types called sk_skb_cb struct. Then we can use this consistently
    in the strparser, sockmap space. Additionally we can start allowing ->cb[]
    write access after this.
    
    Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Jussi Maki <joamaki@gmail.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20211103204736.248403-5-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5cc0d23c5414d23438c5024890e367cc5a0e645
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Wed Nov 3 13:47:34 2021 -0700

    bpf, sockmap: Fix race in ingress receive verdict with redirect to self
    
    [ Upstream commit c5d2177a72a1659554922728fc407f59950aa929 ]
    
    A socket in a sockmap may have different combinations of programs attached
    depending on configuration. There can be no programs in which case the socket
    acts as a sink only. There can be a TX program in this case a BPF program is
    attached to sending side, but no RX program is attached. There can be an RX
    program only where sends have no BPF program attached, but receives are hooked
    with BPF. And finally, both TX and RX programs may be attached. Giving us the
    permutations:
    
     None, Tx, Rx, and TxRx
    
    To date most of our use cases have been TX case being used as a fast datapath
    to directly copy between local application and a userspace proxy. Or Rx cases
    and TxRX applications that are operating an in kernel based proxy. The traffic
    in the first case where we hook applications into a userspace application looks
    like this:
    
      AppA  redirect   AppB
       Tx <-----------> Rx
       |                |
       +                +
       TCP <--> lo <--> TCP
    
    In this case all traffic from AppA (after 3whs) is copied into the AppB
    ingress queue and no traffic is ever on the TCP recieive_queue.
    
    In the second case the application never receives, except in some rare error
    cases, traffic on the actual user space socket. Instead the send happens in
    the kernel.
    
               AppProxy       socket pool
           sk0 ------------->{sk1,sk2, skn}
            ^                      |
            |                      |
            |                      v
           ingress              lb egress
           TCP                  TCP
    
    Here because traffic is never read off the socket with userspace recv() APIs
    there is only ever one reader on the sk receive_queue. Namely the BPF programs.
    
    However, we've started to introduce a third configuration where the BPF program
    on receive should process the data, but then the normal case is to push the
    data into the receive queue of AppB.
    
           AppB
           recv()                (userspace)
         -----------------------
           tcp_bpf_recvmsg()     (kernel)
             |             |
             |             |
             |             |
           ingress_msgQ    |
             |             |
           RX_BPF          |
             |             |
             v             v
           sk->receive_queue
    
    This is different from the App{A,B} redirect because traffic is first received
    on the sk->receive_queue.
    
    Now for the issue. The tcp_bpf_recvmsg() handler first checks the ingress_msg
    queue for any data handled by the BPF rx program and returned with PASS code
    so that it was enqueued on the ingress msg queue. Then if no data exists on
    that queue it checks the socket receive queue. Unfortunately, this is the same
    receive_queue the BPF program is reading data off of. So we get a race. Its
    possible for the recvmsg() hook to pull data off the receive_queue before the
    BPF hook has a chance to read it. It typically happens when an application is
    banging on recv() and getting EAGAINs. Until they manage to race with the RX
    BPF program.
    
    To fix this we note that before this patch at attach time when the socket is
    loaded into the map we check if it needs a TX program or just the base set of
    proto bpf hooks. Then it uses the above general RX hook regardless of if we
    have a BPF program attached at rx or not. This patch now extends this check to
    handle all cases enumerated above, TX, RX, TXRX, and none. And to fix above
    race when an RX program is attached we use a new hook that is nearly identical
    to the old one except now we do not let the recv() call skip the RX BPF program.
    Now only the BPF program pulls data from sk->receive_queue and recv() only
    pulls data from the ingress msgQ post BPF program handling.
    
    With this resolved our AppB from above has been up and running for many hours
    without detecting any errors. We do this by correlating counters in RX BPF
    events and the AppB to ensure data is never skipping the BPF program. Selftests,
    was not able to detect this because we only run them for a short period of time
    on well ordered send/recvs so we don't get any of the noise we see in real
    application environments.
    
    Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Jussi Maki <joamaki@gmail.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20211103204736.248403-4-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41c65a3ce9dbe71ef41a7f3c67608d332cc7e66c
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Wed Nov 3 13:47:33 2021 -0700

    bpf, sockmap: Remove unhash handler for BPF sockmap usage
    
    [ Upstream commit b8b8315e39ffaca82e79d86dde26e9144addf66b ]
    
    We do not need to handle unhash from BPF side we can simply wait for the
    close to happen. The original concern was a socket could transition from
    ESTABLISHED state to a new state while the BPF hook was still attached.
    But, we convinced ourself this is no longer possible and we also improved
    BPF sockmap to handle listen sockets so this is no longer a problem.
    
    More importantly though there are cases where unhash is called when data is
    in the receive queue. The BPF unhash logic will flush this data which is
    wrong. To be correct it should keep the data in the receive queue and allow
    a receiving application to continue reading the data. This may happen when
    tcp_abort() is received for example. Instead of complicating the logic in
    unhash simply moving all this to tcp_close() hook solves this.
    
    Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Jussi Maki <joamaki@gmail.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20211103204736.248403-3-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b90d961cf6352775d68f0f855b7924b50defb4be
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 5 08:54:03 2021 +0100

    arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions
    
    [ Upstream commit c7c386fbc20262c1d911c615c65db6a58667d92c ]
    
    gcc warns about undefined behavior the vmalloc code when building
    with CONFIG_ARM64_PA_BITS_52, when the 'idx++' in the argument to
    __phys_to_pte_val() is evaluated twice:
    
    mm/vmalloc.c: In function 'vmap_pfn_apply':
    mm/vmalloc.c:2800:58: error: operation on 'data->idx' may be undefined [-Werror=sequence-point]
     2800 |         *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot));
          |                                                 ~~~~~~~~~^~
    arch/arm64/include/asm/pgtable-types.h:25:37: note: in definition of macro '__pte'
       25 | #define __pte(x)        ((pte_t) { (x) } )
          |                                     ^
    arch/arm64/include/asm/pgtable.h:80:15: note: in expansion of macro '__phys_to_pte_val'
       80 |         __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
          |               ^~~~~~~~~~~~~~~~~
    mm/vmalloc.c:2800:30: note: in expansion of macro 'pfn_pte'
     2800 |         *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot));
          |                              ^~~~~~~
    
    I have no idea why this never showed up earlier, but the safest
    workaround appears to be changing those macros into inline functions
    so the arguments get evaluated only once.
    
    Cc: Matthew Wilcox <willy@infradead.org>
    Fixes: 75387b92635e ("arm64: handle 52-bit physical addresses in page table entries")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20211105075414.2553155-1-arnd@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f828915064fe70731d22f58e374630a57361d789
Author: Reiji Watanabe <reijiw@google.com>
Date:   Sun Oct 31 21:54:21 2021 -0700

    arm64: arm64_ftr_reg->name may not be a human-readable string
    
    [ Upstream commit 9dc232a8ab18bb20f1dcb03c8e049e3607f3ed15 ]
    
    The id argument of ARM64_FTR_REG_OVERRIDE() is used for two purposes:
    one as the system register encoding (used for the sys_id field of
    __ftr_reg_entry), and the other as the register name (stringified
    and used for the name field of arm64_ftr_reg), which is debug
    information. The id argument is supposed to be a macro that
    indicates an encoding of the register (eg. SYS_ID_AA64PFR0_EL1, etc).
    
    ARM64_FTR_REG(), which also has the same id argument,
    uses ARM64_FTR_REG_OVERRIDE() and passes the id to the macro.
    Since the id argument is completely macro-expanded before it is
    substituted into a macro body of ARM64_FTR_REG_OVERRIDE(),
    the stringified id in the body of ARM64_FTR_REG_OVERRIDE is not
    a human-readable register name, but a string of numeric bitwise
    operations.
    
    Fix this so that human-readable register names are available as
    debug information.
    
    Fixes: 8f266a5d878a ("arm64: cpufeature: Add global feature override facility")
    Signed-off-by: Reiji Watanabe <reijiw@google.com>
    Reviewed-by: Oliver Upton <oupton@google.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20211101045421.2215822-1-reijiw@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d57d522e2f0354b8fba529e204455e558866316
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Nov 7 21:13:07 2021 +0100

    litex_liteeth: Fix a double free in the remove function
    
    [ Upstream commit c45231a7668d6b632534f692b10592ea375b55b0 ]
    
    'netdev' is a managed resource allocated in the probe using
    'devm_alloc_etherdev()'.
    It must not be freed explicitly in the remove function.
    
    Fixes: ee7da21ac4c3 ("net: Add driver for LiteX's LiteETH network interface")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d2dfc33ef4437fe0823ad666e51bf0eeea4a926
Author: Chengfeng Ye <cyeaa@connect.ust.hk>
Date:   Fri Nov 5 06:36:36 2021 -0700

    nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
    
    [ Upstream commit 9fec40f850658e00a14a7dd9e06f7fbc7e59cc4a ]
    
    skb is already freed by dev_kfree_skb in pn533_fill_fragment_skbs,
    but follow error handler branch when pn533_fill_fragment_skbs()
    fails, skb is freed again, results in double free issue. Fix this
    by not free skb in error path of pn533_fill_fragment_skbs.
    
    Fixes: 963a82e07d4e ("NFC: pn533: Split large Tx frames in chunks")
    Fixes: 93ad42020c2d ("NFC: pn533: Target mode Tx fragmentation support")
    Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72fb40d87c59229e465fdf0c3d63481e1f6189d8
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Nov 5 14:42:14 2021 -0700

    llc: fix out-of-bound array index in llc_sk_dev_hash()
    
    [ Upstream commit 8ac9dfd58b138f7e82098a4e0a0d46858b12215b ]
    
    Both ifindex and LLC_SK_DEV_HASH_ENTRIES are signed.
    
    This means that (ifindex % LLC_SK_DEV_HASH_ENTRIES) is negative
    if @ifindex is negative.
    
    We could simply make LLC_SK_DEV_HASH_ENTRIES unsigned.
    
    In this patch I chose to use hash_32() to get more entropy
    from @ifindex, like llc_sk_laddr_hashfn().
    
    UBSAN: array-index-out-of-bounds in ./include/net/llc.h:75:26
    index -43 is out of range for type 'hlist_head [64]'
    CPU: 1 PID: 20999 Comm: syz-executor.3 Not tainted 5.15.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     ubsan_epilogue+0xb/0x5a lib/ubsan.c:151
     __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:291
     llc_sk_dev_hash include/net/llc.h:75 [inline]
     llc_sap_add_socket+0x49c/0x520 net/llc/llc_conn.c:697
     llc_ui_bind+0x680/0xd70 net/llc/af_llc.c:404
     __sys_bind+0x1e9/0x250 net/socket.c:1693
     __do_sys_bind net/socket.c:1704 [inline]
     __se_sys_bind net/socket.c:1702 [inline]
     __x64_sys_bind+0x6f/0xb0 net/socket.c:1702
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7fa503407ae9
    
    Fixes: 6d2e3ea28446 ("llc: use a device based hash table to speed up multicast delivery")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63609f11cda8aef1909478f738cee10c2b59225d
Author: Ian Rogers <irogers@google.com>
Date:   Fri Nov 5 22:37:33 2021 -0700

    perf bpf: Add missing free to bpf_event__print_bpf_prog_info()
    
    [ Upstream commit 88c42f4d6cb249eb68524282f8d4cc32f9059984 ]
    
    If btf__new() is called then there needs to be a corresponding btf__free().
    
    Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andrii Nakryiko <andrii@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: KP Singh <kpsingh@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: bpf@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20211106053733.3580931-2-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18fdce809a9caa96d220ff3b52c83042a526a090
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Nov 5 13:45:12 2021 -0700

    zram: off by one in read_block_state()
    
    [ Upstream commit a88e03cf3d190cf46bc4063a9b7efe87590de5f4 ]
    
    snprintf() returns the number of bytes it would have printed if there
    were space.  But it does not count the NUL terminator.  So that means
    that if "count == copied" then this has already overflowed by one
    character.
    
    This bug likely isn't super harmful in real life.
    
    Link: https://lkml.kernel.org/r/20210916130404.GA25094@kili
    Fixes: c0265342bff4 ("zram: introduce zram memory tracking")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d6b113cbef49413a5c5f1d627590504c67c30e3
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Fri Nov 5 13:45:03 2021 -0700

    mm/zsmalloc.c: close race window between zs_pool_dec_isolated() and zs_unregister_migration()
    
    [ Upstream commit afe8605ca45424629fdddfd85984b442c763dc47 ]
    
    There is one possible race window between zs_pool_dec_isolated() and
    zs_unregister_migration() because wait_for_isolated_drain() checks the
    isolated count without holding class->lock and there is no order inside
    zs_pool_dec_isolated().  Thus the below race window could be possible:
    
      zs_pool_dec_isolated          zs_unregister_migration
        check pool->destroying != 0
                                      pool->destroying = true;
                                      smp_mb();
                                      wait_for_isolated_drain()
                                        wait for pool->isolated_pages == 0
        atomic_long_dec(&pool->isolated_pages);
        atomic_long_read(&pool->isolated_pages) == 0
    
    Since we observe the pool->destroying (false) before atomic_long_dec()
    for pool->isolated_pages, waking pool->migration_wait up is missed.
    
    Fix this by ensure checking pool->destroying happens after the
    atomic_long_dec(&pool->isolated_pages).
    
    Link: https://lkml.kernel.org/r/20210708115027.7557-1-linmiaohe@huawei.com
    Fixes: 701d678599d0 ("mm/zsmalloc.c: fix race condition in zs_destroy_pool")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
    Cc: Henry Burns <henryburns@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ba8ddd87b02e2ae5416683ecb3e5fa87cf2d702
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Tue Oct 19 17:00:04 2021 +0200

    can: mcp251xfd: mcp251xfd_chip_start(): fix error handling for mcp251xfd_chip_rx_int_enable()
    
    [ Upstream commit 69c55f6e7669d46bb40e41f6e2b218428178368a ]
    
    This patch fixes the error handling for mcp251xfd_chip_rx_int_enable().
    Instead just returning the error, properly shut down the chip.
    
    Link: https://lore.kernel.org/all/20211106201526.44292-2-mkl@pengutronix.de
    Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7eb0881aec26099089f12ae850aebd93190b1dfe
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Wed Oct 27 03:07:40 2021 +0900

    can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path
    
    [ Upstream commit d9447f768bc8c60623e4bb3ce65b8f4654d33a50 ]
    
    In es58x_rx_err_msg(), if can->do_set_mode() fails, the function
    directly returns without calling netif_rx(skb). This means that the
    skb previously allocated by alloc_can_err_skb() is not freed. In other
    terms, this is a memory leak.
    
    This patch simply removes the return statement in the error branch and
    let the function continue.
    
    Issue was found with GCC -fanalyzer, please follow the link below for
    details.
    
    Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
    Link: https://lore.kernel.org/all/20211026180740.1953265-1-mailhol.vincent@wanadoo.fr
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e16a1e4ba6da1e153878e0ec6c6ae5597b69dfc9
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Nov 3 15:52:53 2021 -0400

    drm/amdgpu/powerplay: fix sysfs_emit/sysfs_emit_at handling
    
    [ Upstream commit e9c76719c1e99caf95e70de74170291b9457bbc1 ]
    
    sysfs_emit and sysfs_emit_at requrie a page boundary
    aligned buf address. Make them happy!
    
    v2: fix sysfs_emit -> sysfs_emit_at missed conversions
    
    Cc: Lang Yu <lang.yu@amd.com>
    Cc: Darren Powell <darren.powell@amd.com>
    Fixes: 6db0c87a0a8e ("amdgpu/pm: Replace hwmgr smu usage of sprintf with sysfs_emit")
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1774
    Reviewed-by: Lang Yu <lang.yu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97308cd5ce8edc466a2eed1bb31fd81a088ed54d
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed Nov 3 21:11:12 2021 -0300

    Revert "drm/imx: Annotate dma-fence critical section in commit path"
    
    [ Upstream commit 14d9a37c952588930d7226953359fea3ab956d39 ]
    
    This reverts commit f4b34faa08428d813fc3629f882c503487f94a12.
    
    Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in
    commit path") the following possible circular dependency is detected:
    
    [    5.001811] ======================================================
    [    5.001817] WARNING: possible circular locking dependency detected
    [    5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: G        W
    [    5.001833] ------------------------------------------------------
    [    5.001838] kworker/u8:0/7 is trying to acquire lock:
    [    5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x40/0x294
    [    5.001903]
    [    5.001903] but task is already holding lock:
    [    5.001909] c176df78 (dma_fence_map){++++}-{0:0}, at: imx_drm_atomic_commit_tail+0x10/0x160
    [    5.001957]
    [    5.001957] which lock already depends on the new lock.
    ...
    
    Revert it for now.
    
    Tested on a imx6q-sabresd.
    
    Fixes: f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit path")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211104001112.4035691-1-festevam@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94e18f5a5dd1b5e3b89c665fc5ff780858b1c9f6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Oct 29 14:02:38 2021 +0200

    drm: fb_helper: improve CONFIG_FB dependency
    
    [ Upstream commit 9d6366e743f37d36ef69347924ead7bcc596076e ]
    
    My previous patch correctly addressed the possible link failure, but as
    Jani points out, the dependency is now stricter than it needs to be.
    
    Change it again, to allow DRM_FBDEV_EMULATION to be used when
    DRM_KMS_HELPER and FB are both loadable modules and DRM is linked into
    the kernel.
    
    As a side-effect, the option is now only visible when at least one DRM
    driver makes use of DRM_KMS_HELPER. This is better, because the option
    has no effect otherwise.
    
    Fixes: 606b102876e3 ("drm: fb_helper: fix CONFIG_FB dependency")
    Suggested-by: Acked-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211029120307.1407047-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39db3e5681bd8e3b241c6d54916bbedd8e1e3c7d
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Oct 27 11:35:53 2021 +0800

    selftests/bpf/xdp_redirect_multi: Limit the tests in netns
    
    [ Upstream commit 8955c1a329873385775081e029d9a7c6aa9037e1 ]
    
    As I want to test both DEVMAP and DEVMAP_HASH in XDP multicast redirect, I
    limited DEVMAP max entries to a small value for performace. When the test
    runs after amount of interface creating/deleting tests. The interface index
    will exceed the map max entries and xdp_redirect_multi will error out with
    "Get interfacesInterface index to large".
    
    Fix this issue by limit the tests in netns and specify the ifindex when
    creating interfaces.
    
    Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test")
    Reported-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20211027033553.962413-5-liuhangbin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a99e4d94df317577c8d27f2134b68594290a4069
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Oct 27 11:35:52 2021 +0800

    selftests/bpf/xdp_redirect_multi: Give tcpdump a chance to terminate cleanly
    
    [ Upstream commit 648c3677062fbd14d754b853daebb295426771e8 ]
    
    No need to kill tcpdump with -9.
    
    Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test")
    Suggested-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20211027033553.962413-4-liuhangbin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00f991138c2fb9e510f8ba335a2147ac97419df5
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Oct 27 11:35:51 2021 +0800

    selftests/bpf/xdp_redirect_multi: Use arping to accurate the arp number
    
    [ Upstream commit f53ea9dbf78d42a10e2392b5c59362ccc224fd1d ]
    
    The arp request number triggered by ping none exist address is not accurate,
    which may lead the test false negative/positive. Change to use arping to
    accurate the arp number. Also do not use grep pattern match for dot.
    
    Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test")
    Suggested-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20211027033553.962413-3-liuhangbin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddf4f3897357da019edec37b61a7b9a11c62592d
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Oct 27 11:35:50 2021 +0800

    selftests/bpf/xdp_redirect_multi: Put the logs to tmp folder
    
    [ Upstream commit 8b4ac13abe7d82da0e0d22a9ba2e27301559a93e ]
    
    The xdp_redirect_multi test logs are created in selftest folder and not cleaned
    after test. Let's creat a tmp dir and remove the logs after testing.
    
    Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test")
    Suggested-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20211027033553.962413-2-liuhangbin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e13c754499052c4741c658c065a74a5d38d6abda
Author: Mehrdad Arshad Rad <arshad.rad@gmail.com>
Date:   Thu Nov 4 10:13:54 2021 -0700

    libbpf: Fix lookup_and_delete_elem_flags error reporting
    
    [ Upstream commit 64165ddf8ea184631c65e3bbc8d59f6d940590ca ]
    
    Fix bpf_map_lookup_and_delete_elem_flags() to pass the return code through
    libbpf_err_errno() as we do similarly in bpf_map_lookup_and_delete_elem().
    
    Fixes: f12b65432728 ("libbpf: Streamline error reporting for low-level APIs")
    Signed-off-by: Mehrdad Arshad Rad <arshad.rad@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20211104171354.11072-1-arshad.rad@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0f8307c7db314b8f3a52eaae3cecc4a43838dc2
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Nov 4 22:54:17 2021 +0100

    ACPI: PM: Fix device wakeup power reference counting error
    
    [ Upstream commit 452a3e723f75880757acf87b053935c43aa89f89 ]
    
    Fix a device wakeup power reference counting error introduced by
    commit a2d7b2e004af ("ACPI: PM: Fix sharing of wakeup power
    resources") because of a coding mistake.
    
    Fixes: a2d7b2e004af ("ACPI: PM: Fix sharing of wakeup power resources")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27f2e5b91452bf4f453a8ba2de0badeafc8b353a
Author: Kai Song <songkai01@inspur.com>
Date:   Wed Oct 6 22:19:26 2021 +0800

    mfd: altera-sysmgr: Fix a mistake caused by resource_size conversion
    
    [ Upstream commit fae2570d629cdd72f0611d015fc4ba705ae5422b ]
    
    The resource_size defines that:
            res->end - res->start + 1;
    The origin original code is:
            sysmgr_config.max_register = res->end - res->start - 3;
    
    So, the correct fix is that:
            sysmgr_config.max_register = resource_size(res) - 4;
    
    Fixes: d12edf9661a4 ("mfd: altera-sysmgr: Use resource_size function on resource object")
    Signed-off-by: Kai Song <songkai01@inspur.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20211006141926.6120-1-songkai01@inspur.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fb2bcf0affeb3db0b28508efe11545ae20566be
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Sep 24 15:33:47 2021 +0100

    mfd: sprd: Add SPI device ID table
    
    [ Upstream commit c5c7f0677107052060037583b9c8c15d818afb04 ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding a SPI device ID table.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20210924143347.14721-4-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd20d4d8433ee95841ee55fc00a0e7ce94b7f799
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Sep 24 15:33:46 2021 +0100

    mfd: cpcap: Add SPI device ID table
    
    [ Upstream commit d5fa8592b773f4da2b04e7333cd37efec5e4ca43 ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding a SPI device ID table.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20210924143347.14721-3-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34b1f6db7ceaa45fd5913520fffab13ddd62f47a
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Fri May 28 07:51:26 2021 -0400

    mfd: core: Add missing of_node_put for loop iteration
    
    [ Upstream commit 002be81140075e17a1ebd5c3c55e356fbab0ddad ]
    
    Early exits from for_each_child_of_node() should decrement the
    node reference counter.  Reported by Coccinelle:
    
      drivers/mfd/mfd-core.c:197:2-24: WARNING:
        Function "for_each_child_of_node" should have of_node_put() before goto around lines 209.
    
    Fixes: c94bb233a9fe ("mfd: Make MFD core code Device Tree and IRQ domain aware")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20210528115126.18370-1-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca1362fdcbc2cb894147633fcc70940408f783d6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 5 11:21:03 2021 +0100

    ALSA: memalloc: Catch call with NULL snd_dma_buffer pointer
    
    [ Upstream commit dce9446192439eaac81c21f517325fb473735e53 ]
    
    Although we've covered all calls with NULL dma buffer pointer, so far,
    there may be still some else in the wild.  For catching such a case
    more easily, add a WARN_ON_ONCE() in snd_dma_get_ops().
    
    Fixes: 37af81c5998f ("ALSA: core: Abstract memory alloc helpers")
    Link: https://lore.kernel.org/r/20211105102103.28148-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9806f88b774431978ef4b989bdf599cd285e28c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Nov 4 14:34:42 2021 +0100

    octeontx2-pf: select CONFIG_NET_DEVLINK
    
    [ Upstream commit 9cbc3367968de69017a87a1118b62490ac1bdd0a ]
    
    The octeontx2 pf nic driver failsz to link when the devlink support
    is not reachable:
    
    aarch64-linux-ld: drivers/net/ethernet/marvell/octeontx2/nic/otx2_devlink.o: in function `otx2_dl_mcam_count_get':
    otx2_devlink.c:(.text+0x10): undefined reference to `devlink_priv'
    aarch64-linux-ld: drivers/net/ethernet/marvell/octeontx2/nic/otx2_devlink.o: in function `otx2_dl_mcam_count_validate':
    otx2_devlink.c:(.text+0x50): undefined reference to `devlink_priv'
    aarch64-linux-ld: drivers/net/ethernet/marvell/octeontx2/nic/otx2_devlink.o: in function `otx2_dl_mcam_count_set':
    otx2_devlink.c:(.text+0xd0): undefined reference to `devlink_priv'
    aarch64-linux-ld: drivers/net/ethernet/marvell/octeontx2/nic/otx2_devlink.o: in function `otx2_devlink_info_get':
    otx2_devlink.c:(.text+0x150): undefined reference to `devlink_priv'
    
    This is already selected by the admin function driver, but not the
    actual nic, which might be built-in when the af driver is not.
    
    Fixes: 2da489432747 ("octeontx2-pf: devlink params support to set mcam entry count")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c49ae7a8db9e907f40e1f175dd73f835277f227
Author: Huang Guobin <huangguobin4@huawei.com>
Date:   Tue Nov 2 17:37:33 2021 +0800

    bonding: Fix a use-after-free problem when bond_sysfs_slave_add() failed
    
    [ Upstream commit b93c6a911a3fe926b00add28f3b932007827c4ca ]
    
    When I do fuzz test for bonding device interface, I got the following
    use-after-free Calltrace:
    
    ==================================================================
    BUG: KASAN: use-after-free in bond_enslave+0x1521/0x24f0
    Read of size 8 at addr ffff88825bc11c00 by task ifenslave/7365
    
    CPU: 5 PID: 7365 Comm: ifenslave Tainted: G            E     5.15.0-rc1+ #13
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
    Call Trace:
     dump_stack_lvl+0x6c/0x8b
     print_address_description.constprop.0+0x48/0x70
     kasan_report.cold+0x82/0xdb
     __asan_load8+0x69/0x90
     bond_enslave+0x1521/0x24f0
     bond_do_ioctl+0x3e0/0x450
     dev_ifsioc+0x2ba/0x970
     dev_ioctl+0x112/0x710
     sock_do_ioctl+0x118/0x1b0
     sock_ioctl+0x2e0/0x490
     __x64_sys_ioctl+0x118/0x150
     do_syscall_64+0x35/0xb0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f19159cf577
    Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 78
    RSP: 002b:00007ffeb3083c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007ffeb3084bca RCX: 00007f19159cf577
    RDX: 00007ffeb3083ce0 RSI: 0000000000008990 RDI: 0000000000000003
    RBP: 00007ffeb3084bc4 R08: 0000000000000040 R09: 0000000000000000
    R10: 00007ffeb3084bc0 R11: 0000000000000246 R12: 00007ffeb3083ce0
    R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffeb3083cb0
    
    Allocated by task 7365:
     kasan_save_stack+0x23/0x50
     __kasan_kmalloc+0x83/0xa0
     kmem_cache_alloc_trace+0x22e/0x470
     bond_enslave+0x2e1/0x24f0
     bond_do_ioctl+0x3e0/0x450
     dev_ifsioc+0x2ba/0x970
     dev_ioctl+0x112/0x710
     sock_do_ioctl+0x118/0x1b0
     sock_ioctl+0x2e0/0x490
     __x64_sys_ioctl+0x118/0x150
     do_syscall_64+0x35/0xb0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Freed by task 7365:
     kasan_save_stack+0x23/0x50
     kasan_set_track+0x20/0x30
     kasan_set_free_info+0x24/0x40
     __kasan_slab_free+0xf2/0x130
     kfree+0xd1/0x5c0
     slave_kobj_release+0x61/0x90
     kobject_put+0x102/0x180
     bond_sysfs_slave_add+0x7a/0xa0
     bond_enslave+0x11b6/0x24f0
     bond_do_ioctl+0x3e0/0x450
     dev_ifsioc+0x2ba/0x970
     dev_ioctl+0x112/0x710
     sock_do_ioctl+0x118/0x1b0
     sock_ioctl+0x2e0/0x490
     __x64_sys_ioctl+0x118/0x150
     do_syscall_64+0x35/0xb0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Last potentially related work creation:
     kasan_save_stack+0x23/0x50
     kasan_record_aux_stack+0xb7/0xd0
     insert_work+0x43/0x190
     __queue_work+0x2e3/0x970
     delayed_work_timer_fn+0x3e/0x50
     call_timer_fn+0x148/0x470
     run_timer_softirq+0x8a8/0xc50
     __do_softirq+0x107/0x55f
    
    Second to last potentially related work creation:
     kasan_save_stack+0x23/0x50
     kasan_record_aux_stack+0xb7/0xd0
     insert_work+0x43/0x190
     __queue_work+0x2e3/0x970
     __queue_delayed_work+0x130/0x180
     queue_delayed_work_on+0xa7/0xb0
     bond_enslave+0xe25/0x24f0
     bond_do_ioctl+0x3e0/0x450
     dev_ifsioc+0x2ba/0x970
     dev_ioctl+0x112/0x710
     sock_do_ioctl+0x118/0x1b0
     sock_ioctl+0x2e0/0x490
     __x64_sys_ioctl+0x118/0x150
     do_syscall_64+0x35/0xb0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The buggy address belongs to the object at ffff88825bc11c00
     which belongs to the cache kmalloc-1k of size 1024
    The buggy address is located 0 bytes inside of
     1024-byte region [ffff88825bc11c00, ffff88825bc12000)
    The buggy address belongs to the page:
    page:ffffea00096f0400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x25bc10
    head:ffffea00096f0400 order:3 compound_mapcount:0 compound_pincount:0
    flags: 0x57ff00000010200(slab|head|node=1|zone=2|lastcpupid=0x7ff)
    raw: 057ff00000010200 ffffea0009a71c08 ffff888240001968 ffff88810004dbc0
    raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88825bc11b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88825bc11b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff88825bc11c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff88825bc11c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88825bc11d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Put new_slave in bond_sysfs_slave_add() will cause use-after-free problems
    when new_slave is accessed in the subsequent error handling process. Since
    new_slave will be put in the subsequent error handling process, remove the
    unnecessary put to fix it.
    In addition, when sysfs_create_file() fails, if some files have been crea-
    ted successfully, we need to call sysfs_remove_file() to remove them.
    Since there are sysfs_create_files() & sysfs_remove_files() can be used,
    use these two functions instead.
    
    Fixes: 7afcaec49696 (bonding: use kobject_put instead of _del after kobject_add)
    Signed-off-by: Huang Guobin <huangguobin4@huawei.com>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71fb40ae9b07578b3aeebf78fcbb3394810acd9a
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Tue Oct 19 20:27:31 2021 -0300

    drm/ttm: remove ttm_bo_vm_insert_huge()
    
    [ Upstream commit 0d979509539ed1df883a30d442177ca7be609565 ]
    
    The huge page functionality in TTM does not work safely because PUD and
    PMD entries do not have a special bit.
    
    get_user_pages_fast() considers any page that passed pmd_huge() as
    usable:
    
            if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
                         pmd_devmap(pmd))) {
    
    And vmf_insert_pfn_pmd_prot() unconditionally sets
    
            entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
    
    eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE.
    
    As such gup_huge_pmd() will try to deref a struct page:
    
            head = try_grab_compound_head(pmd_page(orig), refs, flags);
    
    and thus crash.
    
    Thomas further notices that the drivers are not expecting the struct page
    to be used by anything - in particular the refcount incr above will cause
    them to malfunction.
    
    Thus everything about this is not able to fully work correctly considering
    GUP_fast. Delete it entirely. It can return someday along with a proper
    PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast.
    
    Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Thomas Hellström <thomas.helllstrom@linux.intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    [danvet: Update subject per Thomas' &Christian's review]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/0-v2-a44694790652+4ac-ttm_pmd_jgg@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d5c7b0eeeca313221ccb660b34ea89a56e19aba
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Wed Nov 3 09:40:23 2021 -0700

    block: fix device_add_disk() kobject_create_and_add() error handling
    
    [ Upstream commit fe7d064fa3faec5d8157029fb8720b4fddc9e1e8 ]
    
    Commit 83cbce957446 ("block: add error handling for device_add_disk /
    add_disk") added error handling to device_add_disk(), however the goto
    label for the kobject_create_and_add() failure did not set the return
    value correctly, and so we can end up in a situation where
    kobject_create_and_add() fails but we report success.
    
    Fixes: 83cbce957446 ("block: add error handling for device_add_disk / add_disk")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20211103164023.1384821-1-mcgrof@kernel.org
    [axboe: fold in followup fix from Wu Bo <wubo40@huawei.com>]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f1e2373563673adbb7e3079d7a6d37bbb9e2d55
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Nov 3 22:08:28 2021 +0100

    net: phy: fix duplex out of sync problem while changing settings
    
    [ Upstream commit a4db9055fdb9cf607775c66d39796caf6439ec92 ]
    
    As reported by Zhang there's a small issue if in forced mode the duplex
    mode changes with the link staying up [0]. In this case the MAC isn't
    notified about the change.
    
    The proposed patch relies on the phylib state machine and ignores the
    fact that there are drivers that uses phylib but not the phylib state
    machine. So let's don't change the behavior for such drivers and fix
    it w/o re-adding state PHY_FORCING for the case that phylib state
    machine is used.
    
    [0] https://lore.kernel.org/netdev/a5c26ffd-4ee4-a5e6-4103-873208ce0dc5@huawei.com/T/
    
    Fixes: 2bd229df5e2e ("net: phy: remove state PHY_FORCING")
    Reported-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Tested-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/7b8b9456-a93f-abbc-1dc5-a2c2542f932c@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96f9abc9183cbbcffb97b23384212fbe54543330
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Nov 3 19:43:47 2021 +0100

    cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
    
    [ Upstream commit dbea75fe18f60e364de6d994fc938a24ba249d81 ]
    
    Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
    ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
    desired values in certain usage scenarios, but it did not prevent
    them from being leaked into the confugirations in which HWP desired
    is expected to be 0.
    
    The failing scenarios are switching the driver from the passive
    mode to the active mode and starting a new kernel via kexec() while
    intel_pstate is running in the passive mode.
    
    To address this issue, ensure that HWP desired will be cleared on
    offline and suspend/shutdown.
    
    Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback")
    Reported-by: Julia Lawall <julia.lawall@inria.fr>
    Tested-by: Julia Lawall <julia.lawall@inria.fr>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8dedce3460e75bc80721fd05cfaf03724be6d08
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Sat Sep 11 03:03:05 2021 -0700

    PCI: Do not enable AtomicOps on VFs
    
    [ Upstream commit 5ec0a6fcb60ea430f8ee7e0bec22db9b22f856d3 ]
    
    Host crashes when pci_enable_atomic_ops_to_root() is called for VFs with
    virtual buses. The virtual buses added to SR-IOV have bus->self set to NULL
    and host crashes due to this.
    
      PID: 4481   TASK: ffff89c6941b0000  CPU: 53  COMMAND: "bash"
      ...
       #3 [ffff9a9481713808] oops_end at ffffffffb9025cd6
       #4 [ffff9a9481713828] page_fault_oops at ffffffffb906e417
       #5 [ffff9a9481713888] exc_page_fault at ffffffffb9a0ad14
       #6 [ffff9a94817138b0] asm_exc_page_fault at ffffffffb9c00ace
          [exception RIP: pcie_capability_read_dword+28]
          RIP: ffffffffb952fd5c  RSP: ffff9a9481713960  RFLAGS: 00010246
          RAX: 0000000000000001  RBX: ffff89c6b1096000  RCX: 0000000000000000
          RDX: ffff9a9481713990  RSI: 0000000000000024  RDI: 0000000000000000
          RBP: 0000000000000080   R8: 0000000000000008   R9: ffff89c64341a2f8
          R10: 0000000000000002  R11: 0000000000000000  R12: ffff89c648bab000
          R13: 0000000000000000  R14: 0000000000000000  R15: ffff89c648bab0c8
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffff9a9481713988] pci_enable_atomic_ops_to_root at ffffffffb95359a6
       #8 [ffff9a94817139c0] bnxt_qplib_determine_atomics at ffffffffc08c1a33 [bnxt_re]
       #9 [ffff9a94817139d0] bnxt_re_dev_init at ffffffffc08ba2d1 [bnxt_re]
    
    Per PCIe r5.0, sec 9.3.5.10, the AtomicOp Requester Enable bit in Device
    Control 2 is reserved for VFs.  The PF value applies to all associated VFs.
    
    Return -EINVAL if pci_enable_atomic_ops_to_root() is called for a VF.
    
    Link: https://lore.kernel.org/r/1631354585-16597-1-git-send-email-selvin.xavier@broadcom.com
    Fixes: 35f5ace5dea4 ("RDMA/bnxt_re: Enable global atomic ops if platform supports")
    Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()")
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d1d54003af46a124aaae949524571b8a3a04d5e
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Wed Nov 3 16:04:33 2021 -0700

    ataflop: remove ataflop_probe_lock mutex
    
    [ Upstream commit 4ddb85d36613c45bde00d368bf9f357bd0708a0c ]
    
    Commit bf9c0538e485b591 ("ataflop: use a separate gendisk for each media
    format") introduced ataflop_probe_lock mutex, but forgot to unlock the
    mutex when atari_floppy_init() (i.e. module loading) succeeded. This will
    result in double lock deadlock if ataflop_probe() is called. Also,
    unregister_blkdev() must not be called from atari_floppy_init() with
    ataflop_probe_lock held when atari_floppy_init() failed, for
    ataflop_probe() waits for ataflop_probe_lock with major_names_lock held
    (i.e. AB-BA deadlock).
    
    __register_blkdev() needs to be called last in order to avoid calling
    ataflop_probe() when atari_floppy_init() is about to fail, for memory for
    completing already-started ataflop_probe() safely will be released as soon
    as atari_floppy_init() released ataflop_probe_lock mutex.
    
    As with commit 8b52d8be86d72308 ("loop: reorder loop_exit"),
    unregister_blkdev() needs to be called first in order to avoid calling
    ataflop_alloc_disk() from ataflop_probe() after del_gendisk() from
    atari_floppy_exit().
    
    By relocating __register_blkdev() / unregister_blkdev() as explained above,
    we can remove ataflop_probe_lock mutex, for probe function and __exit
    function are serialized by major_names_lock mutex.
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Fixes: bf9c0538e485b591 ("ataflop: use a separate gendisk for each media format")
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Tested-by: Michael Schmitz <schmitzmic@gmail.com>
    Link: https://lore.kernel.org/r/20211103230437.1639990-11-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e107071961c558f445ed4d66c45278b35b4b9298
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon Sep 27 15:03:01 2021 -0700

    block/ataflop: provide a helper for cleanup up an atari disk
    
    [ Upstream commit deae1138d04758c7f8939fcb8aee330bc37e3015 ]
    
    Instead of using two separate code paths for cleaning up an atari disk,
    use one. We take the more careful approach to check for *all* disk
    types, as is done on exit. The init path didn't have that check as
    the alternative disk types are only probed for later, they are not
    initialized by default.
    
    Yes, there is a shared tag for all disks.
    
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20210927220302.1073499-14-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 875ffb42476b2156da9dd96445a4e66b8e201086
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon Sep 27 15:03:00 2021 -0700

    block/ataflop: add registration bool before calling del_gendisk()
    
    [ Upstream commit 573effb298011d3fcabc9b12025cf637f8a07911 ]
    
    The ataflop assumes del_gendisk() is safe to call, this is only
    true because add_disk() does not return a failure, but that will
    change soon. And so, before we get to adding error handling for
    that case, let's make sure we keep track of which disks actually
    get registered. Then we use this to only call del_gendisk for them.
    
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20210927220302.1073499-13-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d3261d4606a6d600910ec17dc592cd2b29c6ffa
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon Sep 27 15:02:59 2021 -0700

    block/ataflop: use the blk_cleanup_disk() helper
    
    [ Upstream commit 44a469b6acae6ad05c4acca8429467d1d50a8b8d ]
    
    Use the helper to replace two lines with one.
    
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20210927220302.1073499-12-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 275e4a31a82c704db79b4e233e29ac7d8d9429d7
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Wed Nov 3 16:04:28 2021 -0700

    nvdimm/pmem: cleanup the disk if pmem_release_disk() is yet assigned
    
    [ Upstream commit accf58afb689f81daadde24080ea1164ad2db75f ]
    
    Prior to devm being able to use pmem_release_disk() there are other
    failure which can occur for which we must account for and release the
    disk for. Address those few cases.
    
    Fixes: 3dd60fb9d95d ("nvdimm/pmem: stop using q_usage_count as external pgmap refcount")
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20211103230437.1639990-6-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e8ed252e4833f63aae054fdd4758a2a90763ed3
Author: Chenyuan Mi <cymi20@fudan.edu.cn>
Date:   Tue Sep 7 20:26:33 2021 +0800

    drm/nouveau/svm: Fix refcount leak bug and missing check against null bug
    
    [ Upstream commit 6bb8c2d51811eb5e6504f49efe3b089d026009d2 ]
    
    The reference counting issue happens in one exception handling path of
    nouveau_svmm_bind(). When cli->svm.svmm is null, the function forgets
    to decrease the refcount of mm increased by get_task_mm(), causing a
    refcount leak.
    
    Fix this issue by using mmput() to decrease the refcount in the
    exception handling path.
    
    Also, the function forgets to do check against null when get mm
    by get_task_mm().
    
    Fix this issue by adding null check after get mm by get_task_mm().
    
    Signed-off-by: Chenyuan Mi <cymi20@fudan.edu.cn>
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Fixes: 822cab6150d3 ("drm/nouveau/svm: check for SVM initialized before migrating")
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Reviewed-by: Karol Herbst <kherbst@redhat.com>
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210907122633.16665-1-cymi20@fudan.edu.cn
    Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e65a7ab548a31e9f77c40fbbe57bb65f5c211f0f
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Thu Nov 4 11:46:13 2021 +0100

    selftests: net: properly support IPv6 in GSO GRE test
    
    [ Upstream commit a985442fdecb59504e3a2f1cfdd3c53af017ea5b ]
    
    Explicitly pass -6 to netcat when the test is using IPv6 to prevent
    failures.
    
    Also make sure to pass "-N" to netcat to close the socket after EOF on
    the client side, otherwise we would always hit the timeout and the test
    would fail.
    
    Without this fix applied:
    
     TEST: GREv6/v4 - copy file w/ TSO                                   [FAIL]
     TEST: GREv6/v4 - copy file w/ GSO                                   [FAIL]
     TEST: GREv6/v6 - copy file w/ TSO                                   [FAIL]
     TEST: GREv6/v6 - copy file w/ GSO                                   [FAIL]
    
    With this fix applied:
    
     TEST: GREv6/v4 - copy file w/ TSO                                   [ OK ]
     TEST: GREv6/v4 - copy file w/ GSO                                   [ OK ]
     TEST: GREv6/v6 - copy file w/ TSO                                   [ OK ]
     TEST: GREv6/v6 - copy file w/ GSO                                   [ OK ]
    
    Fixes: 025efa0a82df ("selftests: add simple GSO GRE test")
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57488e25ef53aa266c045bfc9ff0eb7364076cd8
Author: Avri Altman <avri.altman@wdc.com>
Date:   Sun Oct 31 14:36:54 2021 +0200

    scsi: ufs: ufshpb: Properly handle max-single-cmd
    
    [ Upstream commit 9ec5128a8b5631d652ed06b37e0166f337802f90 ]
    
    The spec recommends that for transfer length larger than the max-single-cmd
    attribute (bMAX_DATA_SIZE_FOR_HPB_SINGLE_CMD) it is possible to couple
    pre-requests with the HPB-READ command.  Being a recommendation, using
    pre-requests can be perceived merely as a means of optimization.  A common
    practice was to send pre-requests for chunks within some interval, and
    leave the READ10 untouched if larger.
    
    Now that the pre-request flows have been removed, all the commands are
    single commands.  Properly handle this attribute and do not send HPB-READ
    for transfer lengths larger than max-single-cmd.
    
    [mkp: resolve conflict]
    
    Fixes: 09d9e4d04187 ("scsi: ufs: ufshpb: Remove HPB2.0 flows")
    Link: https://lore.kernel.org/r/20211031123654.17719-1-avri.altman@wdc.com
    Reviewed-by: Daejun Park <daejun7.park@samsung.com>
    Signed-off-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e022fea64e8dd7e5dd137249251e415a1bd9a678
Author: Bean Huo <beanhuo@micron.com>
Date:   Wed Sep 29 22:06:38 2021 +0200

    scsi: ufs: core: Fix NULL pointer dereference
    
    [ Upstream commit 1da3b0141e74c18c2377d4c2655406a90a87742f ]
    
    Calling ufshcd_rpm_{get/put}_sync() prior to ufshcd_scsi_add_wlus() being
    called will trigger a NULL pointer dereference. This is because
    hba->sdev_ufs_device is initialized in ufshcd_scsi_add_wlus().
    
        Unable to handle kernel NULL pointer dereference at virtual address
        0000000000000348
        Mem abort info:
          ESR = 0x96000004
          EC = 0x25: DABT (current EL), IL = 32 bits
          SET = 0, FnV = 0
          EA = 0, S1PTW = 0
          FSC = 0x04: level 0 translation fault
        Data abort info:
          ISV = 0, ISS = 0x00000004
          CM = 0, WnR = 0
        [0000000000000348] user address but active_mm is swapper
        Internal error: Oops: 96000004 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 91 Comm: kworker/u16:1 Not tainted 5.15.0-rc1-beanhuo-linaro-1423
        Hardware name: MicronRB (DT)
        Workqueue: events_unbound async_run_entry_fn
        pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : pm_runtime_drop_link+0x128/0x338
        lr : ufshpb_get_dev_info+0x8c/0x148
        sp : ffff800012573c10
        x29: ffff800012573c10 x28: 0000000000000000 x27: 0000000000000003
        x26: ffff000001d21298 x25: 000000005abcea60 x24: ffff800011d89000
        x23: 0000000000000001 x22: ffff000001d21880 x21: ffff000001ec9300
        x20: 0000000000000004 x19: 0000000000000198 x18: ffffffffffffffff
        x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000041400
        x14: 5eee00201100200a x13: 000000000000bb03 x12: 0000000000000000
        x11: 0000000000000100 x10: 0200000000000000 x9 : bb0000021a162c01
        x8 : 0302010021021003 x7 : 0000000000000000 x6 : ffff800012573af0
        x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000200
        x2 : 0000000000000348 x1 : 0000000000000348 x0 : ffff80001095308c
        Call trace:
         pm_runtime_drop_link+0x128/0x338
         ufshpb_get_dev_info+0x8c/0x148
         ufshcd_probe_hba+0xda0/0x11b8
         ufshcd_async_scan+0x34/0x330
         async_run_entry_fn+0x38/0x180
         process_one_work+0x1f4/0x498
         worker_thread+0x48/0x480
         kthread+0x140/0x158
         ret_from_fork+0x10/0x20
        Code: 88027c01 35ffffa2 17fff6c4 f9800051 (885f7c40)
        ---[ end trace 2ba541335f595c95 ]
    
    ufshpb_get_dev_info() is only called during asynchronous scanning and at
    that time pm_runtime_get_sync() has been called:
    
        ...
        /* Hold auto suspend until async scan completes */
        pm_runtime_get_sync(dev);
        atomic_set(&hba->scsi_block_reqs_cnt, 0);
        ...
        ufshcd_async_scan()
            ufshcd_probe_hba(hba, true);
                ufshcd_device_params_init(hba);
                    ufshpb_get_dev_info();
        ...
            pm_runtime_put_sync(hba->dev);
    
    Remove ufshcd_rpm_{get/put}_sync() from ufshpb_get_dev_info() to fix this
    problem.
    
    Link: https://lore.kernel.org/r/20210929200640.828611-2-huobean@gmail.com
    Fixes: 351b3a849ac7 ("scsi: ufs: ufshpb: Use proper power management API")
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5dd6e6426805468e73c7591733c6297287274447
Author: Daejun Park <daejun7.park@samsung.com>
Date:   Thu Sep 2 09:35:34 2021 +0900

    scsi: ufs: ufshpb: Use proper power management API
    
    [ Upstream commit 351b3a849ac7d92449dc75c43db8a857b38387ea ]
    
    In ufshpb, pm_runtime_{get,put}_sync() are used to avoid unwanted runtime
    suspend during query requests. Whereas commit b294ff3e3449 ("scsi: ufs:
    core: Enable power management for wlun") modified the driver core to use
    ufshcd_rpm_{get,put}_sync() APIs.
    
    Switch to these APIs in HPB module as well.
    
    Link: https://lore.kernel.org/r/20210902003534epcms2p1937a0f0eeb48a441cb69f5ef13ff8430@epcms2p1
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Daejun Park <daejun7.park@samsung.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e476c9f63eecfe8fbf39ae3c16ce51f64d3603f
Author: Jackie Liu <liuyun01@kylinos.cn>
Date:   Fri Oct 22 09:02:01 2021 +0800

    scsi: bsg: Fix errno when scsi_bsg_register_queue() fails
    
    [ Upstream commit 5f7cf82c1d7373fcf9e1062f5654efd5fa2b9211 ]
    
    When the value of error is printed, it will always be 0. We should print
    the correct error code when scsi_bsg_register_queue() fails.
    
    Link: https://lore.kernel.org/r/20211022010201.426746-1-liu.yun@linux.dev
    Fixes: ead09dd3aed5 ("scsi: bsg: Simplify device registration")
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 064b6b0592e112d66a14e80d804661adcb941e5a
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Wed Nov 3 09:58:43 2021 -0700

    nvdimm/btt: do not call del_gendisk() if not needed
    
    [ Upstream commit 3aefb5ee843fbe4789d03bb181e190d462df95e4 ]
    
    del_gendisk() should not called if the disk has not been added. Fix this.
    
    Fixes: 41cd8b70c37a ("libnvdimm, btt: add support for blk integrity")
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20211103165843.1402142-1-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e7af8a90a2c98b1f2695046e8e6c38d14363e63
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jun 27 13:46:24 2021 +0200

    PCI: j721e: Fix j721e_pcie_probe() error path
    
    [ Upstream commit 496bb18483cc0474913e81e18a6b313aaea4c120 ]
    
    If an error occurs after a successful cdns_pcie_init_phy() call, it must be
    undone by a cdns_pcie_disable_phy() call, as already done above and below.
    
    Update the goto to branch at the correct place of the error handling path.
    
    Link: https://lore.kernel.org/r/db477b0cb444891a17c4bb424467667dc30d0bab.1624794264.git.christophe.jaillet@wanadoo.fr
    Fixes: 49e0efdce791 ("PCI: j721e: Add support to provide refclk to PCIe connector")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19c65258dde3deec65ee2504702698c7ee1ae6e9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Oct 31 16:31:35 2021 +0100

    ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses
    
    [ Upstream commit 009a789443fe4c8e6b1ecb7c16b4865c026184cd ]
    
    The handling of PMIC register reads through writing 0 to address 4
    of the OpRegion is wrong. Instead of returning the read value
    through the value64, which is a no-op for function == ACPI_WRITE calls,
    store the value and then on a subsequent function == ACPI_READ with
    address == 3 (the address for the value field of the OpRegion)
    return the stored value.
    
    This has been tested on a Xiaomi Mi Pad 2 and makes the ACPI battery dev
    there mostly functional (unfortunately there are still other issues).
    
    Here are the SET() / GET() functions of the PMIC ACPI device,
    which use this OpRegion, which clearly show the new behavior to
    be correct:
    
    OperationRegion (REGS, 0x8F, Zero, 0x50)
    Field (REGS, ByteAcc, NoLock, Preserve)
    {
        CLNT,   8,
        SA,     8,
        OFF,    8,
        VAL,    8,
        RWM,    8
    }
    
    Method (GET, 3, Serialized)
    {
        If ((AVBE == One))
        {
            CLNT = Arg0
            SA = Arg1
            OFF = Arg2
            RWM = Zero
            If ((AVBG == One))
            {
                GPRW = Zero
            }
        }
    
        Return (VAL) /* \_SB_.PCI0.I2C7.PMI5.VAL_ */
    }
    
    Method (SET, 4, Serialized)
    {
        If ((AVBE == One))
        {
            CLNT = Arg0
            SA = Arg1
            OFF = Arg2
            VAL = Arg3
            RWM = One
            If ((AVBG == One))
            {
                GPRW = One
            }
        }
    }
    
    Fixes: 0afa877a5650 ("ACPI / PMIC: intel: add REGS operation region support")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdcdc4c5ae3d2b10fb107a35920a23abc52805df
Author: Daniel Thompson <daniel.thompson@linaro.org>
Date:   Tue Nov 2 17:31:58 2021 +0000

    kdb: Adopt scheduler's task classification
    
    [ Upstream commit b77dbc86d60459b42ab375e4e23172e7245f2854 ]
    
    Currently kdb contains some open-coded routines to generate a summary
    character for each task. This code currently issues warnings, is
    almost certainly broken and won't make sense to any kernel dev who
    has ever used /proc to examine task states.
    
    Fix both the warning and the potential for confusion by adopting the
    scheduler's task classification. Whilst doing this we also simplify the
    filtering by using mask strings directly (which means we don't have to
    guess all the characters the scheduler might give us).
    
    Unfortunately we can't quite match the scheduler classification completely.
    We add four extra states: - for idle loops and i, m and s for sleeping
    system daemons (which means kthreads in one of the I, M and S states).
    These extra states are used to manage the filters for tools to make the
    output of ps and bta less noisy.
    
    Note: The Fixes below is the last point the original dubious code was
          moved; it was not introduced by that patch. However it gives us
          the last point to which this patch can be easily backported.
          Happily that should be enough to cover the introduction of
          CONFIG_WERROR!
    
    Fixes: 2f064a59a11f ("sched: Change task_struct::state")
    Link: https://lore.kernel.org/r/20211102173158.3315227-1-daniel.thompson@linaro.org
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1deba5e29d9f1df0d6aedc8d5e48807233111db4
Author: Brett Creeley <brett.creeley@intel.com>
Date:   Thu Sep 9 14:38:08 2021 -0700

    ice: Fix not stopping Tx queues for VFs
    
    [ Upstream commit b385cca47363316c6d9a74ae9db407bbc281f815 ]
    
    When a VF is removed and/or reset its Tx queues need to be
    stopped from the PF. This is done by calling the ice_dis_vf_qs()
    function, which calls ice_vsi_stop_lan_tx_rings(). Currently
    ice_dis_vf_qs() is protected by the VF state bit ICE_VF_STATE_QS_ENA.
    Unfortunately, this is causing the Tx queues to not be disabled in some
    cases and when the VF tries to re-enable/reconfigure its Tx queues over
    virtchnl the op is failing. This is because a VF can be reset and/or
    removed before the ICE_VF_STATE_QS_ENA bit is set, but the Tx queues
    were already configured via ice_vsi_cfg_single_txq() in the
    VIRTCHNL_OP_CONFIG_VSI_QUEUES op. However, the ICE_VF_STATE_QS_ENA bit
    is set on a successful VIRTCHNL_OP_ENABLE_QUEUES, which will always
    happen after the VIRTCHNL_OP_CONFIG_VSI_QUEUES op.
    
    This was causing the following error message when loading the ice
    driver, creating VFs, and modifying VF trust in an endless loop:
    
    [35274.192484] ice 0000:88:00.0: Failed to set LAN Tx queue context, error: ICE_ERR_PARAM
    [35274.193074] ice 0000:88:00.0: VF 0 failed opcode 6, retval: -5
    [35274.193640] iavf 0000:88:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6
    
    Fix this by always calling ice_dis_vf_qs() and silencing the error
    message in ice_vsi_stop_tx_ring() since the calling code ignores the
    return anyway. Also, all other places that call ice_vsi_stop_tx_ring()
    catch the error, so this doesn't affect those flows since there was no
    change to the values the function returns.
    
    Other solutions were considered (i.e. tracking which VF queues had been
    "started/configured" in VIRTCHNL_OP_CONFIG_VSI_QUEUES, but it seemed
    more complicated than it was worth. This solution also brings in the
    chance for other unexpected conditions due to invalid state bit checks.
    So, the proposed solution seemed like the best option since there is no
    harm in failing to stop Tx queues that were never started.
    
    This issue can be seen using the following commands:
    
    for i in {0..50}; do
            rmmod ice
            modprobe ice
    
            sleep 1
    
            echo 1 > /sys/class/net/ens785f0/device/sriov_numvfs
            echo 1 > /sys/class/net/ens785f1/device/sriov_numvfs
    
            ip link set ens785f1 vf 0 trust on
            ip link set ens785f0 vf 0 trust on
    
            sleep 2
    
            echo 0 > /sys/class/net/ens785f0/device/sriov_numvfs
            echo 0 > /sys/class/net/ens785f1/device/sriov_numvfs
            sleep 1
            echo 1 > /sys/class/net/ens785f0/device/sriov_numvfs
            echo 1 > /sys/class/net/ens785f1/device/sriov_numvfs
    
            ip link set ens785f1 vf 0 trust on
            ip link set ens785f0 vf 0 trust on
    done
    
    Fixes: 77ca27c41705 ("ice: add support for virtchnl_queue_select.[tx|rx]_queues bitmap")
    Signed-off-by: Brett Creeley <brett.creeley@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abf65a2ee78b94de6db1c39233bc0017c6ad1519
Author: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
Date:   Thu May 6 08:40:03 2021 -0700

    ice: Fix replacing VF hardware MAC to existing MAC filter
    
    [ Upstream commit ce572a5b88d5ca6737b5e23da9892792fd708ad3 ]
    
    VF was not able to change its hardware MAC address in case
    the new address was already present in the MAC filter list.
    Change the handling of VF add mac request to not return
    if requested MAC address is already present on the list
    and check if its hardware MAC needs to be updated in this case.
    
    Fixes: ed4c068d46f6 ("ice: Enable ip link show on the PF to display VF unicast MAC(s)")
    Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
    Tested-by: Tony Brelinski <tony.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 932224ba805d16dd42258e792224c6050b9f92ce
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Nov 2 21:31:22 2021 +0200

    net: dsa: felix: fix broken VLAN-tagged PTP under VLAN-aware bridge
    
    [ Upstream commit 92f62485b3715882cd397b0cbd80a96d179b86d6 ]
    
    Normally it is expected that the dsa_device_ops :: rcv() method finishes
    parsing the DSA tag and consumes it, then never looks at it again.
    
    But commit c0bcf537667c ("net: dsa: ocelot: add hardware timestamping
    support for Felix") added support for RX timestamping in a very
    unconventional way. On this switch, a partial timestamp is available in
    the DSA header, but the driver got away with not parsing that timestamp
    right away, but instead delayed that parsing for a little longer:
    
    dsa_switch_rcv():
            nskb = cpu_dp->rcv(skb, dev); <------------- not here
            -> ocelot_rcv()
            ...
    
            skb = nskb;
            skb_push(skb, ETH_HLEN);
            skb->pkt_type = PACKET_HOST;
            skb->protocol = eth_type_trans(skb, skb->dev);
    
            ...
    
            if (dsa_skb_defer_rx_timestamp(p, skb)) <--- but here
            -> felix_rxtstamp()
                    return 0;
    
    When in felix_rxtstamp(), this driver accounted for the fact that
    eth_type_trans() happened in the meanwhile, so it got a hold of the
    extraction header again by subtracting (ETH_HLEN + OCELOT_TAG_LEN) bytes
    from the current skb->data.
    
    This worked for quite some time but was quite fragile from the very
    beginning. Not to mention that having DSA tag parsing split in two
    different files, under different folders (net/dsa/tag_ocelot.c vs
    drivers/net/dsa/ocelot/felix.c) made it quite non-obvious for patches to
    come that they might break this.
    
    Finally, the blamed commit does the following: at the end of
    ocelot_rcv(), it checks whether the skb payload contains a VLAN header.
    If it does, and this port is under a VLAN-aware bridge, that VLAN ID
    might not be correct in the sense that the packet might have suffered
    VLAN rewriting due to TCAM rules (VCAP IS1). So we consume the VLAN ID
    from the skb payload using __skb_vlan_pop(), and take the classified
    VLAN ID from the DSA tag, and construct a hwaccel VLAN tag with the
    classified VLAN, and the skb payload is VLAN-untagged.
    
    The big problem is that __skb_vlan_pop() does:
    
            memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
            __skb_pull(skb, VLAN_HLEN);
    
    aka it moves the Ethernet header 4 bytes to the right, and pulls 4 bytes
    from the skb headroom (effectively also moving skb->data, by definition).
    So for felix_rxtstamp()'s fragile logic, all bets are off now.
    Instead of having the "extraction" pointer point to the DSA header,
    it actually points to 4 bytes _inside_ the extraction header.
    Corollary, the last 4 bytes of the "extraction" header are in fact 4
    stale bytes of the destination MAC address from the Ethernet header,
    from prior to the __skb_vlan_pop() movement.
    
    So of course, RX timestamps are completely bogus when the system is
    configured in this way.
    
    The fix is actually very simple: just don't structure the code like that.
    For better or worse, the DSA PTP timestamping API does not offer a
    straightforward way for drivers to present their RX timestamps, but
    other drivers (sja1105) have established a simple mechanism to carry
    their RX timestamp from dsa_device_ops :: rcv() all the way to
    dsa_switch_ops :: port_rxtstamp() and even later. That mechanism is to
    simply save the partial timestamp to the skb->cb, and complete it later.
    
    Question: why don't we simply populate the skb's struct
    skb_shared_hwtstamps from ocelot_rcv(), and bother with this
    complication of propagating the timestamp to felix_rxtstamp()?
    
    Answer: dsa_switch_ops :: port_rxtstamp() answers the question whether
    PTP packets need sleepable context to retrieve the full RX timestamp.
    Currently felix_rxtstamp() answers "no, thanks" to that question, and
    calls ocelot_ptp_gettime64() from softirq atomic context. This is
    understandable, since Felix VSC9959 is a PCIe memory-mapped switch, so
    hardware access does not require sleeping. But the felix driver is
    preparing for the introduction of other switches where hardware access
    is over a slow bus like SPI or MDIO:
    https://lore.kernel.org/lkml/20210814025003.2449143-1-colin.foster@in-advantage.com/
    
    So I would like to keep this code structure, so the rework needed when
    that driver will need PTP support will be minimal (answer "yes, I need
    deferred context for this skb's RX timestamp", then the partial
    timestamp will still be found in the skb->cb.
    
    Fixes: ea440cd2d9b2 ("net: dsa: tag_ocelot: use VLAN information from tagging header when available")
    Reported-by: Po Liu <po.liu@nxp.com>
    Cc: Yangbo Lu <yangbo.lu@nxp.com>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21032425c36ff85f16e72ca92193a8c401e4acd5
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Tue Nov 2 10:12:18 2021 +0800

    net: vlan: fix a UAF in vlan_dev_real_dev()
    
    [ Upstream commit 563bcbae3ba233c275c244bfce2efe12938f5363 ]
    
    The real_dev of a vlan net_device may be freed after
    unregister_vlan_dev(). Access the real_dev continually by
    vlan_dev_real_dev() will trigger the UAF problem for the
    real_dev like following:
    
    ==================================================================
    BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120
    Call Trace:
     kasan_report.cold+0x83/0xdf
     vlan_dev_real_dev+0xf9/0x120
     is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0
     is_eth_port_of_netdev_filter+0x28/0x40
     ib_enum_roce_netdev+0x1a3/0x300
     ib_enum_all_roce_netdevs+0xc7/0x140
     netdevice_event_work_handler+0x9d/0x210
    ...
    
    Freed by task 9288:
     kasan_save_stack+0x1b/0x40
     kasan_set_track+0x1c/0x30
     kasan_set_free_info+0x20/0x30
     __kasan_slab_free+0xfc/0x130
     slab_free_freelist_hook+0xdd/0x240
     kfree+0xe4/0x690
     kvfree+0x42/0x50
     device_release+0x9f/0x240
     kobject_put+0x1c8/0x530
     put_device+0x1b/0x30
     free_netdev+0x370/0x540
     ppp_destroy_interface+0x313/0x3d0
    ...
    
    Move the put_device(real_dev) to vlan_dev_free(). Ensure
    real_dev not be freed before vlan_dev unregistered.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+e4df4e1389e28972e955@syzkaller.appspotmail.com
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f48a13b3ec59d1bcd7d1efe04b222f433c4a76e1
Author: Stafford Horne <shorne@gmail.com>
Date:   Wed Nov 3 20:19:33 2021 +0900

    openrisc: fix SMP tlb flush NULL pointer dereference
    
    [ Upstream commit 27dff9a9c247d4e38d82c2e7234914cfe8499294 ]
    
    Throughout the OpenRISC kernel port VMA is passed as NULL when flushing
    kernel tlb entries.  Somehow this was missed when I was testing
    c28b27416da9 ("openrisc: Implement proper SMP tlb flushing") and now the
    SMP kernel fails to completely boot.
    
    In OpenRISC VMA is used only to determine which cores need to have their
    TLB entries flushed.
    
    This patch updates the logic to flush tlbs on all cores when the VMA is
    passed as NULL.  Also, we update places VMA is passed as NULL to use
    flush_tlb_kernel_range instead.  Now, the only place VMA is passed as
    NULL is in the implementation of flush_tlb_kernel_range.
    
    Fixes: c28b27416da9 ("openrisc: Implement proper SMP tlb flushing")
    Reported-by: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e746ef502c9aa6801eafad4b76d4a5c62660bef
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Nov 2 15:02:36 2021 -0700

    ethtool: fix ethtool msg len calculation for pause stats
    
    [ Upstream commit 1aabe578dd86e9f2867c4db4fba9a15f4ba1825d ]
    
    ETHTOOL_A_PAUSE_STAT_MAX is the MAX attribute id,
    so we need to subtract non-stats and add one to
    get a count (IOW -2+1 == -1).
    
    Otherwise we'll see:
    
      ethnl cmd 21: calculated reply length 40, but consumed 52
    
    Fixes: 9a27a33027f2 ("ethtool: add standard pause stats")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 351237a76e3fa1470f0c77f39074f4599085855d
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Nov 3 10:44:59 2021 +0800

    kselftests/net: add missed toeplitz.sh/toeplitz_client.sh to Makefile
    
    [ Upstream commit 17b67370c38de2a878debf39dcbc704a206af4d0 ]
    
    When generating the selftests to another folder, the toeplitz.sh
    and toeplitz_client.sh are missing as they are not in Makefile, e.g.
    
      make -C tools/testing/selftests/ install \
          TARGETS="net" INSTALL_PATH=/tmp/kselftests
    
    Making them under TEST_PROGS_EXTENDED as they test NIC hardware features
    and are not intended to be run from kselftests.
    
    Fixes: 5ebfb4cc3048 ("selftests/net: toeplitz test")
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fca8095c4206d8e3dbda57042b6e135082d9cef2
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Nov 3 10:44:58 2021 +0800

    kselftests/net: add missed vrf_strict_mode_test.sh test to Makefile
    
    [ Upstream commit 8883deb50eb6529ae1fd4641e402da8ab4f720d2 ]
    
    When generating the selftests to another folder, the
    vrf_strict_mode_test.sh test will miss as it is not in Makefile, e.g.
    
      make -C tools/testing/selftests/ install \
          TARGETS="net" INSTALL_PATH=/tmp/kselftests
    
    Fixes: 8735e6eaa438 ("selftests: add selftest for the VRF strict mode")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14a49eb8dcd10094643cdd04531f4a62a7b28a1c
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Nov 3 10:44:57 2021 +0800

    kselftests/net: add missed SRv6 tests
    
    [ Upstream commit 653e7f19b4a0a632cead2390281bde352d3d3273 ]
    
    When generating the selftests to another folder, the SRv6 tests are
    missing as they are not in Makefile, e.g.
    
      make -C tools/testing/selftests/ install \
          TARGETS="net" INSTALL_PATH=/tmp/kselftests
    
    Fixes: 03a0b567a03d ("selftests: seg6: add selftest for SRv6 End.DT46 Behavior")
    Fixes: 2195444e09b4 ("selftests: add selftest for the SRv6 End.DT4 behavior")
    Fixes: 2bc035538e16 ("selftests: add selftest for the SRv6 End.DT6 (VRF) behavior")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19f67358b60036a1489021ee46f244ab3ab933b0
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Nov 3 10:44:56 2021 +0800

    kselftests/net: add missed setup_loopback.sh/setup_veth.sh to Makefile
    
    [ Upstream commit b99ac1841147eefd8d8b52fcf00d7d917949ae7f ]
    
    When generating the selftests to another folder, the include file
    setup_loopback.sh/setup_veth.sh for gro.sh/gre_gro.sh are missing as
    they are not in Makefile, e.g.
    
      make -C tools/testing/selftests/ install \
          TARGETS="net" INSTALL_PATH=/tmp/kselftests
    
    Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test")
    Fixes: 9af771d2ec04 ("selftests/net: allow GRO coalesce test on veth")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13bf487e33d657e13635f3d8a672d3b564e3f023
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Nov 3 10:44:55 2021 +0800

    kselftests/net: add missed icmp.sh test to Makefile
    
    [ Upstream commit ca3676f94b8f40f52d285f9aef36dfd6725bfc14 ]
    
    When generating the selftests to another folder, the icmp.sh test will
    miss as it is not in Makefile, e.g.
    
      make -C tools/testing/selftests/ install \
          TARGETS="net" INSTALL_PATH=/tmp/kselftests
    
    Fixes: 7e9838b7915e ("selftests/net: Add icmp.sh for testing ICMP dummy address responses")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c806a70fa4ca543bcb273682f9f15f18bcf42c7
Author: Maxim Kiselev <bigunclemax@gmail.com>
Date:   Mon Nov 1 18:23:41 2021 +0300

    net: davinci_emac: Fix interrupt pacing disable
    
    [ Upstream commit d52bcb47bdf971a59a2467975d2405fcfcb2fa19 ]
    
    This patch allows to use 0 for `coal->rx_coalesce_usecs` param to
    disable rx irq coalescing.
    
    Previously we could enable rx irq coalescing via ethtool
    (For ex: `ethtool -C eth0 rx-usecs 2000`) but we couldn't disable
    it because this part rejects 0 value:
    
           if (!coal->rx_coalesce_usecs)
                   return -EINVAL;
    
    Fixes: 84da2658a619 ("TI DaVinci EMAC : Implement interrupt pacing functionality.")
    Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
    Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Link: https://lore.kernel.org/r/20211101152343.4193233-1-bigunclemax@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd63d080b9e88e9903f4466f79def4ddec072d2e
Author: Beld Zhang <beldzhang@gmail.com>
Date:   Tue Nov 2 12:32:08 2021 -0600

    io-wq: fix max-workers not correctly set on multi-node system
    
    [ Upstream commit 71c9ce27bb57c59d8d7f5298e730c8096eef3d1f ]
    
    In io-wq.c:io_wq_max_workers(), new_count[] was changed right after each
    node's value was set. This caused the following node getting the setting
    of the previous one.
    
    Returned values are copied from node 0.
    
    Fixes: 2e480058ddc2 ("io-wq: provide a way to limit max number of workers")
    Signed-off-by: Beld Zhang <beldzhang@gmail.com>
    [axboe: minor fixups]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e99270d7f2731f532831923b9dd35b7be79158fe
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Nov 2 09:52:35 2021 +0800

    nbd: fix possible overflow for 'first_minor' in nbd_dev_add()
    
    [ Upstream commit 940c264984fd1457918393c49674f6b39ee16506 ]
    
    If 'part_shift' is not zero, then 'index << part_shift' might
    overflow to a value that is not greater than '0xfffff', then sysfs
    might complains about duplicate creation.
    
    Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20211102015237.2309763-3-yebin10@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 795e6b378692d8cf6fd4d1328d8f3e39c36c1e12
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Nov 2 09:52:34 2021 +0800

    nbd: fix max value for 'first_minor'
    
    [ Upstream commit e4c4871a73944353ea23e319de27ef73ce546623 ]
    
    commit b1a811633f73 ("block: nbd: add sanity check for first_minor")
    checks that 'first_minor' should not be greater than 0xff, which is
    wrong. Whitout the commit, the details that when user pass 0x100000,
    it ends up create sysfs dir "/sys/block/43:0" are as follows:
    
    nbd_dev_add
     disk->first_minor = index << part_shift
      -> default part_shift is 5, first_minor is 0x2000000
      device_add_disk
       ddev->devt = MKDEV(disk->major, disk->first_minor)
        -> (0x2b << 20) | (0x2000000) = 0x2b00000
       device_add
        device_create_sys_dev_entry
             format_dev_t
              sprintf(buffer, "%u:%u", MAJOR(dev), MINOR(dev));
               -> got 43:0
              sysfs_create_link -> /sys/block/43:0
    
    By the way, with the wrong fix, when part_shift is the default value,
    only 8 ndb devices can be created since 8 << 5 is greater than 0xff.
    
    Since the max bits for 'first_minor' should be the same as what
    MKDEV() does, which is 20. Change the upper bound of 'first_minor'
    from 0xff to 0xfffff.
    
    Fixes: b1a811633f73 ("block: nbd: add sanity check for first_minor")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20211102015237.2309763-2-yebin10@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f314286463bca5051eb20ba67dbc712959154122
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Oct 8 15:44:17 2021 +0800

    xen-pciback: Fix return in pm_ctrl_init()
    
    [ Upstream commit 4745ea2628bb43a7ec34b71763b5a56407b33990 ]
    
    Return NULL instead of passing to ERR_PTR while err is zero,
    this fix smatch warnings:
    drivers/xen/xen-pciback/conf_space_capability.c:163
     pm_ctrl_init() warn: passing zero to 'ERR_PTR'
    
    Fixes: a92336a1176b ("xen/pciback: Drop two backends, squash and cleanup some code.")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20211008074417.8260-1-yuehaibing@huawei.com
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db651ace499c5c81408ce333cf065d1b4dd734d9
Author: Sander Vanheule <sander@svanheule.net>
Date:   Thu Oct 28 10:52:43 2021 +0200

    gpio: realtek-otto: fix GPIO line IRQ offset
    
    [ Upstream commit 585a07079909ba9061ddd88214c36653e1aef71a ]
    
    The irqchip uses one domain for all GPIO lines, so the line offset
    should be determined w.r.t. the first line of the first port, not the
    first line of the triggered port.
    
    Fixes: 0d82fb1127fb ("gpio: Add Realtek Otto GPIO support")
    Signed-off-by: Sander Vanheule <sander@svanheule.net>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01e189372d4871fb516966c145810f6262184c9f
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Aug 19 22:48:08 2021 +0200

    i2c: xlr: Fix a resource leak in the error handling path of 'xlr_i2c_probe()'
    
    [ Upstream commit 7f98960c046ee1136e7096aee168eda03aef8a5d ]
    
    A successful 'clk_prepare()' call should be balanced by a corresponding
    'clk_unprepare()' call in the error handling path of the probe, as already
    done in the remove function.
    
    More specifically, 'clk_prepare_enable()' is used, but 'clk_disable()' is
    also already called. So just the unprepare step has still to be done.
    
    Update the error handling path accordingly.
    
    Fixes: 75d31c2372e4 ("i2c: xlr: add support for Sigma Designs controller variant")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b12e19315699274ca6f7d59bcceabf62b891729
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Mon Oct 25 08:01:04 2021 -0700

    dmaengine: idxd: fix resource leak on dmaengine driver disable
    
    [ Upstream commit a3e340c1574b6679f5b333221284d0959095da52 ]
    
    The wq resources needs to be released before the kernel type is reset by
    __drv_disable_wq(). With dma channels unregistered and wq quiesced, all the
    wq resources for dmaengine can be freed. There is no need to wait until wq
    is disabled. With the wq->type being reset to "unknown", the driver is
    skipping the freeing of the resources.
    
    Fixes: 0cda4f6986a3 ("dmaengine: idxd: create dmaengine driver for wq 'device'")
    Reported-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Tested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/163517405099.3484556.12521975053711345244.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b882818aec13f532ac2238025bf53bd151e9a2e
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Oct 26 21:56:40 2021 -0400

    NFSv4: Fix a regression in nfs_set_open_stateid_locked()
    
    [ Upstream commit 01d29f87fcfef38d51ce2b473981a5c1e861ac0a ]
    
    If we already hold open state on the client, yet the server gives us a
    completely different stateid to the one we already hold, then we
    currently treat it as if it were an out-of-sequence update, and wait for
    5 seconds for other updates to come in.
    This commit fixes the behaviour so that we immediately start processing
    of the new stateid, and then leave it to the call to
    nfs4_test_and_free_stateid() to decide what to do with the old stateid.
    
    Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b7e3d5ee357d5bde3ebb0c0239bc78518b82c6f
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:11 2021 -0700

    scsi: qla2xxx: edif: Fix EDIF bsg
    
    [ Upstream commit 9fd26c633e8ab5a291c0241533efff161bbe5570 ]
    
    Various EDIF bsgs did not properly fill out the reply_payload_rcv_len
    field. This causes app to parse empty data in the return payload.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-13-njavali@marvell.com
    Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e56d80025ed0cdec94e3b0b19f1319318df6473d
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:09 2021 -0700

    scsi: qla2xxx: edif: Increase ELS payload
    
    [ Upstream commit 0f6d600a26e89d31d8381b324fc970f72579a126 ]
    
    Currently, firmware limits ELS payload to FC frame size/2112.  This patch
    adjusts memory buffer size to be able to handle max ELS payload.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-11-njavali@marvell.com
    Fixes: 84318a9f01ce ("scsi: qla2xxx: edif: Add send, receive, and accept for auth_els")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aac0a76cb318f1c0afb4fac41d8325831bf3e70e
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:05 2021 -0700

    scsi: qla2xxx: edif: Flush stale events and msgs on session down
    
    [ Upstream commit b1af26c245545a289b331c7b71996ecd88321540 ]
    
    On session down, driver will flush all stale messages and doorbell
    events. This prevents authentication application from having to process
    stale data.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-7-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Co-developed-by: Karunakara Merugu <kmerugu@marvell.com>
    Signed-off-by: Karunakara Merugu <kmerugu@marvell.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dcd0c5e7dec2b2e37acad28ea3c8210e7be6a79b
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:04 2021 -0700

    scsi: qla2xxx: edif: Fix app start delay
    
    [ Upstream commit b492d6a4880fddce098472dec5086d37802c68d3 ]
    
    Current driver does unnecessary pause for each session to get to certain
    state before allowing the app start call to return. In larger environment,
    this introduces a long delay.  Originally the delay was meant to
    synchronize app and driver. However, the with current implementation the
    two sides use various events to synchronize their state.
    
    The same is applied to the authentication failure call.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-6-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 696815ee50f6ccb36416cbc40236e7fa624b0fbf
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:03 2021 -0700

    scsi: qla2xxx: edif: Fix app start fail
    
    [ Upstream commit 8e6d5df3cb32dddf558a52414d29febecb660396 ]
    
    On app start, all sessions need to be reset to see if secure connection can
    be made. Fix the broken check which prevents that process.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-5-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09e4dafeca9b249377b145f05e2c9f8bdfc45b07
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:02 2021 -0700

    scsi: qla2xxx: Turn off target reset during issue_lip
    
    [ Upstream commit 0b7a9fd934a68ebfc1019811b7bdc1742072ad7b ]
    
    When user uses issue_lip to do link bounce, driver sends additional target
    reset to remote device before resetting the link. The target reset would
    affect other paths with active I/Os. This patch will remove the unnecessary
    target reset.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-4-njavali@marvell.com
    Fixes: 5854771e314e ("[SCSI] qla2xxx: Add ISPFX00 specific bus reset routine")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 411ca50eab274a5de20e7f167deecf75d7049c6a
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:01 2021 -0700

    scsi: qla2xxx: Fix gnl list corruption
    
    [ Upstream commit c98c5daaa24b583cba1369b7d167f93c6ae7299c ]
    
    Current code does list element deletion and addition in and out of lock
    protection. This patch moves deletion behind lock.
    
    list_add double add: new=ffff9130b5eb89f8, prev=ffff9130b5eb89f8,
        next=ffff9130c6a715f0.
     ------------[ cut here ]------------
     kernel BUG at lib/list_debug.c:31!
     invalid opcode: 0000 [#1] SMP PTI
     CPU: 1 PID: 182395 Comm: kworker/1:37 Kdump: loaded Tainted: G W  OE
     --------- -  - 4.18.0-193.el8.x86_64 #1
     Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014
     Workqueue: qla2xxx_wq qla2x00_iocb_work_fn [qla2xxx]
     RIP: 0010:__list_add_valid+0x41/0x50
     Code: 85 94 00 00 00 48 39 c7 74 0b 48 39 d7 74 06 b8 01 00 00 00 c3 48 89 f2
     4c 89 c1 48 89 fe 48 c7 c7 60 83 ad 97 e8 4d bd ce ff <0f> 0b 0f 1f 00 66 2e
     0f 1f 84 00 00 00 00 00 48 8b 07 48 8b 57 08
     RSP: 0018:ffffaba306f47d68 EFLAGS: 00010046
     RAX: 0000000000000058 RBX: ffff9130b5eb8800 RCX: 0000000000000006
     RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff9130b7456a00
     RBP: ffff9130c6a70a58 R08: 000000000008d7be R09: 0000000000000001
     R10: 0000000000000000 R11: 0000000000000001 R12: ffff9130c6a715f0
     R13: ffff9130b5eb8824 R14: ffff9130b5eb89f8 R15: ffff9130b5eb89f8
     FS:  0000000000000000(0000) GS:ffff9130b7440000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007efcaaef11a0 CR3: 000000005200a002 CR4: 00000000000606e0
     Call Trace:
      qla24xx_async_gnl+0x113/0x3c0 [qla2xxx]
      ? qla2x00_iocb_work_fn+0x53/0x80 [qla2xxx]
      ? process_one_work+0x1a7/0x3b0
      ? worker_thread+0x30/0x390
      ? create_worker+0x1a0/0x1a0
      ? kthread+0x112/0x130
    
    Link: https://lore.kernel.org/r/20211026115412.27691-3-njavali@marvell.com
    Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ee1c31ce9df4b6dd198b88415cbd1fc60502f16
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Oct 26 04:54:00 2021 -0700

    scsi: qla2xxx: Relogin during fabric disturbance
    
    [ Upstream commit bb2ca6b3f09ac20e8357d257d0557ab5ddf6adcd ]
    
    For RSCN of type "Area, Domain, or Fabric", which indicate a portion or
    entire fabric was disturbed, current driver does not set the scan_need flag
    to indicate a session was affected by the disturbance. This in turn can
    lead to I/O timeout and delay of relogin. Hence initiate relogin in the
    event of fabric disturbance.
    
    Link: https://lore.kernel.org/r/20211026115412.27691-2-njavali@marvell.com
    Fixes: 1560bafdff9e ("scsi: qla2xxx: Use complete switch scan for RSCN events")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b65e9044be04869614062241d101915d1aec1504
Author: Dmitry Bogdanov <d.bogdanov@yadro.com>
Date:   Mon Oct 18 16:57:53 2021 +0300

    scsi: target: core: Remove from tmr_list during LUN unlink
    
    [ Upstream commit 12b6fcd0ea7f3cb7c3b34668fc678779924123ae ]
    
    Currently TMF commands are removed from de_device.dev_tmf_list at the very
    end of se_cmd lifecycle. However, se_lun unlinks from se_cmd upon a command
    status (response) being queued in transport layer. This means that LUN and
    backend device can be deleted in the meantime and a panic will occur:
    
    target_tmr_work()
            cmd->se_tfo->queue_tm_rsp(cmd); // send abort_rsp to a wire
            transport_lun_remove_cmd(cmd) // unlink se_cmd from se_lun
    - // - // - // -
    <<<--- lun remove
    <<<--- core backend device remove
    - // - // - // -
    qlt_handle_abts_completion()
      tfo->free_mcmd()
        transport_generic_free_cmd()
          target_put_sess_cmd()
            core_tmr_release_req() {
              if (dev) { // backend device, can not be null
                spin_lock_irqsave(&dev->se_tmr_lock, flags); //<<<--- CRASH
    
    Call Trace:
    NIP [c000000000e1683c] _raw_spin_lock_irqsave+0x2c/0xc0
    LR [c00800000e433338] core_tmr_release_req+0x40/0xa0 [target_core_mod]
    Call Trace:
    (unreliable)
    0x0
    target_put_sess_cmd+0x2a0/0x370 [target_core_mod]
    transport_generic_free_cmd+0x6c/0x1b0 [target_core_mod]
    tcm_qla2xxx_complete_mcmd+0x28/0x50 [tcm_qla2xxx]
    process_one_work+0x2c4/0x5c0
    worker_thread+0x88/0x690
    
    For the iSCSI protocol this is easily reproduced:
    
     - Send some SCSI sommand
    
     - Send Abort of that command over iSCSI
    
     - Remove LUN on target
    
     - Send next iSCSI command to acknowledge the Abort_Response
    
     - Target panics
    
    There is no need to keep the command in tmr_list until response completion,
    so move the removal from tmr_list from the response completion to the
    response queueing when the LUN is unlinked.  Move the removal from state
    list too as it is a subject to the same race condition.
    
    Link: https://lore.kernel.org/r/20211018135753.15297-1-d.bogdanov@yadro.com
    Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6")
    Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb63b768afca85740b7918d8f87cd5c9add710fc
Author: Jackie Liu <liuyun01@kylinos.cn>
Date:   Tue Sep 7 10:49:04 2021 +0800

    ar7: fix kernel builds for compiler test
    
    [ Upstream commit 28b7ee33a2122569ac065cad578bf23f50cc65c3 ]
    
    TI AR7 Watchdog Timer is only build for 32bit.
    
    Avoid error like:
    In file included from drivers/watchdog/ar7_wdt.c:29:
    ./arch/mips/include/asm/mach-ar7/ar7.h: In function ‘ar7_is_titan’:
    ./arch/mips/include/asm/mach-ar7/ar7.h:111:24: error: implicit declaration of function ‘KSEG1ADDR’; did you mean ‘CKSEG1ADDR’? [-Werror=implicit-function-declaration]
      111 |  return (readl((void *)KSEG1ADDR(AR7_REGS_GPIO + 0x24)) & 0xffff) ==
          |                        ^~~~~~~~~
          |                        CKSEG1ADDR
    
    Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
    Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20210907024904.4127611-1-liu.yun@linux.dev
    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 e5f9487c06bd1371f9698d4d80d5e68c158fec7a
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Mon Aug 9 18:20:31 2021 +0200

    watchdog: f71808e_wdt: fix inaccurate report in WDIOC_GETTIMEOUT
    
    [ Upstream commit 164483c735190775f29d0dcbac0363adc51a068d ]
    
    The fintek watchdog timer can configure timeouts of second granularity
    only up to 255 seconds. Beyond that, the timeout needs to be configured
    with minute granularity. WDIOC_GETTIMEOUT should report the actual
    timeout configured, not just echo back the timeout configured by the
    user. Do so.
    
    Fixes: 96cb4eb019ce ("watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG")
    Suggested-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Link: https://lore.kernel.org/r/5e17960fe8cc0e3cb2ba53de4730b75d9a0f33d5.1628525954.git-series.a.fatoum@pengutronix.de
    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 fb2b4c7b5477f827266dab9b36e02293827c33e1
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Oct 2 17:02:23 2021 -0700

    m68k: set a default value for MEMORY_RESERVE
    
    [ Upstream commit 1aaa557b2db95c9506ed0981bc34505c32d6b62b ]
    
    'make randconfig' can produce a .config file with
    "CONFIG_MEMORY_RESERVE=" (no value) since it has no default.
    When a subsequent 'make all' is done, kconfig restarts the config
    and prompts for a value for MEMORY_RESERVE. This breaks
    scripting/automation where there is no interactive user input.
    
    Add a default value for MEMORY_RESERVE. (Any integer value will
    work here for kconfig.)
    
    Fixes a kconfig warning:
    
    .config:214:warning: symbol value '' invalid for MEMORY_RESERVE
    * Restart config...
    Memory reservation (MiB) (MEMORY_RESERVE) [] (NEW)
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") # from beginning of git history
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Greg Ungerer <gerg@linux-m68k.org>
    Cc: linux-m68k@lists.linux-m68k.org
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f072ec8b41b783ceb98e9893896a73e7f746de8
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Oct 20 12:43:52 2021 -0500

    signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL)
    
    [ Upstream commit ce0ee4e6ac99606f3945f4d47775544edc3f7985 ]
    
    Today the sh code allocates memory the first time a process uses
    the fpu.  If that memory allocation fails, kill the affected task
    with force_sig(SIGKILL) rather than do_group_exit(SIGKILL).
    
    Calling do_group_exit from an exception handler can potentially lead
    to dead locks as do_group_exit is not designed to be called from
    interrupt context.  Instead use force_sig(SIGKILL) to kill the
    userspace process.  Sending signals in general and force_sig in
    particular has been tested from interrupt context so there should be
    no problems.
    
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: linux-sh@vger.kernel.org
    Fixes: 0ea820cf9bf5 ("sh: Move over to dynamically allocated FPU context.")
    Link: https://lkml.kernel.org/r/20211020174406.17889-6-ebiederm@xmission.com
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 671dd8b385b29d7813f03bde85315c46264dbd23
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Wed Sep 1 17:18:05 2021 -0700

    dmaengine: idxd: reconfig device after device reset command
    
    [ Upstream commit e530a9f3db4188d1f4e3704b0948ef69c04d5ca6 ]
    
    Device reset clears the MSIXPERM table and the device registers. Re-program
    the MSIXPERM table and re-enable the error interrupts post reset.
    
    Fixes: 745e92a6d816 ("dmaengine: idxd: idxd: move remove() bits for idxd 'struct device' to device.c")
    Reported-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/163054188513.2853562.12077053294595278181.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1b9ef3abafa72b83dc77f59bc11469e20ed730b
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Sep 21 13:15:58 2021 -0700

    dmanegine: idxd: fix resource free ordering on driver removal
    
    [ Upstream commit 98da0106aac0d3c5d4a3c95d238f1ff88957bbfc ]
    
    Fault triggers on ioread32() when pci driver unbind is envoked. The
    placement of idxd sub-driver removal causes the probing of the device mmio
    region after the mmio mapping being torn down. The driver needs the
    sub-drivers to be unbound but not release the idxd context until all
    shutdown activities has been done. Move the sub-driver unregistering up
    before the remove() calls shutdown(). But take a device ref on the
    idxd->conf_dev so that the memory does not get freed in ->release(). When
    all cleanup activities has been done, release the ref to allow the idxd
    memory to be freed.
    
    [57159.542766] RIP: 0010:ioread32+0x27/0x60
    [57159.547097] Code: 00 66 90 48 81 ff ff ff 03 00 77 1e 48 81 ff 00 00 01 00 76 05 0f
     b7 d7 ed c3 8b 15 03 50 41 01 b8 ff ff ff ff 85 d2 75 04 c3 <8b> 07 c3 55 83 ea 01 48
     89 fe 48 c7 c7 00 70 5f 82 48 89 e5 48 83
    [57159.566647] RSP: 0018:ffffc900011abb60 EFLAGS: 00010292
    [57159.572295] RAX: ffffc900011e0000 RBX: ffff888107d39800 RCX: 0000000000000000
    [57159.579842] RDX: 0000000000000000 RSI: ffffffff82b1e448 RDI: ffffc900011e0090
    [57159.587421] RBP: ffffc900011abb88 R08: 0000000000000000 R09: 0000000000000001
    [57159.594972] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881019840d0
    [57159.602533] R13: ffff8881097e9000 R14: ffffffffa08542a0 R15: 00000000000003a8
    [57159.610093] FS:  00007f991e0a8740(0000) GS:ffff888459900000(0000) knlGS:00000000000
    00000
    [57159.618614] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [57159.624814] CR2: ffffc900011e0090 CR3: 000000010862a002 CR4: 00000000003706e0
    [57159.632397] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [57159.639973] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [57159.647601] Call Trace:
    [57159.650502]  ? idxd_device_disable+0x41/0x110 [idxd]
    [57159.655948]  idxd_device_drv_remove+0x2b/0x80 [idxd]
    [57159.661374]  idxd_config_bus_remove+0x16/0x20
    [57159.666191]  __device_release_driver+0x163/0x240
    [57159.671320]  device_release_driver+0x2b/0x40
    [57159.676052]  bus_remove_device+0xf5/0x160
    [57159.680524]  device_del+0x19c/0x400
    [57159.684440]  device_unregister+0x18/0x60
    [57159.688792]  idxd_remove+0x140/0x1c0 [idxd]
    [57159.693406]  pci_device_remove+0x3e/0xb0
    [57159.697758]  __device_release_driver+0x163/0x240
    [57159.702788]  device_driver_detach+0x43/0xb0
    [57159.707424]  unbind_store+0x11e/0x130
    [57159.711537]  drv_attr_store+0x24/0x30
    [57159.715646]  sysfs_kf_write+0x4b/0x60
    [57159.719710]  kernfs_fop_write_iter+0x153/0x1e0
    [57159.724563]  new_sync_write+0x120/0x1b0
    [57159.728812]  vfs_write+0x23e/0x350
    [57159.732624]  ksys_write+0x70/0xf0
    [57159.736335]  __x64_sys_write+0x1a/0x20
    [57159.740492]  do_syscall_64+0x3b/0x90
    [57159.744465]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [57159.749908] RIP: 0033:0x7f991e19c387
    [57159.753898] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e
     fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51
     c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
    [57159.773564] RSP: 002b:00007ffc2ce2d6a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [57159.781550] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f991e19c387
    [57159.789133] RDX: 000000000000000c RSI: 000055ee2630e140 RDI: 0000000000000001
    [57159.796695] RBP: 000055ee2630e140 R08: 0000000000000000 R09: 00007f991e2324e0
    [57159.804246] R10: 00007f991e2323e0 R11: 0000000000000246 R12: 000000000000000c
    [57159.811800] R13: 00007f991e26f520 R14: 000000000000000c R15: 00007f991e26f700
    [57159.819373] Modules linked in: idxd bridge stp llc bnep sunrpc nls_iso8859_1 intel_
    rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_code
    c_realtek iTCO_wdt 8250_dw snd_hda_codec_generic kvm_intel ledtrig_audio iTCO_vendor_s
    upport snd_hda_intel snd_intel_dspcfg ppdev kvm snd_hda_codec intel_wmi_thunderbolt sn
    d_hwdep irqbypass iwlwifi btusb snd_hda_core rapl btrtl intel_cstate snd_seq btbcm snd
    _seq_device btintel snd_pcm cfg80211 bluetooth pcspkr psmouse input_leds snd_timer int
    el_lpss_pci mei_me intel_lpss snd ecdh_generic ecc mei ucsi_acpi i2c_i801 idma64 i2c_s
    mbus virt_dma soundcore typec_ucsi typec wmi parport_pc parport video mac_hid acpi_pad
     sch_fq_codel drm ip_tables x_tables crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
     usbkbd hid_generic usbmouse aesni_intel usbhid crypto_simd cryptd e1000e hid serio_ra
    w ahci libahci pinctrl_sunrisepoint fuse msr autofs4 [last unloaded: idxd]
    [57159.904082] CR2: ffffc900011e0090
    [57159.907877] ---[ end trace b4e32f49ce9176a4 ]---
    
    Fixes: 49c4959f04b5 ("dmaengine: idxd: fix sequence for pci driver remove() and shutdown()")
    Reported-by: Ziye Yang <ziye.yang@intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/163225535868.4152687.9318737776682088722.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fb118b077f6cb01d421f44562b2600bfcc25feb
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Thu Oct 21 11:05:38 2021 +0800

    dmaengine: tegra210-adma: fix pm runtime unbalance
    
    [ Upstream commit c5a51fc89c0103c03b8a54cf12dac7d014b3a2bf ]
    
    The previous commit 059e969c2a7d ("dmaengine: tegra210-adma: Using
    pm_runtime_resume_and_get to replace open coding") forgets to replace
    the pm_runtime_get_sync in the tegra_adma_probe, but removes the
    pm_runtime_put_noidle.
    
    Fix this by continuing to replace pm_runtime_get_sync with
    pm_runtime_resume_and_get in tegra_adma_probe.
    
    Fixes: 059e969c2a7d ("dmaengine: tegra210-adma: Using pm_runtime_resume_and_get to replace open coding")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20211021030538.3465287-1-mudongliangabcd@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8bc8be6ce69e23af02a69d6e62194dc254254a21
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Sat Oct 23 15:41:01 2021 +0200

    dmaengine: dmaengine_desc_callback_valid(): Check for `callback_result`
    
    [ Upstream commit e7e1e880b114ca640a2f280b0d5d38aed98f98c6 ]
    
    Before the `callback_result` callback was introduced drivers coded their
    invocation to the callback in a similar way to:
    
            if (cb->callback) {
                    spin_unlock(&dma->lock);
                    cb->callback(cb->callback_param);
                    spin_lock(&dma->lock);
            }
    
    With the introduction of `callback_result` two helpers where introduced to
    transparently handle both types of callbacks. And drivers where updated to
    look like this:
    
            if (dmaengine_desc_callback_valid(cb)) {
                    spin_unlock(&dma->lock);
                    dmaengine_desc_callback_invoke(cb, ...);
                    spin_lock(&dma->lock);
            }
    
    dmaengine_desc_callback_invoke() correctly handles both `callback_result`
    and `callback`. But we forgot to update the dmaengine_desc_callback_valid()
    function to check for `callback_result`. As a result DMA descriptors that
    use the `callback_result` rather than `callback` don't have their callback
    invoked by drivers that follow the pattern above.
    
    Fix this by checking for both `callback` and `callback_result` in
    dmaengine_desc_callback_valid().
    
    Fixes: f067025bc676 ("dmaengine: add support to provide error result from a DMA transation")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20211023134101.28042-1-lars@metafoo.de
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b380c56bb4bff143f3a21fd8f37f4a304749975
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Oct 20 18:08:10 2021 +0200

    netfilter: nfnetlink_queue: fix OOB when mac header was cleared
    
    [ Upstream commit 5648b5e1169ff1d6d6a46c35c0b5fbebd2a5cbb2 ]
    
    On 64bit platforms the MAC header is set to 0xffff on allocation and
    also when a helper like skb_unset_mac_header() is called.
    
    dev_parse_header may call skb_mac_header() which assumes valid mac offset:
    
     BUG: KASAN: use-after-free in eth_header_parse+0x75/0x90
     Read of size 6 at addr ffff8881075a5c05 by task nf-queue/1364
     Call Trace:
      memcpy+0x20/0x60
      eth_header_parse+0x75/0x90
      __nfqnl_enqueue_packet+0x1a61/0x3380
      __nf_queue+0x597/0x1300
      nf_queue+0xf/0x40
      nf_hook_slow+0xed/0x190
      nf_hook+0x184/0x440
      ip_output+0x1c0/0x2a0
      nf_reinject+0x26f/0x700
      nfqnl_recv_verdict+0xa16/0x18b0
      nfnetlink_rcv_msg+0x506/0xe70
    
    The existing code only works if the skb has a mac header.
    
    Fixes: 2c38de4c1f8da7 ("netfilter: fix looped (broad|multi)cast's MAC handling")
    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 9981e39ded4be5a7cfd503fc609e13d7976f82b2
Author: Robert-Ionut Alexa <robert-ionut.alexa@nxp.com>
Date:   Fri Apr 23 12:01:51 2021 +0300

    soc: fsl: dpaa2-console: free buffer before returning from dpaa2_console_read
    
    [ Upstream commit 8120bd469f5525da229953c1197f2b826c0109f4 ]
    
    Free the kbuf buffer before returning from the dpaa2_console_read()
    function. The variable no longer goes out of scope, leaking the storage
    it points to.
    
    Fixes: c93349d8c170 ("soc: fsl: add DPAA2 console support")
    Signed-off-by: Robert-Ionut Alexa <robert-ionut.alexa@nxp.com>
    Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Signed-off-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ccaade05b0047c22128236f0728d3a825ea2b2d
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Oct 19 16:45:09 2021 +0200

    auxdisplay: ht16k33: Fix frame buffer device blanking
    
    [ Upstream commit 840fe258332544aa7321921e1723d37b772af7a9 ]
    
    As the ht16k33 frame buffer sub-driver does not register an
    fb_ops.fb_blank() handler, blanking does not work:
    
        $ echo 1 > /sys/class/graphics/fb0/blank
        sh: write error: Invalid argument
    
    Fix this by providing a handler that always returns zero, to make sure
    blank events will be sent to the actual device handling the backlight.
    
    Reported-by: Robin van der Gracht <robin@protonic.nl>
    Suggested-by: Robin van der Gracht <robin@protonic.nl>
    Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fba8ce59bbd45c609d7636b9e237658211f37447
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Oct 19 16:45:08 2021 +0200

    auxdisplay: ht16k33: Connect backlight to fbdev
    
    [ Upstream commit 80f9eb70fd9276938f0a131f76d438021bfd8b34 ]
    
    Currently /sys/class/graphics/fb0/bl_curve is not accessible (-ENODEV),
    as the driver does not connect the backlight to the frame buffer device.
    Fix this moving backlight initialization up, and filling in
    fb_info.bl_dev.
    
    Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reviewed-by: Robin van der Gracht <robin@protonic.nl>
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6d28153d49fc7a3c342e1d59bb6202360132f5a
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Oct 19 16:45:02 2021 +0200

    auxdisplay: img-ascii-lcd: Fix lock-up when displaying empty string
    
    [ Upstream commit afcb5a811ff3ab3969f09666535eb6018a160358 ]
    
    While writing an empty string to a device attribute is a no-op, and thus
    does not need explicit safeguards, the user can still write a single
    newline to an attribute file:
    
        echo > .../message
    
    If that happens, img_ascii_lcd_display() trims the newline, yielding an
    empty string, and causing an infinite loop in img_ascii_lcd_scroll().
    
    Fix this by adding a check for empty strings.  Clear the display in case
    one is encountered.
    
    Fixes: 0cad855fbd083ee5 ("auxdisplay: img-ascii-lcd: driver for simple ASCII LCD displays")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5204722a964270804d42ebda3312df807882750f
Author: Alexey Gladkov <legion@kernel.org>
Date:   Thu Oct 14 18:02:30 2021 +0200

    Fix user namespace leak
    
    [ Upstream commit d5f458a979650e5ed37212f6134e4ee2b28cb6ed ]
    
    Fixes: 61ca2c4afd9d ("NFS: Only reference user namespace from nfs4idmap struct instead of cred")
    Signed-off-by: Alexey Gladkov <legion@kernel.org>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9bd9732cad66f9b13ff71d8a56959defb65f307
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Oct 5 14:05:02 2021 -0400

    NFS: Fix an Oops in pnfs_mark_request_commit()
    
    [ Upstream commit f0caea8882a7412a2ad4d8274f0280cdf849c9e2 ]
    
    Olga reports seeing the following Oops when doing O_DIRECT writes to a
    pNFS flexfiles server:
    
    Oops: 0000 [#1] SMP PTI
    CPU: 1 PID: 234186 Comm: kworker/u8:1 Not tainted 5.15.0-rc4+ #4
    Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.13.0-2.module+el8.3.0+7353+9de0a3cc 04/01/2014
    Workqueue: nfsiod rpc_async_release [sunrpc]
    RIP: 0010:nfs_mark_request_commit+0x12/0x30 [nfs]
    Code: ff ff be 03 00 00 00 e8 ac 34 83 eb e9 29 ff ff
    ff e8 22 bc d7 eb 66 90 0f 1f 44 00 00 48 85 f6 74 16 48 8b 42 10 48
    8b 40 18 <48> 8b 40 18 48 85 c0 74 05 e9 70 fc 15 ec 48 89 d6 e9 68 ed
    ff ff
    RSP: 0018:ffffa82f0159fe00 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff8f3393141880 RCX: 0000000000000000
    RDX: ffffa82f0159fe08 RSI: ffff8f3381252500 RDI: ffff8f3393141880
    RBP: ffff8f33ac317c00 R08: 0000000000000000 R09: ffff8f3487724cb0
    R10: 0000000000000008 R11: 0000000000000001 R12: 0000000000000001
    R13: ffff8f3485bccee0 R14: ffff8f33ac317c10 R15: ffff8f33ac317cd8
    FS:  0000000000000000(0000) GS:ffff8f34fbc80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000018 CR3: 0000000122120006 CR4: 0000000000770ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     nfs_direct_write_completion+0x13b/0x250 [nfs]
     rpc_free_task+0x39/0x60 [sunrpc]
     rpc_async_release+0x29/0x40 [sunrpc]
     process_one_work+0x1ce/0x370
     worker_thread+0x30/0x380
     ? process_one_work+0x370/0x370
     kthread+0x11a/0x140
     ? set_kthread_struct+0x40/0x40
     ret_from_fork+0x22/0x30
    
    Reported-by: Olga Kornievskaia <aglo@umich.edu>
    Fixes: 9c455a8c1e14 ("NFS/pNFS: Clean up pNFS commit operations")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9443fcc22a6cbe0caf1c83f756a0416e83ddb07f
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Oct 4 15:37:42 2021 -0400

    NFS: Fix up commit deadlocks
    
    [ Upstream commit 133a48abf6ecc535d7eddc6da1c3e4c972445882 ]
    
    If O_DIRECT bumps the commit_info rpcs_out field, then that could lead
    to fsync() hangs. The fix is to ensure that O_DIRECT calls
    nfs_commit_end().
    
    Fixes: 723c921e7dfc ("sched/wait, fs/nfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b07aa21474d3e6c84eb4e3838b6f3da0789f4fdb
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Mon Oct 11 11:42:58 2021 +0200

    dmaengine: stm32-dma: fix stm32_dma_get_max_width
    
    [ Upstream commit b20fd5fa310cbf7ec367f263a34382a24c4cee73 ]
    
    buf_addr parameter of stm32_dma_set_xfer_param function is a dma_addr_t.
    We only need to check the remainder of buf_addr/max_width, so, no need to
    use do_div and extra u64 addr. Use '%' instead.
    
    Fixes: e0ebdbdcb42a ("dmaengine: stm32-dma: take address into account when computing max width")
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20211011094259.315023-3-amelie.delaunay@foss.st.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f12d23bc255d7de760902050df200d0edd3db319
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Oct 7 14:12:28 2021 +0300

    dmaengine: at_xdmac: fix AT_XDMAC_CC_PERID() macro
    
    [ Upstream commit 320c88a3104dc955f928a1eecebd551ff89530c0 ]
    
    AT_XDMAC_CC_PERID() should be used to setup bits 24..30 of XDMAC_CC
    register. Using it without parenthesis around 0x7f & (i) will lead to
    setting all the time zero for bits 24..30 of XDMAC_CC as the << operator
    has higher precedence over bitwise &. Thus, add paranthesis around
    0x7f & (i).
    
    Fixes: 15a03850ab8f ("dmaengine: at_xdmac: fix macro typo")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20211007111230.2331837-3-claudiu.beznea@microchip.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98b727511da8d818c7b7db3cda33a0946ca367d2
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Oct 7 14:12:27 2021 +0300

    dmaengine: at_xdmac: call at_xdmac_axi_config() on resume path
    
    [ Upstream commit fa5270ec2f2688d98a82895be7039b81c87d856c ]
    
    at_xdmac could be used on SoCs which supports backup mode (where most
    of the SoC power, including power to DMA controller, is closed at suspend
    time). Thus, on resume, the settings which were previously done need to be
    restored. Do the same for axi configuration.
    
    Fixes: f40566f220a1 ("dmaengine: at_xdmac: add AXI priority support and recommended settings")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20211007111230.2331837-2-claudiu.beznea@microchip.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1976e7b3c03395d8b8baf921315e5985a8de85f8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 12 13:10:28 2021 +0300

    rtc: rv3032: fix error handling in rv3032_clkout_set_rate()
    
    [ Upstream commit c3336b8ac6091df60a5c1049a8c685d0b947cc61 ]
    
    Do not call rv3032_exit_eerd() if the enter function fails but don't
    forget to call the exit when the enter succeeds.
    
    Fixes: 2eeaa532acca ("rtc: rv3032: Add a driver for Microcrystal RV-3032")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20211012101028.GT2083@kadam
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84ea6245dc023f0919253790254e382f71ff4b88
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Sep 4 13:37:32 2021 +0200

    remoteproc: Fix a memory leak in an error handling path in 'rproc_handle_vdev()'
    
    [ Upstream commit 0374a4ea7269645c46c3eb288526ea072fa19e79 ]
    
    If 'copy_dma_range_map() fails, the memory allocated for 'rvdev' will leak.
    Move the 'copy_dma_range_map()' call after the device registration so
    that 'rproc_rvdev_release()' can be called to free some resources.
    
    Also, branch to the error handling path if 'copy_dma_range_map()' instead
    of a direct return to avoid some other leaks.
    
    Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Jim Quinlan <james.quinlan@broadcom.com>
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/e6d0dad6620da4fdf847faa903f79b735d35f262.1630755377.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62eaaa154c8fce93ef35685cca30a6fcb577509e
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Thu Oct 14 13:39:52 2021 -0700

    mtd: core: don't remove debugfs directory if device is in use
    
    [ Upstream commit c13de2386c78e890d4ae6f01a85eefd0b293fb08 ]
    
    Previously, if del_mtd_device() failed with -EBUSY due to a non-zero
    usecount, a subsequent call to attempt the deletion again would try to
    remove a debugfs directory that had already been removed and panic.
    With this change the second call can instead proceed safely.
    
    Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries")
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20211014203953.5424-1-zev@bewilderbeest.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 152d0b535426ae8b86367251a175dc3417feddfd
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Fri Oct 8 18:36:40 2021 +0200

    mtd: rawnand: arasan: Prevent an unsupported configuration
    
    [ Upstream commit fc9e18f9e987ad46722dad53adab1c12148c213c ]
    
    Under the following conditions:
    * after rounding up by 4 the number of bytes to transfer (this is
      related to the controller's internal constraints),
    * if this (rounded) amount of data is situated beyond the end of the
      device,
    * and only in NV-DDR mode,
    the Arasan NAND controller timeouts.
    
    This currently can happen in a particular helper used when picking
    software ECC algorithms. Let's prevent this situation by refusing to use
    the NV-DDR interface with software engines.
    
    Fixes: 4edde6031458 ("mtd: rawnand: arasan: Support NV-DDR interface")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 402239647cb34cea8bc1faaf47fe191c49020df3
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Sat Sep 18 09:22:59 2021 +0900

    PCI: uniphier: Serialize INTx masking/unmasking and fix the bit operation
    
    [ Upstream commit 4caab28a6215da5f3c1b505ff08810bc6acfe365 ]
    
    The condition register PCI_RCV_INTX is used in irq_mask() and irq_unmask()
    callbacks. Accesses to register can occur at the same time without a lock.
    Add a lock into each callback to prevent the issue.
    
    And INTX mask and unmask fields in PCL_RCV_INTX register should only be
    set/reset for each bit. Clearing by PCL_RCV_INTX_ALL_MASK should be
    removed.
    
    INTX status fields in PCL_RCV_INTX register only indicates each INTX
    interrupt status, so the handler can't clear by writing 1 to the field.
    The status is expected to be cleared by the interrupt origin.
    The ack function has no meaning, so should remove it.
    
    Suggested-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/1631924579-24567-1-git-send-email-hayashi.kunihiko@socionext.com
    Fixes: 7e6d5cd88a6f ("PCI: uniphier: Add UniPhier PCIe host controller support")
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Pali Rohár <pali@kernel.org>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 321a355777d06653ab68a1593eab4ad8fdd63c5b
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Fri Jul 9 17:45:29 2021 +0300

    mtd: spi-nor: hisi-sfc: Remove excessive clk_disable_unprepare()
    
    [ Upstream commit 78e4d342187625585932bb437ec26e1060f7fc6f ]
    
    hisi_spi_nor_probe() invokes clk_disable_unprepare() on all paths after
    successful call of clk_prepare_enable(). Besides, the clock is enabled by
    hispi_spi_nor_prep() and disabled by hispi_spi_nor_unprep(). So at remove
    time it is not possible to have the clock enabled. The patch removes
    excessive clk_disable_unprepare() from hisi_spi_nor_remove().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver")
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
    Link: https://lore.kernel.org/r/20210709144529.31379-1-novikov@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c60136d99c213acb207cae23790e4ff0347f11a
Author: Guido Günther <agx@sigxcpu.org>
Date:   Mon Oct 11 15:41:23 2021 +0200

    drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
    
    [ Upstream commit 2f1495fac8d38bfade18bd7e31fa787cd7815626 ]
    
    Components further up in the chain might ask us for supported formats.
    
    Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
    output with mxsfb since it can't determine a proper bus format.
    
    We handle the bus formats that correspond to the DSI formats the bridge
    can potentially output (see chapter 13.6 of the i.MX 8MQ reference
    manual) - which matches what xsfb can input.
    
    Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if present")
    
    Signed-off-by: Guido Günther <agx@sigxcpu.org>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/1712f2b952694fd4484dfd8576fbc5b4d7adf042.1633959458.git.agx@sigxcpu.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d36d2c35fd98259de4b4f44d877365369eb19534
Author: John Keeping <john@metanate.com>
Date:   Wed Oct 6 11:06:03 2021 -0700

    Input: st1232 - increase "wait ready" timeout
    
    [ Upstream commit 2667f6b7af99e81958fa97c03bb519fcb09d0055 ]
    
    I have a ST1633 touch controller which fails to probe due to a timeout
    waiting for the controller to become ready.  Increasing the minimum
    delay to 100ms ensures that the probe sequence completes successfully.
    
    The ST1633 datasheet says nothing about the maximum delay here and the
    ST1232 I2C protocol document says "wait until" with no notion of a
    timeout.
    
    Since this only runs once during probe, being generous with the timout
    seems reasonable and most likely the device will become ready
    eventually.
    
    (It may be worth noting that I saw this issue with a PREEMPT_RT patched
    kernel which probably has tighter wakeups from usleep_range() than other
    preemption models.)
    
    Fixes: f605be6a57b4 ("Input: st1232 - wait until device is ready before reading resolution")
    Signed-off-by: John Keeping <john@metanate.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d268e0125c929eca42f1ea1db79bf23c73894231
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Tue Mar 9 00:00:20 2021 -0800

    fs: orangefs: fix error return code of orangefs_revalidate_lookup()
    
    [ Upstream commit 4c2b46c824a78fc8190d8eafaaea5a9078fe7479 ]
    
    When op_alloc() returns NULL to new_op, no error return code of
    orangefs_revalidate_lookup() is assigned.
    To fix this bug, ret is assigned with -ENOMEM in this case.
    
    Fixes: 8bb8aefd5afb ("OrangeFS: Change almost all instances of the string PVFS2 to OrangeFS.")
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a94284b0fdce9bc5a3a42ff3334223a9d7f84d91
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Sep 23 14:54:18 2021 -0700

    sparc: Add missing "FORCE" target when using if_changed
    
    [ Upstream commit a3c7ca2b141b9735eb383246e966a4f4322e3e65 ]
    
    Fix observed warning:
    
        /builds/linux/arch/sparc/boot/Makefile:35: FORCE prerequisite is missing
    
    Fixes: e1f86d7b4b2a ("kbuild: warn if FORCE is missing for if_changed(_dep,_rule) and filechk")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: Nicolas Schier <n.schier@avm.de>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cab693c0fe29a714e69afb8b472619d951941fc8
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Oct 4 15:44:16 2021 -0400

    NFS: Fix deadlocks in nfs_scan_commit_list()
    
    [ Upstream commit 64a93dbf25d3a1368bb58ddf0f61d0a92d7479e3 ]
    
    Partially revert commit 2ce209c42c01 ("NFS: Wait for requests that are
    locked on the commit list"), since it can lead to deadlocks between
    commit requests and nfs_join_page_group().
    For now we should assume that any locked requests on the commit list are
    either about to be removed and committed by another task, or the writes
    they describe are about to be retransmitted. In either case, we should
    not need to worry.
    
    Fixes: 2ce209c42c01 ("NFS: Wait for requests that are locked on the commit list")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97eaf7af7fd1a4f6e882e812846d59c95085c296
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Oct 8 15:46:52 2021 +0800

    opp: Fix return in _opp_add_static_v2()
    
    [ Upstream commit 27ff8187f13ecfec8a26fb1928e906f46f326cc5 ]
    
    Fix sparse warning:
    drivers/opp/of.c:924 _opp_add_static_v2() warn: passing zero to 'ERR_PTR'
    
    For duplicate OPPs 'ret' be set to zero.
    
    Fixes: deac8703da5f ("PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a67f827379ffef6760aecb8a3f8866d89e7502e
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:43 2021 +0200

    PCI: aardvark: Fix preserving PCI_EXP_RTCTL_CRSSVE flag on emulated bridge
    
    [ Upstream commit d419052bc6c60fa4ab2b5a51d5f1e55a66e2b4ff ]
    
    Commit 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") started
    using CRSSVE flag for handling CRS responses.
    
    PCI_EXP_RTCTL_CRSSVE flag is stored only in emulated config space buffer
    and there is handler for PCI_EXP_RTCTL register. So every read operation
    from config space automatically clears CRSSVE flag as it is not defined in
    PCI_EXP_RTCTL read handler.
    
    Fix this by reading current CRSSVE bit flag from emulated space buffer and
    appending it to PCI_EXP_RTCTL read response.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-5-kabel@kernel.org
    Fixes: 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8c80586b8fbe78961d0312f1f5af60d791efd6e
Author: Marek Behún <kabel@kernel.org>
Date:   Tue Oct 5 20:09:42 2021 +0200

    PCI: aardvark: Don't spam about PIO Response Status
    
    [ Upstream commit 464de7e7fff767e87429cd7be09c4f2cb50a6ccb ]
    
    Use dev_dbg() instead of dev_err() in advk_pcie_check_pio_status().
    
    For example CRS is not an error status, it just says that the request
    should be retried.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-4-kabel@kernel.org
    Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8ae61fe97c203826cf92ce8f923b525bdd6d1c7
Author: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Date:   Thu Oct 7 02:37:06 2021 -0400

    drm/plane-helper: fix uninitialized variable reference
    
    [ Upstream commit 7be28bd73f23e53d6e7f5fe891ba9503fc0c7210 ]
    
    drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_update':
    drivers/gpu/drm/drm_plane_helper.c:113:32: error: 'visible' is used uninitialized [-Werror=uninitialized]
      113 |         struct drm_plane_state plane_state = {
          |                                ^~~~~~~~~~~
    drivers/gpu/drm/drm_plane_helper.c:178:14: note: 'visible' was declared here
      178 |         bool visible;
          |              ^~~~~~~
    cc1: all warnings being treated as errors
    
    visible is an output, not an input. in practice this use might turn out
    OK but it's still UB.
    
    Fixes: df86af9133b4 ("drm/plane-helper: Add drm_plane_helper_check_state()")
    Reviewed-by: Simon Ser <contact@emersion.fr>
    Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211007063706.305984-1-alex_y_xu@yahoo.ca
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c03c7f58ae4919e4456e3701ed819f86e9f8e915
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Jul 9 02:03:29 2021 +0300

    drm/bridge/lontium-lt9611uxc: fix provided connector suport
    
    [ Upstream commit 15184965783aab3ca7ee4f939e2598943b3f40f9 ]
    
    - set DRM_CONNECTOR_POLL_HPD as the connector will generate hotplug
      events on its own
    
    - do not call drm_kms_helper_hotplug_event() unless mode_config.funcs
      pointer is not NULL to remove possible kernel oops.
    
    Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210708230329.395976-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ab7612ff0b58c5cb7590e8e90bc667cf6585779
Author: Baptiste Lepers <baptiste.lepers@gmail.com>
Date:   Mon Sep 6 11:59:24 2021 +1000

    pnfs/flexfiles: Fix misplaced barrier in nfs4_ff_layout_prepare_ds
    
    [ Upstream commit a2915fa06227b056a8f9b0d79b61dca08ad5cfc6 ]
    
    _nfs4_pnfs_v3/v4_ds_connect do
       some work
       smp_wmb
       ds->ds_clp = clp;
    
    And nfs4_ff_layout_prepare_ds currently does
       smp_rmb
       if(ds->ds_clp)
          ...
    
    This patch places the smp_rmb after the if. This ensures that following
    reads only happen once nfs4_ff_layout_prepare_ds has checked that data
    has been properly initialized.
    
    Fixes: d67ae825a59d6 ("pnfs/flexfiles: Add the FlexFile Layout Driver")
    Signed-off-by: Baptiste Lepers <baptiste.lepers@gmail.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6967d9967b7a37cdd2f2e83def026e34e2c6a51a
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Sep 29 08:12:53 2021 -0400

    NFS: Fix dentry verifier races
    
    [ Upstream commit cec08f452a687fce9dfdf47946d00a1d12a8bec5 ]
    
    If the directory changed while we were revalidating the dentry, then
    don't update the dentry verifier. There is no value in setting the
    verifier to an older value, and we could end up overwriting a more up to
    date verifier from a parallel revalidation.
    
    Fixes: efeda80da38d ("NFSv4: Fix revalidation of dentries with delegations")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Tested-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 597e9c7a4acebcdc29bf87e6672ad8e256beb2f4
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Sep 28 11:24:57 2021 -0400

    NFS: Ignore the directory size when marking for revalidation
    
    [ Upstream commit a6a361c4ca3cc3e6f3b39d1b6bca1de90f5f4b11 ]
    
    If we want to revalidate the directory, then just mark the change
    attribute as invalid.
    
    Fixes: 13c0b082b6a9 ("NFS: Replace use of NFS_INO_REVAL_PAGECACHE when checking cache validity")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Tested-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69e0be0efe53fb012f5db32bc328590745cf8f71
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Sep 28 11:15:53 2021 -0400

    NFS: Don't set NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA
    
    [ Upstream commit 488796ec1e39fb9194cc8175f770823d40fbf0ed ]
    
    NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA should be considered
    mutually exclusive.
    
    Fixes: 1c341b777501 ("NFS: Add deferred cache invalidation for close-to-open consistency violations")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Tested-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e2801edf23f04779abd88d5b5fa1d7e5f4e1e6c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sun Sep 26 14:05:04 2021 -0400

    NFS: Default change_attr_type to NFS4_CHANGE_TYPE_IS_UNDEFINED
    
    [ Upstream commit eea413308f2e6deb00f061f18081a53f3ecc8cc6 ]
    
    Both NFSv3 and NFSv2 generate their change attribute from the ctime
    value that was supplied by the server. However the problem is that there
    are plenty of servers out there with ctime resolutions of 1ms or worse.
    In a modern performance system, this is insufficient when trying to
    decide which is the most recent set of attributes when, for instance, a
    READ or GETATTR call races with a WRITE or SETATTR.
    
    For this reason, let's revert to labelling the NFSv2/v3 change
    attributes as NFS4_CHANGE_TYPE_IS_UNDEFINED. This will ensure we protect
    against such races.
    
    Fixes: 7b24dacf0840 ("NFS: Another inode revalidation improvement")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Tested-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47dbabb8279c5b5e7025dae58d6d0bb8d6a75b72
Author: Kewei Xu <kewei.xu@mediatek.com>
Date:   Fri Sep 17 18:14:10 2021 +0800

    i2c: mediatek: fixing the incorrect register offset
    
    [ Upstream commit b8228aea5a19d5111a7bf44f7de6749d1f5d487a ]
    
    The reason for the modification here is that the previous
    offset information is incorrect, OFFSET_DEBUGSTAT = 0xE4 is
    the correct value.
    
    Fixes: 25708278f810 ("i2c: mediatek: Add i2c support for MediaTek MT8183")
    Signed-off-by: Kewei Xu <kewei.xu@mediatek.com>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    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 1721649965e4ec2a656d505191b59120c9f813f5
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Oct 1 21:20:49 2021 -0700

    Input: ariel-pwrbutton - add SPI device ID table
    
    [ Upstream commit 5c4c2c8e6fac26fa0b80c234d6e9f75d637193af ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding a SPI device ID table.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210927134104.38648-1-broonie@kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40f60ee1d33c0072293863d0c9d3a3f60004870b
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Sep 27 14:02:40 2021 +0100

    rtc: mcp795: Add SPI ID table
    
    [ Upstream commit 3109151c47343c80300177ec7704e0757064efdc ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding an id_table listing the
    SPI IDs for everything.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20210927130240.33693-1-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46a2f79455532910be40eb171f1b1fc3676847ea
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Wed Sep 29 12:15:38 2021 -0700

    dmaengine: idxd: move out percpu_ref_exit() to ensure it's outside submission
    
    [ Upstream commit 85f604af9c83a4656b1d07bec73298c3ba7d7c1e ]
    
    percpu_ref_tryget_live() is safe to call as long as ref is between init and
    exit according to the function comment. Move percpu_ref_exit() so it is
    called after the dma channel is no longer valid to ensure this holds true.
    
    Fixes: 93a40a6d7428 ("dmaengine: idxd: add percpu_ref to descriptor submission path")
    Suggested-by: Kevin Tian <kevin.tian@intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/163294293832.914350.10326422026738506152.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c31b0fe8e116354cbfbea52e49a29095f42ec9bd
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Sep 5 17:59:42 2021 +0200

    i2c: i801: Use PCI bus rescan mutex to protect P2SB access
    
    [ Upstream commit 7d6b61c394a42b8385858bb9e306d48a0112823c ]
    
    As pointed out by Andy in [0] using a local mutex here isn't strictly
    wrong but not sufficient. We should hold the PCI rescan lock for P2SB
    operations.
    
    [0] https://www.spinics.net/lists/linux-i2c/msg52717.html
    
    Fixes: 1a987c69ce2c ("i2c: i801: make p2sb_spinlock a mutex")
    Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aad5b030fa2e59cf6115e1bb43d621ac87592737
Author: Dong Aisheng <aisheng.dong@nxp.com>
Date:   Fri Sep 10 17:06:18 2021 +0800

    remoteproc: imx_rproc: Fix TCM io memory type
    
    [ Upstream commit 91bb26637353f35241f5472eedf3202ebe13e2e5 ]
    
    is_iomem was introduced in the commit 40df0a91b2a5 ("remoteproc: add
    is_iomem to da_to_va"), but the driver seemed missed to provide the io
    type correctly.
    This patch updates remoteproc driver to indicate the TCM on IMX are io
    memories. Without the change, remoteproc kick will fail.
    
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Peng Fan <peng.fan@nxp.com>
    Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
    Fixes: 79806d32d5aa ("remoteproc: imx_rproc: support i.MX8MN/P")
    Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210910090621.3073540-4-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 171b2888a410cb184bb94583b2c0ad17f341b940
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Sep 23 20:49:22 2021 +0100

    rtc: pcf2123: Add SPI ID table
    
    [ Upstream commit 5f84478e14aa8b43a4ea85d2e091931741947749 ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding an id_table listing the
    SPI IDs for everything.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20210923194922.53386-4-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75ed1289c376c6427736ae693dd6348071019b6d
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Sep 23 20:49:21 2021 +0100

    rtc: ds1390: Add SPI ID table
    
    [ Upstream commit da87639d6312afb8855717c791768bf2d4ca8ac8 ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding an id_table listing the
    SPI IDs for everything.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20210923194922.53386-3-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7e81f2c0e8a0735bfc95d3661cee284e1ec33ab
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Sep 23 20:49:20 2021 +0100

    rtc: ds1302: Add SPI ID table
    
    [ Upstream commit 8719a17613e0233d707eb22e1645d217594631ef ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding an id_table listing the
    SPI IDs for everything.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20210923194922.53386-2-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9dacf2606711695094879b1eb4f56346eafc82c
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Sep 14 12:30:32 2021 -0400

    nfsd: don't alloc under spinlock in rpc_parse_scope_id
    
    [ Upstream commit 9b6e27d01adcec58e046c624874f8a124e8b07ec ]
    
    Dan Carpenter says:
    
      The patch d20c11d86d8f: "nfsd: Protect session creation and client
      confirm using client_lock" from Jul 30, 2014, leads to the following
      Smatch static checker warning:
    
            net/sunrpc/addr.c:178 rpc_parse_scope_id()
            warn: sleeping in atomic context
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: d20c11d86d8f ("nfsd: Protect session creation and client...")
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a61698358b38384d1e77049e6702f073a2d812c6
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Fri Sep 3 11:26:53 2021 +0300

    mtd: rawnand: intel: Fix potential buffer overflow in probe
    
    [ Upstream commit 46a0dc10fb32bec3e765e51bf71fbc070dc77ca3 ]
    
    ebu_nand_probe() read the value of u32 variable "cs" from the device
    firmware description and used it as the index for array ebu_host->cs
    that can contain MAX_CS (2) elements at most. That could result in
    a buffer overflow and various bad consequences later.
    
    Fix the potential buffer overflow by restricting values of "cs" with
    MAX_CS in probe.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC")
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
    Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
    Co-developed-by: Anton Vasilyev <vasilyev@ispras.ru>
    Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210903082653.16441-1-novikov@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e87c6bc32caf46d621bb3745073c6b3a72f6fe86
Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Date:   Mon Jul 12 14:39:12 2021 +0200

    rpmsg: Fix rpmsg_create_ept return when RPMSG config is not defined
    
    [ Upstream commit 537d3af1bee8ad1415fda9b622d1ea6d1ae76dfa ]
    
    According to the description of the rpmsg_create_ept in rpmsg_core.c
    the function should return NULL on error.
    
    Fixes: 2c8a57088045 ("rpmsg: Provide function stubs for API")
    Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20210712123912.10672-1-arnaud.pouliquen@foss.st.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f3de16a3ca679cad08e238306e972f3e5ef5afe
Author: Tom Rix <trix@redhat.com>
Date:   Sun Oct 4 07:24:22 2020 -0700

    apparmor: fix error check
    
    [ Upstream commit d108370c644b153382632b3e5511ade575c91c86 ]
    
    clang static analysis reports this representative problem:
    
    label.c:1463:16: warning: Assigned value is garbage or undefined
            label->hname = name;
                         ^ ~~~~
    
    In aa_update_label_name(), this the problem block of code
    
            if (aa_label_acntsxprint(&name, ...) == -1)
                    return res;
    
    On failure, aa_label_acntsxprint() has a more complicated return
    that just -1.  So check for a negative return.
    
    It was also noted that the aa_label_acntsxprint() main comment refers
    to a nonexistent parameter, so clean up the comment.
    
    Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c6eefe997adab514917b788ab446e02175dfbe0
Author: Aharon Landau <aharonl@nvidia.com>
Date:   Thu Oct 28 08:55:22 2021 +0300

    RDMA/core: Require the driver to set the IOVA correctly during rereg_mr
    
    [ Upstream commit f1a090f09f42be5a5542009f0be310fdb3e768fc ]
    
    If the driver returns a new MR during rereg it has to fill it with the
    IOVA from the proper source. If IB_MR_REREG_TRANS is set then the IOVA is
    cmd.hca_va, otherwise the IOVA comes from the old MR. mlx5 for example has
    two calls inside rereg_mr:
    
                    return create_real_mr(new_pd, umem, mr->ibmr.iova,
                                          new_access_flags);
    and
                    return create_real_mr(new_pd, new_umem, iova, new_access_flags);
    
    Unconditionally overwriting the iova in the newly allocated MR will
    corrupt the iova if the first path is used.
    
    Remove the redundant initializations from ib_uverbs_rereg_mr().
    
    Fixes: 6e0954b11c05 ("RDMA/uverbs: Allow drivers to create a new HW object during rereg_mr")
    Link: https://lore.kernel.org/r/4b0a31bbc372842613286a10d7a8cbb0ee6069c7.1635400472.git.leonro@nvidia.com
    Signed-off-by: Aharon Landau <aharonl@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f49a9d356bdb741fbabf4ac0f6a341e0bdc3fd7
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Oct 31 16:25:22 2021 +0100

    power: supply: bq27xxx: Fix kernel crash on IRQ handler register error
    
    [ Upstream commit cdf10ffe8f626d8a2edc354abf063df0078b2d71 ]
    
    When registering the IRQ handler fails, do not just return the error code,
    this will free the devm_kzalloc()-ed data struct while leaving the queued
    work queued and the registered power_supply registered with both of them
    now pointing to free-ed memory, resulting in various kernel crashes
    soon afterwards.
    
    Instead properly tear-down things on IRQ handler register errors.
    
    Fixes: 703df6c09795 ("power: bq27xxx_battery: Reorganize I2C into a module")
    Cc: Andrew F. Davis <afd@ti.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dfd04b3a819178a3d1458ca036cc0b98b8adc6e2
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Oct 29 11:58:16 2021 +0200

    mips: cm: Convert to bitfield API to fix out-of-bounds access
    
    [ Upstream commit 18b8f5b6fc53d097cadb94a93d8d6566ba88e389 ]
    
    mips_cm_error_report() extracts the cause and other cause from the error
    register using shifts.  This works fine for the former, as it is stored
    in the top bits, and the shift will thus remove all non-related bits.
    However, the latter is stored in the bottom bits, hence thus needs masking
    to get rid of non-related bits.  Without such masking, using it as an
    index into the cm2_causes[] array will lead to an out-of-bounds access,
    probably causing a crash.
    
    Fix this by using FIELD_GET() instead.  Bite the bullet and convert all
    MIPS CM handling to the bitfield API, to improve readability and safety.
    
    Fixes: 3885c2b463f6a236 ("MIPS: CM: Add support for reporting CM cache errors")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27ddb2735a6e47820533428a214eb95b4fe5c106
Author: Parav Pandit <parav@nvidia.com>
Date:   Tue Oct 26 20:55:17 2021 +0300

    vdpa/mlx5: Fix clearing of VIRTIO_NET_F_MAC feature bit
    
    [ Upstream commit ef76eb83a17e803a66b64ac95b36ae48b3d17c22 ]
    
    Cited patch in the fixes tag clears the features bit during reset.
    mlx5 vdpa device feature bits are static decided by device capabilities.
    These feature bits (including VIRTIO_NET_F_MAC) are initialized during
    device addition time.
    
    Clearing features bit in reset callback cleared the VIRTIO_NET_F_MAC. Due
    to this, MAC address provided by the device is not honored.
    
    Fix it by not clearing the static feature bits during reset.
    
    Fixes: 0686082dbf7a ("vdpa: Add reset callback in vdpa_config_ops")
    Signed-off-by: Parav Pandit <parav@nvidia.com>
    Reviewed-by: Eli Cohen <elic@nvidia.com>
    Link: https://lore.kernel.org/r/20211026175519.87795-7-parav@nvidia.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 0099c7affb21818e3823669fcc5c96bccb0aa8ec
Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Date:   Wed Oct 20 19:23:23 2021 +0800

    virtio_ring: check desc == NULL when using indirect with packed
    
    [ Upstream commit fc6d70f40b3d0b3219e2026d05be0409695f620d ]
    
    When using indirect with packed, we don't check for allocation failures.
    This patch checks that and fall back on direct.
    
    Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support")
    Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20211020112323.67466-3-xuanzhuo@linux.alibaba.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcf29e436895e46cf2b6939a403f92957505afe7
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed Oct 27 09:53:26 2021 +0200

    serial: cpm_uart: Protect udbg definitions by CONFIG_SERIAL_CPM_CONSOLE
    
    [ Upstream commit d142585bceb3218ad432ed0fcd5be9d6e3cd9052 ]
    
    If CONFIG_CONSOLE_POLL=y, and CONFIG_SERIAL_CPM=m (hence
    CONFIG_SERIAL_CPM_CONSOLE=n):
    
        drivers/tty/serial/cpm_uart/cpm_uart_core.c:1109:12: warning: ‘udbg_cpm_getc’ defined but not used [-Wunused-function]
         1109 | static int udbg_cpm_getc(void)
              |            ^~~~~~~~~~~~~
        drivers/tty/serial/cpm_uart/cpm_uart_core.c:1095:13: warning: ‘udbg_cpm_putc’ defined but not used [-Wunused-function]
         1095 | static void udbg_cpm_putc(char c)
              |             ^~~~~~~~~~~~~
    
    Fix this by making the udbg definitions depend on
    CONFIG_SERIAL_CPM_CONSOLE, in addition to CONFIG_CONSOLE_POLL.
    
    Fixes: a60526097f42eb98 ("tty: serial: cpm_uart: Add udbg support for enabling xmon")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/r/20211027075326.3270785-1-geert@linux-m68k.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 874b8c70f39da1ee78b1f27883c9b45597050872
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Oct 18 21:44:16 2021 +0200

    ASoC: rsnd: Fix an error handling path in 'rsnd_node_count()'
    
    [ Upstream commit 173632358fde7a567f28e07c4549b959ee857986 ]
    
    If we return before the end of the 'for_each_child_of_node()' iterator, the
    reference taken on 'np' must be released.
    
    Add the missing 'of_node_put()' call.
    
    Fixes: c413983eb66a ("ASoC: rsnd: adjust disabled module")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/4c0e893cbfa21dc76c1ede0b6f4f8cff42209299.1634586167.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98492898c3673ea89406ebfb48c58af169b81f83
Author: Yixing Liu <liuyixing1@huawei.com>
Date:   Fri Oct 29 18:05:37 2021 +0800

    RDMA/hns: Modify the value of MAX_LP_MSG_LEN to meet hardware compatibility
    
    [ Upstream commit 0e60778efb072d47efc7100c4009b5bd97273b0b ]
    
    The upper limit of MAX_LP_MSG_LEN on HIP08 is 64K, and the upper limit on
    HIP09 is 16K. Regardless of whether it is HIP08 or HIP09, only 16K will be
    used. In order to ensure compatibility, it is unified to 16K.
    
    Setting MAX_LP_MSG_LEN to 16K will not cause performance loss on HIP08.
    
    Fixes: fbed9d2be292 ("RDMA/hns: Fix configuration of ack_req_freq in QPC")
    Link: https://lore.kernel.org/r/20211029100537.27299-1-liangwenpeng@huawei.com
    Signed-off-by: Yixing Liu <liuyixing1@huawei.com>
    Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff021c96a9a713220a761f45cc9d86bb8581e72b
Author: Haoyue Xu <xuhaoyue1@hisilicon.com>
Date:   Fri Oct 29 17:58:46 2021 +0800

    RDMA/hns: Fix initial arm_st of CQ
    
    [ Upstream commit 571fb4fb78a3bf0fcadbe65eca9ca4ccee885af4 ]
    
    We set the init CQ status to ARMED before. As a result, an unexpected CEQE
    would be reported. Therefore, the init CQ status should be set to no_armed
    rather than REG_NXT_CEQE.
    
    Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08")
    Link: https://lore.kernel.org/r/20211029095846.26732-1-liangwenpeng@huawei.com
    Signed-off-by: Haoyue Xu <xuhaoyue1@hisilicon.com>
    Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4fa14bdf83af89bc6edf7d7a5487a54247ffbc7
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Oct 28 15:09:01 2021 +0100

    ASoC: cs42l42: Correct configuring of switch inversion from ts-inv
    
    [ Upstream commit 778a0cbef5fb76bf506f84938517bb77e7a1c478 ]
    
    The setting from the cirrus,ts-inv property should be applied to the
    TIP_SENSE_INV bit, as this is the one that actually affects the jack
    detect block. The TS_INV bit only swaps the meaning of the PLUG and
    UNPLUG interrupts and should always be 1 for the interrupts to have
    the normal meaning.
    
    Due to some misunderstanding the driver had been implemented to
    configure the TS_INV bit based on the jack switch polarity. This made
    the interrupts behave the correct way around, but left the jack detect
    block, button detect and analogue circuits always interpreting an open
    switch as unplugged.
    
    The signal chain inside the codec is:
    
    SENSE pin -> TIP_SENSE_INV -> TS_INV -> (invert) -> interrupts
                      |
                      v
                 Jack detect,
              button detect and
                analog control
    
    As the TIP_SENSE_INV already performs the necessary inversion the
    TS_INV bit never needs to change. It must always be 1 to yield the
    expected interrupt behaviour.
    
    Some extra confusion has arisen because of the additional invert in the
    interrupt path, meaning that a value applied to the TS_INV bit produces
    the opposite effect of applying it to the TIP_SENSE_INV bit. The ts-inv
    property has therefore always had the opposite effect to what might be
    expected (0 = inverted, 1 = not inverted). To maintain the meaning of
    the ts-inv property it must be inverted when applied to TIP_SENSE_INV.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Link: https://lore.kernel.org/r/20211028140902.11786-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dfbcaef20204f5787575082d7c267f42ab5a19ff
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Oct 28 14:59:15 2021 +0200

    powerpc: Don't provide __kernel_map_pages() without ARCH_SUPPORTS_DEBUG_PAGEALLOC
    
    [ Upstream commit f8c0e36b48e32b14bb83332d24e0646acd31d9e9 ]
    
    When ARCH_SUPPORTS_DEBUG_PAGEALLOC is not selected, the user can
    still select CONFIG_DEBUG_PAGEALLOC in which case __kernel_map_pages()
    is provided by mm/page_poison.c
    
    So only define __kernel_map_pages() when both
    CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC and CONFIG_DEBUG_PAGEALLOC
    are defined.
    
    Fixes: 68b44f94d637 ("powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/971b69739ff4746252e711a9845210465c023a9e.1635425947.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06cebea18a337fc996ffa6da916a8ea759ac981d
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Wed Oct 27 11:47:57 2021 -0600

    iommu/dma: Fix incorrect error return on iommu deferred attach
    
    [ Upstream commit ac315f96b3bd6f6b8f18f387816c7c2cc6b32e02 ]
    
    scsi_dma_map() was reporting a failure during boot on an AMD machine
    with the IOMMU enabled.
    
      scsi_dma_map failed: request for 36 bytes!
    
    The issue was tracked down to a mistake in logic: should not return
    an error if iommu_deferred_attach() returns zero.
    
    Reported-by: Marshall Midden <marshallmidden@gmail.com>
    Fixes: dabb16f67215 ("iommu/dma: return error code from iommu_dma_map_sg()")
    Link: https://lore.kernel.org/all/CAD2CkAWjS8=kKwEEN4cgVNjyFORUibzEiCUA-X+SMtbo0JoMmA@mail.gmail.com
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20211027174757.119755-1-logang@deltatee.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4ce4337dc1ca8d9f1b81ce6edb8da2863c88a43
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Thu Oct 28 22:03:25 2021 +0900

    ALSA: oxfw: fix functional regression for Mackie Onyx 1640i in v5.14 or later
    
    [ Upstream commit cddcd5472abb7b8a9c37ccbcf0908b79740a01b5 ]
    
    A user reports functional regression for Mackie Onyx 1640i that the device
    generates slow sound with ALSA oxfw driver which supports media clock
    recovery. Although the device is based on OXFW971 ASIC, it does not
    transfer isochronous packet with own event frequency as expected. The
    device seems to adjust event frequency according to events in received
    isochronous packets in the beginning of packet streaming. This is
    unknown quirk.
    
    This commit fixes the regression to turn the recovery off in driver
    side. As a result, nominal frequency is used in duplex packet streaming
    between device and driver. For stability of sampling rate in events of
    transferred isochronous packet, 4,000 isochronous packets are skipped
    in the beginning of packet streaming.
    
    Reference: https://github.com/takaswie/snd-firewire-improve/issues/38
    Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery")
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5927a99737a6e7355ed3fac137652f2b3b5fd80
Author: Denis Kirjanov <kda@linux-powerpc.org>
Date:   Tue Oct 26 16:31:08 2021 +0300

    powerpc/xmon: fix task state output
    
    [ Upstream commit b1f896ce3542eb2eede5949ee2e481526fae1108 ]
    
    p_state is unsigned since the commit 2f064a59a11f
    
    The patch also uses TASK_RUNNING instead of null.
    
    Fixes: 2f064a59a11f ("sched: Change task_struct::state")
    Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211026133108.7113-1-kda@linux-powerpc.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6b102db217f7bce0ff7205105c41fc32ba8f38e
Author: Bixuan Cui <cuibixuan@linux.alibaba.com>
Date:   Thu Oct 28 15:28:22 2021 +0800

    powerpc/44x/fsp2: add missing of_node_put
    
    [ Upstream commit 290fe8aa69ef5c51c778c0bb33f8ef0181c769f5 ]
    
    Early exits from for_each_compatible_node() should decrement the
    node reference counter.  Reported by Coccinelle:
    
    ./arch/powerpc/platforms/44x/fsp2.c:206:1-25: WARNING: Function
    "for_each_compatible_node" should have of_node_put() before return
    around line 218.
    
    Fixes: 7813043e1bbc ("powerpc/44x/fsp2: Add irq error handlers")
    Signed-off-by: Bixuan Cui <cuibixuan@linux.alibaba.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/1635406102-88719-1-git-send-email-cuibixuan@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a85790059385a051f1f647af37e8bac21674e61
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Oct 26 07:39:25 2021 +0200

    powerpc/book3e: Fix set_memory_x() and set_memory_nx()
    
    [ Upstream commit b6cb20fdc2735f8b2e082937066c33fe376c2ee2 ]
    
    set_memory_x() calls pte_mkexec() which sets _PAGE_EXEC.
    set_memory_nx() calls pte_exprotec() which clears _PAGE_EXEC.
    
    Book3e has 2 bits, UX and SX, which defines the exec rights
    resp. for user (PR=1) and for kernel (PR=0).
    
    _PAGE_EXEC is defined as UX only.
    
    An executable kernel page is set with either _PAGE_KERNEL_RWX
    or _PAGE_KERNEL_ROX, which both have SX set and UX cleared.
    
    So set_memory_nx() call for an executable kernel page does
    nothing because UX is already cleared.
    
    And set_memory_x() on a non-executable kernel page makes it
    executable for the user and keeps it non-executable for kernel.
    
    Also, pte_exec() always returns 'false' on kernel pages, because
    it checks _PAGE_EXEC which doesn't include SX, so for instance
    the W+X check doesn't work.
    
    To fix this:
      - change tlb_low_64e.S to use _PAGE_BAP_UX instead of _PAGE_USER
      - sets both UX and SX in _PAGE_EXEC so that pte_exec() returns
        true whenever one of the two bits is set and pte_exprotect()
        clears both bits.
      - Define a book3e specific version of pte_mkexec() which sets
        either SX or UX based on UR.
    
    Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/c41100f9c144dc5b62e5a751b810190c6b5d42fd.1635226743.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7482771395535e1d216d0ad0891f4caed01d989
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Oct 26 07:39:24 2021 +0200

    powerpc/nohash: Fix __ptep_set_access_flags() and ptep_set_wrprotect()
    
    [ Upstream commit b1b93cb7e794e914787bf7d9936b57a149cdee4f ]
    
    Commit 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code")
    changed those two functions to use pte helpers to determine which
    bits to clear and which bits to set.
    
    This change was based on the assumption that bits to be set/cleared
    are always the same and can be determined by applying the pte
    manipulation helpers on __pte(0).
    
    But on platforms like book3e, the bits depend on whether the page
    is a user page or not.
    
    For the time being it more or less works because of _PAGE_EXEC being
    used for user pages only and exec right being set at all time on
    kernel page. But following patch will clean that and output of
    pte_mkexec() will depend on the page being a user or kernel page.
    
    Instead of trying to make an even more complicated helper where bits
    would become dependent on the final pte value, come back to a more
    static situation like before commit 26973fa5ac0e ("powerpc/mm: use
    pte helpers in generic code"), by introducing an 8xx specific
    version of __ptep_set_access_flags() and ptep_set_wrprotect().
    
    Fixes: 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/922bdab3a220781bae2360ff3dd5adb7fe4d34f1.1635226743.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b4a3cfce497a277f7d91a4169112e7ea238b525
Author: Andrej Shadura <andrew.shadura@collabora.co.uk>
Date:   Tue Oct 19 17:29:17 2021 +0200

    HID: u2fzero: properly handle timeouts in usb_submit_urb
    
    [ Upstream commit 43775e62c4b784f44a159e13ba80e6146a42d502 ]
    
    The wait_for_completion_timeout function returns 0 if timed out or a
    positive value if completed. Hence, "less than zero" comparison always
    misses timeouts and doesn't kill the URB as it should, leading to
    re-sending it while it is active.
    
    Fixes: 42337b9d4d95 ("HID: add driver for U2F Zero built-in LED and RNG")
    Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fcb6023d14900785b391023d26b48f9a3133eeb
Author: Andrej Shadura <andrew.shadura@collabora.co.uk>
Date:   Tue Oct 19 17:29:16 2021 +0200

    HID: u2fzero: clarify error check and length calculations
    
    [ Upstream commit b7abf78b7a6c4a29a6e0ba0bb883fe44a2f3d693 ]
    
    The previous commit fixed handling of incomplete packets but broke error
    handling: offsetof returns an unsigned value (size_t), but when compared
    against the signed return value, the return value is interpreted as if
    it were unsigned, so negative return values are never less than the
    offset.
    
    To make the code easier to read, calculate the minimal packet length
    once and separately, and assign it to a signed int variable to eliminate
    unsigned math and the need for type casts. It then becomes immediately
    obvious how the actual data length is calculated and why the return
    value cannot be less than the minimal length.
    
    Fixes: 22d65765f211 ("HID: u2fzero: ignore incomplete packets without data")
    Fixes: 42337b9d4d95 ("HID: add driver for U2F Zero built-in LED and RNG")
    Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33dcebb916a296e97d6d014386af8f56bd10d79c
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Mon Oct 11 14:27:14 2021 +0300

    clk: at91: clk-master: fix prescaler logic
    
    [ Upstream commit 0ef99f8202c5078a72c05af76bfaed2ea4daab19 ]
    
    When prescaler value read from register is MASTER_PRES_MAX it means
    that the input clock will be divided by 3. Fix the code to reflect
    this.
    
    Fixes: 7a110b9107ed8 ("clk: at91: clk-master: re-factor master clock")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20211011112719.3951784-11-claudiu.beznea@microchip.com
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffe896d043ca1806e2b24f687dfcd520f2f663ed
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Mon Oct 11 14:27:12 2021 +0300

    clk: at91: clk-master: check if div or pres is zero
    
    [ Upstream commit c2910c00fee4cbb7b222d6e02846adef9ae4135a ]
    
    Check if div or pres is zero before using it as argument for ffs().
    In case div is zero ffs() will return 0 and thus substracting from
    zero will lead to invalid values to be setup in registers.
    
    Fixes: 7a110b9107ed8 ("clk: at91: clk-master: re-factor master clock")
    Fixes: 75c88143f3b87 ("clk: at91: clk-master: add master clock support for SAMA7G5")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20211011112719.3951784-9-claudiu.beznea@microchip.com
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a5cd9597e7fb6d4377bc60b5be2b36dcdc2456a
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Mon Oct 11 14:27:11 2021 +0300

    clk: at91: sam9x60-pll: use DIV_ROUND_CLOSEST_ULL
    
    [ Upstream commit f12d028b743bb6136da60b17228a1b6162886444 ]
    
    Use DIV_ROUND_CLOSEST_ULL() to avoid any inconsistency b/w the rate
    computed in sam9x60_frac_pll_recalc_rate() and the one computed in
    sam9x60_frac_pll_compute_mul_frac().
    
    Fixes: 43b1bb4a9b3e1 ("clk: at91: clk-sam9x60-pll: re-factor to support plls with multiple outputs")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20211011112719.3951784-8-claudiu.beznea@microchip.com
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2efda16d42bfb58a7545c0bb6b776a5e5e439172
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Tue Oct 26 13:27:41 2021 +0300

    serial: xilinx_uartps: Fix race condition causing stuck TX
    
    [ Upstream commit 88b20f84f0fe47409342669caf3e58a3fc64c316 ]
    
    xilinx_uartps .start_tx() clears TXEMPTY when enabling TXEMPTY to avoid
    any previous TXEVENT event asserting the UART interrupt. This clear
    operation is done immediately after filling the TX FIFO.
    
    However, if the bytes inserted by cdns_uart_handle_tx() are consumed by
    the UART before the TXEMPTY is cleared, the clear operation eats the new
    TXEMPTY event as well, causing cdns_uart_isr() to never receive the
    TXEMPTY event. If there are bytes still queued in circbuf, TX will get
    stuck as they will never get transferred to FIFO (unless new bytes are
    queued to circbuf in which case .start_tx() is called again).
    
    While the racy missed TXEMPTY occurs fairly often with short data
    sequences (e.g. write 1 byte), in those cases circbuf is usually empty
    so no action on TXEMPTY would have been needed anyway. On the other
    hand, longer data sequences make the race much more unlikely as UART
    takes longer to consume the TX FIFO. Therefore it is rare for this race
    to cause visible issues in general.
    
    Fix the race by clearing the TXEMPTY bit in ISR *before* filling the
    FIFO.
    
    The TXEMPTY bit in ISR will only get asserted at the exact moment the
    TX FIFO *becomes* empty, so clearing the bit before filling FIFO does
    not cause an extra immediate assertion even if the FIFO is initially
    empty.
    
    This is hard to reproduce directly on a normal system, but inserting
    e.g. udelay(200) after cdns_uart_handle_tx(port), setting 4000000 baud,
    and then running "dd if=/dev/zero bs=128 of=/dev/ttyPS0 count=50"
    reliably reproduces the issue on my ZynqMP test system unless this fix
    is applied.
    
    Fixes: 85baf542d54e ("tty: xuartps: support 64 byte FIFO size")
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Link: https://lore.kernel.org/r/20211026102741.2910441-1-anssi.hannula@bitwise.fi
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0379ee4a864b5aa0f864e4c3f0b0b1bace6e364
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Sep 9 15:21:49 2021 +0800

    phy: Sparx5 Eth SerDes: Fix return value check in sparx5_serdes_probe()
    
    [ Upstream commit b4dc97ab0a629eda8bda20d96ef47dac08a505d9 ]
    
    In case of error, the function devm_ioremap() returns NULL
    pointer not ERR_PTR(). The IS_ERR() test in the return value
    check should be replaced with NULL test.
    
    Fixes: 2ff8a1eeb5aa ("phy: Add Sparx5 ethernet serdes PHY driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20210909072149.2934047-1-yangyingliang@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34f5e44c8f2dbe55f42ff238d6b16094fa22aaf9
Author: Sandeep Maheswaram <quic_c_sanm@quicinc.com>
Date:   Mon Oct 25 09:49:35 2021 +0530

    phy: qcom-snps: Correct the FSEL_MASK
    
    [ Upstream commit b475bf0ec40a2b13fb32ef62f5706576d5858460 ]
    
    The FSEL_MASK which selects the refclock is defined incorrectly.
    It should be [4:6] not [5:7]. Due to this incorrect definition, the BIT(7)
    in USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0 is reset which keeps PHY analog
    blocks ON during suspend.
    Fix this issue by correctly defining the FSEL_MASK.
    
    Fixes: 51e8114f80d0 ("phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs")
    Signed-off-by: Sandeep Maheswaram <quic_c_sanm@quicinc.com>
    Link: https://lore.kernel.org/r/1635135575-5668-1-git-send-email-quic_c_sanm@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9999e3d7119755f4a37292489f5f42971692fd75
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Oct 20 18:56:04 2021 +0300

    phy: qcom-qmp: another fix for the sc8180x PCIe definition
    
    [ Upstream commit 26f71abef580537d978f6299330689f029ee1e6c ]
    
    Commit f839f14e24f2 ("phy: qcom-qmp: Add sc8180x PCIe support") added
    SC8180X PCIe tables, but used sm8250_qmp_pcie_serdes_tbl as a serdes
    table because of the copy paste error. Commit bfccd9a71a08 ("phy:
    qcom-qmp: Fix sc8180x PCIe definition") corrected part of this mistake
    by pointing serdes_tbl to sc8180x_qmp_pcie_serdes_tbl, however the
    serdes_tbl_num field was not updated to use sc8180x table. So let's now
    fix the serdes_tbl_num field too.
    
    Fixes: bfccd9a71a08 ("phy: qcom-qmp: Fix sc8180x PCIe definition")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211020155604.1374530-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69cd3bdff881de4f5b853433f99142c5b7163978
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 14 14:00:38 2021 +0300

    phy: ti: gmii-sel: check of_get_address() for failure
    
    [ Upstream commit 8d55027f4e2c04146a75fb63371ab96ccc887f2c ]
    
    Smatch complains that if of_get_address() returns NULL, then "size"
    isn't initialized.  Also it would lead to an Oops.
    
    Fixes: 7f78322cdd67 ("phy: ti: gmii-sel: retrieve ports number and base offset from dt")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Link: https://lore.kernel.org/r/20210914110038.GB11657@kili
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca1e04c638508334b5f37668c4155567974ce2f6
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Thu Sep 23 02:35:48 2021 +0300

    phy: qcom-qusb2: Fix a memory leak on probe
    
    [ Upstream commit bf7ffcd0069d30e2e7ba2b827f08c89f471cd1f3 ]
    
    On success nvmem_cell_read() returns a pointer to a dynamically allocated
    buffer, and therefore it shall be freed after usage.
    
    The issue is reported by kmemleak:
    
      # cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffff3b3803e4b280 (size 128):
        comm "kworker/u16:1", pid 107, jiffies 4294892861 (age 94.120s)
        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:
          [<000000007739afdc>] __kmalloc+0x27c/0x41c
          [<0000000071c0fbf8>] nvmem_cell_read+0x40/0xe0
          [<00000000e803ef1f>] qusb2_phy_init+0x258/0x5bc
          [<00000000fc81fcfa>] phy_init+0x70/0x110
          [<00000000e3d48a57>] dwc3_core_soft_reset+0x4c/0x234
          [<0000000027d1dbd4>] dwc3_core_init+0x68/0x990
          [<000000001965faf9>] dwc3_probe+0x4f4/0x730
          [<000000002f7617ca>] platform_probe+0x74/0xf0
          [<00000000a2576cac>] really_probe+0xc4/0x470
          [<00000000bc77f2c5>] __driver_probe_device+0x11c/0x190
          [<00000000130db71f>] driver_probe_device+0x48/0x110
          [<0000000019f36c2b>] __device_attach_driver+0xa4/0x140
          [<00000000e5812ff7>]  bus_for_each_drv+0x84/0xe0
          [<00000000f4bac574>] __device_attach+0xe4/0x1c0
          [<00000000d3beb631>] device_initial_probe+0x20/0x30
          [<000000008019b9db>] bus_probe_device+0xa4/0xb0
    
    Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210922233548.2150244-1-vladimir.zapolskiy@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e8175481d5a48d6c90d2f97659f3b240e225b52
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Oct 25 16:48:44 2021 +0100

    ASoC: topology: Fix stub for snd_soc_tplg_component_remove()
    
    [ Upstream commit 1198ff12cbdd5f42c032cba1d96ebc7af8024cf9 ]
    
    When removing the index argument from snd_soc_topology_component_remove()
    commit a5b8f71c5477f (ASoC: topology: Remove multistep topology loading)
    forgot to update the stub for !SND_SOC_TOPOLOGY use, causing build failures
    for anything that tries to make use of it.
    
    Fixes: a5b8f71c5477f (ASoC: topology: Remove multistep topology loading)
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20211025154844.2342120-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 804732ec30ba3d3d75daf7c2f57aa5af68adf7cc
Author: Rahul Tanwar <rtanwar@maxlinear.com>
Date:   Wed Oct 20 17:38:15 2021 +0800

    pinctrl: equilibrium: Fix function addition in multiple groups
    
    [ Upstream commit 53b3947ddb7f309d1f611f8dc9bfd6ea9d699907 ]
    
    Ignore the same function with multiple groups.
    Fix a typo in error print.
    
    Fixes: 1948d5c51dba ("pinctrl: Add pinmux & GPIO controller driver for a new SoC")
    Signed-off-by: Rahul Tanwar <rtanwar@maxlinear.com>
    Link: https://lore.kernel.org/r/20211020093815.20870-1-rtanwar@maxlinear.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 286ff24b0002d92953d580d4e7ee44435367d90a
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Mon Oct 11 12:55:34 2021 +0300

    arm64: dts: qcom: sdm845: Fix Qualcomm crypto engine bus clock
    
    [ Upstream commit d5240f8e23641c70bc70892d7999398b081ccb7e ]
    
    The change corrects the described bus clock of the QCE.
    
    Fixes: 3e482859f1ef ("dts: qcom: sdm845: Add dt entries to support crypto engine.")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211011095534.1580406-1-vladimir.zapolskiy@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69ec5e3509f5a4b346c6680a4e250f752bdc590b
Author: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Date:   Wed May 19 20:06:50 2021 +0530

    arm64: dts: qcom: sdm845: Use RPMH_CE_CLK macro directly
    
    [ Upstream commit eed1d9b6e36b06faa53c6dc74134ec21b1336d94 ]
    
    In commit 3e482859f1ef ("dts: qcom: sdm845: Add dt entries
    to support crypto engine."), we decided to use the value indicated
    by constant RPMH_CE_CLK rather than using it directly.
    
    Now that the same RPMH clock value might be used for other
    SoCs (in addition to sdm845), let's use the constant
    RPMH_CE_CLK to make sure that this dtsi is compatible with the
    other qcom ones.
    
    Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
    Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org>
    Link: https://lore.kernel.org/r/20210519143700.27392-8-bhupesh.sharma@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87201f2148f7f6571309b82d56e651b4cace6bc5
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Thu Oct 7 23:33:57 2021 +0200

    arm64: dts: qcom: pmi8994: Fix "eternal"->"external" typo in WLED node
    
    [ Upstream commit b110dfa5ad42be93ebf73540d16430878dfb26bb ]
    
    The property is named "qcom,external-pfet", as found by
    dt_binding_check:
    
        'qcom,eternal-pfet' does not match any of the regexes
    
    Fixes: 37aa540cbd30 ("arm64: dts: qcom: pmi8994: Add WLED node")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211007213400.258371-11-marijn.suijten@somainline.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59bb5796dfbe02a49040516e9c319476b06120d6
Author: Wan Jiabing <wanjiabing@vivo.com>
Date:   Thu Oct 14 04:30:17 2021 -0400

    soc: qcom: apr: Add of_node_put() before return
    
    [ Upstream commit 72f1aa6205d84337b90b065f602a8fe190821781 ]
    
    Fix following coccicheck warning:
    
    ./drivers/soc/qcom/apr.c:485:1-23: WARNING: Function
    for_each_child_of_node should have of_node_put() before return
    
    Early exits from for_each_child_of_node should decrement the
    node reference counter.
    
    Fixes: 834735662602 ("soc: qcom: apr: Add avs/audio tracking functionality")
    Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211014083017.19714-1-wanjiabing@vivo.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1210a638831334dcc0f87a61e5490eff75b737ba
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Oct 20 04:26:39 2021 +0300

    soc: qcom: rpmhpd: fix sm8350_mxc's peer domain
    
    [ Upstream commit 086f52fdc8f7bd273d06a3de2adf65a063eb5392 ]
    
    The sm8350_mxc's domain description incorrectly references
    sm8150_mmcx_ao as a peer instead of sm8350_mxc_ao. Correct this typo.
    
    Fixes: 639c85628757 ("soc: qcom: rpmhpd: Add SM8350 power domains")
    Cc: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211020012639.1183806-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df84a4f710451fd43be2c21f1fdfa68adb264558
Author: Guru Das Srinagesh <quic_gurus@quicinc.com>
Date:   Mon Oct 11 13:00:14 2021 -0700

    firmware: qcom_scm: Fix error retval in __qcom_scm_is_call_available()
    
    [ Upstream commit 38212b2a8a6fc4c3a6fa99d7445b833bedc9a67c ]
    
    Since __qcom_scm_is_call_available() returns bool, have it return false
    instead of -EINVAL if an invalid SMC convention is detected.
    
    This fixes the Smatch static checker warning:
    
            drivers/firmware/qcom_scm.c:255 __qcom_scm_is_call_available()
            warn: signedness bug returning '(-22)'
    
    Fixes: 9d11af8b06a8 ("firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/1633982414-28347-1-git-send-email-quic_gurus@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58d68f2a2ca124adcd614a8d0eb0b3c8e7ab7866
Author: Jack Pham <jackp@codeaurora.org>
Date:   Thu Oct 21 11:01:28 2021 -0700

    usb: dwc3: gadget: Skip resizing EP's TX FIFO if already resized
    
    [ Upstream commit 876a75cb520f5869533a30a6ca01545ec817b7a0 ]
    
    Some functions may dynamically enable and disable their endpoints
    regularly throughout their operation, particularly when Set Interface
    is employed to switch between Alternate Settings.  For instance the
    UAC2 function has its respective endpoints for playback & capture
    associated with AltSetting 1, in which case those endpoints would not
    get enabled until the host activates the AltSetting.  And they
    conversely become disabled when the interfaces' AltSetting 0 is
    chosen.
    
    With the DWC3 FIFO resizing algorithm recently added, every
    usb_ep_enable() call results in a call to resize that EP's TXFIFO,
    but if the same endpoint is enabled again and again, this incorrectly
    leads to FIFO RAM allocation exhaustion as the mechanism did not
    account for the possibility that endpoints can be re-enabled many
    times.
    
    Example log splat:
    
            dwc3 a600000.dwc3: Fifosize(3717) > RAM size(3462) ep3in depth:217973127
            configfs-gadget gadget: u_audio_start_capture:521 Error!
            dwc3 a600000.dwc3: request 000000000be13e18 was not queued to ep3in
    
    Add another bit DWC3_EP_TXFIFO_RESIZED to dep->flags to keep track of
    whether an EP had already been resized in the current configuration.
    If so, bail out of dwc3_gadget_resize_tx_fifos() to avoid the
    calculation error resulting from accumulating the EP's FIFO depth
    repeatedly.  This flag is retained across multiple ep_disable() and
    ep_enable() calls and is cleared when GTXFIFOSIZn is reset in
    dwc3_gadget_clear_tx_fifos() upon receiving the next Set Config.
    
    Fixes: 9f607a309fbe9 ("usb: dwc3: Resize TX FIFOs to meet EP bursting requirements")
    Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Jack Pham <jackp@codeaurora.org>
    Link: https://lore.kernel.org/r/20211021180129.27938-1-jackp@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46256f11c2cf6d04118ca77d32ebdbd1ad999c9c
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Oct 15 12:02:42 2021 +0200

    powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE
    
    [ Upstream commit 68b44f94d6370e2c6c790fedd28e637fa9964a93 ]
    
    fsl_booke and 44x are not able to map kernel linear memory with
    pages, so they can't support DEBUG_PAGEALLOC and KFENCE, and
    STRICT_KERNEL_RWX is also a problem for now.
    
    Enable those only on book3s (both 32 and 64 except KFENCE), 8xx and 40x.
    
    Fixes: 88df6e90fa97 ("[POWERPC] DEBUG_PAGEALLOC for 32-bit")
    Fixes: 95902e6c8864 ("powerpc/mm: Implement STRICT_KERNEL_RWX on PPC32")
    Fixes: 90cbac0e995d ("powerpc: Enable KFENCE for PPC32")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/d1ad9fdd9b27da3fdfa16510bb542ed51fa6e134.1634292136.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b35b82e6648e269aeb6b3521edd5efdc3ce7edc7
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Tue Oct 5 11:53:05 2021 +0200

    usb: dwc2: drd: reset current session before setting the new one
    
    [ Upstream commit 1ad707f559f7cb12c64f3d7cb37f0b1ea27c1058 ]
    
    If role is changed without the "none" step, A- and B- valid session could
    be set at the same time. It is an issue.
    This patch resets A-session if role switch sets B-session, and resets
    B-session if role switch sets A-session.
    Then, it is possible to change the role without the "none" step.
    
    Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support")
    Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20211005095305.66397-4-amelie.delaunay@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27903e1ffbfa991c036d9473ae10d31ca2c8dc5c
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Tue Oct 5 11:53:04 2021 +0200

    usb: dwc2: drd: fix dwc2_drd_role_sw_set when clock could be disabled
    
    [ Upstream commit 8d387f61b0240854e81450c261beb775065bad5d ]
    
    In case of USB_DR_MODE_PERIPHERAL, the OTG clock is disabled at the end of
    the probe (it is not the case if USB_DR_MODE_HOST or USB_DR_MODE_OTG).
    The clock is then enabled on udc_start.
    If dwc2_drd_role_sw_set is called before udc_start (it is the case if the
    usb cable is plugged at boot), GOTGCTL and GUSBCFG registers cannot be
    read/written, so session cannot be overridden.
    To avoid this case, check the ll_hw_enabled value and enable the clock if
    it is available, and disable it after the override.
    
    Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support")
    Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20211005095305.66397-3-amelie.delaunay@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd18f99c5c7835925f8a2afffa960a2aeb6c6739
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Tue Oct 5 11:53:03 2021 +0200

    usb: dwc2: drd: fix dwc2_force_mode call in dwc2_ovr_init
    
    [ Upstream commit b2cab2a24fb5d13ce1d384ecfb6de827fa08a048 ]
    
    Instead of forcing the role to Device, check the dr_mode configuration.
    If the core is Host only, force the mode to Host, this to avoid the
    dwc2_force_mode warning:
    WARNING: CPU: 1 PID: 21 at drivers/usb/dwc2/core.c:615 dwc2_drd_init+0x104/0x17c
    
    When forcing mode to Host, dwc2_force_mode may sleep the time the host
    role is applied. To avoid sleeping while atomic context, move the call
    to dwc2_force_mode after spin_unlock_irqrestore. It is safe, as
    interrupts are not yet unmasked here.
    
    Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support")
    Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20211005095305.66397-2-amelie.delaunay@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 977b112946ec56aff358bea5e1d139fe26ff34f0
Author: Stefan Agner <stefan@agner.ch>
Date:   Wed Oct 20 21:26:42 2021 +0200

    serial: imx: fix detach/attach of serial console
    
    [ Upstream commit 6d0d1b5a1b4870911beb89544ec1a9751c42fec7 ]
    
    If the device used as a serial console gets detached/attached at runtime,
    register_console() will try to call imx_uart_setup_console(), but this
    is not possible since it is marked as __init.
    
    For instance
    
      # cat /sys/devices/virtual/tty/console/active
      tty1 ttymxc0
      # echo -n N > /sys/devices/virtual/tty/console/subsystem/ttymxc0/console
      # echo -n Y > /sys/devices/virtual/tty/console/subsystem/ttymxc0/console
    
    [   73.166649] 8<--- cut here ---
    [   73.167005] Unable to handle kernel paging request at virtual address c154d928
    [   73.167601] pgd = 55433e84
    [   73.167875] [c154d928] *pgd=8141941e(bad)
    [   73.168304] Internal error: Oops: 8000000d [#1] SMP ARM
    [   73.168429] Modules linked in:
    [   73.168522] CPU: 0 PID: 536 Comm: sh Not tainted 5.15.0-rc6-00056-g3968ddcf05fb #3
    [   73.168675] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
    [   73.168791] PC is at imx_uart_console_setup+0x0/0x238
    [   73.168927] LR is at try_enable_new_console+0x98/0x124
    [   73.169056] pc : [<c154d928>]    lr : [<c0196f44>]    psr: a0000013
    [   73.169178] sp : c2ef5e70  ip : 00000000  fp : 00000000
    [   73.169281] r10: 00000000  r9 : c02cf970  r8 : 00000000
    [   73.169389] r7 : 00000001  r6 : 00000001  r5 : c1760164  r4 : c1e0fb08
    [   73.169512] r3 : c154d928  r2 : 00000000  r1 : efffcbd1  r0 : c1760164
    [   73.169641] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    [   73.169782] Control: 10c5387d  Table: 8345406a  DAC: 00000051
    [   73.169895] Register r0 information: non-slab/vmalloc memory
    [   73.170032] Register r1 information: non-slab/vmalloc memory
    [   73.170158] Register r2 information: NULL pointer
    [   73.170273] Register r3 information: non-slab/vmalloc memory
    [   73.170397] Register r4 information: non-slab/vmalloc memory
    [   73.170521] Register r5 information: non-slab/vmalloc memory
    [   73.170647] Register r6 information: non-paged memory
    [   73.170771] Register r7 information: non-paged memory
    [   73.170892] Register r8 information: NULL pointer
    [   73.171009] Register r9 information: non-slab/vmalloc memory
    [   73.171142] Register r10 information: NULL pointer
    [   73.171259] Register r11 information: NULL pointer
    [   73.171375] Register r12 information: NULL pointer
    [   73.171494] Process sh (pid: 536, stack limit = 0xcd1ba82f)
    [   73.171621] Stack: (0xc2ef5e70 to 0xc2ef6000)
    [   73.171731] 5e60:                                     ???????? ???????? ???????? ????????
    [   73.171899] 5e80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.172059] 5ea0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.172217] 5ec0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.172377] 5ee0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.172537] 5f00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.172698] 5f20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.172856] 5f40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.173016] 5f60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.173177] 5f80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.173336] 5fa0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.173496] 5fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.173654] 5fe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.173826] [<c0196f44>] (try_enable_new_console) from [<c01984a8>] (register_console+0x10c/0x2ec)
    [   73.174053] [<c01984a8>] (register_console) from [<c06e2c90>] (console_store+0x14c/0x168)
    [   73.174262] [<c06e2c90>] (console_store) from [<c0383718>] (kernfs_fop_write_iter+0x110/0x1cc)
    [   73.174470] [<c0383718>] (kernfs_fop_write_iter) from [<c02cf5f4>] (vfs_write+0x31c/0x548)
    [   73.174679] [<c02cf5f4>] (vfs_write) from [<c02cf970>] (ksys_write+0x60/0xec)
    [   73.174863] [<c02cf970>] (ksys_write) from [<c0100080>] (ret_fast_syscall+0x0/0x1c)
    [   73.175052] Exception stack(0xc2ef5fa8 to 0xc2ef5ff0)
    [   73.175167] 5fa0:                   ???????? ???????? ???????? ???????? ???????? ????????
    [   73.175327] 5fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
    [   73.175486] 5fe0: ???????? ???????? ???????? ????????
    [   73.175608] Code: 00000000 00000000 00000000 00000000 (00000000)
    [   73.175744] ---[ end trace 9b75121265109bf1 ]---
    
    A similar issue could be triggered by unbinding/binding the serial
    console device [*].
    
    Drop __init so that imx_uart_setup_console() can be safely called at
    runtime.
    
    [*] https://lore.kernel.org/all/20181114174940.7865-3-stefan@agner.ch/
    
    Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Link: https://lore.kernel.org/r/20211020192643.476895-2-francesco.dolcini@toradex.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be9866f92e9cd7e0f126958e0e05f3475b0e3a69
Author: James Smart <jsmart2021@gmail.com>
Date:   Wed Oct 20 14:14:11 2021 -0700

    scsi: lpfc: Wait for successful restart of SLI3 adapter during host sg_reset
    
    [ Upstream commit d305c253af693e69a36cedec880aca6d0c6d789d ]
    
    A prior patch introduced HBA_NEEDS_CFG_PORT flag logic, but in
    lpfc_sli_brdrestart_s3() code path, right after HBA_NEEDS_CFG_PORT is set,
    the phba->hba_flag is cleared in lpfc_sli_brdreset().
    
    Fix by calling lpfc_sli_chipset_init() to wait for successful restart of
    the HBA in lpfc_host_reset_handler() after lpfc_sli_brdrestart().
    
    lpfc_sli_chipset_init() sets the HBA_NEEDS_CFG_PORT flag so that the
    lpfc_sli_hba_setup() routine from lpfc_online() will execute
    lpfc_sli_config_port() initialization step when the brdrestart is
    successful.
    
    Link: https://lore.kernel.org/r/20211020211417.88754-3-jsmart2021@gmail.com
    Fixes: d2f2547efd39 ("scsi: lpfc: Fix auto sli_mode and its effect on CONFIG_PORT for SLI3")
    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 d17f1042be8601bc575ed09981b1d8b5e1264ebe
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Sep 14 10:22:14 2021 +0100

    scsi: ufs: ufshcd-pltfrm: Fix memory leak due to probe defer
    
    [ Upstream commit b6ca770ae7f2c560a29bbd02c4e3d734fafaf804 ]
    
    UFS drivers that probe defer will end up leaking memory allocated for clk
    and regulator names via kstrdup() because the structure that is holding
    this memory is allocated via devm_* variants which will be freed during
    probe defer but the names are never freed.
    
    Use same devm_* variant of kstrdup to free the memory allocated to name
    when driver probe defers.
    
    Kmemleak found around 11 leaks on Qualcomm Dragon Board RB5:
    
    unreferenced object 0xffff66f243fb2c00 (size 128):
      comm "kworker/u16:0", pid 7, jiffies 4294893319 (age 94.848s)
      hex dump (first 32 bytes):
        63 6f 72 65 5f 63 6c 6b 00 76 69 72 74 75 61 6c  core_clk.virtual
        2f 77 6f 72 6b 71 75 65 75 65 2f 73 63 73 69 5f  /workqueue/scsi_
      backtrace:
        [<000000006f788cd1>] slab_post_alloc_hook+0x88/0x410
        [<00000000cfd1372b>] __kmalloc_track_caller+0x138/0x230
        [<00000000a92ab17b>] kstrdup+0xb0/0x110
        [<0000000037263ab6>] ufshcd_pltfrm_init+0x1a8/0x500
        [<00000000a20a5caa>] ufs_qcom_probe+0x20/0x58
        [<00000000a5e43067>] platform_probe+0x6c/0x118
        [<00000000ef686e3f>] really_probe+0xc4/0x330
        [<000000005b18792c>] __driver_probe_device+0x88/0x118
        [<00000000a5d295e8>] driver_probe_device+0x44/0x158
        [<000000007e83f58d>] __device_attach_driver+0xb4/0x128
        [<000000004bfa4470>] bus_for_each_drv+0x68/0xd0
        [<00000000b89a83bc>] __device_attach+0xec/0x170
        [<00000000ada2beea>] device_initial_probe+0x14/0x20
        [<0000000079921612>] bus_probe_device+0x9c/0xa8
        [<00000000d268bf7c>] deferred_probe_work_func+0x90/0xd0
        [<000000009ef64bfa>] process_one_work+0x29c/0x788
    unreferenced object 0xffff66f243fb2c80 (size 128):
      comm "kworker/u16:0", pid 7, jiffies 4294893319 (age 94.848s)
      hex dump (first 32 bytes):
        62 75 73 5f 61 67 67 72 5f 63 6c 6b 00 00 00 00  bus_aggr_clk....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    
    With this patch no memory leaks are reported.
    
    Link: https://lore.kernel.org/r/20210914092214.6468-1-srinivas.kandagatla@linaro.org
    Fixes: aa4976130934 ("ufs: Add regulator enable support")
    Fixes: c6e79dacd86f ("ufs: Add clock initialization support")
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3eab21ff9f879b188fb2144c709369381dbaa1b7
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Oct 12 11:15:21 2021 +0100

    soundwire: bus: stop dereferencing invalid slave pointer
    
    [ Upstream commit 4cbbe74d906be0bcffbe1e74b43a00f99626a69c ]
    
    Slave pointer is invalid after end of list iteration, using this
    would result in below Memory abort.
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
    ...
    Call trace:
     __dev_printk+0x34/0x7c
     _dev_warn+0x6c/0x90
     sdw_bus_exit_clk_stop+0x194/0x1d0
     swrm_runtime_resume+0x13c/0x238
     pm_generic_runtime_resume+0x2c/0x48
     __rpm_callback+0x44/0x150
     rpm_callback+0x6c/0x78
     rpm_resume+0x314/0x558
     rpm_resume+0x378/0x558
     rpm_resume+0x378/0x558
     __pm_runtime_resume+0x3c/0x88
    
    Use bus->dev instead to print this error message.
    
    Fixes: b50bb8ba369cd ("soundwire: bus: handle -ENODATA errors in clock stop/start sequences")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20211012101521.32087-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1d477cf9ba25d07f5b1c0f530225eaf2c0a7bfd
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Fri Sep 3 16:14:19 2021 +0200

    iio: adis: do not disabe IRQs in 'adis_init()'
    
    [ Upstream commit b600bd7eb333554518b4dd36b882b2ae58a5149e ]
    
    With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
    we are doing a HW or SW reset to the device which means that we'll get
    the default state of the data ready pin (which is enabled). Hence there's
    no point in disabling the IRQ in the init function. Moreover, this
    function is intended to initialize internal data structures and not
    really do anything on the device.
    
    As a result of this, some devices were left with the data ready pin enabled
    after probe which was not the desired behavior. Thus, we move the call to
    'adis_enable_irq()' to the initial startup function where it makes more
    sense for it to be.
    
    Note that for devices that cannot mask/unmask the pin, it makes no sense
    to call the function at this point since the IRQ should not have been
    yet requested. This will be improved in a follow up change.
    
    Fixes: ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210903141423.517028-2-nuno.sa@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 715a48b6598452da46f85bfb5725e646b4fbc3b0
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu Oct 14 18:36:09 2021 -0700

    usb: typec: STUSB160X should select REGMAP_I2C
    
    [ Upstream commit 8ef1e58783b9f55daa4a865c7801dc75cbeb8260 ]
    
    REGMAP_I2C is not a user visible kconfig symbol so driver configs
    should not "depend on" it. They should depend on I2C and then
    select REGMAP_I2C.
    
    If this worked, it was only because some other driver had set/enabled
    REGMAP_I2C.
    
    Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family")
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Cc: Amelie Delaunay <amelie.delaunay@st.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: linux-usb@vger.kernel.org
    Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20211015013609.7300-1-rdunlap@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8409b2f07a4d4efb2e783e1ad2ac56bc407b3d2
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Oct 13 12:49:22 2021 +0300

    iio: buffer: Fix double-free in iio_buffers_alloc_sysfs_and_mask()
    
    [ Upstream commit 09776d9374e635b1580b3736c19b95b788fbaa85 ]
    
    When __iio_buffer_alloc_sysfs_and_mask() failed, 'unwind_idx' should be
    set to 'i - 1' to prevent double-free when cleanup resources.
    
    BUG: KASAN: double-free or invalid-free in __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio]
    Call Trace:
     kfree+0x117/0x4c0
     __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio]
     iio_buffers_alloc_sysfs_and_mask+0x60d/0x1570 [industrialio]
     __iio_device_register+0x483/0x1a30 [industrialio]
     ina2xx_probe+0x625/0x980 [ina2xx_adc]
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20211013094923.2473-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96c0265e8742c87e027e16c4dbafad05cfb66b01
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat Oct 16 22:06:07 2021 +0300

    soc: qcom: socinfo: add two missing PMIC IDs
    
    [ Upstream commit 2fae3ecc70405b72ea6c923b216d34547559d6a9 ]
    
    Add IDs for PMK8001 and PMI8996. They also fall in the list of
    'duplicated' IDs, where the same index was used for multiple chips.
    
    Fixes: 7fda2b0bfbd9 ("soc: qcom: socinfo: import PMIC IDs from pmic-spmi")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211016190607.49866-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c8a9b6365ea5be6c5b8f17722486ec3222239c5
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon Oct 4 20:37:32 2021 -0700

    soc: qcom: rpmhpd: Make power_on actually enable the domain
    
    [ Upstream commit e3e56c050ab6e3f1bd811f0787f50709017543e4 ]
    
    The general expectation is that powering on a power-domain should make
    the power domain deliver some power, and if a specific performance state
    is needed further requests has to be made.
    
    But in contrast with other power-domain implementations (e.g. rpmpd) the
    RPMh does not have an interface to enable the power, so the driver has
    to vote for a particular corner (performance level) in rpmh_power_on().
    
    But the corner is never initialized, so a typical request to simply
    enable the power domain would not actually turn on the hardware. Further
    more, when no more clients vote for a performance state (i.e. the
    aggregated vote is 0) the power domain would be turned off.
    
    Fix both of these issues by always voting for a corner with non-zero
    value, when the power domain is enabled.
    
    The tracking of the lowest non-zero corner is performed to handle the
    corner case if there's ever a domain with a non-zero lowest corner, in
    which case both rpmh_power_on() and rpmh_rpmhpd_set_performance_state()
    would be allowed to use this lowest corner.
    
    Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver")
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20211005033732.2284447-1-bjorn.andersson@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94a60d141380bdce5d27e92acd6dc3c76ea7d824
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Fri Oct 15 14:36:08 2021 +0100

    ASoC: cs42l42: Defer probe if request_threaded_irq() returns EPROBE_DEFER
    
    [ Upstream commit 0306988789d9d91a18ff70bd2bf165d3ae0ef1dd ]
    
    The driver can run without an interrupt so if devm_request_threaded_irq()
    failed, the probe() just carried on. But if this was EPROBE_DEFER the
    driver would continue without an interrupt instead of deferring to wait
    for the interrupt to become available.
    
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20211015133619.4698-6-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 001b7f31f50d0cca828594c96997b72b7acdb669
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Fri Oct 15 14:36:06 2021 +0100

    ASoC: cs42l42: Correct some register default values
    
    [ Upstream commit d591d4b32aa9552af14a0c7c586a2d3fe9ecc6e0 ]
    
    Some registers had wrong default values in cs42l42_reg_defaults[].
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Link: https://lore.kernel.org/r/20211015133619.4698-4-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7e17c293ec2965121674a0a509c477e3a99ea3e
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Fri Oct 15 14:36:05 2021 +0100

    ASoC: cs42l42: Always configure both ASP TX channels
    
    [ Upstream commit 6e6825801ab926360f7f4f2dbcfd107d5ab8f025 ]
    
    An I2S frame always has two slots (left and right) even when sending
    mono. The right channel (channel 2) of ASP TX will always have the
    same bit width as the left channel and will always be on the high
    phase of LRCLK.
    
    The previous implementation always passed the field masks for both
    channels to snd_soc_component_update_bits() but for mono the written value
    only contained the settings for channel 1. The result was that for mono
    channel 2 was set to 8-bit (which is an invalid configuration) with both
    channels on the low phase of LRCLK.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 585e7079de0e ("ASoC: cs42l42: Add Capture Support")
    Link: https://lore.kernel.org/r/20211015133619.4698-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0204fbf40c9527f7d3edac4fe56599eaf2e18d54
Author: Olivier Moysan <olivier.moysan@foss.st.com>
Date:   Mon Oct 4 11:03:04 2021 +0200

    ARM: dts: stm32: fix AV96 board SAI2 pin muxing on stm32mp15
    
    [ Upstream commit 1a9a9d226f0f0ef5d9bf588ab432e0d679bb1954 ]
    
    Fix SAI2A and SAI2B pin muxings for AV96 board on STM32MP15.
    Change sai2a-4 & sai2a-5 to sai2a-2 & sai2a-2.
    Change sai2a-4 & sai2a-sleep-5 to sai2b-2 & sai2b-sleep-2
    
    Fixes: dcf185ca8175 ("ARM: dts: stm32: Add alternate pinmux for SAI2 pins on stm32mp15")
    
    Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 210d7e34a13a8a84caf4cfb36f349daff3cc8389
Author: Olivier Moysan <olivier.moysan@foss.st.com>
Date:   Fri Sep 24 18:02:21 2021 +0200

    ARM: dts: stm32: fix SAI sub nodes register range
    
    [ Upstream commit 6f87a74d31277f0896dcf8c0850ec14bde03c423 ]
    
    The STM32 SAI subblocks registers offsets are in the range
    0x0004 (SAIx_CR1) to 0x0020 (SAIx_DR).
    The corresponding range length is 0x20 instead of 0x1c.
    Change reg property accordingly.
    
    Fixes: 5afd65c3a060 ("ARM: dts: stm32: add sai support on stm32mp157c")
    
    Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85d082965af692659f7a3cb0b0a2a74358ef6df7
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Date:   Tue Sep 21 15:34:49 2021 +0200

    ARM: dts: stm32: fix STUSB1600 Type-C irq level on stm32mp15xx-dkx
    
    [ Upstream commit 3d4fb3d4c431f45272bf8c308d3cbe030817f046 ]
    
    STUSB1600 IRQ (Alert pin) is active low (open drain). Interrupts may get
    lost currently, so fix the IRQ type.
    
    Fixes: 83686162c0eb ("ARM: dts: stm32: add STUSB1600 Type-C using I2C4 on stm32mp15xx-dkx")
    
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c80bba28b1f9b23674a803ca4d445ea03843fd9d
Author: Marek Vasut <marex@denx.de>
Date:   Mon Aug 9 14:13:24 2021 +0200

    ARM: dts: stm32: Reduce DHCOR SPI NOR frequency to 50 MHz
    
    [ Upstream commit 2012579b31293d0a8cf2024e9dab66810bf1a15e ]
    
    The SPI NOR is a bit further away from the SoC on DHCOR than on DHCOM,
    which causes additional signal delay. At 108 MHz, this delay triggers
    a sporadic issue where the first bit of RX data is not received by the
    QSPI controller.
    
    There are two options of addressing this problem, either by using the
    DLYB block to compensate the extra delay, or by reducing the QSPI bus
    clock frequency. The former requires calibration and that is overly
    complex, so opt for the second option.
    
    Fixes: 76045bc457104 ("ARM: dts: stm32: Add QSPI NOR on AV96")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Cc: Patrice Chotard <patrice.chotard@foss.st.com>
    Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecca03f758fa26ba8e930f13545568ff85fb493c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Oct 7 16:38:47 2021 +0200

    pinctrl: renesas: checker: Fix off-by-one bug in drive register check
    
    [ Upstream commit 28e7f8ff90583791a034d43b5d2e3fe394142e13 ]
    
    The GENMASK(h, l) macro creates a contiguous bitmask starting at bit
    position @l and ending at position @h, inclusive.
    
    This did not trigger any error checks, as the individual register fields
    cover at most 3 of the 4 available bits.
    
    Fixes: 08df16e07ad0a1ec ("pinctrl: sh-pfc: checker: Add drive strength register checks")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/8f82d6147fbe3367d4c83962480e97f58d9c96a2.1633615652.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 547eae8d290ba73689c1f5ddb8fc889fd84ee886
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.cm>
Date:   Thu Oct 7 13:21:21 2021 +0530

    powerpc/perf: Fix cycles/instructions as PM_CYC/PM_INST_CMPL in power10
    
    [ Upstream commit 8f6aca0e0f26eaaee670cd27896993a45cdc8f9e ]
    
    On power9 and earlier platforms, the default event used for cyles and
    instructions is PM_CYC (0x0001e) and PM_INST_CMPL (0x00002)
    respectively. These events use two programmable PMCs and by default will
    count irrespective of the run latch state (idle state). But since they
    use programmable PMCs, these events can lead to multiplexing with other
    events, because there are only 4 programmable PMCs. Hence in power10,
    performance monitoring unit (PMU) driver uses performance monitor
    counter 5 (PMC5) and performance monitor counter6 (PMC6) for counting
    instructions and cycles.
    
    Currently on power10, the event used for cycles is PM_RUN_CYC (0x600F4)
    and instructions uses PM_RUN_INST_CMPL (0x500fa). But counting of these
    events in idle state is controlled by the CC56RUN bit setting in Monitor
    Mode Control Register0 (MMCR0). If the CC56RUN bit is zero, PMC5/6 will
    not count when CTRL[RUN] (run latch) is zero. This could lead to missing
    some counts if a thread is in idle state during system wide profiling.
    
    To fix it, set the CC56RUN bit in MMCR0 for power10, which makes PMC5
    and PMC6 count instructions and cycles regardless of the run latch
    state. Since this change make PMC5/6 count as PM_INST_CMPL/PM_CYC,
    rename the event code 0x600f4 as PM_CYC instead of PM_RUN_CYC and event
    code 0x500fa as PM_INST_CMPL instead of PM_RUN_INST_CMPL. The changes
    are only for PMC5/6 event codes and will not affect the behaviour of
    PM_RUN_CYC/PM_RUN_INST_CMPL if progammed in other PMC's.
    
    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.cm>
    Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    [mpe: Tweak change log wording for style and consistency]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211007075121.28497-1-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a14e312ad42f124d288456e4995c47e92672692c
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Wed Oct 13 11:40:20 2021 -0400

    dyndbg: make dyndbg a known cli param
    
    [ Upstream commit 5ca173974888368fecfb17ae6fe455df5fd2a9d2 ]
    
    Right now dyndbg shows up as an unknown parameter if used on boot:
    
        Unknown command line parameters: dyndbg=+p
    
    That's because it is unknown, it doesn't sit in the __param
    section, so the processing done to warn users supplying an unknown
    parameter doesn't think it is legitimate.
    
    Install a dummy handler to register it. dynamic debug needs to search
    the whole command line for modules listed that are currently builtin,
    so there's no real work to be done in this callback.
    
    Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
    Tested-by: Jim Cromie <jim.cromie@gmail.com>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Signed-off-by: Jason Baron <jbaron@akamai.com>
    Link: https://lore.kernel.org/r/1634139622-20667-2-git-send-email-jbaron@akamai.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88d564772486c9eae236667485e7db8190e8759a
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Wed Oct 13 10:59:42 2021 -0600

    RDMA/core: Set sgtable nents when using ib_dma_virt_map_sg()
    
    [ Upstream commit ac0fffa0859b8e1e991939663b3ebdd80bf979e6 ]
    
    ib_dma_map_sgtable_attrs() should be mapping the sgls and setting nents
    but the ib_uses_virt_dma() path falls back to ib_dma_virt_map_sg() which
    will not set the nents in the sgtable.
    
    Check the return value (per the map_sg calling convention) and set
    sgt->nents appropriately on success.
    
    Fixes: 79fbd3e1241c ("RDMA: Use the sg_table directly and remove the opencoded version from umem")
    Link: https://lore.kernel.org/r/20211013165942.89806-1-logang@deltatee.com
    Reported-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Tested-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc7f21385c83dea09ddd00c7377aacdf60bf9a27
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Mon Oct 11 17:29:41 2021 +0200

    staging: ks7010: select CRYPTO_HASH/CRYPTO_MICHAEL_MIC
    
    [ Upstream commit 9ca0e55e52c7b2a99f3c2051fc4bd1c63a061519 ]
    
    Fix the following build/link errors:
    
      ld: drivers/staging/ks7010/ks_hostif.o: in function `michael_mic.constprop.0':
      ks_hostif.c:(.text+0x95b): undefined reference to `crypto_alloc_shash'
      ld: ks_hostif.c:(.text+0x97a): undefined reference to `crypto_shash_setkey'
      ld: ks_hostif.c:(.text+0xa13): undefined reference to `crypto_shash_update'
      ld: ks_hostif.c:(.text+0xa28): undefined reference to `crypto_shash_update'
      ld: ks_hostif.c:(.text+0xa48): undefined reference to `crypto_shash_finup'
      ld: ks_hostif.c:(.text+0xa6d): undefined reference to `crypto_destroy_tfm'
    
    Fixes: 8b523f20417d ("staging: ks7010: removed custom Michael MIC implementation.")
    Fixes: 3e5bc68fa5968 ("staging: ks7010: Fix build error")
    Fixes: a4961427e7494 ("Revert "staging: ks7010: Fix build error"")
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Link: https://lore.kernel.org/r/20211011152941.12847-1-vegard.nossum@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab206dd351488f7bf6c7dfc901f08e78eb278059
Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date:   Mon Oct 11 09:11:18 2021 +0300

    staging: most: dim2: do not double-register the same device
    
    [ Upstream commit 2ab189164056b05474275bb40caa038a37713061 ]
    
    Commit 723de0f9171e ("staging: most: remove device from interface
    structure") moved registration of driver-provided struct device to
    the most subsystem.
    
    Dim2 used to register the same struct device to provide a custom device
    attribute. This causes double-registration of the same struct device.
    
    Fix that by moving the custom attribute to driver's dev_groups.
    This moves attribute to the platform_device object, which is a better
    location for platform-specific attributes anyway.
    
    Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
    Acked-by: Christian Gromm <christian.gromm@microchip.com>
    Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
    Link: https://lore.kernel.org/r/20211011061117.21435-1-nikita.yoush@cogentembedded.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1401c37fee26268a76ac8391d661b7c881fde9b
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Oct 5 16:57:47 2021 -0700

    usb: musb: select GENERIC_PHY instead of depending on it
    
    [ Upstream commit fde1fbedbaed4e76cef4600d775b185f59b9b568 ]
    
    The kconfig symbol GENERIC_PHY says:
      All the users of this framework should select this config.
    and around 136 out of 138 drivers do so, so change USB_MUSB_MEDIATEK
    to do so also.
    
    This (also) fixes a long circular dependency problem for an upcoming
    patch.
    
    Fixes: 0990366bab3c ("usb: musb: Add support for MediaTek musb controller")
    Cc: Bin Liu <b-liu@ti.com>
    Cc: Min Guo <min.guo@mediatek.com>
    Cc: Yonglong Wu <yonglong.wu@mediatek.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: linux-mediatek@lists.infradead.org
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20211005235747.5588-1-rdunlap@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de3c7a4167c2cb15c4517d8555d8f679101a0cbd
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Oct 12 10:28:43 2021 +0300

    RDMA/mlx4: Return missed an error if device doesn't support steering
    
    [ Upstream commit f4e56ec4452f48b8292dcf0e1c4bdac83506fb8b ]
    
    The error flow fixed in this patch is not possible because all kernel
    users of create QP interface check that device supports steering before
    set IB_QP_CREATE_NETIF_QP flag.
    
    Fixes: c1c98501121e ("IB/mlx4: Add support for steerable IB UD QPs")
    Link: https://lore.kernel.org/r/91c61f6e60eb0240f8bbc321fda7a1d2986dd03c.1634023677.git.leonro@nvidia.com
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8adfc48bda62ebd6c4c4de209e99b799fc7edab2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 6 10:32:43 2021 +0300

    scsi: csiostor: Uninitialized data in csio_ln_vnp_read_cbfn()
    
    [ Upstream commit f4875d509a0a78ad294a1a538d534b5ba94e685a ]
    
    This variable is just a temporary variable, used to do an endian
    conversion.  The problem is that the last byte is not initialized.  After
    the conversion is completely done, the last byte is discarded so it doesn't
    cause a problem.  But static checkers and the KMSan runtime checker can
    detect the uninitialized read and will complain about it.
    
    Link: https://lore.kernel.org/r/20211006073242.GA8404@kili
    Fixes: 5036f0a0ecd3 ("[SCSI] csiostor: Fix sparse warnings.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40f7932e8ca4190dfb00e0a7460c8f75155ad27f
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Oct 8 14:31:50 2021 +0800

    power: supply: max17040: fix null-ptr-deref in max17040_probe()
    
    [ Upstream commit 1d422ecfc48ee683ae1ccc9217764f6310c0ffce ]
    
    Add check the return value of devm_regmap_init_i2c(), otherwise
    later access may cause null-ptr-deref as follows:
    
    KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367]
    RIP: 0010:regmap_read+0x33/0x170
    Call Trace:
      max17040_probe+0x61b/0xff0 [max17040_battery]
     ? write_comp_data+0x2a/0x90
     ? max17040_set_property+0x1d0/0x1d0 [max17040_battery]
     ? tracer_hardirqs_on+0x33/0x520
     ? __sanitizer_cov_trace_pc+0x1d/0x50
     ? _raw_spin_unlock_irqrestore+0x4b/0x60
     ? trace_hardirqs_on+0x63/0x2d0
     ? write_comp_data+0x2a/0x90
     ? __sanitizer_cov_trace_pc+0x1d/0x50
     ? max17040_set_property+0x1d0/0x1d0 [max17040_battery]
     i2c_device_probe+0xa31/0xbe0
    
    Fixes: 6455a8a84bdf ("power: supply: max17040: Use regmap i2c")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2225dade4147a3ee1b3e68e1026bec4d447425fa
Author: Jakob Hauser <jahau@rocketmail.com>
Date:   Fri Oct 8 10:32:45 2021 +0200

    power: supply: rt5033_battery: Change voltage values to µV
    
    [ Upstream commit bf895295e9a73411889816f1a0c1f4f1a2d9c678 ]
    
    Currently the rt5033_battery driver provides voltage values in mV. It
    should be µV as stated in Documentation/power/power_supply_class.rst.
    
    Fixes: b847dd96e659 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver")
    Cc: Beomho Seo <beomho.seo@samsung.com>
    Cc: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82012f8f4926d33df5a8c670d9c1211a395560dc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Oct 11 15:37:39 2021 +0300

    usb: gadget: hid: fix error code in do_config()
    
    [ Upstream commit 68e7c510fdf4f6167404609da52e1979165649f6 ]
    
    Return an error code if usb_get_function() fails.  Don't return success.
    
    Fixes: 4bc8a33f2407 ("usb: gadget: hid: convert to new interface of f_hid")
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20211011123739.GC15188@kili
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64b913c6d40a8f90e72d2a0b63cf0d5db66f8925
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Oct 5 16:45:16 2021 +0300

    serial: 8250_dw: Drop wrong use of ACPI_PTR()
    
    [ Upstream commit ebabb77a2a115b6c5e68f7364b598310b5f61fb2 ]
    
    ACPI_PTR() is more harmful than helpful. For example, in this case
    if CONFIG_ACPI=n, the ID table left unused which is not what we want.
    
    Instead of adding ifdeffery here and there, drop ACPI_PTR().
    
    Fixes: 6a7320c4669f ("serial: 8250_dw: Add ACPI 5.0 support")
    Reported-by: Daniel Palmer <daniel@0x0f.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20211005134516.23218-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e271314bf2a27e5cba85c06ed8b5eadc05f42576
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Tue Sep 28 16:41:47 2021 -0500

    powerpc/paravirt: correct preempt debug splat in vcpu_is_preempted()
    
    [ Upstream commit fda0eb220021a97c1d656434b9340ebf3fc4704a ]
    
    vcpu_is_preempted() can be used outside of preempt-disabled critical
    sections, yielding warnings such as:
    
    BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/185
    caller is rwsem_spin_on_owner+0x1cc/0x2d0
    CPU: 1 PID: 185 Comm: systemd-udevd Not tainted 5.15.0-rc2+ #33
    Call Trace:
    [c000000012907ac0] [c000000000aa30a8] dump_stack_lvl+0xac/0x108 (unreliable)
    [c000000012907b00] [c000000001371f70] check_preemption_disabled+0x150/0x160
    [c000000012907b90] [c0000000001e0e8c] rwsem_spin_on_owner+0x1cc/0x2d0
    [c000000012907be0] [c0000000001e1408] rwsem_down_write_slowpath+0x478/0x9a0
    [c000000012907ca0] [c000000000576cf4] filename_create+0x94/0x1e0
    [c000000012907d10] [c00000000057ac08] do_symlinkat+0x68/0x1a0
    [c000000012907d70] [c00000000057ae18] sys_symlink+0x58/0x70
    [c000000012907da0] [c00000000002e448] system_call_exception+0x198/0x3c0
    [c000000012907e10] [c00000000000c54c] system_call_common+0xec/0x250
    
    The result of vcpu_is_preempted() is always used speculatively, and the
    function does not access per-cpu resources in a (Linux) preempt-unsafe way.
    Use raw_smp_processor_id() to avoid such warnings, adding explanatory
    comments.
    
    Fixes: ca3f969dcb11 ("powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted()")
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210928214147.312412-3-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddd95eb01afdab9a46289ef0dd6a697c907eaee6
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Tue Sep 28 07:45:50 2021 -0500

    powerpc: fix unbalanced node refcount in check_kvm_guest()
    
    [ Upstream commit 56537faf8821e361d739fc5ff58c9c40f54a1d4c ]
    
    When check_kvm_guest() succeeds in looking up a /hypervisor OF node, it
    returns without performing a matching put for the lookup, leaving the
    node's reference count elevated.
    
    Add the necessary call to of_node_put(), rearranging the code slightly to
    avoid repetition or goto.
    
    Fixes: 107c55005fbd ("powerpc/pseries: Add KVM guest doorbell restrictions")
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210928124550.132020-1-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2af070265d6e7192cf7cdd7002197c76240159b8
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Sep 15 15:34:35 2021 +0200

    video: fbdev: chipsfb: use memset_io() instead of memset()
    
    [ Upstream commit f2719b26ae27282c145202ffd656d5ff1fe737cc ]
    
    While investigating a lockup at startup on Powerbook 3400C, it was
    identified that the fbdev driver generates alignment exception at
    startup:
    
      --- interrupt: 600 at memset+0x60/0xc0
      NIP:  c0021414 LR: c03fc49c CTR: 00007fff
      REGS: ca021c10 TRAP: 0600   Tainted: G        W          (5.14.2-pmac-00727-g12a41fa69492)
      MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 44008442  XER: 20000100
      DAR: cab80020 DSISR: 00017c07
      GPR00: 00000007 ca021cd0 c14412e0 cab80000 00000000 00100000 cab8001c 00000004
      GPR08: 00100000 00007fff 00000000 00000000 84008442 00000000 c0006fb4 00000000
      GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00100000
      GPR24: 00000000 81800000 00000320 c15fa400 c14d1878 00000000 c14d1800 c094e19c
      NIP [c0021414] memset+0x60/0xc0
      LR [c03fc49c] chipsfb_pci_init+0x160/0x580
      --- interrupt: 600
      [ca021cd0] [c03fc46c] chipsfb_pci_init+0x130/0x580 (unreliable)
      [ca021d20] [c03a3a70] pci_device_probe+0xf8/0x1b8
      [ca021d50] [c043d584] really_probe.part.0+0xac/0x388
      [ca021d70] [c043d914] __driver_probe_device+0xb4/0x170
      [ca021d90] [c043da18] driver_probe_device+0x48/0x144
      [ca021dc0] [c043e318] __driver_attach+0x11c/0x1c4
      [ca021de0] [c043ad30] bus_for_each_dev+0x88/0xf0
      [ca021e10] [c043c724] bus_add_driver+0x190/0x22c
      [ca021e40] [c043ee94] driver_register+0x9c/0x170
      [ca021e60] [c0006c28] do_one_initcall+0x54/0x1ec
      [ca021ed0] [c08246e4] kernel_init_freeable+0x1c0/0x270
      [ca021f10] [c0006fdc] kernel_init+0x28/0x11c
      [ca021f30] [c0017148] ret_from_kernel_thread+0x14/0x1c
      Instruction dump:
      7d4601a4 39490777 7d4701a4 39490888 7d4801a4 39490999 7d4901a4 39290aaa
      7d2a01a4 4c00012c 4bfffe88 0fe00000 <4bfffe80> 9421fff0 38210010 48001970
    
    This is due to 'dcbz' instruction being used on non-cached memory.
    'dcbz' instruction is used by memset() to zeroize a complete
    cacheline at once, and memset() is not expected to be used on non
    cached memory.
    
    When performing a 'sparse' check on fbdev driver, it also appears
    that the use of memset() is unexpected:
    
      drivers/video/fbdev/chipsfb.c:334:17: warning: incorrect type in argument 1 (different address spaces)
      drivers/video/fbdev/chipsfb.c:334:17:    expected void *
      drivers/video/fbdev/chipsfb.c:334:17:    got char [noderef] __iomem *screen_base
      drivers/video/fbdev/chipsfb.c:334:15: warning: memset with byte count of 1048576
    
    Use fb_memset() instead of memset(). fb_memset() is defined as
    memset_io() for powerpc.
    
    Fixes: 8c8709334cec ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK")
    Reported-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/884a54f1e5cb774c1d9b4db780209bee5d4f6718.1631712563.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11644855488e93404d5171728d6d08746ed0f717
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Sep 13 17:17:26 2021 +0200

    powerpc/mem: Fix arch/powerpc/mm/mem.c:53:12: error: no previous prototype for 'create_section_mapping'
    
    [ Upstream commit 7eff9bc00ddf1e2281dff575884b7f676c85b006 ]
    
    Commit 8e11d62e2e87 ("powerpc/mem: Add back missing header to fix 'no
    previous prototype' error") was supposed to fix the problem, but in
    the meantime commit a927bd6ba952 ("mm: fix phys_to_target_node() and*
    memory_add_physaddr_to_nid() exports") moved create_section_mapping()
    prototype from asm/sparsemem.h to asm/mmzone.h
    
    Fixes: 8e11d62e2e87 ("powerpc/mem: Add back missing header to fix 'no previous prototype' error")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/025754fde3d027904ae9d0191f395890bec93369.1631541649.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62a1c92858c13e88ae1c1090bcdb00437c02c1a4
Author: Clément Léger <clement.leger@bootlin.com>
Date:   Mon Sep 13 10:26:33 2021 +0200

    clk: at91: check pmc node status before registering syscore ops
    
    [ Upstream commit c405f5c15e9f6094f2fa1658e73e56f3058e2122 ]
    
    Currently, at91 pmc driver always register the syscore_ops whatever
    the status of the pmc node that has been found. When set as secure
    and disabled, the pmc should not be accessed or this will generate
    abort exceptions.
    To avoid this, add a check on node availability before registering
    the syscore operations.
    
    Signed-off-by: Clément Léger <clement.leger@bootlin.com>
    Link: https://lore.kernel.org/r/20210913082633.110168-1-clement.leger@bootlin.com
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Fixes: b3b02eac33ed ("clk: at91: Add sama5d2 suspend/resume")
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 383008a0e009e5da274aa6d9d173e93403d080b0
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Sat Sep 25 23:14:32 2021 +0800

    memory: fsl_ifc: fix leak of irq and nand_irq in fsl_ifc_ctrl_probe
    
    [ Upstream commit 4ed2f3545c2e5acfbccd7f85fea5b1a82e9862d7 ]
    
    The error handling code of fsl_ifc_ctrl_probe is problematic. When
    fsl_ifc_ctrl_init fails or request_irq of fsl_ifc_ctrl_dev->irq fails,
    it forgets to free the irq and nand_irq. Meanwhile, if request_irq of
    fsl_ifc_ctrl_dev->nand_irq fails, it will still free nand_irq even if
    the request_irq is not successful.
    
    Fix this by refactoring the error handling code.
    
    Fixes: d2ae2e20fbdd ("driver/memory:Move Freescale IFC driver to a common driver")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Link: https://lore.kernel.org/r/20210925151434.8170-1-mudongliangabcd@gmail.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee65ec08d36b47db0f1e797c6a98803302f7d403
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jun 27 17:54:31 2021 +0200

    soc/tegra: Fix an error handling path in tegra_powergate_power_up()
    
    [ Upstream commit 986b5094708e508baa452a23ffe809870934a7df ]
    
    If an error occurs after a successful tegra_powergate_enable_clocks()
    call, it must be undone by a tegra_powergate_disable_clocks() call, as
    already done in the below and above error handling paths of this function.
    
    Update the 'goto' to branch at the correct place of the error handling
    path.
    
    Fixes: a38045121bf4 ("soc/tegra: pmc: Add generic PM domain support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a45a76ed14621ea661da095d74fc62601eb2ddd
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Sep 27 14:41:53 2021 +0100

    iio: st_pressure_spi: Add missing entries SPI to device ID table
    
    [ Upstream commit 03748d4e003c9f2ad3cd00e3e46f054dcad6b96d ]
    
    Currently autoloading for SPI devices does not use the DT ID table, it uses
    SPI modalises. Supporting OF modalises is going to be difficult if not
    impractical, an attempt was made but has been reverted, so ensure that
    module autoloading works for this driver by adding SPI IDs for parts that
    only have a compatible listed.
    
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210927134153.12739-1-broonie@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6551bac0eb4275bfa2ea2efab41bacdca58fd3db
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Wed Oct 6 13:40:41 2021 +0300

    ASoC: SOF: topology: do not power down primary core during topology removal
    
    [ Upstream commit ec626334eaffe101df9ed79e161eba95124e64ad ]
    
    When removing the topology components, do not power down
    the primary core. Doing so will result in an IPC timeout
    when the SOF PCI device runtime suspends.
    
    Fixes: 0dcdf84289fb ("ASoC: SOF: add a "core" parameter to widget loading functions")
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20211006104041.27183-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93322efe91f2f43876fbce75ad2a1508169f5d37
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Fri Oct 1 09:34:15 2021 +0200

    arm: dts: omap3-gta04a4: accelerometer irq fix
    
    [ Upstream commit 884ea75d79a36faf3731ad9d6b9c29f58697638d ]
    
    Fix typo in pinctrl. It did only work because the bootloader
    seems to have initialized it.
    
    Fixes: ee327111953b ("ARM: dts: omap3-gta04: Define and use bma180 irq pin")
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f8beede9915a0a0fc548858a4a54042cad6705b
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Sep 30 16:57:14 2021 +0800

    driver core: Fix possible memory leak in device_link_add()
    
    [ Upstream commit df0a18149474c7e6b21f6367fbc6bc8d0f192444 ]
    
    I got memory leak as follows:
    
    unreferenced object 0xffff88801f0b2200 (size 64):
      comm "i2c-lis2hh12-21", pid 5455, jiffies 4294944606 (age 15.224s)
      hex dump (first 32 bytes):
        72 65 67 75 6c 61 74 6f 72 3a 72 65 67 75 6c 61  regulator:regula
        74 6f 72 2e 30 2d 2d 69 32 63 3a 31 2d 30 30 31  tor.0--i2c:1-001
      backtrace:
        [<00000000bf5b0c3b>] __kmalloc_track_caller+0x19f/0x3a0
        [<0000000050da42d9>] kvasprintf+0xb5/0x150
        [<000000004bbbed13>] kvasprintf_const+0x60/0x190
        [<00000000cdac7480>] kobject_set_name_vargs+0x56/0x150
        [<00000000bf83f8e8>] dev_set_name+0xc0/0x100
        [<00000000cc1cf7e3>] device_link_add+0x6b4/0x17c0
        [<000000009db9faed>] _regulator_get+0x297/0x680
        [<00000000845e7f2b>] _devm_regulator_get+0x5b/0xe0
        [<000000003958ee25>] st_sensors_power_enable+0x71/0x1b0 [st_sensors]
        [<000000005f450f52>] st_accel_i2c_probe+0xd9/0x150 [st_accel_i2c]
        [<00000000b5f2ab33>] i2c_device_probe+0x4d8/0xbe0
        [<0000000070fb977b>] really_probe+0x299/0xc30
        [<0000000088e226ce>] __driver_probe_device+0x357/0x500
        [<00000000c21dda32>] driver_probe_device+0x4e/0x140
        [<000000004e650441>] __device_attach_driver+0x257/0x340
        [<00000000cf1891b8>] bus_for_each_drv+0x166/0x1e0
    
    When device_register() returns an error, the name allocated in dev_set_name()
    will be leaked, the put_device() should be used instead of kfree() to give up
    the device reference, then the name will be freed in kobject_cleanup() and the
    references of consumer and supplier will be decreased in device_link_release_fn().
    
    Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reviewed-by: Saravana Kannan <saravanak@google.com>
    Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20210930085714.2057460-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c464ab169800d7bd0e7abd4e8a194cc9cf583ed5
Author: Igor Pylypiv <ipylypiv@google.com>
Date:   Tue Sep 28 19:58:47 2021 -0700

    scsi: pm80xx: Fix misleading log statement in pm8001_mpi_get_nvmd_resp()
    
    [ Upstream commit 4084a7235d38311a77c86ba69ba849bd787db87b ]
    
    pm8001_mpi_get_nvmd_resp() handles a GET_NVMD_DATA response, not a
    SET_NVMD_DATA response, as the log statement implies.
    
    Fixes: 1f889b58716a ("scsi: pm80xx: Fix pm8001_mpi_get_nvmd_resp() race condition")
    Link: https://lore.kernel.org/r/20210929025847.646999-1-ipylypiv@google.com
    Reviewed-by: Changyuan Lyu <changyuanl@google.com>
    Acked-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e781506a76ebbc53206b64453ed74c0674f9dab
Author: Sumit Saxena <sumit.saxena@broadcom.com>
Date:   Wed Sep 29 18:10:20 2021 +0530

    scsi: megaraid_sas: Fix concurrent access to ISR between IRQ polling and real interrupt
    
    [ Upstream commit e7dcc514a49e74051b869697d5ab0370f6301d57 ]
    
    IRQ polling thread calls ISR after enable_irq() to handle any missed I/O
    completion. The atomic flag "in_used" was added to have the synchronization
    between the IRQ polling thread and the interrupt context. There is a bug
    around it leading to a race condition.
    
    Below is the sequence:
    
     - IRQ polling thread accesses ISR, fetches the reply descriptor.
    
     - Real interrupt arrives and pre-empts polling thread (enable_irq() is
       already called).
    
     - Interrupt context picks the same reply descriptor as fetched by polling
       thread, processes it, and exits.
    
     - Polling thread resumes and processes the descriptor which is already
       processed by interrupt thread leads to kernel crash.
    
    Setting the "in_used" flag before fetching the reply descriptor ensures
    synchronized access to ISR.
    
    Link: https://www.spinics.net/lists/linux-scsi/msg159440.html
    Link: https://lore.kernel.org/r/20210929124022.24605-2-sumit.saxena@broadcom.com
    Fixes: 9bedd36e9146 ("scsi: megaraid_sas: Handle missing interrupts while re-enabling IRQs")
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca92b5f2ec88ad7c758d86f8dd088c3254fd8202
Author: Bart Van Assche <bvanassche@google.com>
Date:   Fri Oct 1 11:20:15 2021 -0700

    scsi: ufs: core: Stop clearing UNIT ATTENTIONS
    
    [ Upstream commit edc0596cc04bf0ac3a69c66e994d3ff8b650ff71 ]
    
    Commit aa53f580e67b ("scsi: ufs: Minor adjustments to error handling")
    introduced a ufshcd_clear_ua_wluns() call in
    ufshcd_err_handling_unprepare(). As explained in detail by Adrian Hunter,
    this can trigger a deadlock. Avoid that deadlock by removing the code that
    clears the unit attention. This is safe because the only software that
    relies on clearing unit attentions is the Android Trusty software and
    because support for handling unit attentions has been added in the Trusty
    software.
    
    See also https://lore.kernel.org/linux-scsi/20210930124224.114031-2-adrian.hunter@intel.com/
    
    Note that "scsi: ufs: Retry START_STOP on UNIT_ATTENTION" is a prerequisite
    for this commit.
    
    Link: https://lore.kernel.org/r/20211001182015.1347587-3-jaegeuk@kernel.org
    Fixes: aa53f580e67b ("scsi: ufs: Minor adjustments to error handling")
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Bart Van Assche <bvanassche@google.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f1efc0c0ed2011b621d2678f2c618cf6d9e9d1f
Author: Bean Huo <beanhuo@micron.com>
Date:   Wed Sep 29 22:06:39 2021 +0200

    scsi: ufs: core: Fix ufshcd_probe_hba() prototype to match the definition
    
    [ Upstream commit 68444d73d6a5864ede12df6366bd6602e022ae5b ]
    
    Since commit 568dd9959611 ("scsi: ufs: Rename the second ufshcd_probe_hba()
    argument"), the second ufshcd_probe_hba() argument has been changed to
    init_dev_params.
    
    Link: https://lore.kernel.org/r/20210929200640.828611-3-huobean@gmail.com
    Fixes: 568dd9959611 ("scsi: ufs: Rename the second ufshcd_probe_hba() argument")
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1e06f92b2dbc1898b127e867f4e715d85ba46ed
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Sep 30 13:09:28 2021 +0300

    power: reset: at91-reset: check properly the return value of devm_of_iomap
    
    [ Upstream commit f558c8072c3461b65c12c0068b108f78cebc8246 ]
    
    devm_of_iomap() returns error code or valid pointer. Check its return
    value with IS_ERR().
    
    Fixes: bd3127733f2c ("power: reset: at91-reset: use devm_of_iomap")
    Reported-by: Cristian Birsan <cristian.birsan@microchip.com>
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a8d7bdd5b5eec8821647219b82cdf1a5b43ebb2
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Sep 7 11:53:32 2021 +0100

    soundwire: debugfs: use controller id and link_id for debugfs
    
    [ Upstream commit 75eac387a2539aa6c6bbee3affa23435f2096396 ]
    
    link_id can be zero and if we have multiple controller instances
    in a system like Qualcomm debugfs will end-up with duplicate namespace
    resulting in incorrect debugfs entries.
    
    Using bus-id and link-id combination should give a unique debugfs directory
    entry and should fix below warning too.
    "debugfs: Directory 'master-0' with parent 'soundwire' already present!"
    
    Fixes: bf03473d5bcc ("soundwire: add debugfs support")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210907105332.1257-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 784bf21bb6d17af0e3a593a276ca70dd45623edc
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Sep 29 10:08:37 2021 +0200

    ALSA: usb-audio: Fix possible race at sync of urb completions
    
    [ Upstream commit 86a42ad07905110f82648853c0ea3434b4eab173 ]
    
    USB-audio driver tries to sync with the clear of all pending URBs in
    wait_clear_urbs(), and it waits for all bits in active_mask getting
    cleared.  This works fine for the normal operations, but when a stream
    is managed in the implicit feedback mode, there is still a very thin
    race window: namely, in snd_complete_usb(), the active_mask bit for
    the current URB is once cleared before re-submitted in
    queue_pending_output_urbs().  If wait_clear_urbs() is called during
    that period, it may pass the test and go forward even though there may
    be a still pending URB.
    
    For covering it, this patch adds a new counter to each endpoint to
    keep the number of in-flight URBs, and changes wait_clear_urbs()
    checking this number instead.  The counter is decremented at the end
    of URB complete, hence the reference is kept as long as the URB
    complete is in process.
    
    Link: https://lore.kernel.org/r/20210929080844.11583-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34862fa65cc79ae93c56839480c323d0cf79cb09
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Sep 29 09:29:34 2021 +0200

    ALSA: hda: Use position buffer for SKL+ again
    
    [ Upstream commit c4ca3871e21fa085096316f5f8d9975cf3dfde1d ]
    
    The commit f87e7f25893d ("ALSA: hda - Improved position reporting on
    SKL+") changed the PCM position report for SKL+ chips to use DPIB, but
    according to Pierre, DPIB is no best choice for the accurate position
    reports and it often reports too early.  The recommended method is
    rather the classical position buffer.
    
    This patch makes the PCM position reporting on SKL+ back to the
    position buffer again.
    
    Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+")
    Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210929072934.6809-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 987bfc6eb7aa9a597c36f285d9a5c1e2e4105123
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Sep 29 09:29:33 2021 +0200

    ALSA: hda: Reduce udelay() at SKL+ position reporting
    
    [ Upstream commit 46243b85b0ec5d2cee7545e5ce18c015ce91957e ]
    
    The position reporting on Intel Skylake and later chips via
    azx_get_pos_skl() contains a udelay(20) call for the capture streams.
    A call for this alone doesn't sound too harmful.  However, as the
    pointer PCM ops is one of the hottest path in the PCM operations --
    especially for the timer-scheduled operations like PulseAudio -- such
    a delay hogs CPU usage significantly in the total performance.
    
    The code there was taken from the original code in ASoC SST Skylake
    driver blindly.  The udelay() is a workaround for the case where the
    reported position is behind the period boundary at the timing
    triggered from interrupts; applications often expect that the full
    data is available for the whole period when returned (and also that's
    the definition of the ALSA PCM period).
    
    OTOH, HD-audio (legacy) driver has already some workarounds for the
    delayed position reporting due to its relatively large FIFO, such as
    the BDL position adjustment and the delayed period-elapsed call in the
    work.  That said, the udelay() is almost superfluous for HD-audio
    driver unlike SST, and we can drop the udelay().
    
    Though, the current code doesn't guarantee the full period readiness
    as mentioned in the above, but rather it checks the wallclock and
    detects the unexpected jump.  That's one missing piece, and the drop
    of udelay() needs a bit more sanity checks for the delayed handling.
    
    This patch implements those: the drop of udelay() call in
    azx_get_pos_skl() and the more proper check of hwptr in
    azx_position_ok().  The latter change is applied only for the case
    where the stream is running in the normal mode without
    no_period_wakeup flag.  When no_period_wakeup is set, it essentially
    ignores the period handling and rather concentrates only on the
    current position; which implies that we don't need to care about the
    period boundary at all.
    
    Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+")
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210929072934.6809-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f624d5495cc07e4944cc4801dffe0313b0ca0fc1
Author: David Stevens <stevensd@chromium.org>
Date:   Wed Sep 29 11:32:55 2021 +0900

    iommu/dma: Fix arch_sync_dma for map
    
    [ Upstream commit 06e620345d544e559b2961cb5a676ec9c80c8950 ]
    
    When calling arch_sync_dma, we need to pass it the memory that's
    actually being used for dma. When using swiotlb bounce buffers, this is
    the bounce buffer. Move arch_sync_dma into the __iommu_dma_map_swiotlb
    helper, so it can use the bounce buffer address if necessary.
    
    Now that iommu_dma_map_sg delegates to a function which takes care of
    architectural syncing in the untrusted device case, the call to
    iommu_dma_sync_sg_for_device can be moved so it only occurs for trusted
    devices. Doing the sync for untrusted devices before mapping never
    really worked, since it needs to be able to target swiotlb buffers.
    
    This also moves the architectural sync to before the call to
    __iommu_dma_map, to guarantee that untrusted devices can't see stale
    data they shouldn't see.
    
    Fixes: 82612d66d51d ("iommu: Allow the iommu/dma api to use bounce buffers")
    Signed-off-by: David Stevens <stevensd@chromium.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20210929023300.335969-3-stevensd@google.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d39f447f259aea9310e606ab40ae90eb4fde43d9
Author: David Stevens <stevensd@chromium.org>
Date:   Wed Sep 29 11:32:54 2021 +0900

    iommu/dma: Fix sync_sg with swiotlb
    
    [ Upstream commit 08ae5d4a1ae96b72222e7b02d072bb997ff29dac ]
    
    The is_swiotlb_buffer function takes the physical address of the swiotlb
    buffer, not the physical address of the original buffer. The sglist
    contains the physical addresses of the original buffer, so for the
    sync_sg functions to work properly when a bounce buffer might have been
    used, we need to use iommu_iova_to_phys to look up the physical address.
    This is what sync_single does, so call that function on each sglist
    segment.
    
    The previous code mostly worked because swiotlb does the transfer on map
    and unmap. However, any callers which use DMA_ATTR_SKIP_CPU_SYNC with
    sglists or which call sync_sg would not have had anything copied to the
    bounce buffer.
    
    Fixes: 82612d66d51d ("iommu: Allow the iommu/dma api to use bounce buffers")
    Signed-off-by: David Stevens <stevensd@chromium.org>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20210929023300.335969-2-stevensd@google.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9d8cb8dad2da04a1278bf2a4e75d4a17ceb4b7f
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Tue Sep 28 13:29:43 2021 +0200

    arm64: dts: qcom: pm8916: Remove wrong reg-names for rtc@6000
    
    [ Upstream commit 483de2b44cd3a168458f8f9ff237e78a434729bc ]
    
    While removing the size from the "reg" properties in pm8916.dtsi,
    commit bd6429e81010 ("ARM64: dts: qcom: Remove size elements from
    pmic reg properties") mistakenly also removed the second register
    address for the rtc@6000 device. That one did not represent the size
    of the register region but actually the address of the second "alarm"
    register region of the rtc@6000 device.
    
    Now there are "reg-names" for two "reg" elements, but there is actually
    only one "reg" listed.
    
    Since the DT schema for "qcom,pm8941-rtc" only expects one "reg"
    element anyway, just drop the "reg-names" entirely to fix this.
    
    Fixes: bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210928112945.25310-1-stephan@gerhold.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6705c94d90174f85f146f50bbaae9f363da674d0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 27 14:18:44 2021 +0200

    iommu/mediatek: Fix out-of-range warning with clang
    
    [ Upstream commit f13efafc1a2cf30d4a74c00f40210d6de36db2d0 ]
    
    clang-14 notices that a comparison is never true when
    CONFIG_PHYS_ADDR_T_64BIT is disabled:
    
    drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant 5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
                                         ~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Add an explicit check for the type of the variable to skip the check
    and the warning in that case.
    
    Fixes: b4dad40e4f35 ("iommu/mediatek: Adjust the PA for the 4GB Mode")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Yong Wu <yong.wu@mediatek.com>
    Link: https://lore.kernel.org/r/20210927121857.941160-1-arnd@kernel.org
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7b0d0d6041c7176ea47e3e7e48a7cfef9e04270
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Sep 24 08:50:23 2021 +0200

    arm64: dts: renesas: beacon: Fix Ethernet PHY mode
    
    [ Upstream commit 59a8bda062f8646d99ff8c4956adf37dee1cb75e ]
    
    While networking works fine in RGMII mode when using the Linux generic
    PHY driver, it fails when using the Atheros PHY driver.
    Fix this by correcting the Ethernet PHY mode to RGMII-RXID, which works
    fine with both drivers.
    
    Fixes: a5200e63af57d05e ("arm64: dts: renesas: rzg2: Convert EtherAVB to explicit delay handling")
    Reported-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/2a4c15b2df23bb63f15abf9dfb88860477f4f523.1632465965.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94d42f3a174e18602b5d1d67fe5b3f17d97a2f05
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon Aug 16 20:18:10 2021 +0200

    arm64: dts: qcom: msm8916: Fix Secondary MI2S bit clock
    
    [ Upstream commit 8199a0b31e76d158ac14841e7119890461f8c595 ]
    
    At the moment, playing audio on Secondary MI2S will just end up getting
    stuck, without actually playing any audio. This happens because the wrong
    bit clock is configured when playing audio on Secondary MI2S.
    
    The PRI_I2S_CLK (better name: SPKR_I2S_CLK) is used by the SPKR audio mux
    block that provides both Primary and Secondary MI2S.
    
    The SEC_I2S_CLK (better name: MIC_I2S_CLK) is used by the MIC audio mux
    block that provides Tertiary MI2S. Quaternary MI2S is also part of the
    MIC audio mux but has its own clock (AUX_I2S_CLK).
    
    This means that (quite confusingly) the SEC_I2S_CLK is not actually
    used for Secondary MI2S as the name would suggest. Secondary MI2S
    needs to have the same clock as Primary MI2S configured.
    
    Fix the clock list for the lpass node in the device tree and add
    a comment to clarify this confusing naming. With these changes,
    audio can be played correctly on Secondary MI2S.
    
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Fixes: 3761a3618f55 ("arm64: dts: qcom: add lpass node")
    Tested-by: Vincent Knecht <vincent.knecht@mailoo.org>
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210816181810.2242-1-stephan@gerhold.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8524d9f336ccb1eef6d93e6f1d24c9b3a6ca0246
Author: Yassine Oudjana <y.oudjana@protonmail.com>
Date:   Sat Sep 25 02:24:19 2021 +0000

    ASoC: wcd9335: Use correct version to initialize Class H
    
    [ Upstream commit a270bd9abdc3cd04ec194f1f3164823cbb5a905c ]
    
    The versioning scheme was changed in an earlier patch, which caused the version
    being used to initialize WCD9335 to be interpreted as if it was WCD937X, which
    changed code paths causing broken headphones output. Pass WCD9335 instead of
    WCD9335_VERSION_2_0 to wcd_clsh_ctrl_alloc to fix it.
    
    Fixes: 19c5d1f6a0c3 ("ASoC: codecs: wcd-clsh: add new version support")
    Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
    Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210925022339.786296-1-y.oudjana@protonmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0274b00234512fe62c12c9a83c3a1714aa762e1
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Wed Sep 22 08:41:40 2021 +0100

    pinctrl: renesas: rzg2l: Fix missing port register 21h
    
    [ Upstream commit fcfb63148c241adad54ed99fc318167176d7254b ]
    
    Remove the duplicate port register 22h and replace it with missing port
    register 21h.
    
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Link: https://lore.kernel.org/r/20210922074140.22178-1-biju.das.jz@bp.renesas.com
    Fixes: c4c4637eb57f2a25 ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 259a6fdd691f6c1b8de40eb3b1f49ea1ab6141c9
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Sat Sep 4 10:37:41 2021 +0800

    JFS: fix memleak in jfs_mount
    
    [ Upstream commit c48a14dca2cb57527dde6b960adbe69953935f10 ]
    
    In jfs_mount, when diMount(ipaimap2) fails, it goes to errout35. However,
    the following code does not free ipaimap2 allocated by diReadSpecial.
    
    Fix this by refactoring the error handling code of jfs_mount. To be
    specific, modify the lable name and free ipaimap2 when the above error
    ocurrs.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f776bb118318351f652f0aeadd283259c17292b9
Author: Jackie Liu <liuyun01@kylinos.cn>
Date:   Mon Sep 13 14:19:08 2021 +0800

    MIPS: loongson64: make CPU_LOONGSON64 depends on MIPS_FP_SUPPORT
    
    [ Upstream commit 7f3b3c2bfa9c93ab9b5595543496f570983dc330 ]
    
    mach/loongson64 fails to build when the FPU support is disabled:
    
    arch/mips/loongson64/cop2-ex.c:45:15: error: implicit declaration of function ‘__is_fpu_owner’; did you mean ‘is_fpu_owner’? [-Werror=implicit-function-declaration]
    arch/mips/loongson64/cop2-ex.c:98:30: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:99:30: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:131:43: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:137:38: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:203:30: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:219:30: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:283:38: error: ‘struct thread_struct’ has no member named ‘fpu’
    arch/mips/loongson64/cop2-ex.c:301:38: error: ‘struct thread_struct’ has no member named ‘fpu’
    
    Fixes: ef2f826c8f2f ("MIPS: Loongson-3: Enable the COP2 usage")
    Suggested-by: Huacai Chen <chenhuacai@kernel.org>
    Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
    Reported-by: k2ci robot <kernel-bot@kylinos.cn>
    Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85e7a66ceb2b4b7c0a55aa15b20d09f81db69585
Author: Tong Zhang <ztong0001@gmail.com>
Date:   Mon Sep 6 21:07:02 2021 -0700

    scsi: dc395: Fix error case unwinding
    
    [ Upstream commit cbd9a3347c757383f3d2b50cf7cfd03eb479c481 ]
    
    dc395x_init_one()->adapter_init() might fail. In this case, the acb is
    already cleaned up by adapter_init(), no need to do that in
    adapter_uninit(acb) again.
    
    [    1.252251] dc395x: adapter init failed
    [    1.254900] RIP: 0010:adapter_uninit+0x94/0x170 [dc395x]
    [    1.260307] Call Trace:
    [    1.260442]  dc395x_init_one.cold+0x72a/0x9bb [dc395x]
    
    Link: https://lore.kernel.org/r/20210907040702.1846409-1-ztong0001@gmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Finn Thain <fthain@linux-m68k.org>
    Signed-off-by: Tong Zhang <ztong0001@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52a994c15a9a7bcdb92336dc9a68a898e8d99907
Author: Kuogee Hsieh <khsieh@codeaurora.org>
Date:   Thu Sep 9 12:49:58 2021 -0700

    arm64: dts: qcom: sc7280: fix display port phy reg property
    
    [ Upstream commit 425f30cc843c727bc7753a0d33710d1e4a999168 ]
    
    Existing display port phy reg property is derived from usb phy which
    map display port phy pcs to wrong address which cause aux init
    with wrong address and prevent both dpcd read and write from working.
    Fix this problem by assigning correct pcs address to display port
    phy reg property.
    
    Fixes: bb9efa59c665 ("arm64: dts: qcom: sc7280: Add USB related nodes")
    Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/1631216998-10049-1-git-send-email-khsieh@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15a40b9fd396e116b8e926e4fb3a08aca1ccf6e6
Author: Naina Mehta <nainmeht@codeaurora.org>
Date:   Tue Sep 21 11:29:42 2021 +0530

    soc: qcom: llcc: Disable MMUHWT retention
    
    [ Upstream commit 3a461009e195c3c17f6af73da310b886991309fd ]
    
    Disable MMUHWT retention for SC7280 as done for other platforms
    to avoid more power burn.
    
    Fixes: f6a07be63301 ("soc: qcom: llcc: Add configuration data for SC7280")
    Signed-off-by: Naina Mehta <nainmeht@codeaurora.org>
    Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210921055942.30600-1-saiprakash.ranjan@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2a98348f6988e01ceb4db01625223ac5638775e
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Sep 2 14:51:37 2021 -0700

    arm64: dts: qcom: sc7180: Base dynamic CPU power coefficients in reality
    
    [ Upstream commit 82ea7d411d43f60dce878252558e926f957109f0 ]
    
    The sc7180's dynamic-power-coefficient violates the device tree bindings.
    The bindings (arm/cpus.yaml) say that the units for the
    dynamic-power-coefficient are supposed to be "uW/MHz/V^2". The ones for
    sc7180 aren't this. Qualcomm arbitrarily picked 100 for the "little" CPUs
    and then picked a number for the big CPU based on this.
    
    At the time, there was a giant dicussion about this. Apparently Qualcomm
    Engineers were instructed not to share the actual numbers here. As part
    of the discussion, I pointed out [1] that these numbers shouldn't really
    be secret since once a device is shipping anyone can just run a script
    and produce them. This patch is the result of running the script I posted
    in that discussion on sc7180-trogdor-coachz, which is currently available
    for purchase by consumers.
    
    [1] https://lore.kernel.org/r/CAD=FV=U1FP0e3_AVHpauUUZtD-5X3XCwh5aT9fH_8S_FFML2Uw@mail.gmail.com/
    
    I ran the script four times, measuring little, big, little, big. I used
    the 64-bit version of dhrystone 2.2 in my test. I got these results:
    
    576 kHz, 596 mV, 20 mW, 88 Cx
    768 kHz, 596 mV, 32 mW, 122 Cx
    1017 kHz, 660 mV, 45 mW, 97 Cx
    1248 kHz, 720 mV, 87 mW, 139 Cx
    1324 kHz, 756 mV, 109 mW, 148 Cx
    1516 kHz, 828 mV, 150 mW, 148 Cx
    1612 kHz, 884 mV, 182 mW, 147 Cx
    1708 kHz, 884 mV, 192 mW, 146 Cx
    1804 kHz, 884 mV, 207 mW, 149 Cx
    Your dynamic-power-coefficient for cpu 0: 132
    
    825 kHz, 596 mV, 142 mW, 401 Cx
    979 kHz, 628 mV, 183 mW, 427 Cx
    1113 kHz, 656 mV, 224 mW, 433 Cx
    1267 kHz, 688 mV, 282 mW, 449 Cx
    1555 kHz, 812 mV, 475 mW, 450 Cx
    1708 kHz, 828 mV, 566 mW, 478 Cx
    1843 kHz, 884 mV, 692 mW, 476 Cx
    1900 kHz, 884 mV, 722 mW, 482 Cx
    1996 kHz, 916 mV, 814 mW, 482 Cx
    2112 kHz, 916 mV, 862 mW, 483 Cx
    2208 kHz, 916 mV, 962 mW, 521 Cx
    2323 kHz, 940 mV, 1060 mW, 517 Cx
    2400 kHz, 956 mV, 1133 mW, 518 Cx
    Your dynamic-power-coefficient for cpu 6: 471
    
    576 kHz, 596 mV, 26 mW, 103 Cx
    768 kHz, 596 mV, 40 mW, 147 Cx
    1017 kHz, 660 mV, 54 mW, 114 Cx
    1248 kHz, 720 mV, 97 mW, 151 Cx
    1324 kHz, 756 mV, 113 mW, 150 Cx
    1516 kHz, 828 mV, 154 mW, 148 Cx
    1612 kHz, 884 mV, 194 mW, 155 Cx
    1708 kHz, 884 mV, 203 mW, 152 Cx
    1804 kHz, 884 mV, 219 mW, 155 Cx
    Your dynamic-power-coefficient for cpu 0: 142
    
    825 kHz, 596 mV, 148 mW, 530 Cx
    979 kHz, 628 mV, 189 mW, 475 Cx
    1113 kHz, 656 mV, 230 mW, 461 Cx
    1267 kHz, 688 mV, 287 mW, 466 Cx
    1555 kHz, 812 mV, 469 mW, 445 Cx
    1708 kHz, 828 mV, 567 mW, 480 Cx
    1843 kHz, 884 mV, 699 mW, 482 Cx
    1900 kHz, 884 mV, 719 mW, 480 Cx
    1996 kHz, 916 mV, 814 mW, 484 Cx
    2112 kHz, 916 mV, 861 mW, 483 Cx
    2208 kHz, 916 mV, 963 mW, 522 Cx
    2323 kHz, 940 mV, 1063 mW, 520 Cx
    2400 kHz, 956 mV, 1135 mW, 519 Cx
    Your dynamic-power-coefficient for cpu 6: 489
    
    As you can see, the calculations aren't perfectly consistent but
    roughly you could say about 480 for big and 137 for little.
    
    The ratio between these numbers isn't quite the same as the ratio
    between the two numbers that Qualcomm used. Perhaps this is because
    Qualcomm measured something slightly different than the 64-bit version
    of dhrystone 2.2 or perhaps it's because they fudged these numbers a
    bit (and fudged the capacity-dmips-mhz). As per discussion [2], let's
    use the numbers I came up with and also un-fudge
    capacity-dmips-mhz. While unfudging capacity-dmips-mhz, let's scale it
    so that bigs are 1024 which seems to be the common practice.
    
    In general these numbers don't need to be perfectly exact. In fact,
    they can't be since the CPU power depends a lot on what's being run on
    the CPU and the big/little CPUs are each more or less efficient in
    different operations. Historically running the 32-bit vs. 64-bit
    versions of dhrystone produced notably different numbers, though I
    didn't test this time.
    
    We also need to scale all of the sustainable-power numbers by the same
    amount. I scale ones related to the big CPUs by the adjustment I made
    to the big dynamic-power-coefficient and the ones related to the
    little CPUs by the adjustment I made to the little
    dynamic-power-coefficient.
    
    [2] https://lore.kernel.org/r/0a865b6e-be34-6371-f9f2-9913ee1c5608@codeaurora.org/
    
    Fixes: 71f873169a80 ("arm64: dts: qcom: sc7180: Add dynamic CPU power coefficients")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210902145127.v2.1.I049b30065f3c715234b6303f55d72c059c8625eb@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53616b7315ee5b00409b51b875d8d9458bcd8af7
Author: Peter Rosin <peda@axentia.se>
Date:   Mon Sep 20 22:37:38 2021 +0200

    ARM: dts: at91: tse850: the emac<->phy interface is rmii
    
    [ Upstream commit dcdbc335a91a26e022a803e1a6b837266989c032 ]
    
    This went unnoticed until commit 7897b071ac3b ("net: macb: convert
    to phylink") which tickled the problem. The sama5d3 emac has never
    been capable of rgmii, and it all just happened to work before that
    commit.
    
    Fixes: 21dd0ece34c2 ("ARM: dts: at91: add devicetree for the Axentia TSE-850")
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Link: https://lore.kernel.org/r/ea781f5e-422f-6cbf-3cf4-d5a7bac9392d@axentia.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b327d92c10b27255d68989aa77ed71c2e38fae61
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Sep 21 12:42:25 2021 +0300

    bus: ti-sysc: Fix timekeeping_suspended warning on resume
    
    [ Upstream commit b3e9431854e8f305385d5de225441c0477b936cb ]
    
    On resume we can get a warning at kernel/time/timekeeping.c:824 for
    timekeeping_suspended.
    
    Let's fix this by adding separate functions for sysc_poll_reset_sysstatus()
    and sysc_poll_reset_sysconfig() and have the new functions handle also
    timekeeping_suspended.
    
    If iopoll at some point supports timekeeping_suspended, we can just drop
    the custom handling from these functions.
    
    Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 876ba79c7969fa9c020e7ac84321ca407e7f80e6
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Sun Sep 19 20:29:11 2021 +0000

    arm64: dts: meson-sm1: Fix the pwm regulator supply properties
    
    [ Upstream commit 0b26fa8a02c2834f1fa8a206a285b9f84c4ad764 ]
    
    After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs.
    Changes help link VDDCPU pwm regulator to 12V regulator supply
    instead of dummy regulator.
    
    [   11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property
                   in node /regulator-vddcpu failed
    [   11.602344] VDDCPU: supplied by regulator-dummy
    [   11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT
    [   11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled
    
    Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi")
    Fixes: 700ab8d83927 ("arm64: dts: khadas-vim3: add support for the SM1 based VIM3L")
    Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS")
    Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts")
    
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210919202918.3556-4-linux.amoon@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b9828e4bdbcad43e18e601606ddc8ec93ac4cdc
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Sun Sep 19 20:29:10 2021 +0000

    arm64: dts: meson-g12b: Fix the pwm regulator supply properties
    
    [ Upstream commit 62183863f708c2464769e0d477c8ce9f3d326feb ]
    
    After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs.
    Changes help link VDDCP_A and VDDCPU_B pwm regulator to 12V regulator
    supply instead of dummy regulator.
    
    [    4.147196] VDDCPU_A: will resolve supply early: pwm
    [    4.147216] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply from device tree
    [    4.147227] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply property in node /regulator-vddcpu-a failed
    [    4.147258] VDDCPU_A: supplied by regulator-dummy
    [    4.147288] regulator-dummy: could not add device link regulator.12: -ENOENT
    [    4.147353] VDDCPU_A: 721 <--> 1022 mV at 871 mV, enabled
    [    4.152014] VDDCPU_B: will resolve supply early: pwm
    [    4.152035] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply from device tree
    [    4.152047] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply property in node /regulator-vddcpu-b failed
    [    4.152079] VDDCPU_B: supplied by regulator-dummy
    [    4.152108] regulator-dummy: could not add device link regulator.13: -ENOENT
    
    Fixes: c6d29c66e582 ("arm64: dts: meson-g12b-khadas-vim3: add initial device-tree")
    Fixes: d14734a04a8a ("arm64: dts: meson-g12b-odroid-n2: enable DVFS")
    Fixes: 3cb74db9b256 ("arm64: dts: meson: convert ugoos-am6 to common w400 dtsi")
    
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210919202918.3556-3-linux.amoon@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2bbd1ce92d21b3d9b9f5580686626e4dd73329e
Author: Anand Moon <linux.amoon@gmail.com>
Date:   Sun Sep 19 20:29:09 2021 +0000

    arm64: dts: meson-g12a: Fix the pwm regulator supply properties
    
    [ Upstream commit 085675117ecf5e02c4220698fd549024ec64ad2c ]
    
    After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs.
    Changes help link VDDCPU pwm regulator to 12V regulator supply
    instead of dummy regulator.
    
    [   11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property
                   in node /regulator-vddcpu failed
    [   11.602344] VDDCPU: supplied by regulator-dummy
    [   11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT
    [   11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled
    
    Fixes: e9bc0765cc12 ("arm64: dts: meson-g12a: enable DVFS on G12A boards")
    
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20210919202918.3556-2-linux.amoon@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4def729518ec83222326f9fa0b0c2b275d7c5467
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Sep 15 11:23:56 2021 +0530

    arm64: dts: ti: j7200-main: Fix "bus-range" upto 256 bus number for PCIe
    
    [ Upstream commit 8bb8429290c0043a78804ae48294b53f781ee426 ]
    
    commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device
    tree node") incorrectly added PCIe bus numbers from 0 to 15 (copy-paste
    from J721E node). Enable all the supported bus numbers from 0 to 255
    defined in PCIe spec here.
    
    Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node")
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20210915055358.19997-5-kishon@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b9ab4a7e52baeccd12d4eb184e94125afeec651
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Sep 15 11:23:55 2021 +0530

    arm64: dts: ti: j7200-main: Fix "vendor-id"/"device-id" properties of pcie node
    
    [ Upstream commit 0d553792726a61ced760422e74ea67552ac69cdb ]
    
    commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device
    tree node") incorrectly added "vendor-id" and "device-id" as 16-bit
    properties though both of them are 32-bit properties. Fix it here.
    
    Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node")
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20210915055358.19997-4-kishon@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef26fb3a1931e7bbf8e5b086fa3e913e0d18b453
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Sep 15 11:23:54 2021 +0530

    arm64: dts: ti: k3-j721e-main: Fix "bus-range" upto 256 bus number for PCIe
    
    [ Upstream commit 5f46633565b1c1e1840a927676065d72b442dac4 ]
    
    commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device
    tree nodes") restricted PCIe bus numbers from 0 to 15 (due to SMMU
    restriction in J721E). However since SMMU is not enabled, allow the full
    supported bus numbers from 0 to 255.
    
    Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes")
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20210915055358.19997-3-kishon@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 461a478eabea30ddd497c5c2ee9e720a0e45060f
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Wed Sep 15 11:23:53 2021 +0530

    arm64: dts: ti: k3-j721e-main: Fix "max-virtual-functions" in PCIe EP nodes
    
    [ Upstream commit 9af3ef954975c383eeb667aee207d9ce6fbef8c4 ]
    
    commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device
    tree nodes") added "max-virtual-functions" to have 16 bit values.
    Fix "max-virtual-functions" in PCIe endpoint (EP) nodes to have 8 bit
    values instead of 16.
    
    Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes")
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20210915055358.19997-2-kishon@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13fef1930da87a1de78304145c0895f6c58d5a4f
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Wed Sep 15 05:32:38 2021 -0700

    RDMA/bnxt_re: Fix query SRQ failure
    
    [ Upstream commit 598d16fa1bf93431ad35bbab3ed1affe4fb7b562 ]
    
    Fill the missing parameters for the FW command while querying SRQ.
    
    Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")
    Link: https://lore.kernel.org/r/1631709163-2287-8-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 280ad4f332f93c6d557796c68e3f162d0a85aea5
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Mon Aug 30 19:57:39 2021 +0200

    ARM: dts: qcom: msm8974: Add xo_board reference clock to DSI0 PHY
    
    [ Upstream commit 8ccecf6c710b8c048eecc65709640642e5357d6e ]
    
    According to YAML validation, and for a future patchset putting this
    xo_board reference clock to use as VCO reference parent, add the missing
    clock to dsi_phy0.
    
    Fixes: 5a9fc531f6ec ("ARM: dts: msm8974: add display support")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210830175739.143401-1-marijn.suijten@somainline.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6096069c91ed3a91bb8afdd2caccad0e66072145
Author: Alex Bee <knaerzche@gmail.com>
Date:   Wed Jun 23 13:59:26 2021 +0200

    arm64: dts: rockchip: Fix GPU register width for RK3328
    
    [ Upstream commit 932b4610f55b49f3a158b0db451137bab7ed0e1f ]
    
    As can be seen in RK3328's TRM the register range for the GPU is
    0xff300000 to 0xff330000.
    It would (and does in vendor kernel) overlap with the registers of
    the HEVC encoder (node/driver do not exist yet in upstream kernel).
    See already existing h265e_mmu node.
    
    Fixes: 752fbc0c8da7 ("arm64: dts: rockchip: add rk3328 mali gpu node")
    Signed-off-by: Alex Bee <knaerzche@gmail.com>
    Link: https://lore.kernel.org/r/20210623115926.164861-1-knaerzche@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df54f16f3c059e995a5b71f14312dccde5cc4fe2
Author: Jackie Liu <liuyun01@kylinos.cn>
Date:   Wed Sep 1 20:35:57 2021 +0800

    ARM: s3c: irq-s3c24xx: Fix return value check for s3c24xx_init_intc()
    
    [ Upstream commit 2aa717473ce96c93ae43a5dc8c23cedc8ce7dd9f ]
    
    The s3c24xx_init_intc() returns an error pointer upon failure, not NULL.
    let's add an error pointer check in s3c24xx_handle_irq.
    
    s3c_intc[0] is not NULL or ERR, we can simplify the code.
    
    Fixes: 1f629b7a3ced ("ARM: S3C24XX: transform irq handling into a declarative form")
    Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
    Link: https://lore.kernel.org/r/20210901123557.1043953-1-liu.yun@linux.dev
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca4e2606674821ef17bd4a234ec50c70c6fabebe
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Sep 10 16:31:52 2021 -0700

    scsi: lpfc: Fix NVMe I/O failover to non-optimized path
    
    [ Upstream commit b507357f79171fb4fb4e732ca43a1f30bc5aab1d ]
    
    Currently, we hold off unregistering with NVMe transport layer until GID_FT
    or ADISC completes upon receipt of RSCN. In the ADISC discovery routine,
    for nodes not found in the GID_FT response, the nodes are unregistered from
    the SCSI transport but not UNREG_RPI'd. Meaning outstanding WQEs continue
    to be outstanding and were not failed back to the OS. If an NVMe device,
    this mean there wasn't initial termination of the I/Os so they could be
    issued on a different NVMe path.
    
    Fix by unregistering the RPI so that I/O is cancelled.
    
    Link: https://lore.kernel.org/r/20210910233159.115896-8-jsmart2021@gmail.com
    Fixes: 0614568361b0 ("scsi: lpfc: Delay unregistering from transport until GIDFT or ADISC completes")
    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 79becd68e16ebd973f852f5fe7f3959cfb00efdd
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Sep 8 09:46:17 2021 -0700

    scsi: qla2xxx: edif: Use link event to wake up app
    
    [ Upstream commit 527d46e0b0147f2b32b78ba49c6a231835b24a41 ]
    
    Authentication application may be running and in the past tried to probe
    driver (app_start) but was unsuccessful. This could be due to the bsg layer
    not being ready to service the request. On a successful link up, driver
    will use the netlink Link Up event to notify the app to retry the app_start
    call.
    
    In another case, app does not poll for new NPIV host. This link up event
    would notify app of the presence of a new SCSI host.
    
    Link: https://lore.kernel.org/r/20210908164622.19240-6-njavali@marvell.com
    Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3e165e8e7793cac1ab77c84e64326dcf29b29b9
Author: Ajish Koshy <Ajish.Koshy@microchip.com>
Date:   Mon Sep 6 22:34:02 2021 +0530

    scsi: pm80xx: Fix lockup in outbound queue management
    
    [ Upstream commit b27a40534ef76a22628a5c12f98ea489823a8ba5 ]
    
    Commit 1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue
    processing") introduced a lock per outbound queue. Prior to that change the
    driver was using a global lock for all outbound queues.
    
    While processing the I/O responses and events the driver takes the outbound
    queue spinlock and is supposed to release it in pm8001_ccb_task_free_done()
    before calling command done(). Since the older code was using a global
    lock, pm8001_ccb_task_free_done() was releasing the global spin lock. The
    change that split the lock per outbound queue did not consider this and
    pm8001_ccb_task_free_done() was still releasing the global lock.
    
    Link: https://lore.kernel.org/r/20210906170404.5682-3-Ajish.Koshy@microchip.com
    Fixes: 1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue processing")
    Acked-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Ajish Koshy <Ajish.Koshy@microchip.com>
    Signed-off-by: Viswas G <Viswas.G@microchip.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8525028b4652cf1afc0b85d9f93390eea684c01b
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Apr 23 09:02:26 2021 +0200

    clk: mvebu: ap-cpu-clk: Fix a memory leak in error handling paths
    
    [ Upstream commit af9617b419f77cf0b99702a7b2b0519da0d27715 ]
    
    If we exit the for_each_of_cpu_node loop early, the reference on the
    current node must be decremented, otherwise there is a leak.
    
    Fixes: f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/545df946044fc1fc05a4217cdf0054be7a79e49e.1619161112.git.christophe.jaillet@wanadoo.fr
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 532c48310396fbe769c4facdb9163dc539522b05
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Aug 19 17:37:02 2021 +0200

    arm64: dts: broadcom: bcm4908: Fix UART clock name
    
    [ Upstream commit 6c38c39ab2141f53786d73e706675e8819a3f2cb ]
    
    According to the binding the correct clock name is "refclk".
    
    Fixes: 2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed1b1ab0581ef4b029d6d9c7de0cfe6cf34f986d
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Aug 19 08:57:02 2021 +0200

    ARM: dts: BCM5301X: Fix memory nodes names
    
    [ Upstream commit c5e1df3276d7a500678da9453be31a66ad115150 ]
    
    Thix fixes:
    arch/arm/boot/dts/bcm4708-netgear-r6250.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]}
    arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]}
    arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 402653184]]}
    arch/arm/boot/dts/bcm4709-linksys-ea9200.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]}
    arch/arm/boot/dts/bcm4709-netgear-r7000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]}
    arch/arm/boot/dts/bcm4709-netgear-r8000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]}
    arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]}
    arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 402653184]]}
    arch/arm/boot/dts/bcm53016-meraki-mr32.dt.yaml: /: memory: False schema does not allow {'reg': [[0, 134217728]], 'device_type': ['memory']}
    arch/arm/boot/dts/bcm94708.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]}
    arch/arm/boot/dts/bcm94709.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]}
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d41e6c4fae2991afde8696dfec6c719897db25a6
Author: Junji Wei <weijunji@bytedance.com>
Date:   Tue Aug 31 16:32:23 2021 +0800

    RDMA/rxe: Fix wrong port_cap_flags
    
    [ Upstream commit dcd3f985b20ffcc375f82ca0ca9f241c7025eb5e ]
    
    The port->attr.port_cap_flags should be set to enum
    ib_port_capability_mask_bits in ib_mad.h, not
    RDMA_CORE_CAP_PROT_ROCE_UDP_ENCAP.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20210831083223.65797-1-weijunji@bytedance.com
    Signed-off-by: Junji Wei <weijunji@bytedance.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42a6f69c5aa8fb87a6fcadf9feb86a825715f692
Author: Alexandru Ardelean <aardelean@deviqon.com>
Date:   Mon Aug 23 14:22:00 2021 +0300

    iio: st_sensors: disable regulators after device unregistration
    
    [ Upstream commit 9f0b3e0cc0c88618aa9e5cecef747b1337ae0a5d ]
    
    Up until commit ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal
    to core") only the ST pressure driver seems to have had any regulator
    disable. After that commit, the regulator handling was moved into the
    common st_sensors logic.
    
    In all instances of this regulator handling, the regulators were disabled
    before unregistering the IIO device.
    This can cause issues where the device would be powered down and still be
    available to userspace, allowing it to send invalid/garbage data.
    
    This change moves the st_sensors_power_disable() after the common probe
    functions. These common probe functions also handle unregistering the IIO
    device.
    
    Fixes: 774487611c949 ("iio: pressure-core: st: Provide support for the Vdd power supply")
    Fixes: ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core")
    Cc: Lee Jones <lee.jones@linaro.org>
    Cc: Denis CIOCCA <denis.ciocca@st.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
    Link: https://lore.kernel.org/r/20210823112204.243255-2-aardelean@deviqon.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5e4939b5e0cbda6058be8bbe8225fb09675eaa9
Author: Dongjin Kim <tobetter@gmail.com>
Date:   Thu Aug 26 12:28:32 2021 +0900

    arm64: dts: meson: sm1: add Ethernet PHY reset line for ODROID-C4/HC4
    
    [ Upstream commit 9d02214f8332d5dbbcce3d6c5c915e54d43a0c46 ]
    
    This patch is to fix an issue that the ethernet link doesn't come up
    when using ip link set down/up:
       [   11.428114] meson8b-dwmac ff3f0000.ethernet eth0: Link is Down
       [   14.428595] meson8b-dwmac ff3f0000.ethernet eth0: PHY [0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=31)
       [   14.428610] meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma
       [   14.428974] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
       [   14.711185] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_open: Hw setup failed
    
    This fix refers to two commits applied for ODROID-N2 (G12B).
        commit 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY reset line")
        commit 1c7412530d5d0 ("arm64: dts: meson: g12b: odroid-n2: fix PHY deassert timing requirements")
    
    Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi")
    Signed-off-by: Dongjin Kim <tobetter@gmail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    [narmstrong: added fixes tag and typo in commit log]
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/YScKYFWlYymgGw3l@anyang-linuxfactory-or-kr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03060aec7281d5dd5e1460e322771c5b011d4117
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Sep 3 21:17:52 2021 +0300

    staging: r8188eu: fix memory leak in rtw_set_key
    
    [ Upstream commit 393db0f6827f96054a769ba3a38aa382d137d3c7 ]
    
    Before returning with an error we should free allocated buffers, since
    they are not assigned to anywhere.
    
    Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/ee783fbb71abb549505b84542223be7a7c905eea.1630692375.git.paskripkin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8853e04ea61d4296b09347f361e3b3fd8f859b7f
Author: Hector.Yuan <hector.yuan@mediatek.com>
Date:   Mon Oct 4 22:42:33 2021 +0800

    cpufreq: Fix parameter in parse_perf_domain()
    
    [ Upstream commit 4a08e3271c55f8b5d56906a8aa5bd041911cf897 ]
    
    Pass cpu to parse_perf_domain() instead of pcpu.
    
    Fixes: 8486a32dd484 ("cpufreq: Add of_perf_domain_get_sharing_cpumask")
    Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com>
    [ Viresh: Massaged changelog ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bbc554a98f9b8d605b99d2517526b731db7d3f2
Author: Frank Rowand <frank.rowand@sony.com>
Date:   Thu Oct 28 20:32:25 2021 -0500

    of: unittest: fix EXPECT text for gpio hog errors
    
    [ Upstream commit e85860e5bc077865a04f0a88d0b0335d3200484a ]
    
    The console message text for gpio hog errors does not match
    what unittest expects.
    
    Fixes: f4056e705b2ef ("of: unittest: add overlay gpio test to catch gpio hog problem")
    Signed-off-by: Frank Rowand <frank.rowand@sony.com>
    Link: https://lore.kernel.org/r/20211029013225.2048695-1-frowand.list@gmail.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d55aca82dda6cc145c0efaee577c5a00804a4802
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Mon Nov 1 15:21:52 2021 -0700

    bpf: Fix propagation of signed bounds from 64-bit min/max into 32-bit.
    
    [ Upstream commit 388e2c0b978339dee9b0a81a2e546f8979e021e2 ]
    
    Similar to unsigned bounds propagation fix signed bounds.
    The 'Fixes' tag is a hint. There is no security bug here.
    The verifier was too conservative.
    
    Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking")
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20211101222153.78759-2-alexei.starovoitov@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d03a5b00a33613a0ddab0f9c2ff2f48b83b8b40d
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Mon Nov 1 15:21:51 2021 -0700

    bpf: Fix propagation of bounds from 64-bit min/max into 32-bit and var_off.
    
    [ Upstream commit b9979db8340154526d9ab38a1883d6f6ba9b6d47 ]
    
    Before this fix:
    166: (b5) if r2 <= 0x1 goto pc+22
    from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0xffffffff))
    
    After this fix:
    166: (b5) if r2 <= 0x1 goto pc+22
    from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0x1))
    
    While processing BPF_JLE the reg_set_min_max() would set true_reg->umax_value = 1
    and call __reg_combine_64_into_32(true_reg).
    
    Without the fix it would not pass the condition:
    if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value))
    
    since umin_value == 0 at this point.
    Before commit 10bf4e83167c the umin was incorrectly ingored.
    The commit 10bf4e83167c fixed the correctness issue, but pessimized
    propagation of 64-bit min max into 32-bit min max and corresponding var_off.
    
    Fixes: 10bf4e83167c ("bpf: Fix propagation of 32 bit unsigned bounds from 64 bit bounds")
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20211101222153.78759-1-alexei.starovoitov@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3acd3a08462e899bf564bf614f2cb4bb59e6d5a
Author: Dan Schatzberg <schatzberg.dan@gmail.com>
Date:   Thu Oct 28 15:15:27 2021 -0700

    cgroup: Fix rootcg cpu.stat guest double counting
    
    [ Upstream commit 81c49d39aea8a10e6d05d3aa1cb65ceb721e19b0 ]
    
    In account_guest_time in kernel/sched/cputime.c guest time is
    attributed to both CPUTIME_NICE and CPUTIME_USER in addition to
    CPUTIME_GUEST_NICE and CPUTIME_GUEST respectively. Therefore, adding
    both to calculate usage results in double counting any guest time at
    the rootcg.
    
    Fixes: 936f2a70f207 ("cgroup: add cpu.stat file to root cgroup")
    Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c47be68b31cf317f2b6d80839ac57ef6db325816
Author: Liu Jian <liujian56@huawei.com>
Date:   Fri Oct 29 22:12:14 2021 +0800

    skmsg: Lose offset info in sk_psock_skb_ingress
    
    [ Upstream commit 7303524e04af49a47991e19f895c3b8cdc3796c7 ]
    
    If sockmap enable strparser, there are lose offset info in
    sk_psock_skb_ingress(). If the length determined by parse_msg function is not
    skb->len, the skb will be converted to sk_msg multiple times, and userspace
    app will get the data multiple times.
    
    Fix this by get the offset and length from strp_msg. And as Cong suggested,
    add one bit in skb->_sk_redir to distinguish enable or disable strparser.
    
    Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20211029141216.211899-1-liujian56@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5c69b9fb5c4b7982dd31bf0adee353256e1bf3a
Author: Geliang Tang <geliang.tang@suse.com>
Date:   Fri Oct 29 16:55:58 2021 -0700

    selftests: mptcp: fix proto type in link_failure tests
    
    [ Upstream commit 7c909a98042ce403c8497c5d6ff94dd53bdd2131 ]
    
    In listener_ns, we should pass srv_proto argument to mptcp_connect command,
    not cl_proto.
    
    Fixes: 7d1e6f1639044 ("selftests: mptcp: add testcase for active-back")
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c6197e7eac71468730c274ebc653adf1fed2ee0
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Fri Oct 29 15:03:16 2021 -0700

    ibmvnic: delay complete()
    
    [ Upstream commit 6b278c0cb378079f3c0c61ae4a369c09ff1a4188 ]
    
    If we get CRQ_INIT, we set errno to -EIO and first call complete() to
    notify the waiter. Then we try to schedule a FAILOVER reset. If this
    occurs while adapter is in PROBING state, ibmvnic_reset() changes the
    error code to EAGAIN and returns without scheduling the FAILOVER. The
    purpose of setting error code to EAGAIN is to ask the waiter to retry.
    
    But due to the earlier complete() call, the waiter may already have seen
    the -EIO response and decided not to retry. This can cause intermittent
    failures when bringing up ibmvnic adapters during boot, specially in
    in kexec/kdump kernels.
    
    Defer the complete() call until after scheduling the reset.
    
    Also streamline the error code to EAGAIN. Don't see why we need EIO
    sometimes. All 3 callers of ibmvnic_reset_init() can handle EAGAIN.
    
    Fixes: 17c8705838a5 ("ibmvnic: Return error code if init interrupted by transport event")
    Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Reviewed-by: Dany Madden <drt@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a208e02e9ee723649701589b1823dcbe955bd35
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Fri Oct 29 15:03:15 2021 -0700

    ibmvnic: Process crqs after enabling interrupts
    
    [ Upstream commit 6e20d00158f31f7631d68b86996b7e951c4451c8 ]
    
    Soon after registering a CRQ it is possible that we get a fail over or
    maybe a CRQ_INIT from the VIOS while interrupts were disabled.
    
    Look for any such CRQs after enabling interrupts.
    
    Otherwise we can intermittently fail to bring up ibmvnic adapters during
    boot, specially in kexec/kdump kernels.
    
    Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
    Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Reviewed-by: Dany Madden <drt@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fac0105a5c9f0a2e93f071b7373900e53afae9f8
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Fri Oct 29 15:03:14 2021 -0700

    ibmvnic: don't stop queue in xmit
    
    [ Upstream commit 8878e46fcfd46b19964bd90e13b25dd94cbfc9be ]
    
    If adapter's resetting bit is on, discard the packet but don't stop the
    transmit queue - instead leave that to the reset code. With this change,
    it is possible that we may get several calls to ibmvnic_xmit() that simply
    discard packets and return.
    
    But if we stop the queue here, we might end up doing so just after
    __ibmvnic_open() started the queues (during a hard/soft reset) and before
    the ->resetting bit was cleared. If that happens, there will be no one to
    restart queue and transmissions will be blocked indefinitely.
    
    This can cause a TIMEOUT reset and with auto priority failover enabled,
    an unnecessary FAILOVER reset to less favored backing device and then a
    FAILOVER back to the most favored backing device. If we hit the window
    repeatedly, we can get stuck in a loop of TIMEOUT, FAILOVER, FAILOVER
    resets leaving the adapter unusable for extended periods of time.
    
    Fixes: 7f5b030830fe ("ibmvnic: Free skb's in cases of failure in transmit")
    Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
    Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Reviewed-by: Dany Madden <drt@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e619ad4e2d4c3ee57dbc8fb7edbfa7a9ac83dfce
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Oct 29 08:51:34 2021 -0700

    udp6: allow SO_MARK ctrl msg to affect routing
    
    [ Upstream commit 42dcfd850e514b229d616a53dec06d0f2533217c ]
    
    Commit c6af0c227a22 ("ip: support SO_MARK cmsg")
    added propagation of SO_MARK from cmsg to skb->mark.
    For IPv4 and raw sockets the mark also affects route
    lookup, but in case of IPv6 the flow info is
    initialized before cmsg is parsed.
    
    Fixes: c6af0c227a22 ("ip: support SO_MARK cmsg")
    Reported-and-tested-by: Xintong Hu <huxintong@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e89d244fef559bb7d879b0a1a3b7aec20ac08f8f
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Tue Oct 26 16:34:09 2021 +0200

    selftests/bpf: Fix fclose/pclose mismatch in test_progs
    
    [ Upstream commit f48ad69097fe79d1de13c4d8fef556d4c11c5e68 ]
    
    Make sure to use pclose() to properly close the pipe opened by popen().
    
    Fixes: 81f77fd0deeb ("bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID")
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/bpf/20211026143409.42666-1-andrea.righi@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb657a4e125d282a4fd8bbae10876b58c932121c
Author: Daniel Jordan <daniel.m.jordan@oracle.com>
Date:   Thu Oct 21 14:30:28 2021 -0400

    crypto: pcrypt - Delay write to padata->info
    
    [ Upstream commit 68b6dea802cea0dbdd8bd7ccc60716b5a32a5d8a ]
    
    These three events can race when pcrypt is used multiple times in a
    template ("pcrypt(pcrypt(...))"):
    
      1.  [taskA] The caller makes the crypto request via crypto_aead_encrypt()
      2.  [kworkerB] padata serializes the inner pcrypt request
      3.  [kworkerC] padata serializes the outer pcrypt request
    
    3 might finish before the call to crypto_aead_encrypt() returns in 1,
    resulting in two possible issues.
    
    First, a use-after-free of the crypto request's memory when, for
    example, taskA writes to the outer pcrypt request's padata->info in
    pcrypt_aead_enc() after kworkerC completes the request.
    
    Second, the outer pcrypt request overwrites the inner pcrypt request's
    return code with -EINPROGRESS, making a successful request appear to
    fail.  For instance, kworkerB writes the outer pcrypt request's
    padata->info in pcrypt_aead_done() and then taskA overwrites it
    in pcrypt_aead_enc().
    
    Avoid both situations by delaying the write of padata->info until after
    the inner crypto request's return code is checked.  This prevents the
    use-after-free by not touching the crypto request's memory after the
    next-inner crypto request is made, and stops padata->info from being
    overwritten.
    
    Fixes: 5068c7a883d16 ("crypto: pcrypt - Add pcrypt crypto parallelization wrapper")
    Reported-by: syzbot+b187b77c8474f9648fae@syzkaller.appspotmail.com
    Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbf7b2dbd131f6dc025cfd84fedae73bead8e50a
Author: Nikolay Aleksandrov <nikolay@nvidia.com>
Date:   Fri Oct 29 15:05:27 2021 +0300

    selftests: net: bridge: update IGMP/MLD membership interval value
    
    [ Upstream commit 34d7ecb3d4f772eb00ce1f7195ae30886ddf4d2e ]
    
    When I fixed IGMPv3/MLDv2 to use the bridge's multicast_membership_interval
    value which is chosen by user-space instead of calculating it based on
    multicast_query_interval and multicast_query_response_interval I forgot
    to update the selftests relying on that behaviour. Now we have to
    manually set the expected GMI value to perform the tests correctly and get
    proper results (similar to IGMPv2 behaviour).
    
    Fixes: fac3cb82a54a ("net: bridge: mcast: use multicast_membership_interval for IGMPv3")
    Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24c8fd323957d80521caefa2b2f5a67531cf2ec1
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Thu Oct 28 17:58:35 2021 +0200

    net: bridge: fix uninitialized variables when BRIDGE_CFM is disabled
    
    [ Upstream commit 829e050eea69c7442441b714b6f5b339b5b8c367 ]
    
    Function br_get_link_af_size_filtered() calls br_cfm_{,peer}_mep_count()
    that return a count. When BRIDGE_CFM is not enabled these functions
    simply return -EOPNOTSUPP but do not modify count parameter and
    calling function then works with uninitialized variables.
    Modify these inline functions to return zero in count parameter.
    
    Fixes: b6d0425b816e ("bridge: cfm: Netlink Notifications.")
    Cc: Henrik Bjoernlund <henrik.bjoernlund@microchip.com>
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e176585f054a92ccc604831fe134698f12bc6547
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Thu Oct 28 15:55:34 2021 +0100

    net: phylink: avoid mvneta warning when setting pause parameters
    
    [ Upstream commit fd8d9731bcdfb22d28e45bce789bcb211c868c78 ]
    
    mvneta does not support asymetric pause modes, and it flags this by the
    lack of AsymPause in the supported field. When setting pause modes, we
    check that pause->rx_pause == pause->tx_pause, but only when pause
    autoneg is enabled. When pause autoneg is disabled, we still allow
    pause->rx_pause != pause->tx_pause, which is incorrect when the MAC
    does not support asymetric pause, and causes mvneta to issue a warning.
    
    Fix this by removing the test for pause->autoneg, so we always check
    that pause->rx_pause == pause->tx_pause for network devices that do not
    support AsymPause.
    
    Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9073b88b1b29bcff1a805699756ba810c0668b81
Author: Yinjun Zhang <yinjun.zhang@corigine.com>
Date:   Fri Oct 29 13:29:03 2021 +0200

    nfp: fix potential deadlock when canceling dim work
    
    [ Upstream commit 17e712c6a1bade9dac02a7bf2b464746faa7e9a0 ]
    
    When port is linked down, the process which has acquired rtnl_lock
    will wait for the in-progress dim work to finish, and the work also
    acquires rtnl_lock, which may cause deadlock.
    
    Currently IRQ_MOD registers can be configured by `ethtool -C` and
    dim work, and which will take effect depends on the execution order,
    rtnl_lock is useless here, so remove them.
    
    Fixes: 9d32e4e7e9e1 ("nfp: add support for coalesce adaptive feature")
    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>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9f7832a4f141376559402fc4114a236a4cad416
Author: Yinjun Zhang <yinjun.zhang@corigine.com>
Date:   Fri Oct 29 13:29:02 2021 +0200

    nfp: fix NULL pointer access when scheduling dim work
    
    [ Upstream commit f8d384a640dd32aaf0a05fec137ccbf0e986b09f ]
    
    Each rx/tx ring has a related dim work, when rx/tx ring number is
    decreased by `ethtool -L`, the corresponding rx_ring or tx_ring is
    assigned NULL, while its related work is not destroyed. When scheduled,
    the work will access NULL pointer.
    
    Fixes: 9d32e4e7e9e1 ("nfp: add support for coalesce adaptive feature")
    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>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6c25579a8a04862f9e4f0e55a458ea0815f3cc8
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Sep 7 23:06:32 2021 +0200

    ipmi: kcs_bmc: Fix a memory leak in the error handling path of 'kcs_bmc_serio_add_device()'
    
    [ Upstream commit f281d010b87454e72475b668ad66e34961f744e0 ]
    
    In the unlikely event where 'devm_kzalloc()' fails and 'kzalloc()'
    succeeds, 'port' would be leaking.
    
    Test each allocation separately to avoid the leak.
    
    Fixes: 3a3d2f6a4c64 ("ipmi: kcs_bmc: Add serio adaptor")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Message-Id: <ecbfa15e94e64f4b878ecab1541ea46c74807670.1631048724.git.christophe.jaillet@wanadoo.fr>
    Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8dabc670c402ed900c8ca502790321529839b73
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date:   Wed Oct 27 15:27:27 2021 +0530

    net: amd-xgbe: Toggle PLL settings during rate change
    
    [ Upstream commit daf182d360e509a494db18666799f4e85d83dda0 ]
    
    For each rate change command submission, the FW has to do a phy
    power off sequence internally. For this to happen correctly, the
    PLL re-initialization control setting has to be turned off before
    sending mailbox commands and re-enabled once the command submission
    is complete.
    
    Without the PLL control setting, the link up takes longer time in a
    fixed phy configuration.
    
    Fixes: 47f164deab22 ("amd-xgbe: Add PCI device support")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1fafee96a7a622b2d1e824bac4cd15a9e1288e9
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Oct 28 05:36:04 2021 -0400

    sctp: return true only for pathmtu update in sctp_transport_pl_toobig
    
    [ Upstream commit 75cf662c64dd8543f56c329c69eba18141c8fd9f ]
    
    sctp_transport_pl_toobig() supposes to return true only if there's
    pathmtu update, so that in sctp_icmp_frag_needed() it would call
    sctp_assoc_sync_pmtu() and sctp_retransmit(). This patch is to fix
    these return places in sctp_transport_pl_toobig().
    
    Fixes: 836964083177 ("sctp: do state transition when receiving an icmp TOOBIG packet")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 554153b1cd01203fc462f814749b37fe081121a8
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Oct 28 05:36:03 2021 -0400

    sctp: subtract sctphdr len in sctp_transport_pl_hlen
    
    [ Upstream commit cc4665ca646c96181a7c00198aa72c59e0c576e8 ]
    
    sctp_transport_pl_hlen() is called to calculate the outer header length
    for PL. However, as the Figure in rfc8899#section-4.4:
    
       Any additional
         headers         .--- MPS -----.
                |        |             |
                v        v             v
         +------------------------------+
         | IP | ** | PL | protocol data |
         +------------------------------+
    
                    <----- PLPMTU ----->
         <---------- PMTU -------------->
    
    Outer header are IP + Any additional headers, which doesn't include
    Packetization Layer itself header, namely sctphdr, whereas sctphdr
    is counted by __sctp_mtu_payload().
    
    The incorrect calculation caused the link pathmtu to be set larger
    than expected by t->pl.pmtu + sctp_transport_pl_hlen(). This patch
    is to fix it by subtracting sctphdr len in sctp_transport_pl_hlen().
    
    Fixes: d9e2e410ae30 ("sctp: add the constants/variables and states and some APIs for transport")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 118eedc0064456f9560af73d77852d802f8c4c3d
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Oct 28 05:36:02 2021 -0400

    sctp: reset probe_timer in sctp_transport_pl_update
    
    [ Upstream commit c6ea04ea692fa0d8e7faeb133fcd28e3acf470a0 ]
    
    sctp_transport_pl_update() is called when transport update its dst and
    pathmtu, instead of stopping the PLPMTUD probe timer, PLPMTUD should
    start over and reset the probe timer. Otherwise, the PLPMTUD service
    would stop.
    
    Fixes: 92548ec2f1f9 ("sctp: add the probe timer in transport for PLPMTUD")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cebfaefcccf466dc276a97e97ce1f00e0e5d7c1
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Oct 28 05:36:01 2021 -0400

    sctp: allow IP fragmentation when PLPMTUD enters Error state
    
    [ Upstream commit 40171248bb8934537fec8fbaf718e57c8add187c ]
    
    Currently when PLPMTUD enters Error state, transport pathmtu will be set
    to MIN_PLPMTU(512) while probe is continuing with BASE_PLPMTU(1200). It
    will cause pathmtu to stay in a very small value, even if the real pmtu
    is some value like 1000.
    
    RFC8899 doesn't clearly say how to set the value in Error state. But one
    possibility could be keep using BASE_PLPMTU for the real pmtu, but allow
    to do IP fragmentation when it's in Error state.
    
    As it says in rfc8899#section-5.4:
    
       Some paths could be unable to sustain packets of the BASE_PLPMTU
       size.  The Error State could be implemented to provide robustness to
       such paths.  This allows fallback to a smaller than desired PLPMTU
       rather than suffer connectivity failure.  This could utilize methods
       such as endpoint IP fragmentation to enable the PL sender to
       communicate using packets smaller than the BASE_PLPMTU.
    
    This patch is to set pmtu to BASE_PLPMTU instead of MIN_PLPMTU for Error
    state in sctp_transport_pl_send/toobig(), and set packet ipfragok for
    non-probe packets when it's in Error state.
    
    Fixes: 1dc68c194571 ("sctp: do state transition when PROBE_COUNT == MAX_PROBES on HB send path")
    Reported-by: Ying Xu <yinxu@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c51fa32f6310ed4eceac753eed20d2e7d7962d4
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Thu Oct 28 12:05:01 2021 +0530

    selftests/bpf: Fix memory leak in test_ima
    
    [ Upstream commit efadf2ad17a2d5dc90bda4e6e8b2f96af4c62dae ]
    
    The allocated ring buffer is never freed, do so in the cleanup path.
    
    Fixes: f446b570ac7e ("bpf/selftests: Update the IMA test to use BPF ring buffer")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20211028063501.2239335-9-memxor@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 844134cd097c6f3ba0e4d05a2cecfd047022d431
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Thu Oct 28 12:05:00 2021 +0530

    selftests/bpf: Fix fd cleanup in sk_lookup test
    
    [ Upstream commit c3fc706e94f5653def2783ffcd809a38676b7551 ]
    
    Similar to the fix in commit:
    e31eec77e4ab ("bpf: selftests: Fix fd cleanup in get_branch_snapshot")
    
    We use designated initializer to set fds to -1 without breaking on
    future changes to MAX_SERVER constant denoting the array size.
    
    The particular close(0) occurs on non-reuseport tests, so it can be seen
    with -n 115/{2,3} but not 115/4. This can cause problems with future
    tests if they depend on BTF fd never being acquired as fd 0, breaking
    internal libbpf assumptions.
    
    Fixes: 0ab5539f8584 ("selftests/bpf: Tests for BPF_SK_LOOKUP attach point")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20211028063501.2239335-8-memxor@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3e3c222c306b59334c704e4098256a8aaf3e9d6
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Oct 27 13:26:19 2021 -0400

    drm/amdgpu/gmc6: fix DMA mask from 44 to 40 bits
    
    [ Upstream commit 403475be6d8b122c3e6b8a47e075926d7299e5ef ]
    
    The DMA mask on SI parts is 40 bits not 44.  Copy
    paste typo.
    
    Fixes: 244511f386ccb9 ("drm/amdgpu: simplify and cleanup setting the dma mask")
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1762
    Acked-by: Christian König <christian.koenig@amd.com>
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76eb974438109209b02758d7a3ac726c9c653439
Author: Lang Yu <lang.yu@amd.com>
Date:   Thu Oct 21 14:36:36 2021 +0800

    drm/amdgpu: fix a potential memory leak in amdgpu_device_fini_sw()
    
    [ Upstream commit a5c5d8d50ecf5874be90a76e1557279ff8a30c9e ]
    
    amdgpu_fence_driver_sw_fini() should be executed before
    amdgpu_device_ip_fini(), otherwise fence driver resource
    won't be properly freed as adev->rings have been tore down.
    
    Fixes: 72c8c97b1522 ("drm/amdgpu: Split amdgpu_device_fini into early and late")
    
    Signed-off-by: Lang Yu <lang.yu@amd.com>
    Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d834f80e51d7723c993336330ed106d602f1d22d
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Mon Oct 25 17:22:08 2021 +0200

    wcn36xx: Channel list update before hardware scan
    
    [ Upstream commit d707f812bb0513ea0030d0c9fe2a456bae5a4583 ]
    
    The channel scan list must be updated before triggering a hardware scan
    so that firmware takes into account the regulatory info for each single
    channel such as active/passive config, power, DFS, etc... Without this
    the firmware uses its own internal default channel configuration, which
    is not aligned with mac80211 regulatory rules, and misses several
    channels (e.g. 144).
    
    Fixes: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1635175328-25642-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 677c9ad9839ced509be7a91cbff4cb7027a9f8de
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 26 14:41:32 2021 -0700

    bpf: Fixes possible race in update_prog_stats() for 32bit arches
    
    [ Upstream commit d979617aa84d96acca44c2f5778892b4565e322f ]
    
    It seems update_prog_stats() suffers from same issue fixed
    in the prior patch:
    
    As it can run while interrupts are enabled, it could
    be re-entered and the u64_stats syncp could be mangled.
    
    Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211026214133.3114279-3-eric.dumazet@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae1fffdf3b95d7ef2dbcc5aeab80db2a2ce06cb5
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 26 14:41:31 2021 -0700

    bpf: Avoid races in __bpf_prog_run() for 32bit arches
    
    [ Upstream commit f941eadd8d6d4ee2f8c9aeab8e1da5e647533a7d ]
    
    __bpf_prog_run() can run from non IRQ contexts, meaning
    it could be re entered if interrupted.
    
    This calls for the irq safe variant of u64_stats_update_{begin|end},
    or risk a deadlock.
    
    This patch is a nop on 64bit arches, fortunately.
    
    syzbot report:
    
    WARNING: inconsistent lock state
    5.12.0-rc3-syzkaller #0 Not tainted
    --------------------------------
    inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
    udevd/4013 [HC0[0]:SC0[0]:HE1:SE1] takes:
    ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: sk_filter include/linux/filter.h:867 [inline]
    ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: do_one_broadcast net/netlink/af_netlink.c:1468 [inline]
    ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: netlink_broadcast_filtered+0x27c/0x4fc net/netlink/af_netlink.c:1520
    {IN-SOFTIRQ-W} state was registered at:
      lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510
      lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483
      do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline]
      do_write_seqcount_begin include/linux/seqlock.h:545 [inline]
      u64_stats_update_begin include/linux/u64_stats_sync.h:129 [inline]
      bpf_prog_run_pin_on_cpu include/linux/filter.h:624 [inline]
      bpf_prog_run_clear_cb+0x1bc/0x270 include/linux/filter.h:755
      run_filter+0xa0/0x17c net/packet/af_packet.c:2031
      packet_rcv+0xc0/0x3e0 net/packet/af_packet.c:2104
      dev_queue_xmit_nit+0x2bc/0x39c net/core/dev.c:2387
      xmit_one net/core/dev.c:3588 [inline]
      dev_hard_start_xmit+0x94/0x518 net/core/dev.c:3609
      sch_direct_xmit+0x11c/0x1f0 net/sched/sch_generic.c:313
      qdisc_restart net/sched/sch_generic.c:376 [inline]
      __qdisc_run+0x194/0x7f8 net/sched/sch_generic.c:384
      qdisc_run include/net/pkt_sched.h:136 [inline]
      qdisc_run include/net/pkt_sched.h:128 [inline]
      __dev_xmit_skb net/core/dev.c:3795 [inline]
      __dev_queue_xmit+0x65c/0xf84 net/core/dev.c:4150
      dev_queue_xmit+0x14/0x18 net/core/dev.c:4215
      neigh_resolve_output net/core/neighbour.c:1491 [inline]
      neigh_resolve_output+0x170/0x228 net/core/neighbour.c:1471
      neigh_output include/net/neighbour.h:510 [inline]
      ip6_finish_output2+0x2e4/0x9fc net/ipv6/ip6_output.c:117
      __ip6_finish_output net/ipv6/ip6_output.c:182 [inline]
      __ip6_finish_output+0x164/0x3f8 net/ipv6/ip6_output.c:161
      ip6_finish_output+0x2c/0xb0 net/ipv6/ip6_output.c:192
      NF_HOOK_COND include/linux/netfilter.h:290 [inline]
      ip6_output+0x74/0x294 net/ipv6/ip6_output.c:215
      dst_output include/net/dst.h:448 [inline]
      NF_HOOK include/linux/netfilter.h:301 [inline]
      NF_HOOK include/linux/netfilter.h:295 [inline]
      mld_sendpack+0x2a8/0x7e4 net/ipv6/mcast.c:1679
      mld_send_cr net/ipv6/mcast.c:1975 [inline]
      mld_ifc_timer_expire+0x1e8/0x494 net/ipv6/mcast.c:2474
      call_timer_fn+0xd0/0x570 kernel/time/timer.c:1431
      expire_timers kernel/time/timer.c:1476 [inline]
      __run_timers kernel/time/timer.c:1745 [inline]
      run_timer_softirq+0x2e4/0x384 kernel/time/timer.c:1758
      __do_softirq+0x204/0x7ac kernel/softirq.c:345
      do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline]
      invoke_softirq kernel/softirq.c:228 [inline]
      __irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
      irq_exit+0x10/0x3c kernel/softirq.c:446
      __handle_domain_irq+0xb4/0x120 kernel/irq/irqdesc.c:692
      handle_domain_irq include/linux/irqdesc.h:176 [inline]
      gic_handle_irq+0x84/0xac drivers/irqchip/irq-gic.c:370
      __irq_svc+0x5c/0x94 arch/arm/kernel/entry-armv.S:205
      debug_smp_processor_id+0x0/0x24 lib/smp_processor_id.c:53
      rcu_read_lock_held_common kernel/rcu/update.c:108 [inline]
      rcu_read_lock_sched_held+0x24/0x7c kernel/rcu/update.c:123
      trace_lock_acquire+0x24c/0x278 include/trace/events/lock.h:13
      lock_acquire+0x3c/0x74 kernel/locking/lockdep.c:5481
      rcu_lock_acquire include/linux/rcupdate.h:267 [inline]
      rcu_read_lock include/linux/rcupdate.h:656 [inline]
      avc_has_perm_noaudit+0x6c/0x260 security/selinux/avc.c:1150
      selinux_inode_permission+0x140/0x220 security/selinux/hooks.c:3141
      security_inode_permission+0x44/0x60 security/security.c:1268
      inode_permission.part.0+0x5c/0x13c fs/namei.c:521
      inode_permission fs/namei.c:494 [inline]
      may_lookup fs/namei.c:1652 [inline]
      link_path_walk.part.0+0xd4/0x38c fs/namei.c:2208
      link_path_walk fs/namei.c:2189 [inline]
      path_lookupat+0x3c/0x1b8 fs/namei.c:2419
      filename_lookup+0xa8/0x1a4 fs/namei.c:2453
      user_path_at_empty+0x74/0x90 fs/namei.c:2733
      do_readlinkat+0x5c/0x12c fs/stat.c:417
      __do_sys_readlink fs/stat.c:450 [inline]
      sys_readlink+0x24/0x28 fs/stat.c:447
      ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64
      0x7eaa4974
    irq event stamp: 298277
    hardirqs last  enabled at (298277): [<802000d0>] no_work_pending+0x4/0x34
    hardirqs last disabled at (298276): [<8020c9b8>] do_work_pending+0x9c/0x648 arch/arm/kernel/signal.c:676
    softirqs last  enabled at (298216): [<8020167c>] __do_softirq+0x584/0x7ac kernel/softirq.c:372
    softirqs last disabled at (298201): [<8024dff4>] do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline]
    softirqs last disabled at (298201): [<8024dff4>] invoke_softirq kernel/softirq.c:228 [inline]
    softirqs last disabled at (298201): [<8024dff4>] __irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&(&pstats->syncp)->seq);
      <Interrupt>
        lock(&(&pstats->syncp)->seq);
    
     *** DEADLOCK ***
    
    1 lock held by udevd/4013:
     #0: 82b09c5c (rcu_read_lock){....}-{1:2}, at: sk_filter_trim_cap+0x54/0x434 net/core/filter.c:139
    
    stack backtrace:
    CPU: 1 PID: 4013 Comm: udevd Not tainted 5.12.0-rc3-syzkaller #0
    Hardware name: ARM-Versatile Express
    Backtrace:
    [<81802550>] (dump_backtrace) from [<818027c4>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:252)
     r7:00000080 r6:600d0093 r5:00000000 r4:82b58344
    [<818027ac>] (show_stack) from [<81809e98>] (__dump_stack lib/dump_stack.c:79 [inline])
    [<818027ac>] (show_stack) from [<81809e98>] (dump_stack+0xb8/0xe8 lib/dump_stack.c:120)
    [<81809de0>] (dump_stack) from [<81804a00>] (print_usage_bug.part.0+0x228/0x230 kernel/locking/lockdep.c:3806)
     r7:86bcb768 r6:81a0326c r5:830f96a8 r4:86bcb0c0
    [<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (print_usage_bug kernel/locking/lockdep.c:3776 [inline])
    [<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (valid_state kernel/locking/lockdep.c:3818 [inline])
    [<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (mark_lock_irq kernel/locking/lockdep.c:4021 [inline])
    [<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (mark_lock.part.0+0xc34/0x136c kernel/locking/lockdep.c:4478)
     r10:83278fe8 r9:82c6d748 r8:00000000 r7:82c6d2d4 r6:00000004 r5:86bcb768
     r4:00000006
    [<802ba584>] (mark_lock.part.0) from [<802bc644>] (mark_lock kernel/locking/lockdep.c:4442 [inline])
    [<802ba584>] (mark_lock.part.0) from [<802bc644>] (mark_usage kernel/locking/lockdep.c:4391 [inline])
    [<802ba584>] (mark_lock.part.0) from [<802bc644>] (__lock_acquire+0x9bc/0x3318 kernel/locking/lockdep.c:4854)
     r10:86bcb768 r9:86bcb0c0 r8:00000001 r7:00040000 r6:0000075a r5:830f96a8
     r4:00000000
    [<802bbc88>] (__lock_acquire) from [<802bfb90>] (lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510)
     r10:00000000 r9:600d0013 r8:00000000 r7:00000000 r6:828a2680 r5:828a2680
     r4:861e5bc8
    [<802bfaa0>] (lock_acquire.part.0) from [<802bff28>] (lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483)
     r10:8146137c r9:00000000 r8:00000001 r7:00000000 r6:00000000 r5:00000000
     r4:ff7c9dec
    [<802bfebc>] (lock_acquire) from [<81381eb4>] (do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline])
    [<802bfebc>] (lock_acquire) from [<81381eb4>] (do_write_seqcount_begin include/linux/seqlock.h:545 [inline])
    [<802bfebc>] (lock_acquire) from [<81381eb4>] (u64_stats_update_begin include/linux/u64_stats_sync.h:129 [inline])
    [<802bfebc>] (lock_acquire) from [<81381eb4>] (__bpf_prog_run_save_cb include/linux/filter.h:727 [inline])
    [<802bfebc>] (lock_acquire) from [<81381eb4>] (bpf_prog_run_save_cb include/linux/filter.h:741 [inline])
    [<802bfebc>] (lock_acquire) from [<81381eb4>] (sk_filter_trim_cap+0x26c/0x434 net/core/filter.c:149)
     r10:a4095dd0 r9:ff7c9dd0 r8:e44be000 r7:8146137c r6:00000001 r5:8611ba80
     r4:00000000
    [<81381c48>] (sk_filter_trim_cap) from [<8146137c>] (sk_filter include/linux/filter.h:867 [inline])
    [<81381c48>] (sk_filter_trim_cap) from [<8146137c>] (do_one_broadcast net/netlink/af_netlink.c:1468 [inline])
    [<81381c48>] (sk_filter_trim_cap) from [<8146137c>] (netlink_broadcast_filtered+0x27c/0x4fc net/netlink/af_netlink.c:1520)
     r10:00000001 r9:833d6b1c r8:00000000 r7:8572f864 r6:8611ba80 r5:8698d800
     r4:8572f800
    [<81461100>] (netlink_broadcast_filtered) from [<81463e60>] (netlink_broadcast net/netlink/af_netlink.c:1544 [inline])
    [<81461100>] (netlink_broadcast_filtered) from [<81463e60>] (netlink_sendmsg+0x3d0/0x478 net/netlink/af_netlink.c:1925)
     r10:00000000 r9:00000002 r8:8698d800 r7:000000b7 r6:8611b900 r5:861e5f50
     r4:86aa3000
    [<81463a90>] (netlink_sendmsg) from [<81321f54>] (sock_sendmsg_nosec net/socket.c:654 [inline])
    [<81463a90>] (netlink_sendmsg) from [<81321f54>] (sock_sendmsg+0x3c/0x4c net/socket.c:674)
     r10:00000000 r9:861e5dd4 r8:00000000 r7:86570000 r6:00000000 r5:86570000
     r4:861e5f50
    [<81321f18>] (sock_sendmsg) from [<813234d0>] (____sys_sendmsg+0x230/0x29c net/socket.c:2350)
     r5:00000040 r4:861e5f50
    [<813232a0>] (____sys_sendmsg) from [<8132549c>] (___sys_sendmsg+0xac/0xe4 net/socket.c:2404)
     r10:00000128 r9:861e4000 r8:00000000 r7:00000000 r6:86570000 r5:861e5f50
     r4:00000000
    [<813253f0>] (___sys_sendmsg) from [<81325684>] (__sys_sendmsg net/socket.c:2433 [inline])
    [<813253f0>] (___sys_sendmsg) from [<81325684>] (__do_sys_sendmsg net/socket.c:2442 [inline])
    [<813253f0>] (___sys_sendmsg) from [<81325684>] (sys_sendmsg+0x58/0xa0 net/socket.c:2440)
     r8:80200224 r7:00000128 r6:00000000 r5:7eaa541c r4:86570000
    [<8132562c>] (sys_sendmsg) from [<80200060>] (ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64)
    Exception stack(0x861e5fa8 to 0x861e5ff0)
    5fa0:                   00000000 00000000 0000000c 7eaa541c 00000000 00000000
    5fc0: 00000000 00000000 76fbf840 00000128 00000000 0000008f 7eaa541c 000563f8
    5fe0: 00056110 7eaa53e0 00036cec 76c9bf44
     r6:76fbf840 r5:00000000 r4:00000000
    
    Fixes: 492ecee892c2 ("bpf: enable program stats")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211026214133.3114279-2-eric.dumazet@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ab36444a538c23f6991f029512bf5f155d9384a
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Mon Oct 25 10:25:36 2021 +0200

    wcn36xx: Fix discarded frames due to wrong sequence number
    
    [ Upstream commit 113f304dbc1627c6ec9d5329d839964095768980 ]
    
    The firmware is offering features such as ARP offload, for which
    firmware crafts its own (QoS)packets without waking up the host.
    Point is that the sequence numbers generated by the firmware are
    not in sync with the host mac80211 layer and can cause packets
    such as firmware ARP reponses to be dropped by the AP (too old SN).
    
    To fix this we need to let the firmware manages the sequence
    numbers by its own (except for QoS null frames). There is a SN
    counter for each QoS queue and one global/baseline counter for
    Non-QoS.
    
    Fixes: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2e55ffee66f5701b5065e8c785abe11d7f6a82b
Author: Benjamin Li <benl@squareup.com>
Date:   Fri Oct 22 17:15:28 2021 -0700

    wcn36xx: add proper DMA memory barriers in rx path
    
    [ Upstream commit 9bfe38e064af5decba2ffce66a2958ab8b10eaa4 ]
    
    This is essentially exactly following the dma_wmb()/dma_rmb() usage
    instructions in Documentation/memory-barriers.txt.
    
    The theoretical races here are:
    
    1. DXE (the DMA Transfer Engine in the Wi-Fi subsystem) seeing the
    dxe->ctrl & WCN36xx_DXE_CTRL_VLD write before the dxe->dst_addr_l
    write, thus performing DMA into the wrong address.
    
    2. CPU reading dxe->dst_addr_l before DXE unsets dxe->ctrl &
    WCN36xx_DXE_CTRL_VLD. This should generally be harmless since DXE
    doesn't write dxe->dst_addr_l (no risk of freeing the wrong skb).
    
    Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
    Signed-off-by: Benjamin Li <benl@squareup.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211023001528.3077822-1-benl@squareup.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 960a216b078a5fc2a7642246959140910be20146
Author: Wang Hai <wanghai38@huawei.com>
Date:   Wed Oct 20 20:03:45 2021 +0800

    libertas: Fix possible memory leak in probe and disconnect
    
    [ Upstream commit 9692151e2fe7a326bafe99836fd1f20a2cc3a049 ]
    
    I got memory leak as follows when doing fault injection test:
    
    unreferenced object 0xffff88812c7d7400 (size 512):
      comm "kworker/6:1", pid 176, jiffies 4295003332 (age 822.830s)
      hex dump (first 32 bytes):
        00 68 1e 04 81 88 ff ff 01 00 00 00 00 00 00 00  .h..............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490
        [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470
        [<ffffffffa02c9873>] if_usb_probe+0x63/0x446 [usb8xxx]
        [<ffffffffa022668a>] usb_probe_interface+0x1aa/0x3c0 [usbcore]
        [<ffffffff82b59630>] really_probe+0x190/0x480
        [<ffffffff82b59a19>] __driver_probe_device+0xf9/0x180
        [<ffffffff82b59af3>] driver_probe_device+0x53/0x130
        [<ffffffff82b5a075>] __device_attach_driver+0x105/0x130
        [<ffffffff82b55949>] bus_for_each_drv+0x129/0x190
        [<ffffffff82b593c9>] __device_attach+0x1c9/0x270
        [<ffffffff82b5a250>] device_initial_probe+0x20/0x30
        [<ffffffff82b579c2>] bus_probe_device+0x142/0x160
        [<ffffffff82b52e49>] device_add+0x829/0x1300
        [<ffffffffa02229b1>] usb_set_configuration+0xb01/0xcc0 [usbcore]
        [<ffffffffa0235c4e>] usb_generic_driver_probe+0x6e/0x90 [usbcore]
        [<ffffffffa022641f>] usb_probe_device+0x6f/0x130 [usbcore]
    
    cardp is missing being freed in the error handling path of the probe
    and the path of the disconnect, which will cause memory leak.
    
    This patch adds the missing kfree().
    
    Fixes: 876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211020120345.2016045-3-wanghai38@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59de456628bd2ab2fc1f78a0b54960cb9bfbe458
Author: Wang Hai <wanghai38@huawei.com>
Date:   Wed Oct 20 20:03:44 2021 +0800

    libertas_tf: Fix possible memory leak in probe and disconnect
    
    [ Upstream commit d549107305b4634c81223a853701c06bcf657bc3 ]
    
    I got memory leak as follows when doing fault injection test:
    
    unreferenced object 0xffff88810a2ddc00 (size 512):
      comm "kworker/6:1", pid 176, jiffies 4295009893 (age 757.220s)
      hex dump (first 32 bytes):
        00 50 05 18 81 88 ff ff 00 00 00 00 00 00 00 00  .P..............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490
        [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470
        [<ffffffffa02a1530>] if_usb_probe+0x60/0x37c [libertas_tf_usb]
        [<ffffffffa022668a>] usb_probe_interface+0x1aa/0x3c0 [usbcore]
        [<ffffffff82b59630>] really_probe+0x190/0x480
        [<ffffffff82b59a19>] __driver_probe_device+0xf9/0x180
        [<ffffffff82b59af3>] driver_probe_device+0x53/0x130
        [<ffffffff82b5a075>] __device_attach_driver+0x105/0x130
        [<ffffffff82b55949>] bus_for_each_drv+0x129/0x190
        [<ffffffff82b593c9>] __device_attach+0x1c9/0x270
        [<ffffffff82b5a250>] device_initial_probe+0x20/0x30
        [<ffffffff82b579c2>] bus_probe_device+0x142/0x160
        [<ffffffff82b52e49>] device_add+0x829/0x1300
        [<ffffffffa02229b1>] usb_set_configuration+0xb01/0xcc0 [usbcore]
        [<ffffffffa0235c4e>] usb_generic_driver_probe+0x6e/0x90 [usbcore]
        [<ffffffffa022641f>] usb_probe_device+0x6f/0x130 [usbcore]
    
    cardp is missing being freed in the error handling path of the probe
    and the path of the disconnect, which will cause memory leak.
    
    This patch adds the missing kfree().
    
    Fixes: c305a19a0d0a ("libertas_tf: usb specific functions")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211020120345.2016045-2-wanghai38@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 964b738fde92a8bc8a0174fc93a58e89fe7eb02a
Author: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
Date:   Fri Oct 22 17:26:48 2021 +0200

    KVM: s390: Fix handle_sske page fault handling
    
    [ Upstream commit 85f517b29418158d3e6e90c3f0fc01b306d2f1a1 ]
    
    If handle_sske cannot set the storage key, because there is no
    page table entry or no present large page entry, it calls
    fixup_user_fault.
    However, currently, if the call succeeds, handle_sske returns
    -EAGAIN, without having set the storage key.
    Instead, retry by continue'ing the loop without incrementing the
    address.
    The same issue in handle_pfmf was fixed by
    a11bdb1a6b78 ("KVM: s390: Fix pfmf and conditional skey emulation").
    
    Fixes: bd096f644319 ("KVM: s390: Add skey emulation fault handling")
    Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20211022152648.26536-1-scgl@linux.ibm.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 777194b87fb3695b8a1e3c60acdf166394342695
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Oct 26 09:51:28 2021 +0800

    samples/kretprobes: Fix return value if register_kretprobe() failed
    
    [ Upstream commit f76fbbbb5061fe14824ba5807c44bd7400a6b4e1 ]
    
    Use the actual return value instead of always -1 if register_kretprobe()
    failed.
    
    E.g. without this patch:
    
     # insmod samples/kprobes/kretprobe_example.ko func=no_such_func
     insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Operation not permitted
    
    With this patch:
    
     # insmod samples/kprobes/kretprobe_example.ko func=no_such_func
     insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Unknown symbol in module
    
    Link: https://lkml.kernel.org/r/1635213091-24387-2-git-send-email-yangtiezhu@loongson.cn
    
    Fixes: 804defea1c02 ("Kprobes: move kprobe examples to samples/")
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41c9a411aad01e6c97355ede0741ff2d3d1cc561
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Mon Oct 25 21:56:27 2021 +0100

    spi: spi-rpc-if: Check return value of rpcif_sw_init()
    
    [ Upstream commit 0b0a281ed7001d4c4f4c47bdc84680c4997761ca ]
    
    rpcif_sw_init() can fail so make sure we check the return value
    of it and on error exit rpcif_spi_probe() callback with error code.
    
    Fixes: eb8d6d464a27 ("spi: add Renesas RPC-IF driver")
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20211025205631.21151-4-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca5c67889bd6d68c03d9debff927d4b4dc5c20b7
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Tue Oct 26 16:32:42 2021 +0800

    cpufreq: intel_pstate: Fix cpu->pstate.turbo_freq initialization
    
    [ Upstream commit c72bcf0ab87a92634e58af62e89af0f40dfd0b88 ]
    
    Fix a problem in active mode that cpu->pstate.turbo_freq is initialized
    only if HWP-to-frequency scaling factor is refined.
    
    In passive mode, this problem is not exposed, because
    cpu->pstate.turbo_freq is set again, later in
    intel_cpufreq_cpu_init()->intel_pstate_get_hwp_cap().
    
    Fixes: eb3693f0521e ("cpufreq: intel_pstate: hybrid: CPU-specific scaling factor")
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d9b7edfdcf2d191d4279749d0b8b7ce35fd3ea5
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Fri Oct 15 15:55:50 2021 -0400

    tracing: Fix missing trace_boot_init_histograms kstrdup NULL checks
    
    [ Upstream commit 3c20bd3af535d64771b193bb4dd41ed662c464ce ]
    
    trace_boot_init_histograms misses NULL pointer checks for kstrdup
    failure.
    
    Link: https://lkml.kernel.org/r/20211015195550.22742-1-mathieu.desnoyers@efficios.com
    
    Fixes: 64dc7f6958ef5 ("tracing/boot: Show correct histogram error command")
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3ec9c358a42552c44e5541857e9a06645e0e2f2
Author: Jon Maxwell <jmaxwell37@gmail.com>
Date:   Mon Oct 25 10:59:03 2021 +1100

    tcp: don't free a FIN sk_buff in tcp_remove_empty_skb()
    
    [ Upstream commit cf12e6f9124629b18a6182deefc0315f0a73a199 ]
    
    v1: Implement a more general statement as recommended by Eric Dumazet. The
    sequence number will be advanced, so this check will fix the FIN case and
    other cases.
    
    A customer reported sockets stuck in the CLOSING state. A Vmcore revealed that
    the write_queue was not empty as determined by tcp_write_queue_empty() but the
    sk_buff containing the FIN flag had been freed and the socket was zombied in
    that state. Corresponding pcaps show no FIN from the Linux kernel on the wire.
    
    Some instrumentation was added to the kernel and it was found that there is a
    timing window where tcp_sendmsg() can run after tcp_send_fin().
    
    tcp_sendmsg() will hit an error, for example:
    
    1269 ▹       if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))↩
    1270 ▹       ▹       goto do_error;↩
    
    tcp_remove_empty_skb() will then free the FIN sk_buff as "skb->len == 0". The
    TCP socket is now wedged in the FIN-WAIT-1 state because the FIN is never sent.
    
    If the other side sends a FIN packet the socket will transition to CLOSING and
    remain that way until the system is rebooted.
    
    Fix this by checking for the FIN flag in the sk_buff and don't free it if that
    is the case. Testing confirmed that fixed the issue.
    
    Fixes: fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases")
    Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
    Reported-by: Monir Zouaoui <Monir.Zouaoui@mail.schwarz>
    Reported-by: Simon Stier <simon.stier@mail.schwarz>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d48715b25f2ef1f839eb9ee107d45dd029229f12
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Tue Oct 26 03:08:26 2021 +0200

    libbpf: Fix endianness detection in BPF_CORE_READ_BITFIELD_PROBED()
    
    [ Upstream commit 45f2bebc8079788f62f22d9e8b2819afb1789d7b ]
    
    __BYTE_ORDER is supposed to be defined by a libc, and __BYTE_ORDER__ -
    by a compiler. bpf_core_read.h checks __BYTE_ORDER == __LITTLE_ENDIAN,
    which is true if neither are defined, leading to incorrect behavior on
    big-endian hosts if libc headers are not included, which is often the
    case.
    
    Fixes: ee26dade0e3b ("libbpf: Add support for relocatable bitfields")
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20211026010831.748682-2-iii@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf5e3d54de65100191ef1b08e2bac47a1a96b0a8
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Sep 24 15:41:11 2021 +0100

    tpm_tis_spi: Add missing SPI ID
    
    [ Upstream commit 7eba41fe8c7bb01ff3d4b757bd622375792bc720 ]
    
    In commit c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
    we added SPI IDs for all the DT aliases to handle the fact that we always
    use SPI modaliases to load modules even when probed via DT however the
    mentioned commit missed that the SPI and OF device ID entries did not
    match and were different and so DT nodes with compatible
    "tcg,tpm_tis-spi" will not match.  Add an extra ID for tpm_tis-spi
    rather than just fix the existing one since what's currently there is
    going to be better for anyone actually using SPI IDs to instantiate.
    
    Fixes: c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
    Fixes: 96c8395e2166 ("spi: Revert modalias changes")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf736690bcbe39c328eef22e00314e38b3fa4475
Author: Hao Wu <hao.wu@rubrik.com>
Date:   Wed Sep 8 02:26:06 2021 -0700

    tpm: fix Atmel TPM crash caused by too frequent queries
    
    [ Upstream commit 79ca6f74dae067681a779fd573c2eb59649989bc ]
    
    The Atmel TPM 1.2 chips crash with error
    `tpm_try_transmit: send(): error -62` since kernel 4.14.
    It is observed from the kernel log after running `tpm_sealdata -z`.
    The error thrown from the command is as follows
    ```
    $ tpm_sealdata -z
    Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl,
    code=0087 (135), I/O error
    ```
    
    The issue was reproduced with the following Atmel TPM chip:
    ```
    $ tpm_version
    T0  TPM 1.2 Version Info:
      Chip Version:        1.2.66.1
      Spec Level:          2
      Errata Revision:     3
      TPM Vendor ID:       ATML
      TPM Version:         01010000
      Manufacturer Info:   41544d4c
    ```
    
    The root cause of the issue is due to the TPM calls to msleep()
    were replaced with usleep_range() [1], which reduces
    the actual timeout. Via experiments, it is observed that
    the original msleep(5) actually sleeps for 15ms.
    Because of a known timeout issue in Atmel TPM 1.2 chip,
    the shorter timeout than 15ms can cause the error described above.
    
    A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further
    reduced the timeout to less than 1ms. With experiments,
    the problematic timeout in the latest kernel is the one
    for `wait_for_tpm_stat`.
    
    To fix it, the patch reverts the timeout of `wait_for_tpm_stat`
    to 15ms for all Atmel TPM 1.2 chips, but leave it untouched
    for Ateml TPM 2.0 chip, and chips from other vendors.
    As explained above, the chosen 15ms timeout is
    the actual timeout before this issue introduced,
    thus the old value is used here.
    Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us,
    TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to
    the existing TPM_TIMEOUT_RANGE_US (300us).
    The fixed has been tested in the system with the affected Atmel chip
    with no issues observed after boot up.
    
    References:
    [1] 9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM
    1.2/2.0 generic drivers
    [2] cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core
    [3] 59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit()
    [4] 424eaf910c32 tpm: reduce polling time to usecs for even finer
    granularity
    
    Fixes: 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")
    Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/
    Signed-off-by: Hao Wu <hao.wu@rubrik.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5949ef0753be9b560482b8e6b9305c62c6d7830
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Oct 25 15:45:28 2021 -0700

    libbpf: Fix off-by-one bug in bpf_core_apply_relo()
    
    [ Upstream commit de5d0dcef602de39070c31c7e56c58249c56ba37 ]
    
    Fix instruction index validity check which has off-by-one error.
    
    Fixes: 3ee4f5335511 ("libbpf: Split bpf_core_apply_relo() into bpf_program independent helper.")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211025224531.1088894-2-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af25dbc8460fe65eb0c913e365f682ee7d73cd60
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Wed Oct 20 09:40:36 2021 +0800

    blk-cgroup: synchronize blkg creation against policy deactivation
    
    [ Upstream commit 0c9d338c8443b06da8e8d3bfce824c5ea6d3488f ]
    
    Our test reports a null pointer dereference:
    
    [  168.534653] ==================================================================
    [  168.535614] Disabling lock debugging due to kernel taint
    [  168.536346] BUG: kernel NULL pointer dereference, address: 0000000000000008
    [  168.537274] #PF: supervisor read access in kernel mode
    [  168.537964] #PF: error_code(0x0000) - not-present page
    [  168.538667] PGD 0 P4D 0
    [  168.539025] Oops: 0000 [#1] PREEMPT SMP KASAN
    [  168.539656] CPU: 13 PID: 759 Comm: bash Tainted: G    B             5.15.0-rc2-next-202100
    [  168.540954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_0738364
    [  168.542736] RIP: 0010:bfq_pd_init+0x88/0x1e0
    [  168.543318] Code: 98 00 00 00 e8 c9 e4 5b ff 4c 8b 65 00 49 8d 7c 24 08 e8 bb e4 5b ff 4d0
    [  168.545803] RSP: 0018:ffff88817095f9c0 EFLAGS: 00010002
    [  168.546497] RAX: 0000000000000001 RBX: ffff888101a1c000 RCX: 0000000000000000
    [  168.547438] RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff888106553428
    [  168.548402] RBP: ffff888106553400 R08: ffffffff961bcaf4 R09: 0000000000000001
    [  168.549365] R10: ffffffffa2e16c27 R11: fffffbfff45c2d84 R12: 0000000000000000
    [  168.550291] R13: ffff888101a1c098 R14: ffff88810c7a08c8 R15: ffffffffa55541a0
    [  168.551221] FS:  00007fac75227700(0000) GS:ffff88839ba80000(0000) knlGS:0000000000000000
    [  168.552278] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  168.553040] CR2: 0000000000000008 CR3: 0000000165ce7000 CR4: 00000000000006e0
    [  168.554000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  168.554929] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  168.555888] Call Trace:
    [  168.556221]  <TASK>
    [  168.556510]  blkg_create+0x1c0/0x8c0
    [  168.556989]  blkg_conf_prep+0x574/0x650
    [  168.557502]  ? stack_trace_save+0x99/0xd0
    [  168.558033]  ? blkcg_conf_open_bdev+0x1b0/0x1b0
    [  168.558629]  tg_set_conf.constprop.0+0xb9/0x280
    [  168.559231]  ? kasan_set_track+0x29/0x40
    [  168.559758]  ? kasan_set_free_info+0x30/0x60
    [  168.560344]  ? tg_set_limit+0xae0/0xae0
    [  168.560853]  ? do_sys_openat2+0x33b/0x640
    [  168.561383]  ? do_sys_open+0xa2/0x100
    [  168.561877]  ? __x64_sys_open+0x4e/0x60
    [  168.562383]  ? __kasan_check_write+0x20/0x30
    [  168.562951]  ? copyin+0x48/0x70
    [  168.563390]  ? _copy_from_iter+0x234/0x9e0
    [  168.563948]  tg_set_conf_u64+0x17/0x20
    [  168.564467]  cgroup_file_write+0x1ad/0x380
    [  168.565014]  ? cgroup_file_poll+0x80/0x80
    [  168.565568]  ? __mutex_lock_slowpath+0x30/0x30
    [  168.566165]  ? pgd_free+0x100/0x160
    [  168.566649]  kernfs_fop_write_iter+0x21d/0x340
    [  168.567246]  ? cgroup_file_poll+0x80/0x80
    [  168.567796]  new_sync_write+0x29f/0x3c0
    [  168.568314]  ? new_sync_read+0x410/0x410
    [  168.568840]  ? __handle_mm_fault+0x1c97/0x2d80
    [  168.569425]  ? copy_page_range+0x2b10/0x2b10
    [  168.570007]  ? _raw_read_lock_bh+0xa0/0xa0
    [  168.570622]  vfs_write+0x46e/0x630
    [  168.571091]  ksys_write+0xcd/0x1e0
    [  168.571563]  ? __x64_sys_read+0x60/0x60
    [  168.572081]  ? __kasan_check_write+0x20/0x30
    [  168.572659]  ? do_user_addr_fault+0x446/0xff0
    [  168.573264]  __x64_sys_write+0x46/0x60
    [  168.573774]  do_syscall_64+0x35/0x80
    [  168.574264]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [  168.574960] RIP: 0033:0x7fac74915130
    [  168.575456] Code: 73 01 c3 48 8b 0d 58 ed 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 444
    [  168.577969] RSP: 002b:00007ffc3080e288 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [  168.578986] RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007fac74915130
    [  168.579937] RDX: 0000000000000009 RSI: 000056007669f080 RDI: 0000000000000001
    [  168.580884] RBP: 000056007669f080 R08: 000000000000000a R09: 00007fac75227700
    [  168.581841] R10: 000056007655c8f0 R11: 0000000000000246 R12: 0000000000000009
    [  168.582796] R13: 0000000000000001 R14: 00007fac74be55e0 R15: 00007fac74be08c0
    [  168.583757]  </TASK>
    [  168.584063] Modules linked in:
    [  168.584494] CR2: 0000000000000008
    [  168.584964] ---[ end trace 2475611ad0f77a1a ]---
    
    This is because blkg_alloc() is called from blkg_conf_prep() without
    holding 'q->queue_lock', and elevator is exited before blkg_create():
    
    thread 1                            thread 2
    blkg_conf_prep
     spin_lock_irq(&q->queue_lock);
     blkg_lookup_check -> return NULL
     spin_unlock_irq(&q->queue_lock);
    
     blkg_alloc
      blkcg_policy_enabled -> true
      pd = ->pd_alloc_fn
      blkg->pd[i] = pd
                                       blk_mq_exit_sched
                                        bfq_exit_queue
                                         blkcg_deactivate_policy
                                          spin_lock_irq(&q->queue_lock);
                                          __clear_bit(pol->plid, q->blkcg_pols);
                                          spin_unlock_irq(&q->queue_lock);
                                        q->elevator = NULL;
      spin_lock_irq(&q->queue_lock);
       blkg_create
        if (blkg->pd[i])
         ->pd_init_fn -> q->elevator is NULL
      spin_unlock_irq(&q->queue_lock);
    
    Because blkcg_deactivate_policy() requires queue to be frozen, we can
    grab q_usage_counter to synchoronize blkg_conf_prep() against
    blkcg_deactivate_policy().
    
    Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20211020014036.2141723-1-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39581715d6e5bcdb280be4e24dbdaa22bcac00c6
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Sun Oct 24 13:20:13 2021 +1300

    block: ataflop: more blk-mq refactoring fixes
    
    [ Upstream commit d28e4dff085c5a87025c9a0a85fb798bd8e9ca17 ]
    
    As it turns out, my earlier patch in commit 86d46fdaa12a (block:
    ataflop: fix breakage introduced at blk-mq refactoring) was
    incomplete. This patch fixes any remaining issues found during
    more testing and code review.
    
    Requests exceeding 4 k are handled in 4k segments but
    __blk_mq_end_request() is never called on these (still
    sectors outstanding on the request). With redo_fd_request()
    removed, there is no provision to kick off processing of the
    next segment, causing requests exceeding 4k to hang. (By
    setting /sys/block/fd0/queue/max_sectors_k <= 4 as workaround,
    this behaviour can be avoided).
    
    Instead of reintroducing redo_fd_request(), requeue the remainder
    of the request by calling blk_mq_requeue_request() on incomplete
    requests (i.e. when blk_update_request() still returns true), and
    rely on the block layer to queue the residual as new request.
    
    Both error handling and formatting needs to release the
    ST-DMA lock, so call finish_fdc() on these (this was previously
    handled by redo_fd_request()). finish_fdc() may be called
    legitimately without the ST-DMA lock held - make sure we only
    release the lock if we actually held it. In a similar way,
    early exit due to errors in ataflop_queue_rq() must release
    the lock.
    
    After minor errors, fd_error sets up to recalibrate the drive
    but never re-runs the current operation (another task handled by
    redo_fd_request() before). Call do_fd_action() to get the next
    steps (seek, retry read/write) underway.
    
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Fixes: 6ec3938cff95f (ataflop: convert to blk-mq)
    CC: linux-block@vger.kernel.org
    Link: https://lore.kernel.org/r/20211024002013.9332-1-schmitzmic@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a8cd2686ec7822d7a97d54d7e83b8974da81be3
Author: Abinaya Kalaiselvan <akalaise@codeaurora.org>
Date:   Wed Oct 20 11:59:07 2021 +0300

    ath10k: fix module load regression with iram-recovery feature
    
    [ Upstream commit 6f8c8bf4c7c9be1c42088689fd4370e06b46608a ]
    
    Commit 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
    introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But
    this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit
    was not enabled in the ath10k coredump_mask module parameter:
    
    [ 2209.328190] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
    [ 2209.434414] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
    [ 2209.547191] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 cbade90a
    [ 2210.896485] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id 0:1 crc32 a040efc2
    [ 2213.603339] ath10k_pci 0000:02:00.0: failed to copy target iram contents: -12
    [ 2213.839027] ath10k_pci 0000:02:00.0: could not init core (-12)
    [ 2213.933910] ath10k_pci 0000:02:00.0: could not probe fw (-12)
    
    And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA
    enabled so anyone using a firmware with iram-recovery feature would fail. To my
    knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099
    enabled the feature.
    
    The reason for regression was that ath10k_core_copy_target_iram() used
    ath10k_coredump_get_mem_layout() to get the memory layout, but when
    ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out
    with an error.
    
    While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is
    disabled but the firmware has iram-recovery enabled the module load fails with
    similar error messages. I fixed that by returning 0 from
    ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns
    NULL.
    
    Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139
    
    Fixes: 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
    Signed-off-by: Abinaya Kalaiselvan <akalaise@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211020075054.23061-1-kvalo@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a521a0ddd5aad05b455e7134954923c4f2ef74fe
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 18 15:30:38 2021 +0100

    ARM: 9142/1: kasan: work around LPAE build warning
    
    [ Upstream commit c2e6df3eaaf120cde5e7c3a70590dd82e427458a ]
    
    pgd_page_vaddr() returns an 'unsigned long' address, causing a warning
    with the memcpy() call in kasan_init():
    
    arch/arm/mm/kasan_init.c: In function 'kasan_init':
    include/asm-generic/pgtable-nop4d.h:44:50: error: passing argument 2 of '__memcpy' makes pointer from integer without a cast [-Werror=int-conversion]
       44 | #define pgd_page_vaddr(pgd)                     ((unsigned long)(p4d_pgtable((p4d_t){ pgd })))
          |                                                 ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          |                                                  |
          |                                                  long unsigned int
    arch/arm/include/asm/string.h:58:45: note: in definition of macro 'memcpy'
       58 | #define memcpy(dst, src, len) __memcpy(dst, src, len)
          |                                             ^~~
    arch/arm/mm/kasan_init.c:229:16: note: in expansion of macro 'pgd_page_vaddr'
      229 |                pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
          |                ^~~~~~~~~~~~~~
    arch/arm/include/asm/string.h:21:47: note: expected 'const void *' but argument is of type 'long unsigned int'
       21 | extern void *__memcpy(void *dest, const void *src, __kernel_size_t n);
          |                                   ~~~~~~~~~~~~^~~
    
    Avoid this by adding an explicit typecast.
    
    Link: https://lore.kernel.org/all/CACRpkdb3DMvof3-xdtss0Pc6KM36pJA-iy=WhvtNVnsDpeJ24Q@mail.gmail.com/
    
    Fixes: 5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory")
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 348273847a56ac4a2bcb148000b8e7ac9cde0078
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Sun Oct 24 20:17:48 2021 +0300

    net: dsa: avoid refcount warnings when ->port_{fdb,mdb}_del returns error
    
    [ Upstream commit 232deb3f9567ce37d99b8616a6c07c1fc0436abf ]
    
    At present, when either of ds->ops->port_fdb_del() or ds->ops->port_mdb_del()
    return a non-zero error code, we attempt to save the day and keep the
    data structure associated with that switchdev object, as the deletion
    procedure did not complete.
    
    However, the way in which we do this is suspicious to the checker in
    lib/refcount.c, who thinks it is buggy to increment a refcount that
    became zero, and that this is indicative of a use-after-free.
    
    Fixes: 161ca59d39e9 ("net: dsa: reference count the MDB entries at the cross-chip notifier level")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69abfe39c7d6f9c2162e1f7a3b1950124144a1de
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 20 17:25:22 2021 +0100

    irq: mips: avoid nested irq_enter()
    
    [ Upstream commit c65b52d02f6c1a06ddb20cba175ad49eccd6410d ]
    
    As bcm6345_l1_irq_handle() is a chained irqchip handler, it will be
    invoked within the context of the root irqchip handler, which must have
    entered IRQ context already.
    
    When bcm6345_l1_irq_handle() calls arch/mips's do_IRQ() , this will nest
    another call to irq_enter(), and the resulting nested increment to
    `rcu_data.dynticks_nmi_nesting` will cause rcu_is_cpu_rrupt_from_idle()
    to fail to identify wakeups from idle, resulting in failure to preempt,
    and RCU stalls.
    
    Chained irqchip handlers must invoke IRQ handlers by way of thee core
    irqchip code, i.e. generic_handle_irq() or generic_handle_domain_irq()
    and should not call do_IRQ(), which is intended only for root irqchip
    handlers.
    
    Fix bcm6345_l1_irq_handle() by calling generic_handle_irq() directly.
    
    Fixes: c7c42ec2baa1de7a ("irqchips/bmips: Add bcm6345-l1 interrupt controller")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca46cc192bece0edd1172eae97d9472353510514
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date:   Mon Sep 20 15:24:51 2021 +0200

    KVM: s390: pv: avoid stalls for kvm_s390_pv_init_vm
    
    [ Upstream commit 1e2aa46de526a5adafe580bca4c25856bb06f09e ]
    
    When the system is heavily overcommitted, kvm_s390_pv_init_vm might
    generate stall notifications.
    
    Fix this by using uv_call_sched instead of just uv_call. This is ok because
    we are not holding spinlocks.
    
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Fixes: 214d9bbcd3a672 ("s390/mm: provide memory management functions for protected KVM guests")
    Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Message-Id: <20210920132502.36111-4-imbrenda@linux.ibm.com>
    Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb69970e0cd97e20a89f7b41270acd5a9896ae7a
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date:   Mon Sep 20 15:24:50 2021 +0200

    KVM: s390: pv: avoid double free of sida page
    
    [ Upstream commit d4074324b07a94a1fca476d452dfbb3a4e7bf656 ]
    
    If kvm_s390_pv_destroy_cpu is called more than once, we risk calling
    free_page on a random page, since the sidad field is aliased with the
    gbea, which is not guaranteed to be zero.
    
    This can happen, for example, if userspace calls the KVM_PV_DISABLE
    IOCTL, and it fails, and then userspace calls the same IOCTL again.
    This scenario is only possible if KVM has some serious bug or if the
    hardware is broken.
    
    The solution is to simply return successfully immediately if the vCPU
    was already non secure.
    
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Fixes: 19e1227768863a1469797c13ef8fea1af7beac2c ("KVM: S390: protvirt: Introduce instruction data area bounce buffer")
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Message-Id: <20210920132502.36111-3-imbrenda@linux.ibm.com>
    Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eadbd5d1ec2977c1c99e87eb8f59b26f1c2e6cd9
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Sep 9 18:22:44 2021 +0200

    s390/uv: fully validate the VMA before calling follow_page()
    
    [ Upstream commit 46c22ffd2772201662350bc7b94b9ea9d3ee5ac2 ]
    
    We should not walk/touch page tables outside of VMA boundaries when
    holding only the mmap sem in read mode. Evil user space can modify the
    VMA layout just before this function runs and e.g., trigger races with
    page table removal code since commit dd2283f2605e ("mm: mmap: zap pages
    with read mmap_sem in munmap").
    
    find_vma() does not check if the address is >= the VMA start address;
    use vma_lookup() instead.
    
    Fixes: 214d9bbcd3a6 ("s390/mm: provide memory management functions for protected KVM guests")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Link: https://lore.kernel.org/r/20210909162248.14969-6-david@redhat.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9c017ab05a494477c402236337375a55257cc14
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Sep 9 18:22:43 2021 +0200

    s390/mm: fix VMA and page table handling code in storage key handling functions
    
    [ Upstream commit 949f5c1244ee6c36d2e81c588d1200eaa83a3df6 ]
    
    There are multiple things broken about our storage key handling
    functions:
    
    1. We should not walk/touch page tables outside of VMA boundaries when
       holding only the mmap sem in read mode. Evil user space can modify the
       VMA layout just before this function runs and e.g., trigger races with
       page table removal code since commit dd2283f2605e ("mm: mmap: zap pages
       with read mmap_sem in munmap"). gfn_to_hva() will only translate using
       KVM memory regions, but won't validate the VMA.
    
    2. We should not allocate page tables outside of VMA boundaries: if
       evil user space decides to map hugetlbfs to these ranges, bad things
       will happen because we suddenly have PTE or PMD page tables where we
       shouldn't have them.
    
    3. We don't handle large PUDs that might suddenly appeared inside our page
       table hierarchy.
    
    Don't manually allocate page tables, properly validate that we have VMA and
    bail out on pud_large().
    
    All callers of page table handling functions, except
    get_guest_storage_key(), call fixup_user_fault() in case they
    receive an -EFAULT and retry; this will allocate the necessary page tables
    if required.
    
    To keep get_guest_storage_key() working as expected and not requiring
    kvm_s390_get_skeys() to call fixup_user_fault() distinguish between
    "there is simply no page table or huge page yet and the key is assumed
    to be 0" and "this is a fault to be reported".
    
    Although commit 637ff9efe5ea ("s390/mm: Add huge pmd storage key handling")
    introduced most of the affected code, it was actually already broken
    before when using get_locked_pte() without any VMA checks.
    
    Note: Ever since commit 637ff9efe5ea ("s390/mm: Add huge pmd storage key
    handling") we can no longer set a guest storage key (for example from
    QEMU during VM live migration) without actually resolving a fault.
    Although we would have created most page tables, we would choke on the
    !pmd_present(), requiring a call to fixup_user_fault(). I would
    have thought that this is problematic in combination with postcopy life
    migration ... but nobody noticed and this patch doesn't change the
    situation. So maybe it's just fine.
    
    Fixes: 9fcf93b5de06 ("KVM: S390: Create helper function get_guest_storage_key")
    Fixes: 24d5dd0208ed ("s390/kvm: Provide function for setting the guest storage key")
    Fixes: a7e19ab55ffd ("KVM: s390: handle missing storage-key facility")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210909162248.14969-5-david@redhat.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 735d269aa767673bd53512019a50e7d624585e13
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Sep 9 18:22:42 2021 +0200

    s390/mm: validate VMA in PGSTE manipulation functions
    
    [ Upstream commit fe3d10024073f06f04c74b9674bd71ccc1d787cf ]
    
    We should not walk/touch page tables outside of VMA boundaries when
    holding only the mmap sem in read mode. Evil user space can modify the
    VMA layout just before this function runs and e.g., trigger races with
    page table removal code since commit dd2283f2605e ("mm: mmap: zap pages
    with read mmap_sem in munmap"). gfn_to_hva() will only translate using
    KVM memory regions, but won't validate the VMA.
    
    Further, we should not allocate page tables outside of VMA boundaries: if
    evil user space decides to map hugetlbfs to these ranges, bad things will
    happen because we suddenly have PTE or PMD page tables where we
    shouldn't have them.
    
    Similarly, we have to check if we suddenly find a hugetlbfs VMA, before
    calling get_locked_pte().
    
    Fixes: 2d42f9477320 ("s390/kvm: Add PGSTE manipulation functions")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210909162248.14969-4-david@redhat.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbeff6651f5e1ddfafcecab3658a3009a5d3b260
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Sep 9 18:22:41 2021 +0200

    s390/gmap: don't unconditionally call pte_unmap_unlock() in __gmap_zap()
    
    [ Upstream commit b159f94c86b43cf7e73e654bc527255b1f4eafc4 ]
    
    ... otherwise we will try unlocking a spinlock that was never locked via a
    garbage pointer.
    
    At the time we reach this code path, we usually successfully looked up
    a PGSTE already; however, evil user space could have manipulated the VMA
    layout in the meantime and triggered removal of the page table.
    
    Fixes: 1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210909162248.14969-3-david@redhat.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d6a0e31be0c6fcfef4db8d8739579913d271548
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Sep 9 18:22:40 2021 +0200

    s390/gmap: validate VMA in __gmap_zap()
    
    [ Upstream commit 2d8fb8f3914b40e3cc12f8cbb74daefd5245349d ]
    
    We should not walk/touch page tables outside of VMA boundaries when
    holding only the mmap sem in read mode. Evil user space can modify the
    VMA layout just before this function runs and e.g., trigger races with
    page table removal code since commit dd2283f2605e ("mm: mmap: zap pages
    with read mmap_sem in munmap"). The pure prescence in our guest_to_host
    radix tree does not imply that there is a VMA.
    
    Further, we should not allocate page tables (via get_locked_pte()) outside
    of VMA boundaries: if evil user space decides to map hugetlbfs to these
    ranges, bad things will happen because we suddenly have PTE or PMD page
    tables where we shouldn't have them.
    
    Similarly, we have to check if we suddenly find a hugetlbfs VMA, before
    calling get_locked_pte().
    
    Note that gmap_discard() is different:
    zap_page_range()->unmap_single_vma() makes sure to stay within VMA
    boundaries.
    
    Fixes: b31288fa83b2 ("s390/kvm: support collaborative memory management")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210909162248.14969-2-david@redhat.com
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 908e8e54ef8ded24b07225d42ecaec209f1b02cf
Author: Nick Hainke <vincent@systemli.org>
Date:   Fri Oct 8 00:57:25 2021 +0200

    mt76: mt7615: mt7622: fix ibss and meshpoint
    
    [ Upstream commit 753453afacc0243bd45de45e34218a8d17493e8f ]
    
    commit 7f4b7920318b ("mt76: mt7615: add ibss support") introduced IBSS
    and commit f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh")
    meshpoint support.
    
    Both used in the "get_omac_idx"-function:
    
            if (~mask & BIT(HW_BSSID_0))
                    return HW_BSSID_0;
    
    With commit d8d59f66d136 ("mt76: mt7615: support 16 interfaces") the
    ibss and meshpoint mode should "prefer hw bssid slot 1-3". However,
    with that change the ibss or meshpoint mode will not send any beacon on
    the mt7622 wifi anymore. Devices were still able to exchange data but
    only if a bssid already existed. Two mt7622 devices will never be able
    to communicate.
    
    This commits reverts the preferation of slot 1-3 for ibss and
    meshpoint. Only NL80211_IFTYPE_STATION will still prefer slot 1-3.
    
    Tested on Banana Pi R64.
    
    Fixes: d8d59f66d136 ("mt76: mt7615: support 16 interfaces")
    Signed-off-by: Nick Hainke <vincent@systemli.org>
    Acked-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211007225725.2615-1-vincent@systemli.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae2df723141fc7eceea7b5d6575cee2e6787e14f
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Fri Oct 22 17:31:57 2021 -0700

    libbpf: Fix BTF header parsing checks
    
    [ Upstream commit c825f5fee19caf301d9821cd79abaa734322de26 ]
    
    Original code assumed fixed and correct BTF header length. That's not
    always the case, though, so fix this bug with a proper additional check.
    And use actual header length instead of sizeof(struct btf_header) in
    sanity checks.
    
    Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
    Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211023003157.726961-2-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffb5d239e7ed074c4627ff2bed39eb06cbe9323d
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Fri Oct 22 17:31:56 2021 -0700

    libbpf: Fix overflow in BTF sanity checks
    
    [ Upstream commit 5245dafe3d49efba4d3285cf27ee1cc1eeafafc6 ]
    
    btf_header's str_off+str_len or type_off+type_len can overflow as they
    are u32s. This will lead to bypassing the sanity checks during BTF
    parsing, resulting in crashes afterwards. Fix by using 64-bit signed
    integers for comparison.
    
    Fixes: d8123624506c ("libbpf: Fix BTF data layout checks and allow empty BTF")
    Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211023003157.726961-1-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6c63efb0c8d5e69a12247a3323612e168737e95
Author: Quentin Monnet <quentin@isovalent.com>
Date:   Fri Oct 22 10:47:43 2021 +0100

    bpftool: Avoid leaking the JSON writer prepared for program metadata
    
    [ Upstream commit e89ef634f81c9d90e1824ab183721f3b361472e6 ]
    
    Bpftool creates a new JSON object for writing program metadata in plain
    text mode, regardless of metadata being present or not. Then this writer
    is freed if any metadata has been found and printed, but it leaks
    otherwise. We cannot destroy the object unconditionally, because the
    destructor prints an undesirable line break. Instead, make sure the
    writer is created only after we have found program metadata to print.
    
    Found with valgrind.
    
    Fixes: aff52e685eb3 ("bpftool: Support dumping metadata")
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20211022094743.11052-1-quentin@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d33132c03ff5b33bed76c412bad0af21b48320e
Author: Mauricio Vásquez <mauricio@kinvolk.io>
Date:   Fri Oct 22 15:20:35 2021 -0500

    libbpf: Fix memory leak in btf__dedup()
    
    [ Upstream commit 1000298c76830bc291358e98e8fa5baa3baa9b3a ]
    
    Free btf_dedup if btf_ensure_modifiable() returns error.
    
    Fixes: 919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API")
    Signed-off-by: Mauricio Vásquez <mauricio@kinvolk.io>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20211022202035.48868-1-mauricio@kinvolk.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32293389e84a373169904746c61fa46503e2b2cd
Author: Jim Mattson <jmattson@google.com>
Date:   Wed Sep 29 17:36:49 2021 -0700

    KVM: selftests: Fix nested SVM tests when built with clang
    
    [ Upstream commit ed290e1c20da19fa100a3e0f421aa31b65984960 ]
    
    Though gcc conveniently compiles a simple memset to "rep stos," clang
    prefers to call the libc version of memset. If a test is dynamically
    linked, the libc memset isn't available in L1 (nor is the PLT or the
    GOT, for that matter). Even if the test is statically linked, the libc
    memset may choose to use some CPU features, like AVX, which may not be
    enabled in L1. Note that __builtin_memset doesn't solve the problem,
    because (a) the compiler is free to call memset anyway, and (b)
    __builtin_memset may also choose to use features like AVX, which may
    not be available in L1.
    
    To avoid a myriad of problems, use an explicit "rep stos" to clear the
    VMCB in generic_svm_setup(), which is called both from L0 and L1.
    
    Reported-by: Ricardo Koller <ricarkol@google.com>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Fixes: 20ba262f8631a ("selftests: KVM: AMD Nested test infrastructure")
    Message-Id: <20210930003649.4026553-1-jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6293f673f2d90949f86afc0f5609182b7915c0c
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Tue Oct 19 20:27:26 2021 +0900

    smackfs: use netlbl_cfg_cipsov4_del() for deleting cipso_v4_doi
    
    [ Upstream commit 0934ad42bb2c5df90a1b9de690f93de735b622fe ]
    
    syzbot is reporting UAF at cipso_v4_doi_search() [1], for smk_cipso_doi()
    is calling kfree() without removing from the cipso_v4_doi_list list after
    netlbl_cfg_cipsov4_map_add() returned an error. We need to use
    netlbl_cfg_cipsov4_del() in order to remove from the list and wait for
    RCU grace period before kfree().
    
    Link: https://syzkaller.appspot.com/bug?extid=93dba5b91f0fed312cbd [1]
    Reported-by: syzbot <syzbot+93dba5b91f0fed312cbd@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Fixes: 6c2e8ac0953fccdd ("netlabel: Update kernel configuration API")
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19bbbeb408d0aa3aa5591d17a664423b69fc08e2
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Fri Oct 15 10:39:18 2021 +0300

    crypto: tcrypt - fix skcipher multi-buffer tests for 1420B blocks
    
    [ Upstream commit 3ae88f676aa63366ffa9eebb8ae787c7e19f0c57 ]
    
    Commit ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks")
    mentions:
    > power-of-2 block size. So let's add 1420 bytes explicitly, and round
    > it up to the next blocksize multiple of the algo in question if it
    > does not support 1420 byte blocks.
    but misses updating skcipher multi-buffer tests.
    
    Fix this by using the proper (rounded) input size.
    
    Fixes: ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks")
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48ae8d2243f0208bc0c6fd627c3353454abbe9c2
Author: Jessica Zhang <jesszhan@codeaurora.org>
Date:   Wed Oct 20 11:34:38 2021 -0700

    drm/msm/dsi: fix wrong type in msm_dsi_host
    
    [ Upstream commit 409af447c2a0a6e08ba190993a1153c91d3b11bd ]
    
    Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate
    from u32 to unsigned long, since clk_get_rate() returns an unsigned long.
    
    Fixes: a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org>
    Link: https://lore.kernel.org/r/20211020183438.32263-1-jesszhan@codeaurora.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f88d19f0f6a96f7aee51f1a423a45e168a7e038
Author: Jessica Zhang <jesszhan@codeaurora.org>
Date:   Wed Oct 20 10:57:33 2021 -0700

    drm/msm: Fix potential NULL dereference in DPU SSPP
    
    [ Upstream commit 8bf71a5719b6cc5b6ba358096081e5d50ea23ab6 ]
    
    Move initialization of sblk in _sspp_subblk_offset() after NULL check to
    avoid potential NULL pointer dereference.
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org>
    Link: https://lore.kernel.org/r/20211020175733.3379-1-jesszhan@codeaurora.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 907d34b74c6456d76db3f623824dc1261fe57aef
Author: Joerg Roedel <jroedel@suse.de>
Date:   Thu Oct 21 10:08:32 2021 +0200

    x86/sev: Fix stack type check in vc_switch_off_ist()
    
    [ Upstream commit 5681981fb788281b09a4ea14d310d30b2bd89132 ]
    
    The value of STACK_TYPE_EXCEPTION_LAST points to the last _valid_
    exception stack. Reflect that in the check done in the
    vc_switch_off_ist() function.
    
    Fixes: a13644f3a53de ("x86/entry/64: Add entry code for #VC handler")
    Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20211021080833.30875-2-joro@8bytes.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3dd4b42d95a0692c85ebd5da635bae62fa6c9d83
Author: Kees Cook <keescook@chromium.org>
Date:   Sat Aug 28 10:57:47 2021 -0700

    clocksource/drivers/timer-ti-dm: Select TIMER_OF
    
    [ Upstream commit eda9a4f7af6ee47e9e131f20e4f8a41a97379293 ]
    
    When building OMAP_DM_TIMER without TIMER_OF, there are orphan sections
    due to the use of TIMER_OF_DELCARE() without CONFIG_TIMER_OF. Select
    CONFIG_TIMER_OF when enaling OMAP_DM_TIMER:
    
    arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section `__timer_of_table'
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/lkml/202108282255.tkdt4ani-lkp@intel.com/
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Keerthy <j-keerthy@ti.com>
    Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
    Cc: Ladislav Michl <ladis@linux-mips.org>
    Cc: Grygorii Strashko <grygorii.strashko@ti.com>
    Cc: linux-omap@vger.kernel.org
    Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210828175747.3777891-1-keescook@chromium.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f74e6d5161ea9d8189535a45144615c1e48cb61
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Thu Oct 7 21:13:37 2021 +0200

    PM: hibernate: fix sparse warnings
    
    [ Upstream commit 01de5fcd8b1ac0ca28d2bb0921226a54fdd62684 ]
    
    When building the kernel with sparse enabled 'C=1' the following
    warnings shows up:
    
    kernel/power/swap.c:390:29: warning: incorrect type in assignment (different base types)
    kernel/power/swap.c:390:29:    expected int ret
    kernel/power/swap.c:390:29:    got restricted blk_status_t
    
    This is due to function hib_wait_io() returns a 'blk_status_t' which is
    a bitwise u8. Commit 5416da01ff6e ("PM: hibernate: Remove
    blk_status_to_errno in hib_wait_io") seemed to have mixed up the return
    type. However, the 4e4cbee93d56 ("block: switch bios to blk_status_t")
    actually broke the behaviour by returning the wrong type.
    
    Rework so function hib_wait_io() returns a 'int' instead of
    'blk_status_t' and make sure to call function
    blk_status_to_errno(hb->error)' when returning from function
    hib_wait_io() a int gets returned.
    
    Fixes: 4e4cbee93d56 ("block: switch bios to blk_status_t")
    Fixes: 5416da01ff6e ("PM: hibernate: Remove blk_status_to_errno in hib_wait_io")
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff950ae83201efeafdd440eac798201fd7e3f8cb
Author: Max Gurtovoy <mgurtovoy@nvidia.com>
Date:   Sun Oct 17 11:58:16 2021 +0300

    nvme-rdma: fix error code in nvme_rdma_setup_ctrl
    
    [ Upstream commit 09748122009aed7bfaa7acc33c10c083a4758322 ]
    
    In case that icdoff is not zero or mandatory keyed sgls are not
    supported by the NVMe/RDMA target, we'll go to error flow but we'll
    return 0 to the caller. Fix it by returning an appropriate error code.
    
    Fixes: c66e2998c8ca ("nvme-rdma: centralize controller setup sequence")
    Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2cf0bed6817e283ec1708bc2ca3bb5d8b9f0f4f
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed Oct 20 15:39:59 2021 +0800

    nbd: Fix use-after-free in pid_show
    
    [ Upstream commit 0c98057be9efa32de78dbc4685fc73da9d71faa1 ]
    
    I got issue as follows:
    [  263.886511] BUG: KASAN: use-after-free in pid_show+0x11f/0x13f
    [  263.888359] Read of size 4 at addr ffff8880bf0648c0 by task cat/746
    [  263.890479] CPU: 0 PID: 746 Comm: cat Not tainted 4.19.90-dirty #140
    [  263.893162] Call Trace:
    [  263.893509]  dump_stack+0x108/0x15f
    [  263.893999]  print_address_description+0xa5/0x372
    [  263.894641]  kasan_report.cold+0x236/0x2a8
    [  263.895696]  __asan_report_load4_noabort+0x25/0x30
    [  263.896365]  pid_show+0x11f/0x13f
    [  263.897422]  dev_attr_show+0x48/0x90
    [  263.898361]  sysfs_kf_seq_show+0x24d/0x4b0
    [  263.899479]  kernfs_seq_show+0x14e/0x1b0
    [  263.900029]  seq_read+0x43f/0x1150
    [  263.900499]  kernfs_fop_read+0xc7/0x5a0
    [  263.903764]  vfs_read+0x113/0x350
    [  263.904231]  ksys_read+0x103/0x270
    [  263.905230]  __x64_sys_read+0x77/0xc0
    [  263.906284]  do_syscall_64+0x106/0x360
    [  263.906797]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reproduce this issue as follows:
    1. nbd-server 8000 /tmp/disk
    2. nbd-client localhost 8000 /dev/nbd1
    3. cat /sys/block/nbd1/pid
    Then trigger use-after-free in pid_show.
    
    Reason is after do step '2', nbd-client progress is already exit. So
    it's task_struct already freed.
    To solve this issue, revert part of 6521d39a64b3's modify and remove
    useless 'recv_task' member of nbd_device.
    
    Fixes: 6521d39a64b3 ("nbd: Remove variable 'pid'")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20211020073959.2679255-1-yebin10@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0fd4b3aeea6caab8de8f6ce5b6f0e2c01aff41f
Author: Stefan Agner <stefan@agner.ch>
Date:   Tue Oct 19 21:16:47 2021 +0200

    phy: micrel: ksz8041nl: do not use power down mode
    
    [ Upstream commit 2641b62d2fab52648e34cdc6994b2eacde2d27c1 ]
    
    Some Micrel KSZ8041NL PHY chips exhibit continuous RX errors after using
    the power down mode bit (0.11). If the PHY is taken out of power down
    mode in a certain temperature range, the PHY enters a weird state which
    leads to continuously reporting RX errors. In that state, the MAC is not
    able to receive or send any Ethernet frames and the activity LED is
    constantly blinking. Since Linux is using the suspend callback when the
    interface is taken down, ending up in that state can easily happen
    during a normal startup.
    
    Micrel confirmed the issue in errata DS80000700A [*], caused by abnormal
    clock recovery when using power down mode. Even the latest revision (A4,
    Revision ID 0x1513) seems to suffer that problem, and according to the
    errata is not going to be fixed.
    
    Remove the suspend/resume callback to avoid using the power down mode
    completely.
    
    [*] https://ww1.microchip.com/downloads/en/DeviceDoc/80000700A.pdf
    
    Fixes: 1a5465f5d6a2 ("phy/micrel: Add suspend/resume support to Micrel PHYs")
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89249cd9fa1f009ba6311e232fac1b8b5a19fd9f
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Tue Oct 19 12:19:50 2021 -0600

    net: enetc: unmap DMA in enetc_send_cmd()
    
    [ Upstream commit cd4bc63de774eee95e9bac26a565cd80e0fca421 ]
    
    Coverity complains of a possible dereference of a null return value.
    
            5. returned_null: kzalloc returns NULL. [show details]
            6. var_assigned: Assigning: si_data = NULL return value from kzalloc.
    488        si_data = kzalloc(data_size, __GFP_DMA | GFP_KERNEL);
    489        cbd.length = cpu_to_le16(data_size);
    490
    491        dma = dma_map_single(&priv->si->pdev->dev, si_data,
    492                             data_size, DMA_FROM_DEVICE);
    
    While this kzalloc() is unlikely to fail, I did notice that the function
    returned without unmapping si_data.
    
    Fix this by refactoring the error paths and checking for kzalloc()
    failure.
    
    Fixes: 888ae5a3952ba ("net: enetc: add tc flower psfp offload driver")
    Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org (open list)
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 493a9e6367a1ca1c0ddd5d8b35a5089d6908e803
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Oct 16 11:43:58 2021 +0300

    iwlwifi: pnvm: read EFI data only if long enough
    
    [ Upstream commit e864a77f51d0d8113b49cf7d030bc9dc911c8176 ]
    
    If the data we get from EFI is not even long enough for
    the package struct we expect then ignore it entirely.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Fixes: a1a6a4cf49ec ("iwlwifi: pnvm: implement reading PNVM from UEFI")
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20211016114029.33feba783518.I54a5cf33975d0330792b3d208b225d479e168f32@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0b49d055533682b8efd93a673b24f1a6fb69588
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Oct 16 11:43:57 2021 +0300

    iwlwifi: pnvm: don't kmemdup() more than we have
    
    [ Upstream commit 0f892441d8c353144e3669b7991fa5fe0bd353e9 ]
    
    We shouldn't kmemdup() more data than we have, that might
    cause the code to crash. Fix that by updating the length
    before the kmemdup.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ab0e64c3fba9.Ic6a3295fc384750b51b4270bf0b7d94984a139f2@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2fd84b3674862cca60e5a6fcdaf6bdea1e5f755
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Oct 16 11:43:55 2021 +0300

    iwlwifi: mvm: reset PM state on unsuccessful resume
    
    [ Upstream commit 2f629a7772e2a7bdaff25178917a40073f79702c ]
    
    If resume fails for some reason, we need to set the PM state
    back to normal so we're able to send commands during firmware
    reset, rather than failing all of them because we're in D3.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Fixes: 708a39aaca22 ("iwlwifi: mvm: don't send commands during suspend\resume transition")
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20211016114029.7ceb9eaca9f6.If0cbef38c6d07ec1ddce125878a4bdadcb35d2c9@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89f000f4c9e05867b68e7a50a20494054d8bb330
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Sat Oct 16 17:32:43 2021 +0200

    mwifiex: Send DELBA requests according to spec
    
    [ Upstream commit cc8a8bc37466f79b24d972555237f3d591150602 ]
    
    While looking at on-air packets using Wireshark, I noticed we're never
    setting the initiator bit when sending DELBA requests to the AP: While
    we set the bit on our del_ba_param_set bitmask, we forget to actually
    copy that bitmask over to the command struct, which means we never
    actually set the initiator bit.
    
    Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command
    struct.
    
    Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Acked-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5b21a4c096da165353b88feae274ce991184605
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Fri Oct 15 12:03:35 2021 +0800

    rsi: stop thread firstly in rsi_91x_init() error handling
    
    [ Upstream commit 515e7184bdf0a3ebf1757cc77fb046b4fe282189 ]
    
    When fail to init coex module, free 'common' and 'adapter' directly, but
    common->tx_thread which will access 'common' and 'adapter' is running at
    the same time. That will trigger the UAF bug.
    
    ==================================================================
    BUG: KASAN: use-after-free in rsi_tx_scheduler_thread+0x50f/0x520 [rsi_91x]
    Read of size 8 at addr ffff8880076dc000 by task Tx-Thread/124777
    CPU: 0 PID: 124777 Comm: Tx-Thread Not tainted 5.15.0-rc5+ #19
    Call Trace:
     dump_stack_lvl+0xe2/0x152
     print_address_description.constprop.0+0x21/0x140
     ? rsi_tx_scheduler_thread+0x50f/0x520
     kasan_report.cold+0x7f/0x11b
     ? rsi_tx_scheduler_thread+0x50f/0x520
     rsi_tx_scheduler_thread+0x50f/0x520
    ...
    
    Freed by task 111873:
     kasan_save_stack+0x1b/0x40
     kasan_set_track+0x1c/0x30
     kasan_set_free_info+0x20/0x30
     __kasan_slab_free+0x109/0x140
     kfree+0x117/0x4c0
     rsi_91x_init+0x741/0x8a0 [rsi_91x]
     rsi_probe+0x9f/0x1750 [rsi_usb]
    
    Stop thread before free 'common' and 'adapter' to fix it.
    
    Fixes: 2108df3c4b18 ("rsi: add coex support")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211015040335.1021546-1-william.xuanziyang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec280de6f40916e90aff93232a135fe76ed317c7
Author: Shayne Chen <shayne.chen@mediatek.com>
Date:   Mon Oct 18 16:07:04 2021 +0800

    mt76: mt7915: fix muar_idx in mt7915_mcu_alloc_sta_req()
    
    [ Upstream commit 161cc13912d3c3e8857001988dfba39be842454a ]
    
    For broadcast/multicast wcid, the muar_idx should be 0xe.
    
    Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4ab42fbe70da7673fdbf24471c0c87f62c53e57
Author: Shayne Chen <shayne.chen@mediatek.com>
Date:   Mon Oct 18 16:07:02 2021 +0800

    mt76: mt7915: fix sta_rec_wtbl tag len
    
    [ Upstream commit afa0370f3a3a64af6d368da0bedd72ab2a026cd0 ]
    
    Fix tag len error for sta_rec_wtbl, which causes fw parsing error for
    the tags placed behind it.
    
    Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 439393358568aacd090c578b89936a4becba5000
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Thu Oct 14 17:19:53 2021 +0200

    mt76: connac: fix possible NULL pointer dereference in mt76_connac_get_phy_mode_v2
    
    [ Upstream commit b5f2ba8a4c794e8349c0e30036352b9f685164c4 ]
    
    Fix the following NULL pointer dereference in mt76_connac_get_phy_mode_v2
    routine triggered on mt7663s device when sta is NULL
    
    [    5.490700] mt7663s mmc0:0001:1: N9 Firmware Version: 3.1.1, Build Time: 20200604161656
    [    5.490815] mt7663s mmc0:0001:1: Region number: 0x4
    [    5.490868] mt7663s mmc0:0001:1: Parsing tailer Region: 0
    [    5.496251] mt7663s mmc0:0001:1: Region 0, override_addr = 0x00118000
    [    5.496419] mt7663s mmc0:0001:1: Parsing tailer Region: 1
    [    5.624027] mt7663s mmc0:0001:1: Parsing tailer Region: 2
    [    5.656999] mt7663s mmc0:0001:1: Parsing tailer Region: 3
    [    5.671876] mt7663s mmc0:0001:1: override_addr = 0x00118000, option = 3
    [    9.358658] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [    9.358775] #PF: supervisor read access in kernel mode
    [    9.358831] #PF: error_code(0x0000) - not-present page
    [    9.358886] PGD 0 P4D 0
    [    9.358917] Oops: 0000 [#1] SMP
    [    9.358960] CPU: 0 PID: 235 Comm: NetworkManager Not tainted 5.15.0-rc4-kvm-02151-g39e333d657f4-dirty #769
    [    9.359057] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014
    [    9.359150] RIP: 0010:mt76_connac_get_phy_mode_v2+0xc9/0x11c
    [    9.359473] RAX: 0000000000000013 RBX: 0000000000000000 RCX: 0000000000000027
    [    9.359546] RDX: ffff8881f9c17358 RSI: 0000000000000001 RDI: ffff8881f9c17350
    [    9.359624] RBP: ffff88810bac1ed4 R08: ffffffff822a4a48 R09: 0000000000000003
    [    9.359697] R10: ffffffff82234a60 R11: ffffffff82234a60 R12: ffff88810bac1eec
    [    9.359779] R13: 0000000000000000 R14: ffff88810bad1648 R15: ffff88810bac1eb8
    [    9.359859] FS:  00007f5f1e45bbc0(0000) GS:ffff8881f9c00000(0000) knlGS:0000000000000000
    [    9.359939] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    9.360003] CR2: 0000000000000000 CR3: 0000000105d5d000 CR4: 00000000000006b0
    [    9.360083] Call Trace:
    [    9.360116]  mt76_connac_mcu_uni_add_bss.cold+0x21/0x250
    [    9.360175]  ? schedule_preempt_disabled+0xa/0x10
    [    9.360232]  ? __mutex_lock.constprop.0+0x2ab/0x460
    [    9.360286]  mt7615_remove_interface+0x63/0x1d0
    [    9.360342]  drv_remove_interface+0x32/0xe0
    [    9.360385]  ieee80211_do_stop+0x5da/0x800
    [    9.360428]  ? dev_reset_queue+0x30/0x90
    [    9.360472]  ieee80211_stop+0x3b/0xb0
    [    9.360516]  __dev_close_many+0x7a/0xd0
    [    9.360559]  __dev_change_flags+0xd6/0x1f0
    [    9.360604]  dev_change_flags+0x21/0x60
    [    9.360648]  do_setlink+0x259/0xfb0
    [    9.360686]  ? __nla_validate_parse+0x51/0xb80
    [    9.360742]  __rtnl_newlink+0x5b3/0x960
    [    9.360785]  ? inet6_fill_ifla6_attrs+0x41d/0x470
    [    9.360841]  ? __kmalloc_track_caller+0x57/0x3c0
    [    9.360905]  ? netlink_trim+0x8a/0xb0
    [    9.360949]  ? skb_queue_tail+0x1b/0x50
    
    Fixes: 67aa27431c7f8 ("mt76: mt7921: rely on mt76_connac_mcu common library")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f71b42e27e1239d749e23297ec65fa5eb3872cc
Author: Ryder Lee <ryder.lee@mediatek.com>
Date:   Mon Sep 27 12:59:49 2021 +0800

    mt76: mt7615: fix monitor mode tear down crash
    
    [ Upstream commit a6fdbdd1ac2996a58a84672ef37efb5cbb98fadf ]
    
    [  103.451600] CPU 3 Unable to handle kernel paging request at virtual address 00000003, epc == 8576591c, ra == 857659f0
    [  103.462226] Oops[#1]:
    [  103.464499] CPU: 3 PID: 9247 Comm: ifconfig Tainted: G        W         5.4.143 #0
    [  103.472031] $ 0   : 00000000 00000001 83be3854 00000000
    [  103.477239] $ 4   : 8102a374 8102a374 8102f0b0 00000200
    [  103.482444] $ 8   : 0000002d 000001e4 64373765 5d206337
    [  103.487647] $12   : 00000000 00000005 00000000 0006d1df
    [  103.492853] $16   : 83be3848 853838a8 8743d600 00010000
    [  103.498059] $20   : 00000000 00000000 8553dec0 0000007f
    [  103.503266] $24   : 00000003 80382084
    [  103.508472] $28   : 831d4000 831d5bc0 00000001 857659f0
    [  103.513678] Hi    : 00000122
    [  103.516543] Lo    : d1768000
    [  103.519452] epc   : 8576591c mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common]
    [  103.526306] ra    : 857659f0 mt7615_mcu_add_bss+0x1a4/0x3c0 [mt7615_common]
    [  103.533232] Status: 11007c03 KERNEL EXL IE
    [  103.537402] Cause : 40800008 (ExcCode 02)
    [  103.541389] BadVA : 00000003
    [  103.544253] PrId  : 0001992f (MIPS 1004Kc)
    [  103.797086] Call Trace:
    [  103.799562] [<8576591c>] mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common]
    [  103.806082] [<85760a14>] mt7615_remove_interface+0x74/0x1e0 [mt7615_common]
    [  103.813280] [<85603fcc>] drv_remove_interface+0x2c/0xa0 [mac80211]
    [  103.819612] [<8561a8e4>] ieee80211_del_virtual_monitor.part.22+0x74/0xe8 [mac80211]
    [  103.827410] [<8561b7f0>] ieee80211_do_stop+0x4a4/0x8a0 [mac80211]
    [  103.833671] [<8561bc00>] ieee80211_stop+0x14/0x24 [mac80211]
    [  103.839405] [<8045a328>] __dev_close_many+0x9c/0x10c
    [  103.844364] [<80463de4>] __dev_change_flags+0x16c/0x1e4
    [  103.849569] [<80463e84>] dev_change_flags+0x28/0x70
    [  103.854440] [<80521e54>] devinet_ioctl+0x280/0x774
    [  103.859222] [<80526248>] inet_ioctl+0xa4/0x1c8
    [  103.863674] [<80436830>] sock_ioctl+0x2d8/0x4bc
    [  103.868201] [<801adbb4>] do_vfs_ioctl+0xb8/0x7c0
    [  103.872804] [<801ae30c>] ksys_ioctl+0x50/0xb4
    [  103.877156] [<80014598>] syscall_common+0x34/0x58
    
    Fixes: 04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
    Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68acaaf117a9976fedbf13e00f39d7503df09b12
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Tue Sep 14 23:50:22 2021 +0800

    mt76: mt7921: fix retrying release semaphore without end
    
    [ Upstream commit 02d1c7d494d8052288bc175e4ff54b56d08a3c5f ]
    
    We should pass the error code to the caller immediately
    to avoid the possible infinite retry to release the semaphore.
    
    Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support")
    Co-developed-by: YN Chen <YN.Chen@mediatek.com>
    Signed-off-by: YN Chen <YN.Chen@mediatek.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a881727bb3b0d30435e8882658626ea5ebaf46a
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Tue Sep 14 18:42:51 2021 +0200

    mt76: mt7915: fix possible infinite loop release semaphore
    
    [ Upstream commit e500c9470e26be66eb2bc6de773ae9091149118a ]
    
    Fix possible infinite loop in mt7915_load_patch if
    mt7915_mcu_patch_sem_ctrl always returns an error.
    
    Fixes: e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dba165e255dbf76f9283f5b2b69f466e33a95b9e
Author: Ryder Lee <ryder.lee@mediatek.com>
Date:   Thu Sep 2 13:52:04 2021 +0800

    mt76: mt7615: fix hwmon temp sensor mem use-after-free
    
    [ Upstream commit 0bb4e9187ea4a59dc6658a62978deda0c0dc4b28 ]
    
    Without this change, garbage is seen in the hwmon name and sensors output
    for mt7615 is garbled.
    
    Fixes: 109e505ad944 ("mt76: mt7615: add thermal sensor device support")
    Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32ec365cdca6357dc30620565531ed7f3933bfa1
Author: Ben Greear <greearb@candelatech.com>
Date:   Thu Sep 2 13:52:03 2021 +0800

    mt76: mt7915: fix hwmon temp sensor mem use-after-free
    
    [ Upstream commit 0ae3ff5684514d72357240f1033a7494c51f93ed ]
    
    Without this change, garbage is seen in the hwmon name and sensors output
    for mt7915 is garbled. It appears that the hwmon logic does not make a
    copy of the incoming string, but instead just copies a char* and expects
    it to never go away.
    
    Fixes: 33fe9c639c13 ("mt76: mt7915: add thermal sensor device support")
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c9e98bca4a5aa4119231e3a7fa7154179518cbe
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Wed Aug 18 10:20:57 2021 +0200

    mt76: mt7921: always wake device if necessary in debugfs
    
    [ Upstream commit 569008744178b672ea3ad9047fa3098f1b73ca55 ]
    
    Add missing device wakeup in debugfs code if we are accessing chip
    registers.
    
    Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ed4d081f2eb1b91acf9b3ce6794188111d45be8
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Sat Aug 14 02:09:18 2021 +0800

    mt76: mt7921: fix kernel warning from cfg80211_calculate_bitrate
    
    [ Upstream commit 8e695328a1006b7bab2d972e7d0111fa6e6faf51 ]
    
    Fix the kernel warning from cfg80211_calculate_bitrate
    due to the legacy rate is not parsed well in the current driver.
    
    Also, zeros struct rate_info before we fill it out to avoid the old value
    is kept such as rate->legacy.
    
    [  790.921560] WARNING: CPU: 7 PID: 970 at net/wireless/util.c:1298 cfg80211_calculate_bitrate+0x354/0x35c [cfg80211]
    [  790.987738] Hardware name: MediaTek Asurada rev1 board (DT)
    [  790.993298] pstate: a0400009 (NzCv daif +PAN -UAO)
    [  790.998104] pc : cfg80211_calculate_bitrate+0x354/0x35c [cfg80211]
    [  791.004295] lr : cfg80211_calculate_bitrate+0x180/0x35c [cfg80211]
    [  791.010462] sp : ffffffc0129c3880
    [  791.013765] x29: ffffffc0129c3880 x28: ffffffd38305bea8
    [  791.019065] x27: ffffffc0129c3970 x26: 0000000000000013
    [  791.024364] x25: 00000000000003ca x24: 000000000000002f
    [  791.029664] x23: 00000000000000d0 x22: ffffff8d108bc000
    [  791.034964] x21: ffffff8d108bc0d0 x20: ffffffc0129c39a8
    [  791.040264] x19: ffffffc0129c39a8 x18: 00000000ffff0a10
    [  791.045563] x17: 0000000000000050 x16: 00000000000000ec
    [  791.050910] x15: ffffffd3f9ebed9c x14: 0000000000000006
    [  791.056211] x13: 00000000000b2eea x12: 0000000000000000
    [  791.061511] x11: 00000000ffffffff x10: 0000000000000000
    [  791.066811] x9 : 0000000000000000 x8 : 0000000000000000
    [  791.072110] x7 : 0000000000000000 x6 : ffffffd3fafa5a7b
    [  791.077409] x5 : 0000000000000000 x4 : 0000000000000000
    [  791.082708] x3 : 0000000000000000 x2 : 0000000000000000
    [  791.088008] x1 : ffffff8d3f79c918 x0 : 0000000000000000
    [  791.093308] Call trace:
    [  791.095770]  cfg80211_calculate_bitrate+0x354/0x35c [cfg80211]
    [  791.101615]  nl80211_put_sta_rate+0x6c/0x2c0 [cfg80211]
    [  791.106853]  nl80211_send_station+0x980/0xaa4 [cfg80211]
    [  791.112178]  nl80211_get_station+0xb4/0x134 [cfg80211]
    [  791.117308]  genl_rcv_msg+0x3a0/0x440
    [  791.120960]  netlink_rcv_skb+0xcc/0x118
    [  791.124785]  genl_rcv+0x34/0x48
    [  791.127916]  netlink_unicast+0x144/0x1dc
    
    Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support")
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22f41d4f2e36ae9ad932c7ce7da2d8bfc4eb4f0d
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Wed Aug 11 13:58:24 2021 +0800

    mt76: mt7921: fix firmware usage of RA info using legacy rates
    
    [ Upstream commit 99b8e195994d9d77de3bfe0cb403c44a57c2cf79 ]
    
    According to the firmware usage, OFDM rates should fill out bit 6 - 13
    while CCK rates should fill out bit 0 - 3 in legacy field of RA info to
    make the rate adaption runs propertly. Otherwise, a unicast frame might be
    picking up the unsupported rate to send out.
    
    Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support")
    Reported-by: Joshua Emele <jemele@chromium.org>
    Co-developed-by: YN Chen <YN.Chen@mediatek.com>
    Signed-off-by: YN Chen <YN.Chen@mediatek.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90ecf88cc293e98782dc40776ef515df282d779a
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Fri Aug 13 06:48:24 2021 +0800

    mt76: mt7921: report HE MU radiotap
    
    [ Upstream commit 4fee32153ab62356aeea9d152d8f33a5fd3a0086 ]
    
    Report HE MU/BF radiotap.
    
    That fixed HE MU packets dropped by mac80211 because they are missing the
    ieee80211_radiotap_he_mu header.
    
    Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support")
    Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
    Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
    Co-developed-by: Eric-SY Chang <Eric-SY.Chang@mediatek.com>
    Signed-off-by: Eric-SY Chang <Eric-SY.Chang@mediatek.com>
    Tested-by: Eric-SY Chang <Eric-SY.Chang@mediatek.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf5b9c9df69c634623568583d81b74b5b6173268
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sun Aug 8 21:11:49 2021 +0200

    mt76: overwrite default reg_ops if necessary
    
    [ Upstream commit f6e1f59885dae5a2553f8bbd328be2cb1c80ccb2 ]
    
    Introduce mt76_register_debugfs_fops routine in order to
    define per-driver regs file operations and make sure the
    device is up before reading or writing its registers
    
    Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support")
    Fixes: de5ff3c9d1a2 ("mt76: mt7615: introduce pm_power_save delayed work")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30dc676d4b0203a72cbebaecc7c0634a06ffd304
Author: Leon Yen <Leon.Yen@mediatek.com>
Date:   Wed Jul 28 06:59:16 2021 +0800

    mt76: connac: fix GTK rekey offload failure on WPA mixed mode
    
    [ Upstream commit 781f62960c635cfed55a8f8c0f909bdaf8268257 ]
    
    Update the proper firmware programming sequence to fix GTK rekey
    offload failure on WPA mixed mode.
    
    In the mt76_connac_mcu_key_iter,
    gtk_tlv->proto should be only set up on pairwise key
    and gtk_tlk->group_cipher should be only set up on the group key.
    
    Otherwise, those parameters required by firmware would be set
    incorrectly to cause GTK rekey offload failure on WPA mixed mode
    and then disconnection follows.
    
    Fixes: b47e21e75c80 ("mt76: mt7615: add gtk rekey offload support")
    Co-developed-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Leon Yen <Leon.Yen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8c0958687c7ab9fdbb96d31f32b254fcf9b2d06
Author: Deren Wu <deren.wu@mediatek.com>
Date:   Tue Jul 27 17:47:09 2021 +0800

    mt76: mt7921: fix dma hang in rmmod
    
    [ Upstream commit a23f80aa9c5e6ad4ec8df88037b7ffd4162b1ec4 ]
    
    The dma would be broken after rmmod flow. There are two different
    cases causing this issue.
    1. dma access without privilege.
    2. hw access sequence borken by another context.
    
    This patch handle both cases to avoid hw crash.
    
    Fixes: 2b9ea5a8cf1bd ("mt76: mt7921: add mt7921_dma_cleanup in mt7921_unregister_device")
    Signed-off-by: Deren Wu <deren.wu@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bfda0a8dc7770bffc2d77b4dfb386b4086f9ccf
Author: Shayne Chen <shayne.chen@mediatek.com>
Date:   Tue Jul 20 21:00:14 2021 +0800

    mt76: mt7915: fix bit fields for HT rate idx
    
    [ Upstream commit 47f1c08db7f3aaa2d13f8e56209375462ace7b8a ]
    
    The bit fields of tx rate idx should be 6 bits, otherwise it might be
    incorrect in HT mode.
    For VHT/HE rates, only 4 bits are actually used by rate idx, the other
    2 bits are used for other functions.
    
    Fixes: c31d94af1843 ("mt76: mt7915: fix tx rate related fields in tx descriptor")
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02c474990173a78c05dbc7ffe1cd2d0b771023b1
Author: Shayne Chen <shayne.chen@mediatek.com>
Date:   Tue Jul 20 10:48:32 2021 +0800

    mt76: mt7915: fix potential overflow of eeprom page index
    
    [ Upstream commit 82a980f82a511ce74ab57eb9f692d02225eb32f4 ]
    
    If total eeprom size is divisible by per-page size, the i in for loop
    will exceed max page index, which happens in our newer chipset.
    
    Fixes: 26f18380e6ca ("mt76: mt7915: add support for flash mode")
    Signed-off-by: Bo Jiao <bo.jiao@mediatek.com>
    Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f2d2c8d930749265a0d6e1eff41e3f21c877869
Author: Deren Wu <deren.wu@mediatek.com>
Date:   Wed Jul 14 23:50:52 2021 +0800

    mt76: mt7921: Fix out of order process by invalid event pkt
    
    [ Upstream commit cd3f387371e941e6806b455b4ba5b9f4ca4b77c6 ]
    
    The acceptable event report should inlcude original CMD-ID. Otherwise,
    drop unexpected result from fw.
    
    Fixes: 1c099ab44727c ("mt76: mt7921: add MCU support")
    Signed-off-by: Jimmy Hu <Jimmy.Hu@mediatek.com>
    Signed-off-by: Deren Wu <deren.wu@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75ed8ca355fb4146fb41d75ad44e83a71d4d8cb3
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Tue Jun 22 09:48:30 2021 +0200

    mt76: mt76x02: fix endianness warnings in mt76x02_mac.c
    
    [ Upstream commit c33edef520213feccebc22c9474c685b9fb60611 ]
    
    Fix the following sparse warning in mt76x02_mac_write_txwi and
    mt76x02_mac_tx_rate_val routines:
    drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:237:19:
            warning: restricted __le16 degrades to intege
            warning: cast from restricted __le16
    drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:383:28:
            warning: incorrect type in assignment (different base types)
            expected restricted __le16 [usertype] rate
            got unsigned long
    
    Fixes: db9f11d3433f7 ("mt76: store wcid tx rate info in one u32 reduce locking")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fcee803e24833a332cc25b37275d78ff32a104f
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Wed Jun 23 15:19:19 2021 +0200

    mt76: mt7921: fix survey-dump reporting
    
    [ Upstream commit 64ed76d118c656907ec1155f2cdd24de778470a2 ]
    
    Fix MIB tx-rx MIB counters for survey-dump reporting.
    
    Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7afd7a5e68d7e45dccc746366801a0ae7717c27
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Sun Jun 20 15:48:07 2021 +0800

    mt76: fix build error implicit enumeration conversion
    
    [ Upstream commit adedbc643f02f5a3193b8dcc5cfca97b4c988667 ]
    
    drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:114:10: error: implicit
    conversion from enumeration type 'enum mt76_cipher_type' to different
    enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion]
                    return MT_CIPHER_NONE;
                    ~~~~~~ ^~~~~~~~~~~~~~
    
    drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:114:10: error: implicit
    conversion from enumeration type 'enum mt76_cipher_type' to different
    enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion]
                    return MT_CIPHER_NONE;
                    ~~~~~~ ^~~~~~~~~~~~~~
    
    Fixes: c368362c36d3 ("mt76: fix iv and CCMP header insertion")
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21255ccf73bb561cd69636893e27e501696bcf1a
Author: Leon Yen <Leon.Yen@mediatek.com>
Date:   Thu Jul 8 12:29:06 2021 +0800

    mt76: connac: fix mt76_connac_gtk_rekey_tlv usage
    
    [ Upstream commit d741abeafa47a7331cd4fe526e44db4ad3da0f62 ]
    
    The mistaken structure is introduced since we added the GTK rekey offload
    to mt7663. The patch fixes mt76_connac_gtk_rekey_tlv structure according
    to the MT7663 and MT7921 firmware we have submitted into
    linux-firmware.git.
    
    Fixes: b47e21e75c80 ("mt76: mt7615: add gtk rekey offload support")
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Leon Yen <Leon.Yen@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95792d2088ea0e73913a05435df648bd5d0918c6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jun 25 17:58:54 2021 +0300

    mt76: mt7915: fix info leak in mt7915_mcu_set_pre_cal()
    
    [ Upstream commit 3924715ffe5e064a85f56490f77b7b2084230800 ]
    
    Zero out all the unused members of "req" so that we don't disclose
    stack information.
    
    Fixes: 495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8dea17cf36fae38822141d308569c2111014b5f4
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Jun 21 23:53:22 2021 +0200

    mt76: mt7615: fix endianness warning in mt7615_mac_write_txwi
    
    [ Upstream commit d81bfb41e30c42531536c5d2baa4d275a8309715 ]
    
    Fix the following sparse warning in mt7615_mac_write_txwi routine:
    drivers/net/wireless/mediatek/mt76/mt7615/mac.c:758:17:
            warning: incorrect type in assignment
            expected restricted __le32 [usertype]
            got unsigned long
    
    Fixes: 04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
    Fixes: d4bf77bd74930 ("mt76: mt7615: introduce mt7663u support to mt7615_write_txwi")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1c7ea995cbf93c32759acfe296fe58b6d7edb44
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Jun 21 11:18:58 2021 +0200

    mt76: mt7921: fix endianness warning in mt7921_update_txs
    
    [ Upstream commit 7fc167bbc9296e6aeaaa4063db3639e8a3db75f6 ]
    
    Fix the following sparse warning in mt7921_update_txs routine:
    drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31:
            warning: cast to restricted __le32
    drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31:
            warning: restricted __le32 degrades to integer
    
    Fixes: e5bca8c5d2cd3 ("mt76: mt7921: improve code readability for mt7921_update_txs")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef02f94e138e2e9c632c8963aee35cc1e8594ce5
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Mon Jun 21 10:21:31 2021 +0200

    mt76: mt7915: fix endianness warning in mt7915_mac_add_txs_skb
    
    [ Upstream commit 08b3c8da87aed4200dab00906f149d675ca90f23 ]
    
    Fix the following sparse warning in mt7915_mac_add_txs_skb routine:
    
    drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:29:
            warning: cast to restricted __le32
    drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:23:
            warning: restricted __le32 degrades to integer
    
    Fixes: 3de4cb1756565 ("mt76: mt7915: add support for tx status reporting")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90d9e4050bc3fa3004c83c2ca06e7a4cc52f68c3
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sat Jun 19 20:18:19 2021 +0200

    mt76: mt7921: fix endianness in mt7921_mcu_tx_done_event
    
    [ Upstream commit df040215c077de0c13aab12c222bd0360a0d3988 ]
    
    Fix endianness in mt7921_mcu_tx_done_event event reported by the
    firmware.
    
    Fixes: 3cce2b98e0241 ("mt76: mt7921: introduce mac tx done handling")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a9bd1b941f4418371ca932cf47f304caca18426
Author: Lang Yu <lang.yu@amd.com>
Date:   Mon Oct 11 13:57:25 2021 +0800

    drm/amdkfd: Fix an inappropriate error handling in allloc memory of gpu
    
    [ Upstream commit 5aeeac6fa38fca450faed9770f75b1470c0e2073 ]
    
    We should unreference a gem object instead of an amdgpu bo here.
    
    Fixes: fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
    
    Signed-off-by: Lang Yu <lang.yu@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b7030b379e44c28cb1b62e6f3aef887228762cf
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Oct 16 12:11:08 2021 +0200

    ACPI: PM: Fix sharing of wakeup power resources
    
    [ Upstream commit a2d7b2e004af6b09f21ac3d10f8f4456c16a8ddf ]
    
    If an ACPI wakeup power resource is shared between multiple devices,
    it may not be managed correctly.
    
    Suppose, for example, that two devices, A and B, share a wakeup power
    resource P whose wakeup_enabled flag is 0 initially.  Next, suppose
    that wakeup power is enabled for A and B, in this order, and disabled
    for B.  When wakeup power is enabled for A, P will be turned on and
    its wakeup_enabled flag will be set.  Next, when wakeup power is
    enabled for B, P will not be touched, because its wakeup_enabled flag
    is set.  Now, when wakeup power is disabled for B, P will be turned
    off which is incorrect, because A will still need P in order to signal
    wakeup.
    
    Moreover, if wakeup power is enabled for A and then disabled for B,
    the latter will cause P to be turned off incorrectly (it will be still
    needed by A), because acpi_disable_wakeup_device_power() is allowed
    to manipulate power resources when the wakeup.prepare_count counter
    of the given device is 0.
    
    While the first issue could be addressed by changing the
    wakeup_enabled power resource flag into a counter, addressing the
    second one requires modifying acpi_disable_wakeup_device_power() to
    do nothing when the target device's wakeup.prepare_count reference
    counter is zero and that would cause the new counter to be redundant.
    Namely, if acpi_disable_wakeup_device_power() is modified as per the
    above, every change of the new counter following a wakeup.prepare_count
    change would be reflected by the analogous change of the main reference
    counter of the given power resource.
    
    Accordingly, modify acpi_disable_wakeup_device_power() to do nothing
    when the target device's wakeup.prepare_count reference counter is
    zero and drop the power resource wakeup_enabled flag altogether.
    
    While at it, ensure that all of the power resources that can be
    turned off will be turned off when disabling device wakeup due to
    a power resource manipulation error, to prevent energy from being
    wasted.
    
    Fixes: b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 453c3013a586ba7c0991c46d5446feb407867d9e
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Oct 15 19:01:28 2021 +0200

    ACPI: PM: Turn off unused wakeup power resources
    
    [ Upstream commit 7a63296d6f579a02b2675b4b0fe5b1cd3235e8d3 ]
    
    If an ACPI power resource is found to be "on" during the
    initialization of the list of wakeup power resources of a device,
    it is reference counted and its wakeup_enabled flag is set, which is
    problematic if the deivce in question is the only user of the given
    power resource, it is never runtime-suspended and it is not allowed
    to wake up the system from sleep, because in that case the given
    power resource will stay "on" until the system reboots and energy
    will be wasted.
    
    It is better to simply turn off wakeup power resources that are "on"
    during the initialization unless their reference counters are not
    zero, because that may be the only opportunity to prevent them from
    staying in the "on" state all the time.
    
    Fixes: b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6500e7148a01763927e346b4e2dc7e969663e45f
Author: Fei Shao <fshao@chromium.org>
Date:   Thu Oct 14 20:03:52 2021 +0800

    mailbox: mtk-cmdq: Fix local clock ID usage
    
    [ Upstream commit 0a5ad4322927ee4aaba6facc0e4faf1ab6c0d48e ]
    
    In the probe function, the clock IDs were pointed to local variables
    which should only be used in the same code block, and any access to them
    after the probing stage becomes an use-after-free case.
    
    Since there are only limited variants of the gce clock names so far, we
    can just declare them as static constants to fix the issue.
    
    Fixes: 85dfdbfc13ea ("mailbox: cmdq: add multi-gce clocks support for mt8195")
    Signed-off-by: Fei Shao <fshao@chromium.org>
    Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac2592454712e075ce58d28086d20aa984b8edb0
Author: Fei Shao <fshao@chromium.org>
Date:   Thu Oct 14 20:03:51 2021 +0800

    mailbox: mtk-cmdq: Validate alias_id on probe
    
    [ Upstream commit 5c154b6a51c2d2d7f266b3ef49b7dd1dc8cb5b65 ]
    
    of_alias_get_id() may return -ENODEV which leads to illegal access to
    the cmdq->clocks array.
    Adding a check over alias_id to prevent the unexpected behavior.
    
    Fixes: 85dfdbfc13ea ("mailbox: cmdq: add multi-gce clocks support for mt8195")
    Signed-off-by: Fei Shao <fshao@chromium.org>
    Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62a0a0539da7d94df256735eab025517fcd5ca67
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Oct 18 11:25:37 2021 -0700

    platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning
    
    [ Upstream commit fd96e35ea7b95f1e216277805be89d66e4ae962d ]
    
    A new warning in clang points out a use of bitwise OR with boolean
    expressions in this driver:
    
    drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
            else if ((strlencmp(cmd, "level disengaged") == 0) |
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                               ||
    drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning
    1 error generated.
    
    This should clearly be a logical OR so change it to fix the warning.
    
    Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1476
    Reported-by: Tor Vic <torvic9@mailbox.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20211018182537.2316800-1-nathan@kernel.org
    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 3e6e11f8537c088ec40e81bd3ce175d89c5ea27d
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Tue Oct 19 11:20:26 2021 +0200

    blk-wbt: prevent NULL pointer dereference in wb_timer_fn
    
    [ Upstream commit 480d42dc001bbfe953825a92073012fcd5a99161 ]
    
    The timer callback used to evaluate if the latency is exceeded can be
    executed after the corresponding disk has been released, causing the
    following NULL pointer dereference:
    
    [ 119.987108] BUG: kernel NULL pointer dereference, address: 0000000000000098
    [ 119.987617] #PF: supervisor read access in kernel mode
    [ 119.987971] #PF: error_code(0x0000) - not-present page
    [ 119.988325] PGD 7c4a4067 P4D 7c4a4067 PUD 7bf63067 PMD 0
    [ 119.988697] Oops: 0000 [#1] SMP NOPTI
    [ 119.988959] CPU: 1 PID: 9353 Comm: cloud-init Not tainted 5.15-rc5+arighi #rc5+arighi
    [ 119.989520] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
    [ 119.990055] RIP: 0010:wb_timer_fn+0x44/0x3c0
    [ 119.990376] Code: 41 8b 9c 24 98 00 00 00 41 8b 94 24 b8 00 00 00 41 8b 84 24 d8 00 00 00 4d 8b 74 24 28 01 d3 01 c3 49 8b 44 24 60 48 8b 40 78 <4c> 8b b8 98 00 00 00 4d 85 f6 0f 84 c4 00 00 00 49 83 7c 24 30 00
    [ 119.991578] RSP: 0000:ffffb5f580957da8 EFLAGS: 00010246
    [ 119.991937] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
    [ 119.992412] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88f476d7f780
    [ 119.992895] RBP: ffffb5f580957dd0 R08: 0000000000000000 R09: 0000000000000000
    [ 119.993371] R10: 0000000000000004 R11: 0000000000000002 R12: ffff88f476c84500
    [ 119.993847] R13: ffff88f4434390c0 R14: 0000000000000000 R15: ffff88f4bdc98c00
    [ 119.994323] FS: 00007fb90bcd9c00(0000) GS:ffff88f4bdc80000(0000) knlGS:0000000000000000
    [ 119.994952] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 119.995380] CR2: 0000000000000098 CR3: 000000007c0d6000 CR4: 00000000000006e0
    [ 119.995906] Call Trace:
    [ 119.996130] ? blk_stat_free_callback_rcu+0x30/0x30
    [ 119.996505] blk_stat_timer_fn+0x138/0x140
    [ 119.996830] call_timer_fn+0x2b/0x100
    [ 119.997136] __run_timers.part.0+0x1d1/0x240
    [ 119.997470] ? kvm_clock_get_cycles+0x11/0x20
    [ 119.997826] ? ktime_get+0x3e/0xa0
    [ 119.998110] ? native_apic_msr_write+0x2c/0x30
    [ 119.998456] ? lapic_next_event+0x20/0x30
    [ 119.998779] ? clockevents_program_event+0x94/0xf0
    [ 119.999150] run_timer_softirq+0x2a/0x50
    [ 119.999465] __do_softirq+0xcb/0x26f
    [ 119.999764] irq_exit_rcu+0x8c/0xb0
    [ 120.000057] sysvec_apic_timer_interrupt+0x43/0x90
    [ 120.000429] ? asm_sysvec_apic_timer_interrupt+0xa/0x20
    [ 120.000836] asm_sysvec_apic_timer_interrupt+0x12/0x20
    
    In this case simply return from the timer callback (no action
    required) to prevent the NULL pointer dereference.
    
    BugLink: https://bugs.launchpad.net/bugs/1947557
    Link: https://lore.kernel.org/linux-mm/YWRNVTk9N8K0RMst@arighi-desktop/
    Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting")
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Link: https://lore.kernel.org/r/YW6N2qXpBU3oc50q@arighi-desktop
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 456b47cacdc72d31e32b3e7aa5e5f24a611608e5
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Tue Oct 19 19:13:21 2021 +1300

    block: ataflop: fix breakage introduced at blk-mq refactoring
    
    [ Upstream commit 86d46fdaa12ae5befc16b8d73fc85a3ca0399ea6 ]
    
    Refactoring of the Atari floppy driver when converting to blk-mq
    has broken the state machine in not-so-subtle ways:
    
    finish_fdc() must be called when operations on the floppy device
    have completed. This is crucial in order to relase the ST-DMA
    lock, which protects against concurrent access to the ST-DMA
    controller by other drivers (some DMA related, most just related
    to device register access - broken beyond compare, I know).
    
    When rewriting the driver's old do_request() function, the fact
    that finish_fdc() was called only when all queued requests had
    completed appears to have been overlooked. Instead, the new
    request function calls finish_fdc() immediately after the last
    request has been queued. finish_fdc() executes a dummy seek after
    most requests, and this overwrites the state machine's interrupt
    hander that was set up to wait for completion of the read/write
    request just prior. To make matters worse, finish_fdc() is called
    before device interrupts are re-enabled, making certain that the
    read/write interupt is missed.
    
    Shifting the finish_fdc() call into the read/write request
    completion handler ensures the driver waits for the request to
    actually complete. With a queue depth of 2, we won't see long
    request sequences, so calling finish_fdc() unconditionally just
    adds a little overhead for the dummy seeks, and keeps the code
    simple.
    
    While we're at it, kill ataflop_commit_rqs() which does nothing
    but run finish_fdc() unconditionally, again likely wiping out an
    in-flight request.
    
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Fixes: 6ec3938cff95 ("ataflop: convert to blk-mq")
    CC: linux-block@vger.kernel.org
    CC: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Link: https://lore.kernel.org/r/20211019061321.26425-1-schmitzmic@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4eac23d60cbc105b5991e4341d09d165c21145f8
Author: Bixuan Cui <cuibixuan@huawei.com>
Date:   Sat Sep 11 16:58:47 2021 +0800

    io-wq: Remove duplicate code in io_workqueue_create()
    
    [ Upstream commit 71e1cef2d794338cc7b979d4c6144e1dc12718b5 ]
    
    While task_work_add() in io_workqueue_create() is true,
    then duplicate code is executed:
    
      -> clear_bit_unlock(0, &worker->create_state);
      -> io_worker_release(worker);
      -> atomic_dec(&acct->nr_running);
      -> io_worker_ref_put(wq);
      -> return false;
    
      -> clear_bit_unlock(0, &worker->create_state); // back to io_workqueue_create()
      -> io_worker_release(worker);
      -> kfree(worker);
    
    The io_worker_release() and clear_bit_unlock() are executed twice.
    
    Fixes: 3146cba99aa2 ("io-wq: make worker creation resilient against signals")
    Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
    Link: https://lore.kernel.org/r/20210911085847.34849-1-cuibixuan@huawei.com
    Reviwed-by: Hao Xu <haoxu@linux.alibaba.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8dccb28c3291b31ebae55cf6e783f3b5d2c9a56
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Oct 16 08:21:44 2021 +0200

    mmc: mxs-mmc: disable regulator on error and in the remove function
    
    [ Upstream commit ce5f6c2c9b0fcb4094f8e162cfd37fb4294204f7 ]
    
    The 'reg_vmmc' regulator is enabled in the probe. It is never disabled.
    Neither in the error handling path of the probe nor in the remove
    function.
    
    Register a devm_action to disable it when needed.
    
    Fixes: 4dc5a79f1350 ("mmc: mxs-mmc: enable regulator for mmc slot")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/4aadb3c97835f7b80f00819c3d549e6130384e67.1634365151.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6eff31412becfd7e4ad79ac0c7b0bcc3cade9e2d
Author: Sean Young <sean@mess.org>
Date:   Wed Oct 13 09:14:10 2021 +0100

    media: ir_toy: assignment to be16 should be of correct type
    
    [ Upstream commit febfe985fc2ea052a363f6525ff624b8efd5273c ]
    
    commit f0c15b360fb6 ("media: ir_toy: prevent device from hanging during
    transmit") removed a cpu_to_be16() cast, which causes a sparse warning.
    
    Fixes: f0c15b360fb6 ("media: ir_toy: prevent device from hanging during transmit")
    Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13e59b7cb277d8ed4e1b6c099e10c7afe93e64a7
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Oct 10 20:38:36 2021 +0100

    media: ivtv: fix build for UML
    
    [ Upstream commit 6cb67bea945bdf0ad40e633cd2d9fbeb0855675b ]
    
    Prevent the use of page table macros and types from 2 conflicting
    places. This fixes multiple build errors and warnings, e.g.:
    
    ../arch/x86/include/asm/pgtable_64_types.h:21:34: error: conflicting types for ‘pte_t’
     typedef struct { pteval_t pte; } pte_t;
                                      ^~~~~
    In file included from ../include/linux/mm_types_task.h:16:0,
                     from ../include/linux/mm_types.h:5,
                     from ../include/linux/buildid.h:5,
                     from ../include/linux/module.h:14,
                     from ../drivers/media/pci/ivtv/ivtv-driver.h:40,
                     from ../drivers/media/pci/ivtv/ivtvfb.c:29:
    ../arch/um/include/asm/page.h:57:39: note: previous declaration of ‘pte_t’ was here
     typedef struct { unsigned long pte; } pte_t;
    
    ../arch/x86/include/asm/pgtable_types.h:284:43: error: expected ‘)’ before ‘prot’
     static inline pgprot_t pgprot_nx(pgprot_t prot)
                                               ^
    ../include/linux/pgtable.h:914:26: note: in definition of macro ‘pgprot_nx’
     #define pgprot_nx(prot) (prot)
                              ^~~~
    In file included from ../arch/x86/include/asm/memtype.h:6:0,
                     from ../drivers/media/pci/ivtv/ivtvfb.c:40:
    ../arch/x86/include/asm/pgtable_types.h:288:0: warning: "pgprot_nx" redefined
     #define pgprot_nx pgprot_nx
    
    ../arch/x86/include/asm/page_types.h:11:0: warning: "PAGE_SIZE" redefined
     #define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
    
    In file included from ../include/linux/mm_types_task.h:16:0,
                     from ../include/linux/mm_types.h:5,
                     from ../include/linux/buildid.h:5,
                     from ../include/linux/module.h:14,
                     from ../drivers/media/pci/ivtv/ivtv-driver.h:40,
                     from ../drivers/media/pci/ivtv/ivtvfb.c:29:
    ../arch/um/include/asm/page.h:14:0: note: this is the location of the previous definition
     #define PAGE_SIZE (_AC(1, UL) << PAGE_SHIFT)
    
    Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: Andy Walls <awalls@md.metrocast.net>
    Cc: linux-um@lists.infradead.org
    Cc: Richard Weinberger <richard@nod.at>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51911aa157caf8bba831ce59c4e4093399237116
Author: jason-jh.lin <jason-jh.lin@mediatek.com>
Date:   Wed Sep 29 15:08:07 2021 +0800

    mailbox: Remove WARN_ON for async_cb.cb in cmdq_exec_done
    
    [ Upstream commit ce1537fe288469bf68ee0aabdb860a790b4755ef ]
    
    Because mtk_drm_crtc_update_config is not using cmdq_pkt_flush_async,
    it won't have pkt->async_cb.cb anymore.
    
    So remove the WARN_ON check of pkt->async_cb.cb at cmdq_exec_done.
    
    Fixes: 1b6b0ce2240e ("mailbox: mtk-cmdq: Use mailbox rx_callback")
    Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com>
    Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a0b9ebec182877c81b065a3e7c4bc5794fb825b
Author: Jackie Liu <liuyun01@kylinos.cn>
Date:   Sat Oct 9 09:58:53 2021 +0800

    thermal/drivers/qcom/lmh: make QCOM_LMH depends on QCOM_SCM
    
    [ Upstream commit 9e5a4fb8423081d0efbf165c71c7f4abdf5f918c ]
    
    Without QCOM_SCM, build failed, avoid like below:
    
    aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
    aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected!
    aarch64-linux-gnu-ld: drivers/thermal/qcom/lmh.o: in function `lmh_probe':
    /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:141: undefined reference to `qcom_scm_lmh_dcvsh_available'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:144: undefined reference to `qcom_scm_lmh_dcvsh'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:149: undefined reference to `qcom_scm_lmh_dcvsh'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:154: undefined reference to `qcom_scm_lmh_dcvsh'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:159: undefined reference to `qcom_scm_lmh_dcvsh'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:166: undefined reference to `qcom_scm_lmh_profile_change'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:173: undefined reference to `qcom_scm_lmh_dcvsh'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:180: undefined reference to `qcom_scm_lmh_dcvsh'
    aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:187: undefined reference to `qcom_scm_lmh_dcvsh'
    make[1]: *** [/data/arm/workspace/kernel-build/linux/Makefile:1183: vmlinux] Error 1
    make[1]: Leaving directory '/data/arm/workspace/kernel-build/linux/build'
    make: *** [Makefile:219: __sub-make] Error 2
    make: Leaving directory '/data/arm/workspace/kernel-build/linux'
    
    Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
    Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
    Link: https://lore.kernel.org/r/20211009015853.3509559-1-liu.yun@linux.dev
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3988164fe9ddf98ebf5b5cdede91ac38c5f08a7e
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Oct 15 06:37:39 2021 -0700

    net: stream: don't purge sk_error_queue in sk_stream_kill_queues()
    
    [ Upstream commit 24bcbe1cc69fa52dc4f7b5b2456678ed464724d8 ]
    
    sk_stream_kill_queues() can be called on close when there are
    still outstanding skbs to transmit. Those skbs may try to queue
    notifications to the error queue (e.g. timestamps).
    If sk_stream_kill_queues() purges the queue without taking
    its lock the queue may get corrupted, and skbs leaked.
    
    This shows up as a warning about an rmem leak:
    
    WARNING: CPU: 24 PID: 0 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x...
    
    The leak is always a multiple of 0x300 bytes (the value is in
    %rax on my builds, so RAX: 0000000000000300). 0x300 is truesize of
    an empty sk_buff. Indeed if we dump the socket state at the time
    of the warning the sk_error_queue is often (but not always)
    corrupted. The ->next pointer points back at the list head,
    but not the ->prev pointer. Indeed we can find the leaked skb
    by scanning the kernel memory for something that looks like
    an skb with ->sk = socket in question, and ->truesize = 0x300.
    The contents of ->cb[] of the skb confirms the suspicion that
    it is indeed a timestamp notification (as generated in
    __skb_complete_tx_timestamp()).
    
    Removing purging of sk_error_queue should be okay, since
    inet_sock_destruct() does it again once all socket refs
    are gone. Eric suggests this may cause sockets that go
    thru disconnect() to maintain notifications from the
    previous incarnations of the socket, but that should be
    okay since the race was there anyway, and disconnect()
    is not exactly dependable.
    
    Thanks to Jonathan Lemon and Omar Sandoval for help at various
    stages of tracing the issue.
    
    Fixes: cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbc24df3a5f671fe202a3b1a58eb446bc6dd3775
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 13 11:13:15 2021 +0300

    drm/msm: uninitialized variable in msm_gem_import()
    
    [ Upstream commit 2203bd0e5c12ffc53ffdd4fbd7b12d6ba27e0424 ]
    
    The msm_gem_new_impl() function cleans up after itself so there is no
    need to call drm_gem_object_put().  Conceptually, it does not make sense
    to call a kref_put() function until after the reference counting has
    been initialized which happens immediately after this call in the
    drm_gem_(private_)object_init() functions.
    
    In the msm_gem_import() function the "obj" pointer is uninitialized, so
    it will lead to a crash.
    
    Fixes: 05b849111c07 ("drm/msm: prime support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20211013081315.GG6010@kili
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3464103cf485b8b55446d33ae2a41e56d662bc48
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 13 11:11:33 2021 +0300

    drm/msm: fix potential NULL dereference in cleanup
    
    [ Upstream commit 027d052a36e56789a2134772bacb4fd0860f03a3 ]
    
    The "msm_obj->node" list needs to be initialized earlier so that the
    list_del() in msm_gem_free_object() doesn't experience a NULL pointer
    dereference.
    
    Fixes: 6ed0897cd800 ("drm/msm: Fix debugfs deadlock")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20211013081133.GF6010@kili
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbbe146447984ccf90da9201074952ed80ccffb6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Oct 11 15:40:05 2021 +0300

    drm/msm: unlock on error in get_sched_entity()
    
    [ Upstream commit 7425e8167507fe512d8ac0825acda4aebf0a7ca0 ]
    
    Add a missing unlock on the error path if drm_sched_entity_init() fails.
    
    Fixes: 68002469e571 ("drm/msm: One sched entity per process per priority")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20211011124005.GE15188@kili
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de99b40b93ac85dd85ac3abfa3d608311e901169
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Oct 4 13:38:06 2021 +0300

    drm/msm: potential error pointer dereference in init()
    
    [ Upstream commit b6816441a14bbe356ba8590de79cfea2de6a085c ]
    
    The msm_iommu_new() returns error pointers on failure so check for that
    to avoid an Oops.
    
    Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20211004103806.GD25015@kili
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c14f0035476fab52d2763d75ccf0e71c29aa4ee0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Oct 4 16:45:30 2021 +0300

    drm/msm: Fix potential Oops in a6xx_gmu_rpmh_init()
    
    [ Upstream commit 3d91e50ff58364f6572ad268b508175d27800e51 ]
    
    There are two problems here:
    1) The "seqptr" is used uninitalized when we free it at the end.
    2) The a6xx_gmu_get_mmio() function returns error pointers.  It never
       returns true.
    
    Fixes: 64245fc55172 ("drm/msm/a6xx: use AOP-initialized PDC for a650")
    Fixes: f8fc924e088e ("drm/msm/a6xx: Fix PDC register overlap")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20211004134530.GB11689@kili
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dafe75a9a6dc661841ff51f01eae5bed73653570
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat Oct 2 04:08:30 2021 +0300

    drm/msm/dsi: do not enable irq handler before powering up the host
    
    [ Upstream commit bf94ec093d05e3ed3142d9291b876eeb9997ba5c ]
    
    The DSI host might be left in some state by the bootloader. If this
    state generates an IRQ, it might hang the system by holding the
    interrupt line before the driver sets up the DSI host to the known
    state.
    
    Move the request_irq into msm_dsi_host_init and pass IRQF_NO_AUTOEN to
    it. Call enable/disable_irq after msm_dsi_host_power_on/_off()
    functions, so that we can be sure that the interrupt is delivered when
    the host is in the known state.
    
    It is not possible to defer the interrupt enablement to a later point,
    because drm_panel_prepare might need to communicate with the panel over
    the DSI link and that requires working interrupt.
    
    Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
    Link: https://lore.kernel.org/r/20211002010830.647416-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f25451eae2870b227e29593041f80a7b5322062
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Fri Oct 15 10:45:04 2021 +0800

    thermal/core: fix a UAF bug in __thermal_cooling_device_register()
    
    [ Upstream commit 0a5c26712f963f0500161a23e0ffff8d29f742ab ]
    
    When device_register() return failed, program will goto out_kfree_type
    to release 'cdev->device' by put_device(). That will call thermal_release()
    to free 'cdev'. But the follow-up processes access 'cdev' continually.
    That trggers the UAF bug.
    
    ====================================================================
    BUG: KASAN: use-after-free in __thermal_cooling_device_register+0x75b/0xa90
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     dump_stack_lvl+0xe2/0x152
     print_address_description.constprop.0+0x21/0x140
     ? __thermal_cooling_device_register+0x75b/0xa90
     kasan_report.cold+0x7f/0x11b
     ? __thermal_cooling_device_register+0x75b/0xa90
     __thermal_cooling_device_register+0x75b/0xa90
     ? memset+0x20/0x40
     ? __sanitizer_cov_trace_pc+0x1d/0x50
     ? __devres_alloc_node+0x130/0x180
     devm_thermal_of_cooling_device_register+0x67/0xf0
     max6650_probe.cold+0x557/0x6aa
    ......
    
    Freed by task 258:
     kasan_save_stack+0x1b/0x40
     kasan_set_track+0x1c/0x30
     kasan_set_free_info+0x20/0x30
     __kasan_slab_free+0x109/0x140
     kfree+0x117/0x4c0
     thermal_release+0xa0/0x110
     device_release+0xa7/0x240
     kobject_put+0x1ce/0x540
     put_device+0x20/0x30
     __thermal_cooling_device_register+0x731/0xa90
     devm_thermal_of_cooling_device_register+0x67/0xf0
     max6650_probe.cold+0x557/0x6aa [max6650]
    
    Do not use 'cdev' again after put_device() to fix the problem like doing
    in thermal_zone_device_register().
    
    [dlezcano]: as requested by Rafael, change the affectation into two statements.
    
    Fixes: 584837618100 ("thermal/drivers/core: Use a char pointer for the cooling device name")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/r/20211015024504.947520-1-william.xuanziyang@huawei.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b208436e229bd117af010701336341af9dc539d3
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Oct 10 19:36:42 2021 +0300

    crypto: octeontx2 - set assoclen in aead_do_fallback()
    
    [ Upstream commit 06f6e365e2ecf799c249bb464aa9d5f055e88b56 ]
    
    Currently, in case of aead fallback, no associated data info is set in the
    fallback request. To fix this, call aead_request_set_ad() to pass the assoclen.
    
    Fixes: 6f03f0e8b6c8 ("crypto: octeontx2 - register with linux crypto framework")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 300ae3a5e88421fc4456ca2cf9bd37cbf1dad12d
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 14 06:41:26 2021 -0700

    tcp: switch orphan_count to bare per-cpu counters
    
    [ Upstream commit 19757cebf0c5016a1f36f7fe9810a9f0b33c0832 ]
    
    Use of percpu_counter structure to track count of orphaned
    sockets is causing problems on modern hosts with 256 cpus
    or more.
    
    Stefan Bach reported a serious spinlock contention in real workloads,
    that I was able to reproduce with a netfilter rule dropping
    incoming FIN packets.
    
        53.56%  server  [kernel.kallsyms]      [k] queued_spin_lock_slowpath
                |
                ---queued_spin_lock_slowpath
                   |
                    --53.51%--_raw_spin_lock_irqsave
                              |
                               --53.51%--__percpu_counter_sum
                                         tcp_check_oom
                                         |
                                         |--39.03%--__tcp_close
                                         |          tcp_close
                                         |          inet_release
                                         |          inet6_release
                                         |          sock_close
                                         |          __fput
                                         |          ____fput
                                         |          task_work_run
                                         |          exit_to_usermode_loop
                                         |          do_syscall_64
                                         |          entry_SYSCALL_64_after_hwframe
                                         |          __GI___libc_close
                                         |
                                          --14.48%--tcp_out_of_resources
                                                    tcp_write_timeout
                                                    tcp_retransmit_timer
                                                    tcp_write_timer_handler
                                                    tcp_write_timer
                                                    call_timer_fn
                                                    expire_timers
                                                    __run_timers
                                                    run_timer_softirq
                                                    __softirqentry_text_start
    
    As explained in commit cf86a086a180 ("net/dst: use a smaller percpu_counter
    batch for dst entries accounting"), default batch size is too big
    for the default value of tcp_max_orphans (262144).
    
    But even if we reduce batch sizes, there would still be cases
    where the estimated count of orphans is beyond the limit,
    and where tcp_too_many_orphans() has to call the expensive
    percpu_counter_sum_positive().
    
    One solution is to use plain per-cpu counters, and have
    a timer to periodically refresh this cache.
    
    Updating this cache every 100ms seems about right, tcp pressure
    state is not radically changing over shorter periods.
    
    percpu_counter was nice 15 years ago while hosts had less
    than 16 cpus, not anymore by current standards.
    
    v2: Fix the build issue for CONFIG_CRYPTO_DEV_CHELSIO_TLS=m,
        reported by kernel test robot <lkp@intel.com>
        Remove unused socket argument from tcp_too_many_orphans()
    
    Fixes: dd24c00191d5 ("net: Use a percpu_counter for orphan_count")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Stefan Bach <sfb@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cae022f91174fabce164cf3d061edaaad0eacb1f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Oct 13 22:06:06 2021 -0700

    net: tulip: winbond-840: fix build for UML
    
    [ Upstream commit a3d708925fcca1a2f7219bc9ce93e6341f85c1e0 ]
    
    On i386, when builtin (not a loadable module), the winbond-840 driver
    inspects boot_cpu_data to see what CPU family it is running on, and
    then acts on that data. The "family" struct member (x86) does not exist
    when running on UML, so prevent that test and do the default action.
    
    Prevents this build error on UML + i386:
    
    ../drivers/net/ethernet/dec/tulip/winbond-840.c: In function ‘init_registers’:
    ../drivers/net/ethernet/dec/tulip/winbond-840.c:882:19: error: ‘struct cpuinfo_um’ has no member named ‘x86’
      if (boot_cpu_data.x86 <= 4) {
    
    Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: linux-um@lists.infradead.org
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Link: https://lore.kernel.org/r/20211014050606.7288-1-rdunlap@infradead.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be060f47ef386789a78df4fc459edc2aff1e46ee
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Oct 13 22:05:16 2021 -0700

    net: intel: igc_ptp: fix build for UML
    
    [ Upstream commit 523994ba3ad1b7b55abe4a72e156897b5e2db825 ]
    
    On a UML build, the igc_ptp driver uses CONFIG_X86_TSC for timestamp
    conversion. The function that is used is not available on UML builds,
    so have the function use the default system_counterval_t timestamp
    instead for UML builds.
    
    Prevents this build error on UML:
    
    ../drivers/net/ethernet/intel/igc/igc_ptp.c: In function ‘igc_device_tstamp_to_system’:
    ../drivers/net/ethernet/intel/igc/igc_ptp.c:777:9: error: implicit declaration of function ‘convert_art_ns_to_tsc’ [-Werror=implicit-function-declaration]
      return convert_art_ns_to_tsc(tstamp);
    ../drivers/net/ethernet/intel/igc/igc_ptp.c:777:9: error: incompatible types when returning type ‘int’ but ‘struct system_counterval_t’ was expected
      return convert_art_ns_to_tsc(tstamp);
    
    Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: linux-um@lists.infradead.org
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
    Cc: intel-wired-lan@lists.osuosl.org
    Link: https://lore.kernel.org/r/20211014050516.6846-1-rdunlap@infradead.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fa75b667335de13bbb2821dfcf2a115a91c9005
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Oct 13 22:05:00 2021 -0700

    net: fealnx: fix build for UML
    
    [ Upstream commit cd2621d07d517473611b170c69beb6524c677740 ]
    
    On i386, when builtin (not a loadable module), the fealnx driver
    inspects boot_cpu_data to see what CPU family it is running on, and
    then acts on that data. The "family" struct member (x86) does not exist
    when running on UML, so prevent that test and do the default action.
    
    Prevents this build error on UML + i386:
    
    ../drivers/net/ethernet/fealnx.c: In function ‘netdev_open’:
    ../drivers/net/ethernet/fealnx.c:861:19: error: ‘struct cpuinfo_um’ has no member named ‘x86’
    
    Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: linux-um@lists.infradead.org
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Link: https://lore.kernel.org/r/20211014050500.5620-1-rdunlap@infradead.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3869eecf050416a1d19bac60926f6b5d64b0aa58
Author: Zhang Qiao <zhangqiao22@huawei.com>
Date:   Wed Sep 15 14:40:30 2021 +0800

    kernel/sched: Fix sched_fork() access an invalid sched_task_group
    
    [ Upstream commit 4ef0c5c6b5ba1f38f0ea1cedad0cad722f00c14a ]
    
    There is a small race between copy_process() and sched_fork()
    where child->sched_task_group point to an already freed pointer.
    
            parent doing fork()      | someone moving the parent
                                     | to another cgroup
      -------------------------------+-------------------------------
      copy_process()
          + dup_task_struct()<1>
                                      parent move to another cgroup,
                                      and free the old cgroup. <2>
          + sched_fork()
            + __set_task_cpu()<3>
            + task_fork_fair()
              + sched_slice()<4>
    
    In the worst case, this bug can lead to "use-after-free" and
    cause panic as shown above:
    
      (1) parent copy its sched_task_group to child at <1>;
    
      (2) someone move the parent to another cgroup and free the old
          cgroup at <2>;
    
      (3) the sched_task_group and cfs_rq that belong to the old cgroup
          will be accessed at <3> and <4>, which cause a panic:
    
      [] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      [] PGD 8000001fa0a86067 P4D 8000001fa0a86067 PUD 2029955067 PMD 0
      [] Oops: 0000 [#1] SMP PTI
      [] CPU: 7 PID: 648398 Comm: ebizzy Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0.x86_64+ #1
      [] RIP: 0010:sched_slice+0x84/0xc0
    
      [] Call Trace:
      []  task_fork_fair+0x81/0x120
      []  sched_fork+0x132/0x240
      []  copy_process.part.5+0x675/0x20e0
      []  ? __handle_mm_fault+0x63f/0x690
      []  _do_fork+0xcd/0x3b0
      []  do_syscall_64+0x5d/0x1d0
      []  entry_SYSCALL_64_after_hwframe+0x65/0xca
      [] RIP: 0033:0x7f04418cd7e1
    
    Between cgroup_can_fork() and cgroup_post_fork(), the cgroup
    membership and thus sched_task_group can't change. So update child's
    sched_task_group at sched_post_fork() and move task_fork() and
    __set_task_cpu() (where accees the sched_task_group) from sched_fork()
    to sched_post_fork().
    
    Fixes: 8323f26ce342 ("sched: Fix race in task_group")
    Signed-off-by: Zhang Qiao <zhangqiao22@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lkml.kernel.org/r/20210915064030.2231-1-zhangqiao22@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d719ff1151c74e9230e5ea9be3fdf2cea5dc51a5
Author: Sven Eckelmann <seckelmann@datto.com>
Date:   Tue Jun 11 19:21:31 2019 +0200

    ath10k: fix max antenna gain unit
    
    [ Upstream commit 0a491167fe0cf9f26062462de2a8688b96125d48 ]
    
    Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
    steps). This isn't the case for max_antenna_gain - which is still expected
    by the firmware as dB.
    
    The firmware is converting it from dB to the internal (twicepower)
    representation when it calculates the limits of a channel. This can be seen
    in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
    expected 12 (6 dB), the tpc_stats shows 24 (12 dB).
    
    Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.
    
    Fixes: 02256930d9b8 ("ath10k: use proper tx power unit")
    Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20190611172131.6064-1-sven@narfation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd0fe5985b0ab05173f5b4c02b164722482f9903
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Tue Sep 28 02:22:38 2021 -0700

    hwmon: (pmbus/lm25066) Let compiler determine outer dimension of lm25066_coeff
    
    [ Upstream commit b7931a7b0e0df4d2a25fedd895ad32c746b77bc1 ]
    
    Maintaining this manually is error prone (there are currently only
    five chips supported, not six); gcc can do it for us automatically.
    
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Fixes: 666c14906b49 ("hwmon: (pmbus/lm25066) Drop support for LM25063")
    Link: https://lore.kernel.org/r/20210928092242.30036-5-zev@bewilderbeest.net
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b275c71a7b70e7100e236b90adc76edda7e9f374
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Oct 12 19:27:58 2021 +0800

    hwmon: Fix possible memleak in __hwmon_device_register()
    
    [ Upstream commit ada61aa0b1184a8fda1a89a340c7d6cc4e59aee5 ]
    
    I got memory leak as follows when doing fault injection test:
    
    unreferenced object 0xffff888102740438 (size 8):
      comm "27", pid 859, jiffies 4295031351 (age 143.992s)
      hex dump (first 8 bytes):
        68 77 6d 6f 6e 30 00 00                          hwmon0..
      backtrace:
        [<00000000544b5996>] __kmalloc_track_caller+0x1a6/0x300
        [<00000000df0d62b9>] kvasprintf+0xad/0x140
        [<00000000d3d2a3da>] kvasprintf_const+0x62/0x190
        [<000000005f8f0f29>] kobject_set_name_vargs+0x56/0x140
        [<00000000b739e4b9>] dev_set_name+0xb0/0xe0
        [<0000000095b69c25>] __hwmon_device_register+0xf19/0x1e50 [hwmon]
        [<00000000a7e65b52>] hwmon_device_register_with_info+0xcb/0x110 [hwmon]
        [<000000006f181e86>] devm_hwmon_device_register_with_info+0x85/0x100 [hwmon]
        [<0000000081bdc567>] tmp421_probe+0x2d2/0x465 [tmp421]
        [<00000000502cc3f8>] i2c_device_probe+0x4e1/0xbb0
        [<00000000f90bda3b>] really_probe+0x285/0xc30
        [<000000007eac7b77>] __driver_probe_device+0x35f/0x4f0
        [<000000004953d43d>] driver_probe_device+0x4f/0x140
        [<000000002ada2d41>] __device_attach_driver+0x24c/0x330
        [<00000000b3977977>] bus_for_each_drv+0x15d/0x1e0
        [<000000005bf2a8e3>] __device_attach+0x267/0x410
    
    When device_register() returns an error, the name allocated in
    dev_set_name() will be leaked, the put_device() should be used
    instead of calling hwmon_dev_release() to give up the device
    reference, then the name will be freed in kobject_cleanup().
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: bab2243ce189 ("hwmon: Introduce hwmon_device_register_with_groups")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211012112758.2681084-1-yangyingliang@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9531d477589d5608ea3601bb5f144a5bce377947
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Mon Oct 11 14:12:35 2021 +0200

    net, neigh: Fix NTF_EXT_LEARNED in combination with NTF_USE
    
    [ Upstream commit e4400bbf5b15750e1b59bf4722d18d99be60c69f ]
    
    The NTF_EXT_LEARNED neigh flag is usually propagated back to user space
    upon dump of the neighbor table. However, when used in combination with
    NTF_USE flag this is not the case despite exempting the entry from the
    garbage collector. This results in inconsistent state since entries are
    typically marked in neigh->flags with NTF_EXT_LEARNED, but here they are
    not. Fix it by propagating the creation flag to ___neigh_create().
    
    Before fix:
    
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
      [...]
    
    After fix:
    
      # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
      # ./ip/ip n
      192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE
      [...]
    
    Fixes: 9ce33e46531d ("neighbour: support for NTF_EXT_LEARNED flag")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Roopa Prabhu <roopa@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dacdfe7870aea353c787f6b7b1ac9ce2b836b6e5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Oct 11 15:39:12 2021 +0300

    memstick: jmb38x_ms: use appropriate free function in jmb38x_ms_alloc_host()
    
    [ Upstream commit beae4a6258e64af609ad5995cc6b6056eb0d898e ]
    
    The "msh" pointer is device managed, meaning that memstick_alloc_host()
    calls device_initialize() on it.  That means that it can't be free
    using kfree() but must instead be freed with memstick_free_host().
    Otherwise it leads to a tiny memory leak of device resources.
    
    Fixes: 60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20211011123912.GD15188@kili
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d78b5b1ce013cd10b6f9466af8b038097374514
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 27 11:44:47 2021 +0200

    memstick: avoid out-of-range warning
    
    [ Upstream commit 4853396f03c3019eccf5cd113e464231e9ddf0b3 ]
    
    clang-14 complains about a sanity check that always passes when the
    page size is 64KB or larger:
    
    drivers/memstick/core/ms_block.c:1739:21: error: result of comparison of constant 65536 with expression of type 'unsigned short' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (msb->page_size > PAGE_SIZE) {
                ~~~~~~~~~~~~~~ ^ ~~~~~~~~~
    
    This is fine, it will still work on all architectures, so just shut
    up that warning with a cast.
    
    Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20210927094520.696665-1-arnd@kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b9c76df7ff0ece2f97a57549c2c6aae359e86e2
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Sep 21 14:00:26 2021 +0300

    mmc: sdhci-omap: Fix context restore
    
    [ Upstream commit d806e334d0390502cd2a820ad33d65d7f9bba618 ]
    
    We need to restore context in a specified order with HCTL set in two
    phases. This is similar to what omap_hsmmc_context_restore() is doing.
    Otherwise SDIO can stop working on resume.
    
    And for PM runtime and SDIO cards, we need to also save SYSCTL, IE and
    ISE.
    
    This should not be a problem currently, and these patches can be applied
    whenever suitable.
    
    Fixes: ee0f309263a6 ("mmc: sdhci-omap: Add Support for Suspend/Resume")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210921110029.21944-3-tony@atomide.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e28a1a0a412a02c59ce82cede64591604f90e6f9
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Sep 21 14:00:25 2021 +0300

    mmc: sdhci-omap: Fix NULL pointer exception if regulator is not configured
    
    [ Upstream commit 8e0e7bd38b1ec7f9e5d18725ad41828be4e09859 ]
    
    If sdhci-omap is configured for an unused device instance and the device
    is not set as disabled, we can get a NULL pointer dereference:
    
    Unable to handle kernel NULL pointer dereference at virtual address
    00000045
    ...
    (regulator_set_voltage) from [<c07d7008>] (mmc_regulator_set_ocr+0x44/0xd0)
    (mmc_regulator_set_ocr) from [<c07e2d80>] (sdhci_set_ios+0xa4/0x490)
    (sdhci_set_ios) from [<c07ea690>] (sdhci_omap_set_ios+0x124/0x160)
    (sdhci_omap_set_ios) from [<c07c8e94>] (mmc_power_up.part.0+0x3c/0x154)
    (mmc_power_up.part.0) from [<c07c9d20>] (mmc_start_host+0x88/0x9c)
    (mmc_start_host) from [<c07cad34>] (mmc_add_host+0x58/0x7c)
    (mmc_add_host) from [<c07e2574>] (__sdhci_add_host+0xf0/0x22c)
    (__sdhci_add_host) from [<c07eaf68>] (sdhci_omap_probe+0x318/0x72c)
    (sdhci_omap_probe) from [<c06a39d8>] (platform_probe+0x58/0xb8)
    
    AFAIK we are not seeing this with the devices configured in the mainline
    kernel but this can cause issues for folks bringing up their boards.
    
    Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210921110029.21944-2-tony@atomide.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b084516fbc30979a75757f222e96dbbcfe6ff5e
Author: Catherine Sullivan <csully@google.com>
Date:   Mon Oct 11 08:36:50 2021 -0700

    gve: Track RX buffer allocation failures
    
    [ Upstream commit 1b4d1c9bab091ac6e20a3ff80c30c5cefe192bf4 ]
    
    The rx_buf_alloc_fail counter wasn't getting updated.
    
    Fixes: 433e274b8f7b0 ("gve: Add stats for gve.")
    Signed-off-by: Catherine Sullivan <csully@google.com>
    Signed-off-by: Jeroen de Borst <jeroendb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd2c9032b88c7c8524801458fb02091caca3821d
Author: John Fraker <jfraker@google.com>
Date:   Mon Oct 11 08:36:47 2021 -0700

    gve: Recover from queue stall due to missed IRQ
    
    [ Upstream commit 87a7f321bb6a45e54b7d6c90d032ee5636a6ad97 ]
    
    Don't always reset the driver on a TX timeout. Attempt to
    recover by kicking the queue in case an IRQ was missed.
    
    Fixes: 9e5f7d26a4c08 ("gve: Add workqueue and reset support")
    Signed-off-by: John Fraker <jfraker@google.com>
    Signed-off-by: David Awogbemila <awogbemila@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5be2a62567fdb1bff9395686488df86533f9316
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 6 10:36:22 2021 +0300

    b43: fix a lower bounds test
    
    [ Upstream commit 9b793db5fca44d01f72d3564a168171acf7c4076 ]
    
    The problem is that "channel" is an unsigned int, when it's less 5 the
    value of "channel - 5" is not a negative number as one would expect but
    is very high positive value instead.
    
    This means that "start" becomes a very high positive value.  The result
    of that is that we never enter the "for (i = start; i <= end; i++) {"
    loop.  Instead of storing the result from b43legacy_radio_aci_detect()
    it just uses zero.
    
    Fixes: ef1a628d83fc ("b43: Implement dynamic PHY API")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael Büsch <m@bues.ch>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211006073621.GE8404@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9179a2da18c32218bcdf02ba72e61ec37d70e7c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 6 10:35:42 2021 +0300

    b43legacy: fix a lower bounds test
    
    [ Upstream commit c1c8380b0320ab757e60ed90efc8b1992a943256 ]
    
    The problem is that "channel" is an unsigned int, when it's less 5 the
    value of "channel - 5" is not a negative number as one would expect but
    is very high positive value instead.
    
    This means that "start" becomes a very high positive value.  The result
    of that is that we never enter the "for (i = start; i <= end; i++) {"
    loop.  Instead of storing the result from b43legacy_radio_aci_detect()
    it just uses zero.
    
    Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael Büsch <m@bues.ch>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211006073542.GD8404@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bef6e617dbc92c665ccbaf7a6ad3f504def3253
Author: liqiong <liqiong@nfschina.com>
Date:   Sat Oct 9 18:38:21 2021 +0800

    ima: fix deadlock when traversing "ima_default_rules".
    
    [ Upstream commit eb0782bbdfd0d7c4786216659277c3fd585afc0e ]
    
    The current IMA ruleset is identified by the variable "ima_rules"
    that default to "&ima_default_rules". When loading a custom policy
    for the first time, the variable is updated to "&ima_policy_rules"
    instead. That update isn't RCU-safe, and deadlocks are possible.
    Indeed, some functions like ima_match_policy() may loop indefinitely
    when traversing "ima_default_rules" with list_for_each_entry_rcu().
    
    When iterating over the default ruleset back to head, if the list
    head is "ima_default_rules", and "ima_rules" have been updated to
    "&ima_policy_rules", the loop condition (&entry->list != ima_rules)
    stays always true, traversing won't terminate, causing a soft lockup
    and RCU stalls.
    
    Introduce a temporary value for "ima_rules" when iterating over
    the ruleset to avoid the deadlocks.
    
    Signed-off-by: liqiong <liqiong@nfschina.com>
    Reviewed-by: THOBY Simon <Simon.THOBY@viveris.fr>
    Fixes: 38d859f991f3 ("IMA: policy can now be updated multiple times")
    Reported-by: kernel test robot <lkp@intel.com> (Fix sparse: incompatible types in comparison expression.)
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 594a893df55db9915a68e9ee5b985280bd03d089
Author: Markus Schneider-Pargmann <msp@baylibre.com>
Date:   Thu Sep 30 21:12:42 2021 +0200

    hwrng: mtk - Force runtime pm ops for sleep ops
    
    [ Upstream commit b6f5f0c8f72d348b2d07b20d7b680ef13a7ffe98 ]
    
    Currently mtk_rng_runtime_suspend/resume is called for both runtime pm
    and system sleep operations.
    
    This is wrong as these should only be runtime ops as the name already
    suggests. Currently freezing the system will lead to a call to
    mtk_rng_runtime_suspend even if the device currently isn't active. This
    leads to a clock warning because it is disabled/unprepared although it
    isn't enabled/prepared currently.
    
    This patch fixes this by only setting the runtime pm ops and forces to
    call the runtime pm ops from the system sleep ops as well if active but
    not otherwise.
    
    Fixes: 81d2b34508c6 ("hwrng: mtk - add runtime PM support")
    Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51dbedbf08e01f07443bdea9aa74ffd3330d2ec8
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Tue Sep 28 12:44:30 2021 +0100

    crypto: qat - disregard spurious PFVF interrupts
    
    [ Upstream commit 18fcba469ba5359c1de7e3fb16f7b9e8cd1b8e02 ]
    
    Upon receiving a PFVF message, check if the interrupt bit is set in the
    message. If it is not, that means that the interrupt was probably
    triggered by a collision. In this case, disregard the message and
    re-enable the interrupts.
    
    Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0536282842a7798cf591eacd2067ce5f97c208f
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Tue Sep 28 12:44:29 2021 +0100

    crypto: qat - detect PFVF collision after ACK
    
    [ Upstream commit 9b768e8a3909ac1ab39ed44a3933716da7761a6f ]
    
    Detect a PFVF collision between the local and the remote function by
    checking if the message on the PFVF CSR has been overwritten.
    This is done after the remote function confirms that the message has
    been received, by clearing the interrupt bit, or the maximum number of
    attempts (ADF_IOV_MSG_ACK_MAX_RETRY) to check the CSR has been exceeded.
    
    Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Co-developed-by: Marco Chiappero <marco.chiappero@intel.com>
    Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2805fb00de540f2112d080f0efbae6353711a9c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 27 14:18:03 2021 +0200

    crypto: ccree - avoid out-of-range warnings from clang
    
    [ Upstream commit cfd6fb45cfaf46fa9547421d8da387dc9c7997d4 ]
    
    clang points out inconsistencies in the FIELD_PREP() invocation in
    this driver that result from the 'mask' being a 32-bit value:
    
    drivers/crypto/ccree/cc_driver.c:117:18: error: result of comparison of constant 18446744073709551615 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            cache_params |= FIELD_PREP(mask, val);
                            ^~~~~~~~~~~~~~~~~~~~~
    include/linux/bitfield.h:94:3: note: expanded from macro 'FIELD_PREP'
                    __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");    \
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    include/linux/bitfield.h:52:28: note: expanded from macro '__BF_FIELD_CHECK'
                    BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull,         \
                    ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    This does not happen in other places that just pass a constant here.
    
    Work around the warnings by widening the type of the temporary variable.
    
    Fixes: 05c2a705917b ("crypto: ccree - rework cache parameters handling")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Gilad ben-Yossef <gilad@benyossef.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0535d350637893c63ee5b4c4f03658320bf71624
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Sun Aug 22 11:48:03 2021 +0200

    media: dvb-frontends: mn88443x: Handle errors of clk_prepare_enable()
    
    [ Upstream commit 69a10678e2fba3d182e78ea041f2d1b1a6058764 ]
    
    mn88443x_cmn_power_on() did not handle possible errors of
    clk_prepare_enable() and always finished successfully so that its caller
    mn88443x_probe() did not care about failed preparing/enabling of clocks
    as well.
    
    Add missed error handling in both mn88443x_cmn_power_on() and
    mn88443x_probe(). This required to change the return value of the former
    from "void" to "int".
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: 0f408ce8941f ("media: dvb-frontends: add Socionext MN88443x ISDB-S/T demodulator driver")
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
    Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a117b767084d7de12e526fbe96efc8228b3679c7
Author: Mansur Alisha Shaik <mansur@codeaurora.org>
Date:   Tue Sep 14 05:57:07 2021 +0200

    media: venus: fix vpp frequency calculation for decoder
    
    [ Upstream commit 1444232152ea33f5ae41fc14bade3e74d642b634 ]
    
    In existing video driver implementation vpp frequency calculation in
    calculate_inst_freq() is always zero because the value of vpp_freq_per_mb
    is always zero for decoder.
    
    Fixed this by correcting the calculating the vpp frequency calculation for
    decoder.
    
    Fixes: 3cfe5815ce0e ("media: venus: Enable low power setting for encoder")
    Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ad069d68eea2bbdeec105dd6c386e177fd322a7
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Sep 25 22:40:26 2021 +0200

    netfilter: nft_dynset: relax superfluous check on set updates
    
    [ Upstream commit 7b1394892de8d95748d05e3ee41e85edb4abbfa1 ]
    
    Relax this condition to make add and update commands idempotent for sets
    with no timeout. The eval function already checks if the set element
    timeout is available and updates it if the update command is used.
    
    Fixes: 22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d846b69dc7ffca2042428cd46b323fed4ce6a801
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Sep 28 10:40:22 2021 +0200

    rcu: Fix rcu_dynticks_curr_cpu_in_eqs() vs noinstr
    
    [ Upstream commit 74aece72f95f399dd29363669dc32a1344c8fab4 ]
    
      vmlinux.o: warning: objtool: rcu_nmi_enter()+0x36: call to __kasan_check_read() leaves .noinstr.text section
    
    noinstr cannot have atomic_*() functions in because they're explicitly
    annotated, use arch_atomic_*().
    
    Fixes: 2be57f732889 ("rcu: Weaken ->dynticks accesses and updates")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa1af3cb0e47aa0a7abe2c179dde07011465e29c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Sep 28 10:40:21 2021 +0200

    rcu: Always inline rcu_dynticks_task*_{enter,exit}()
    
    [ Upstream commit 7663ad9a5dbcc27f3090e6bfd192c7e59222709f ]
    
    RCU managed to grow a few noinstr violations:
    
      vmlinux.o: warning: objtool: rcu_dynticks_eqs_enter()+0x0: call to rcu_dynticks_task_trace_enter() leaves .noinstr.text section
      vmlinux.o: warning: objtool: rcu_dynticks_eqs_exit()+0xe: call to rcu_dynticks_task_trace_exit() leaves .noinstr.text section
    
    Fix them by adding __always_inline to the relevant trivial functions.
    
    Also replace the noinstr with __always_inline for the existing
    rcu_dynticks_task_*() functions since noinstr would force noinline
    them, even when empty, which seems silly.
    
    Fixes: 7d0c9c50c5a1 ("rcu-tasks: Avoid IPIing userspace/idle tasks if kernel is so built")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0b693aa948b7d73d4c102c6bdc238a3240bca4e
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Tue Oct 5 15:44:19 2021 +0000

    EDAC/amd64: Handle three rank interleaving mode
    
    [ Upstream commit 9f4873fb6af7966de8fcbd95c36b61351c1c4b1f ]
    
    AMD Rome systems and later support interleaving between three identical
    ranks within a channel.
    
    Check for this mode by counting the number of enabled chip selects and
    comparing their masks. If there are exactly three enabled chip selects
    and their masks are identical, then three rank interleaving is enabled.
    
    The size of a rank is determined from its mask value. However, three
    rank interleaving doesn't follow the method of swapping an interleave
    bit with the most significant bit. Rather, the interleave bit is flipped
    and the most significant bit remains the same. There is only a single
    interleave bit in this case.
    
    Account for this when determining the chip select size by keeping the
    most significant bit at its original value and ignoring any zero bits.
    This will return a full bitmask in [MSB:1].
    
    Fixes: e53a3b267fb0 ("EDAC/amd64: Find Chip Select memory size using Address Mask")
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20211005154419.2060504-1-yazen.ghannam@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3357b8a431b3c2b5ef443a134b5abf702ef927a7
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Sep 29 16:37:53 2021 +0200

    x86/insn: Use get_unaligned() instead of memcpy()
    
    [ Upstream commit f96b4675839b66168f5a07bf964dde6c2f1c4885 ]
    
    Use get_unaligned() instead of memcpy() to access potentially unaligned
    memory, which, when accessed through a pointer, leads to undefined
    behavior. get_unaligned() describes much better what is happening there
    anyway even if memcpy() does the job.
    
    In addition, since perf tool builds with -Werror, it would fire with:
    
      util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix':
      tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed]
         10 |  const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \
    
    because -Werror=packed would complain if the packed attribute would have
    no effect on the layout of the structure.
    
    In this case, that is intentional so disable the warning only for that
    compilation unit.
    
    That part is Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    
    No functional changes.
    
    Fixes: 5ba1071f7554 ("x86/insn, tools/x86: Fix undefined behavior due to potential unaligned accesses")
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Link: https://lkml.kernel.org/r/YVSsIkj9Z29TyUjE@zn.tnic
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c38c852c0ac2218e5cb1b75e5fb5daa718475e5
Author: Vincent Donnefort <vincent.donnefort@arm.com>
Date:   Wed Sep 8 15:05:22 2021 +0100

    PM: EM: Fix inefficient states detection
    
    [ Upstream commit aa1a43262ad5df010768f69530fa179ff81651d3 ]
    
    Currently, a debug message is printed if an inefficient state is detected
    in the Energy Model. Unfortunately, it won't detect if the first state is
    inefficient or if two successive states are. Fix this behavior.
    
    Fixes: 27871f7a8a34 (PM: Introduce an Energy Model management framework)
    Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
    Reviewed-by: Quentin Perret <qperret@google.com>
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8f0c3c39e26e8790b33722f95542aadb5872903
Author: Linus Lüssing <ll@simonwunderlich.de>
Date:   Tue Oct 5 16:55:53 2021 +0300

    ath9k: Fix potential interrupt storm on queue reset
    
    [ Upstream commit 4925642d541278575ad1948c5924d71ffd57ef14 ]
    
    In tests with two Lima boards from 8devices (QCA4531 based) on OpenWrt
    19.07 we could force a silent restart of a device with no serial
    output when we were sending a high amount of UDP traffic (iperf3 at 80
    MBit/s in both directions from external hosts, saturating the wifi and
    causing a load of about 4.5 to 6) and were then triggering an
    ath9k_queue_reset().
    
    Further debugging showed that the restart was caused by the ath79
    watchdog. With disabled watchdog we could observe that the device was
    constantly going into ath_isr() interrupt handler and was returning
    early after the ATH_OP_HW_RESET flag test, without clearing any
    interrupts. Even though ath9k_queue_reset() calls
    ath9k_hw_kill_interrupts().
    
    With JTAG we could observe the following race condition:
    
    1) ath9k_queue_reset()
       ...
       -> ath9k_hw_kill_interrupts()
       -> set_bit(ATH_OP_HW_RESET, &common->op_flags);
       ...
       <- returns
    
          2) ath9k_tasklet()
             ...
             -> ath9k_hw_resume_interrupts()
             ...
             <- returns
    
                     3) loops around:
                        ...
                        handle_int()
                        -> ath_isr()
                           ...
                           -> if (test_bit(ATH_OP_HW_RESET,
                                           &common->op_flags))
                                return IRQ_HANDLED;
    
                        x) ath_reset_internal():
                           => never reached <=
    
    And in ath_isr() we would typically see the following interrupts /
    interrupt causes:
    
    * status: 0x00111030 or 0x00110030
    * async_cause: 2 (AR_INTR_MAC_IPQ)
    * sync_cause: 0
    
    So the ath9k_tasklet() reenables the ath9k interrupts
    through ath9k_hw_resume_interrupts() which ath9k_queue_reset() had just
    disabled. And ath_isr() then keeps firing because it returns IRQ_HANDLED
    without actually clearing the interrupt.
    
    To fix this IRQ storm also clear/disable the interrupts again when we
    are in reset state.
    
    Cc: Sven Eckelmann <sven@narfation.org>
    Cc: Simon Wunderlich <sw@simonwunderlich.de>
    Cc: Linus Lüssing <linus.luessing@c0d3.blue>
    Fixes: 872b5d814f99 ("ath9k: do not access hardware on IRQs during reset")
    Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210914192515.9273-3-linus.luessing@c0d3.blue
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 428199299910d0a759ae7c1a1bc9f71797a2832e
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Tue Oct 5 16:55:53 2021 +0300

    ath10k: Don't always treat modem stop events as crashes
    
    [ Upstream commit 747ff7d3d7424876111b7559b7f6704762f89796 ]
    
    When rebooting on sc7180 Trogdor devices I see the following crash from
    the wifi driver.
    
     ath10k_snoc 18800000.wifi: firmware crashed! (guid 83493570-29a2-4e98-a83e-70048c47669c)
    
    This is because a modem stop event looks just like a firmware crash to
    the driver, the qmi connection is closed in both cases. Use the qcom ssr
    notifier block to stop treating the qmi connection close event as a
    firmware crash signal when the modem hasn't actually crashed. See
    ath10k_qmi_event_server_exit() for more details.
    
    This silences the crash message seen during every reboot.
    
    Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990")
    Cc: Youghandhar Chintala <youghand@codeaurora.org>
    Cc: Abhishek Kumar <kuabhs@chromium.org>
    Cc: Steev Klimaszewski <steev@kali.org>
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Cc: Rakesh Pillai <pillair@codeaurora.org>
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Rakesh Pillai <pillair@codeaurora.org>
    Tested-By: Youghandhar Chintala <youghand@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210922233341.182624-1-swboyd@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff3487b0894939f5999bb8d906d52e1538216d4c
Author: Colin Ian King <colin.king@intel.com>
Date:   Fri Sep 17 18:07:02 2021 +0200

    media: em28xx: Don't use ops->suspend if it is NULL
    
    [ Upstream commit 51fa3b70d27342baf1ea8aaab3e96e5f4f26d5b2 ]
    
    The call to ops->suspend for the dev->dev_next case can currently
    trigger a call on a null function pointer if ops->suspend is null.
    Skip over the use of function ops->suspend if it is null.
    
    Addresses-Coverity: ("Dereference after null check")
    
    Fixes: be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner functionality")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9a0ff08a69ed13bf3eb3a1e751a0108c0f407e7
Author: Anel Orazgaliyeva <anelkz@amazon.de>
Date:   Mon Sep 6 18:34:40 2021 +0000

    cpuidle: Fix kobject memory leaks in error paths
    
    [ Upstream commit e5f5a66c9aa9c331da5527c2e3fd9394e7091e01 ]
    
    Commit c343bf1ba5ef ("cpuidle: Fix three reference count leaks")
    fixes the cleanup of kobjects; however, it removes kfree() calls
    altogether, leading to memory leaks.
    
    Fix those and also defer the initialization of dev->kobj_dev until
    after the error check, so that we do not end up with a dangling
    pointer.
    
    Fixes: c343bf1ba5ef ("cpuidle: Fix three reference count leaks")
    Signed-off-by: Anel Orazgaliyeva <anelkz@amazon.de>
    Suggested-by: Aman Priyadarshi <apeureka@amazon.de>
    [ rjw: Subject edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c95380ba527ae0aee29b2a133c5d0c481d472759
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 27 16:28:02 2021 +0200

    drm: fb_helper: fix CONFIG_FB dependency
    
    [ Upstream commit 606b102876e3741851dfb09d53f3ee57f650a52c ]
    
    With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
    
    aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function `drm_fb_helper_alloc_fbi':
    (.text+0x10cc): undefined reference to `framebuffer_alloc'
    
    Tighten the dependency so it is only allowed in the case that DRM can
    link against FB.
    
    Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
    Link: https://lore.kernel.org/all/20210721152211.2706171-1-arnd@kernel.org/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210927142816.2069269-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a213407573c6bcee43b9a334bae1effdb9337912
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 20 12:05:35 2021 +0200

    crypto: ecc - fix CRYPTO_DEFAULT_RNG dependency
    
    [ Upstream commit 38aa192a05f22f9778f9420e630f0322525ef12e ]
    
    The ecc.c file started out as part of the ECDH algorithm but got
    moved out into a standalone module later. It does not build without
    CRYPTO_DEFAULT_RNG, so now that other modules are using it as well we
    can run into this link error:
    
    aarch64-linux-ld: ecc.c:(.text+0xfc8): undefined reference to `crypto_default_rng'
    aarch64-linux-ld: ecc.c:(.text+0xff4): undefined reference to `crypto_put_default_rng'
    
    Move the 'select CRYPTO_DEFAULT_RNG' statement into the correct symbol.
    
    Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm")
    Fixes: 4e6602916bc6 ("crypto: ecdsa - Add support for ECDSA signature verification")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af18fe7671364698dc700166705378de50688605
Author: Punit Agrawal <punitagrawal@gmail.com>
Date:   Tue Sep 14 23:38:37 2021 +0900

    kprobes: Do not use local variable when creating debugfs file
    
    [ Upstream commit 8f7262cd66699a4b02eb7549b35c81b2116aad95 ]
    
    debugfs_create_file() takes a pointer argument that can be used during
    file operation callbacks (accessible via i_private in the inode
    structure). An obvious requirement is for the pointer to refer to
    valid memory when used.
    
    When creating the debugfs file to dynamically enable / disable
    kprobes, a pointer to local variable is passed to
    debugfs_create_file(); which will go out of scope when the init
    function returns. The reason this hasn't triggered random memory
    corruption is because the pointer is not accessed during the debugfs
    file callbacks.
    
    Since the enabled state is managed by the kprobes_all_disabled global
    variable, the local variable is not needed. Fix the incorrect (and
    unnecessary) usage of local variable during debugfs_file_create() by
    passing NULL instead.
    
    Link: https://lkml.kernel.org/r/163163031686.489837.4476867635937014973.stgit@devnote2
    
    Fixes: bf8f6e5b3e51 ("Kprobes: The ON/OFF knob thru debugfs")
    Signed-off-by: Punit Agrawal <punitagrawal@gmail.com>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69dce456e2be1b654abdf7c90a015d29a74b7195
Author: Yee Lee <yee.lee@mediatek.com>
Date:   Thu Sep 30 16:16:13 2021 +0800

    scs: Release kasan vmalloc poison in scs_free process
    
    [ Upstream commit 528a4ab45300fa6283556d9b48e26b45a8aa15c4 ]
    
    Since scs allocation is moved to vmalloc region, the
    shadow stack is protected by kasan_posion_vmalloc.
    However, the vfree_atomic operation needs to access
    its context for scs_free process and causes kasan error
    as the dump info below.
    
    This patch Adds kasan_unpoison_vmalloc() before vfree_atomic,
    which aligns to the prior flow as using kmem_cache.
    The vmalloc region will go back posioned in the following
    vumap() operations.
    
     ==================================================================
     BUG: KASAN: vmalloc-out-of-bounds in llist_add_batch+0x60/0xd4
     Write of size 8 at addr ffff8000100b9000 by task kthreadd/2
    
     CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.15.0-rc2-11681-g92477dd1faa6-dirty #1
     Hardware name: linux,dummy-virt (DT)
     Call trace:
      dump_backtrace+0x0/0x43c
      show_stack+0x1c/0x2c
      dump_stack_lvl+0x68/0x84
      print_address_description+0x80/0x394
      kasan_report+0x180/0x1dc
      __asan_report_store8_noabort+0x48/0x58
      llist_add_batch+0x60/0xd4
      vfree_atomic+0x60/0xe0
      scs_free+0x1dc/0x1fc
      scs_release+0xa4/0xd4
      free_task+0x30/0xe4
      __put_task_struct+0x1ec/0x2e0
      delayed_put_task_struct+0x5c/0xa0
      rcu_do_batch+0x62c/0x8a0
      rcu_core+0x60c/0xc14
      rcu_core_si+0x14/0x24
      __do_softirq+0x19c/0x68c
      irq_exit+0x118/0x2dc
      handle_domain_irq+0xcc/0x134
      gic_handle_irq+0x7c/0x1bc
      call_on_irq_stack+0x40/0x70
      do_interrupt_handler+0x78/0x9c
      el1_interrupt+0x34/0x60
      el1h_64_irq_handler+0x1c/0x2c
      el1h_64_irq+0x78/0x7c
      _raw_spin_unlock_irqrestore+0x40/0xcc
      sched_fork+0x4f0/0xb00
      copy_process+0xacc/0x3648
      kernel_clone+0x168/0x534
      kernel_thread+0x13c/0x1b0
      kthreadd+0x2bc/0x400
      ret_from_fork+0x10/0x20
    
     Memory state around the buggy address:
      ffff8000100b8f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      ffff8000100b8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
     >ffff8000100b9000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                        ^
      ffff8000100b9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      ffff8000100b9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
     ==================================================================
    
    Suggested-by: Kuan-Ying Lee <kuan-ying.lee@mediatek.com>
    Acked-by: Will Deacon <will@kernel.org>
    Tested-by: Will Deacon <will@kernel.org>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Yee Lee <yee.lee@mediatek.com>
    Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks")
    Link: https://lore.kernel.org/r/20210930081619.30091-1-yee.lee@mediatek.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43cfb5df9289e1334233d05f88d0f2d4b1750385
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Mon Sep 13 12:22:54 2021 +0200

    media: atmel: fix the ispck initialization
    
    [ Upstream commit d7f26849ed7cc875d0ff7480c2efebeeccea2bad ]
    
    The runtime enabling of the ISPCK (internally clocks the pipeline inside
    the ISC) has to be done after the pm_runtime for the ISC dev has been
    started.
    
    After the commit by Mauro:
    the ISC failed to probe with the error:
    
    atmel-sama5d2-isc f0008000.isc: failed to enable ispck: -13
    atmel-sama5d2-isc: probe of f0008000.isc failed with error -13
    
    This is because the enabling of the ispck is done too early in the probe,
    and the PM runtime returns invalid request.
    Thus, moved this clock enabling after pm_runtime_idle is called.
    
    The ISPCK is required only for sama5d2 type of ISC.
    Thus, add a bool inside the isc struct that is platform dependent.
    For the sama7g5-isc, the enabling of the ISPCK is wrong and does not make
    sense. Removed it from the sama7g5 probe. In sama7g5-isc, there is only
    one clock, the MCK, which also clocks the internal pipeline of the ISC.
    
    Adapted the clk_prepare and clk_unprepare to request the runtime PM
    for both clocks (MCK and ISPCK) in case of sama5d2-isc, and the single
    clock (MCK) in case of sama7g5-isc.
    
    Fixes: dd97908ee350 ("media: atmel: properly get pm_runtime")
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ead5a141ea2237093c5290103d7953d93c3a859f
Author: Colin Ian King <colin.king@intel.com>
Date:   Wed Aug 4 10:50:10 2021 +0200

    media: cx23885: Fix snd_card_free call on null card pointer
    
    [ Upstream commit 7266dda2f1dfe151b12ef0c14eb4d4e622fb211c ]
    
    Currently a call to snd_card_new that fails will set card with a NULL
    pointer, this causes a null pointer dereference on the error cleanup
    path when card it passed to snd_card_free. Fix this by adding a new
    error exit path that does not call snd_card_free and exiting via this
    new path.
    
    Addresses-Coverity: ("Explicit null dereference")
    
    Fixes: 9e44d63246a9 ("[media] cx23885: Add ALSA support")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a225627ba4ab02d258c87940436a39243ce7b29
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Aug 3 21:46:10 2021 +0200

    media: tm6000: Avoid card name truncation
    
    [ Upstream commit 42bb98e420d454fef3614b70ea11cc59068395f6 ]
    
    The "card" string only holds 31 characters (and the terminating NUL).
    In order to avoid truncation, use a shorter card description instead of
    the current result, "Trident TVMaster TM5600/6000/60".
    
    Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: e28f49b0b2a8 ("V4L/DVB: tm6000: fix some info messages")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afa370b5316f13c7319fe6581dfbeb921e613265
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Aug 3 21:46:09 2021 +0200

    media: si470x: Avoid card name truncation
    
    [ Upstream commit 2908249f3878a591f7918368fdf0b7b0a6c3158c ]
    
    The "card" string only holds 31 characters (and the terminating NUL).
    In order to avoid truncation, use a shorter card description instead of
    the current result, "Silicon Labs Si470x FM Radio Re".
    
    Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 78656acdcf48 ("V4L/DVB (7038): USB radio driver for Silicon Labs Si470x FM Radio Receivers")
    Fixes: cc35bbddfe10 ("V4L/DVB (12416): radio-si470x: add i2c driver for si470x")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccd29579f7e70b2b20551a0bc02442d4c86d5f4b
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Aug 3 21:46:08 2021 +0200

    media: radio-wl1273: Avoid card name truncation
    
    [ Upstream commit dfadec236aa99f6086141949c9dc3ec50f3ff20d ]
    
    The "card" string only holds 31 characters (and the terminating NUL).
    In order to avoid truncation, use a shorter card description instead of
    the current result, "Texas Instruments Wl1273 FM Rad".
    
    Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fd64cd9ffdeb2241f611c453a9e288523abc589
Author: Ondrej Jirman <megous@megous.com>
Date:   Wed Sep 8 12:56:09 2021 +0200

    media: sun6i-csi: Allow the video device to be open multiple times
    
    [ Upstream commit 8ed852834683ebe064157e069af8dfb41cad6403 ]
    
    Previously it was possible, but a recent fix for uninitialized
    `ret` variable broke this behavior.
    
    v4l2_fh_is_singular_file() check is there just to determine
    whether the power needs to be enabled, and it's not a failure
    if it returns false.
    
    Fixes: ba9139116bc0 ("media: sun6i-csi: add a missing return code")
    Signed-off-by: Ondrej Jirman <megous@megous.com>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e44fa27c650fd644cc843afa3b0b9e7b1928a1bb
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Sep 5 01:28:08 2021 +0200

    media: i2c: ths8200 needs V4L2_ASYNC
    
    [ Upstream commit e4625044d656f3c33ece0cc9da22577bc10ca5d3 ]
    
    Fix the build errors reported by the kernel test robot by
    selecting V4L2_ASYNC:
    
    mips-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_remove':
    ths8200.c:(.text+0x1ec): undefined reference to `v4l2_async_unregister_subdev'
    mips-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_probe':
    ths8200.c:(.text+0x404): undefined reference to `v4l2_async_register_subdev'
    
    Fixes: ed29f89497006 ("media: i2c: ths8200: support asynchronous probing")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Lad Prabhakar <prabhakar.csengg@gmail.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b0b7b8a2ba5d6874cbbc66df0bec984bafc2dd9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 21 13:12:53 2021 +0200

    media: imx-jpeg: Fix the error handling path of 'mxc_jpeg_probe()'
    
    [ Upstream commit 5c47dc6657543b3c4dffcbe741fb693b9b96796d ]
    
    A successful 'mxc_jpeg_attach_pm_domains()' call should be balanced by a
    corresponding 'mxc_jpeg_detach_pm_domains()' call in the error handling
    path of the probe, as already done in the remove function.
    
    Update the error handling path accordingly.
    
    Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56bc844703f075a5bd17cac76fce659bcc53b9a9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Aug 19 22:21:25 2021 +0200

    media: mtk-vpu: Fix a resource leak in the error handling path of 'mtk_vpu_probe()'
    
    [ Upstream commit 2143ad413c05c7be24c3a92760e367b7f6aaac92 ]
    
    A successful 'clk_prepare()' call should be balanced by a corresponding
    'clk_unprepare()' call in the error handling path of the probe, as already
    done in the remove function.
    
    Update the error handling path accordingly.
    
    Fixes: 3003a180ef6b ("[media] VPU: mediatek: support Mediatek VPU")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Houlong Wei <houlong.wei@mediatek.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a2ab1ce79ba47361335bb3ac546162849e75ca9
Author: Tom Rix <trix@redhat.com>
Date:   Thu Aug 12 19:00:43 2021 +0200

    media: TDA1997x: handle short reads of hdmi info frame.
    
    [ Upstream commit 48d219f9cc667bc6fbc3e3af0b1bfd75db94fce4 ]
    
    Static analysis reports this representative problem
    
    tda1997x.c:1939: warning: 7th function call argument is an uninitialized
    value
    
    The 7th argument is buffer[0], which is set in the earlier call to
    io_readn().  When io_readn() call to io_read() fails with the first
    read, buffer[0] is not set and 0 is returned and stored in len.
    
    The later call to hdmi_infoframe_unpack()'s size parameter is the
    static size of buffer, always 40, so a short read is not caught
    in hdmi_infoframe_unpacks()'s checking.  The variable len should be
    used instead.
    
    Zero initialize buffer to 0 so it is in a known start state.
    
    Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7f187649c245bff662911cf876cfaece507278f
Author: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Date:   Fri May 28 10:36:41 2021 +0200

    media: mtk-vcodec: venc: fix return value when start_streaming fails
    
    [ Upstream commit 065a7c66bd8b21db212fa86187ff12f0cac6ea6d ]
    
    In case vb2ops_venc_start_streaming fails, the error value
    is overwritten by the ret value of pm_runtime_put which might
    be 0. Fix it.
    
    Fixes: 985c73693fe5a (" media: mtk-vcodec: Separating mtk encoder driver")
    Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f0ea72e4a34b281564019c3c4c89dea26b115b2
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Fri Jun 18 14:29:06 2021 +0200

    media: v4l2-ioctl: S_CTRL output the right value
    
    [ Upstream commit c87ed93574e3cd8346c05bd934c617596c12541b ]
    
    If the driver does not implement s_ctrl, but it does implement
    s_ext_ctrls, we convert the call.
    
    When that happens we have also to convert back the response from
    s_ext_ctrls.
    
    Fixes v4l2_compliance:
    Control ioctls (Input 0):
                    fail: v4l2-test-controls.cpp(411): returned control value out of range
                    fail: v4l2-test-controls.cpp(507): invalid control 00980900
            test VIDIOC_G/S_CTRL: FAIL
    
    Fixes: 35ea11ff8471 ("V4L/DVB (8430): videodev: move some functions from v4l2-dev.h to v4l2-common.h or v4l2-ioctl.h")
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e14a3d9f768dec6e5e9ccd13a6856cb305e2a0f
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Mon Aug 16 15:08:59 2021 +0200

    media: imx258: Fix getting clock frequency
    
    [ Upstream commit d170b0ea1760989fe8ac053bef83e61f3bf87992 ]
    
    Obtain the clock frequency by reading the clock-frequency property if
    there's no clock.
    
    Fixes: 9fda25332c4b ("media: i2c: imx258: get clock from device properties and enable it via runtime PM")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d30d3397db1ebfd29c70aabf693af4df9281d668
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Aug 13 16:34:20 2021 +0200

    media: dvb-usb: fix ununit-value in az6027_rc_query
    
    [ Upstream commit afae4ef7d5ad913cab1316137854a36bea6268a5 ]
    
    Syzbot reported ununit-value bug in az6027_rc_query(). The problem was
    in missing state pointer initialization. Since this function does nothing
    we can simply initialize state to REMOTE_NO_KEY_PRESSED.
    
    Reported-and-tested-by: syzbot+2cd8c5db4a85f0a04142@syzkaller.appspotmail.com
    
    Fixes: 76f9a820c867 ("V4L/DVB: AZ6027: Initial import of the driver")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98cb3a055b18cee34e78dc4249a0eb539ce9eee3
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Tue Jul 20 11:28:27 2021 +0200

    media: ttusb-dec: avoid release of non-acquired mutex
    
    [ Upstream commit 36b9d695aa6fb8e9a312db21af41f90824d16ab4 ]
    
    ttusb_dec_send_command() invokes mutex_lock_interruptible() that can
    fail but then it releases the non-acquired mutex. The patch fixes that.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: dba328bab4c6 ("media: ttusb-dec: cleanup an error handling logic")
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8b2ae89671d42483ec880acdf2a7d3b607bd31e
Author: Colin Ian King <colin.king@intel.com>
Date:   Tue Jul 20 18:07:49 2021 +0200

    media: cxd2880-spi: Fix a null pointer dereference on error handling path
    
    [ Upstream commit 11b982e950d2138e90bd120501df10a439006ff8 ]
    
    Currently the null pointer check on dvb_spi->vcc_supply is inverted and
    this leads to only null values of the dvb_spi->vcc_supply being passed
    to the call of regulator_disable causing null pointer dereferences.
    Fix this by only calling regulator_disable if dvb_spi->vcc_supply is
    not null.
    
    Addresses-Coverity: ("Dereference after null check")
    
    Fixes: dcb014582101 ("media: cxd2880-spi: Fix an error handling path")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6100e16716e69eba4191fb0af157cff74d7a806
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Jul 30 21:35:05 2021 +0200

    media: meson-ge2d: Fix rotation parameter changes detection in 'ge2d_s_ctrl()'
    
    [ Upstream commit 4b9e3e8af4b336eefca1f1ee535bc4b6734ed6aa ]
    
    There is likely a typo here. To be consistent, we should compare
    'fmt.height' with 'ctx->out.pix_fmt.height', not 'ctx->out.pix_fmt.width'.
    
    Instead of fixing the test, just remove it and copy 'fmt' unconditionally.
    
    Fixes: 59a635327ca7 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2899243f272f8801dceb1bb692bd1a3ae3f281c2
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jul 29 22:23:33 2021 +0200

    media: em28xx: add missing em28xx_close_extension
    
    [ Upstream commit 2c98b8a3458df03abdc6945bbef67ef91d181938 ]
    
    If em28xx dev has ->dev_next pointer, we need to delete ->dev_next list
    node from em28xx_extension_devlist on disconnect to avoid UAF bugs and
    corrupted list bugs, since driver frees this pointer on disconnect.
    
    Reported-and-tested-by: syzbot+a6969ef522a36d3344c9@syzkaller.appspotmail.com
    
    Fixes: 1a23f81b7dc3 ("V4L/DVB (9979): em28xx: move usb probe code to a proper place")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6a908c5935daa080fac13f0d82086fb5643f3a5
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Mon Sep 27 20:29:39 2021 +0530

    libbpf: Fix skel_internal.h to set errno on loader retval < 0
    
    [ Upstream commit e68ac0082787f4e8ee6ae5b19076ec7709ce715b ]
    
    When the loader indicates an internal error (result of a checked bpf
    system call), it returns the result in attr.test.retval. However, tests
    that rely on ASSERT_OK_PTR on NULL (returned from light skeleton) may
    miss that NULL denotes an error if errno is set to 0. This would result
    in skel pointer being NULL, while ASSERT_OK_PTR returning 1, leading to
    a SEGV on dereference of skel, because libbpf_get_error relies on the
    assumption that errno is always set in case of error for ptr == NULL.
    
    In particular, this was observed for the ksyms_module test. When
    executed using `./test_progs -t ksyms`, prior tests manipulated errno
    and the test didn't crash when it failed at ksyms_module load, while
    using `./test_progs -t ksyms_module` crashed due to errno being
    untouched.
    
    Fixes: 67234743736a (libbpf: Generate loader program out of BPF ELF file.)
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20210927145941.1383001-11-memxor@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 798419802590614d3987ab9346edcebfb7da40ad
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Sep 27 14:58:10 2021 +0200

    drm/amdgpu: fix warning for overflow check
    
    [ Upstream commit 335aea75b0d95518951cad7c4c676e6f1c02c150 ]
    
    The overflow check in amdgpu_bo_list_create() causes a warning with
    clang-14 on 64-bit architectures, since the limit can never be
    exceeded.
    
    drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison of constant 256204778801521549 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (num_entries > (SIZE_MAX - sizeof(struct amdgpu_bo_list))
                ~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The check remains useful for 32-bit architectures, so just avoid the
    warning by using size_t as the type for the count.
    
    Fixes: 920990cb080a ("drm/amdgpu: allocate the bo_list array after the list")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09732e205684a9b8b477008df2fa4f34c4501863
Author: Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>
Date:   Tue Sep 28 11:51:49 2021 -0700

    arm64: mm: update max_pfn after memory hotplug
    
    [ Upstream commit 8fac67ca236b961b573355e203dbaf62a706a2e5 ]
    
    After new memory blocks have been hotplugged, max_pfn and max_low_pfn
    needs updating to reflect on new PFNs being hot added to system.
    Without this patch, debug-related functions that use max_pfn such as
    get_max_dump_pfn() or read_page_owner() will not work with any page in
    memory that is hot-added after boot.
    
    Fixes: 4ab215061554 ("arm64: Add memory hotplug support")
    Signed-off-by: Sudarshan Rajagopalan <quic_sudaraja@quicinc.com>
    Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Georgi Djakov <quic_c_gdjako@quicinc.com>
    Tested-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
    Link: https://lore.kernel.org/r/a51a27ee7be66024b5ce626310d673f24107bcb8.1632853776.git.quic_cgoldswo@quicinc.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 410a0f42ced0046466e0fded3b171d256c98563e
Author: Matthew Auld <matthew.auld@intel.com>
Date:   Mon Sep 27 12:41:02 2021 +0100

    drm/ttm: stop calling tt_swapin in vm_access
    
    [ Upstream commit f5d28856b89baab4232a9f841e565763fcebcdf9 ]
    
    In commit:
    
    commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
    Author: Felix Kuehling <Felix.Kuehling@amd.com>
    Date:   Thu Jul 13 17:01:16 2017 -0400
    
        drm/ttm: Implement vm_operations_struct.access v2
    
    we added the vm_access hook, where we also directly call tt_swapin for
    some reason. If something is swapped-out then the ttm_tt must also be
    unpopulated, and since access_kmap should also call tt_populate, if
    needed, then swapping-in will already be handled there.
    
    If anything, calling tt_swapin directly here would likely always fail
    since the tt->pages won't yet be populated, or worse since the tt->pages
    array is never actually cleared in unpopulate this might lead to a nasty
    uaf.
    
    Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
    Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Cc: Christian König <christian.koenig@amd.com>
    Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210927114114.152310-1-matthew.auld@intel.com
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 092e6cb650ebeae4540fd3844d25a8688566bf32
Author: Fabio Estevam <festevam@denx.de>
Date:   Tue Sep 28 14:00:47 2021 +0300

    ath10k: sdio: Add missing BH locking around napi_schdule()
    
    [ Upstream commit 019edd01d174ce4bb2e517dd332922514d176601 ]
    
    On a i.MX-based board with a QCA9377 Wifi chip, the following errors
    are seen after launching the 'hostapd' application:
    
    hostapd /etc/wifi.conf
    Configuration file: /etc/wifi.conf
    wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
    NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
    Using interface wlan0 with hwaddr 00:1f:7b:31:04:a0 and ssid "thessid"
    IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
    wlan0: interface state COUNTRY_UPDATE->ENABLED
    wlan0: AP-ENABLED
    NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
    NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
    NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
    NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
    ...
    
    Fix this problem by adding the BH locking around napi-schedule(),
    in the same way it was done in commit e63052a5dd3c ("mlx5e: add
    add missing BH locking around napi_schdule()").
    
    Its commit log provides the following explanation:
    
    "It's not correct to call napi_schedule() in pure process
    context. Because we use __raise_softirq_irqoff() we require
    callers to be in a context which will eventually lead to
    softirq handling (hardirq, bh disabled, etc.).
    
    With code as is users will see:
    
    NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
    "
    
    Fixes: cfee8793a74d ("ath10k: enable napi on RX path for sdio")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210824144339.2796122-1-festevam@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63287a77b1382bfbc9f9ce57fcf64534bb31a273
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Tue Sep 28 14:00:47 2021 +0300

    ath10k: Fix missing frame timestamp for beacon/probe-resp
    
    [ Upstream commit e6dfbc3ba90cc2b619229be56b485f085a0a8e1c ]
    
    When receiving a beacon or probe response, we should update the
    boottime_ns field which is the timestamp the frame was received at.
    (cf mac80211.h)
    
    This fixes a scanning issue with Android since it relies on this
    timestamp to determine when the AP has been seen for the last time
    (via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter).
    
    Fixes: 5e3dd157d7e7 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1629811733-7927-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cef58d2c34667e34181be36f4950fdc0ab30e068
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Sep 28 16:15:13 2021 +0200

    gve: DQO: avoid unused variable warnings
    
    [ Upstream commit 1e0083bd0777e4a418a6710d9ee04b979cdbe5cc ]
    
    The use of dma_unmap_addr()/dma_unmap_len() in the driver causes
    multiple warnings when these macros are defined as empty, e.g.
    in an ARCH=i386 allmodconfig build:
    
    drivers/net/ethernet/google/gve/gve_tx_dqo.c: In function 'gve_tx_add_skb_no_copy_dqo':
    drivers/net/ethernet/google/gve/gve_tx_dqo.c:494:40: error: unused variable 'buf' [-Werror=unused-variable]
      494 |                 struct gve_tx_dma_buf *buf =
    
    This is not how the NEED_DMA_MAP_STATE macros are meant to work,
    as they rely on never using local variables or a temporary structure
    like gve_tx_dma_buf.
    
    Remote the gve_tx_dma_buf definition and open-code the contents
    in all places to avoid the warning. This causes some rather long
    lines but otherwise ends up making the driver slightly smaller.
    
    Fixes: a57e5de476be ("gve: DQO: Add TX path")
    Link: https://lore.kernel.org/netdev/20210723231957.1113800-1-bcf@google.com/
    Link: https://lore.kernel.org/netdev/20210721151100.2042139-1-arnd@kernel.org/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b955d5d60389e8c65c816d1c6f28188b1d4ebba
Author: Baochen Qiang <bqiang@codeaurora.org>
Date:   Tue Sep 28 14:00:44 2021 +0300

    ath11k: Fix memory leak in ath11k_qmi_driver_event_work
    
    [ Upstream commit 72de799aa9e3e064b35238ef053d2f0a49db055a ]
    
    The buffer pointed to by event is not freed in case
    ATH11K_FLAG_UNREGISTERING bit is set, resulting in
    memory leak, so fix it.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210913180246.193388-4-jouni@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3ccc878b5fb9c8a19bdfd59c117c5b8e865761b
Author: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Date:   Tue Sep 28 14:00:43 2021 +0300

    ath11k: fix packet drops due to incorrect 6 GHz freq value in rx status
    
    [ Upstream commit 9d6ae1f5cf733c0e8d7f904c501fd015c4b9f0f4 ]
    
    Frequency in rx status is being filled incorrectly in the 6 GHz band as
    channel number received is invalid in this case which is causing packet
    drops. So fix that.
    
    Fixes: 5dcf42f8b79d ("ath11k: Use freq instead of channel number in rx path")
    Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210722102054.43419-2-jouni@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b087c2fc0d7667e25c7b68679363a3869db8e96
Author: Sriram R <srirrama@codeaurora.org>
Date:   Tue Sep 28 12:05:40 2021 +0300

    ath11k: Avoid race during regd updates
    
    [ Upstream commit 1db2b0d0a39102238fcbf9092cefa65a710642e9 ]
    
    Whenever ath11k is bootup with a user country already set, cfg80211
    notifies this country info to ath11k soon after registration, where the
    notification is sent to the firmware for fetching the rules of this user
    country input.
    
    Multiple race conditions could be seen in this scenario where a new
    request is either lost as pointed in [1] or a new regd overwrites the
    default regd provided by the firmware during bootup. Note that, the
    default regd is used for intersection purpose and hence it should not be
    overwritten.
    
    The main reason as pointed by [1] is the usage of ATH11K_FLAG_REGISTERED
    flag which is updated after completion of core registration, whereas the
    reg notification from cfg80211 and wmi events for the corresponding
    request can happen much before that. Since the ATH11K_FLAG_REGISTERED is
    currently used to determine if the event containing reg rules belong to
    default regd or for user request, there is a possibility of the default
    regd getting overwritten.
    
    Since the default reg rules will be received only once per pdev on
    firmware load, the above flag based check can be replaced with a check
    to see if default_regd is already set, so that we can now always update
    the new_regd. Also if the new_regd is set, this will be always used to
    update the reg rules for the registered phy.
    
    [1] https://patchwork.kernel.org/project/linux-wireless/patch/1829665.1PRlr7bOQj@ripper/
    
    Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01460-QCAHKSWPL_SILICONZ-1
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    
    Signed-off-by: Sriram R <srirrama@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210721212029.142388-4-jouni@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b59c76797e62eaa62d97ccc4af744f2508393e1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 28 12:05:43 2021 +0300

    ath11k: fix some sleeping in atomic bugs
    
    [ Upstream commit aadf7c81a0771b8f1c97dabca6a48bae1b387779 ]
    
    The ath11k_dbring_bufs_replenish() and ath11k_dbring_fill_bufs()
    take a "gfp" parameter but they since they take spinlocks, the
    allocations they do have to be atomic.  This causes a bug because
    ath11k_dbring_buf_setup passes GFP_KERNEL for the gfp flags.
    
    The fix is to use GFP_ATOMIC and remove the unused parameters.
    
    Fixes: bd6478559e27 ("ath11k: Add direct buffer ring support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210812070434.GE31863@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1ddaa5dcef63c8083cb2e3a8a4ea14a7fd04bc2
Author: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Date:   Tue Sep 14 11:18:41 2021 +0200

    bpf/tests: Fix error in tail call limit tests
    
    [ Upstream commit 18935a72eb25525b655262579e1652362a3b29bb ]
    
    This patch fixes an error in the tail call limit test that caused the
    test to fail on for x86-64 JIT. Previously, the register R0 was used to
    report the total number of tail calls made. However, after a tail call
    fall-through, the value of the R0 register is undefined. Now, all tail
    call error path tests instead use context state to store the count.
    
    Fixes: 874be05f525e ("bpf, tests: Add tail call test suite")
    Reported-by: Paul Chaignon <paul@cilium.io>
    Reported-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Link: https://lore.kernel.org/bpf/20210914091842.4186267-14-johan.almbladh@anyfinetworks.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 739b92765e0463cbb612d8e0efe3ac0fab70cafb
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sun Sep 26 00:59:28 2021 +0200

    net: dsa: rtl8366: Fix a bug in deleting VLANs
    
    [ Upstream commit d8251b9db34a2cbc5619b610e7e8aad1d165c531 ]
    
    We were checking that the MC (member config) was != 0
    for some reason, all we need to check is that the config
    has no ports, i.e. no members. Then it can be recycled.
    This must be some misunderstanding.
    
    Fixes: 4ddcaf1ebb5e ("net: dsa: rtl8366: Properly clear member config")
    Cc: Mauri Sandberg <sandberg@mailfence.com>
    Cc: DENG Qingfang <dqfext@gmail.com>
    Reviewed-by: Alvin Å ipraga <alsi@bang-olufsen.dk>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57e4d980b7fe9da03b1a95ad8e3752d37b5e6278
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sun Sep 26 00:59:27 2021 +0200

    net: dsa: rtl8366rb: Fix off-by-one bug
    
    [ Upstream commit 5f5f12f5d4b108399130bb5c11f07765851d9cdb ]
    
    The max VLAN number with non-4K VLAN activated is 15, and the
    range is 0..15. Not 16.
    
    The impact should be low since we by default have 4K VLAN and
    thus have 4095 VLANs to play with in this switch. There will
    not be a problem unless the code is rewritten to only use
    16 VLANs.
    
    Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
    Cc: Mauri Sandberg <sandberg@mailfence.com>
    Cc: DENG Qingfang <dqfext@gmail.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Alvin Å ipraga <alsi@bang-olufsen.dk>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9cc25e8529d567e08da98d11f092b21449763144
Author: Leon Romanovsky <leon@kernel.org>
Date:   Sat Sep 25 14:22:50 2021 +0300

    net/mlx5: Accept devlink user input after driver initialization complete
    
    [ Upstream commit 64ea2d0e7263b67d8efc93fa1baace041ed36d1e ]
    
    The change of devlink_alloc() to accept device makes sure that device
    is fully initialized and device_register() does nothing except allowing
    users to use that devlink instance.
    
    Such change ensures that no user input will be usable till that point and
    it eliminates the need to worry about internal locking as long as devlink_register
    is called last since all accesses to the devlink are during initialization.
    
    This change fixes the following lockdep warning.
    
     ======================================================
     WARNING: possible circular locking dependency detected
     5.14.0-rc2+ #27 Not tainted
     ------------------------------------------------------
     devlink/265 is trying to acquire lock:
     ffff8880133c2bc0 (&dev->intf_state_mutex){+.+.}-{3:3}, at: mlx5_unload_one+0x1e/0xa0 [mlx5_core]
     but task is already holding lock:
     ffffffff8362b468 (devlink_mutex){+.+.}-{3:3}, at: devlink_nl_pre_doit+0x2b/0x8d0
     which lock already depends on the new lock.
     the existing dependency chain (in reverse order) is:
    
     -> #1 (devlink_mutex){+.+.}-{3:3}:
            __mutex_lock+0x149/0x1310
            devlink_register+0xe7/0x280
            mlx5_devlink_register+0x118/0x480 [mlx5_core]
            mlx5_init_one+0x34b/0x440 [mlx5_core]
            probe_one+0x480/0x6e0 [mlx5_core]
            pci_device_probe+0x2a0/0x4a0
            really_probe+0x1cb/0xba0
            __driver_probe_device+0x18f/0x470
            driver_probe_device+0x49/0x120
            __driver_attach+0x1ce/0x400
            bus_for_each_dev+0x11e/0x1a0
            bus_add_driver+0x309/0x570
            driver_register+0x20f/0x390
            0xffffffffa04a0062
            do_one_initcall+0xd5/0x400
            do_init_module+0x1c8/0x760
            load_module+0x7d9d/0xa4b0
            __do_sys_finit_module+0x118/0x1a0
            do_syscall_64+0x3d/0x90
            entry_SYSCALL_64_after_hwframe+0x44/0xae
    
     -> #0 (&dev->intf_state_mutex){+.+.}-{3:3}:
            __lock_acquire+0x2999/0x5a40
            lock_acquire+0x1a9/0x4a0
            __mutex_lock+0x149/0x1310
            mlx5_unload_one+0x1e/0xa0 [mlx5_core]
            mlx5_devlink_reload_down+0x185/0x2b0 [mlx5_core]
            devlink_reload+0x1f2/0x640
            devlink_nl_cmd_reload+0x6c3/0x10d0
            genl_family_rcv_msg_doit+0x1e9/0x2f0
            genl_rcv_msg+0x27f/0x4a0
            netlink_rcv_skb+0x11e/0x340
            genl_rcv+0x24/0x40
            netlink_unicast+0x433/0x700
            netlink_sendmsg+0x6fb/0xbe0
            sock_sendmsg+0xb0/0xe0
            __sys_sendto+0x192/0x240
            __x64_sys_sendto+0xdc/0x1b0
            do_syscall_64+0x3d/0x90
            entry_SYSCALL_64_after_hwframe+0x44/0xae
    
     other info that might help us debug this:
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(devlink_mutex);
                                    lock(&dev->intf_state_mutex);
                                    lock(devlink_mutex);
       lock(&dev->intf_state_mutex);
    
      *** DEADLOCK ***
    
     3 locks held by devlink/265:
      #0: ffffffff836371d0 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
      #1: ffffffff83637288 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0x31a/0x4a0
      #2: ffffffff8362b468 (devlink_mutex){+.+.}-{3:3}, at: devlink_nl_pre_doit+0x2b/0x8d0
    
     stack backtrace:
     CPU: 0 PID: 265 Comm: devlink Not tainted 5.14.0-rc2+ #27
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
     Call Trace:
      dump_stack_lvl+0x45/0x59
      check_noncircular+0x268/0x310
      ? print_circular_bug+0x460/0x460
      ? __kernel_text_address+0xe/0x30
      ? alloc_chain_hlocks+0x1e6/0x5a0
      __lock_acquire+0x2999/0x5a40
      ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
      ? add_lock_to_list.constprop.0+0x6c/0x530
      lock_acquire+0x1a9/0x4a0
      ? mlx5_unload_one+0x1e/0xa0 [mlx5_core]
      ? lock_release+0x6c0/0x6c0
      ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
      ? lock_is_held_type+0x98/0x110
      __mutex_lock+0x149/0x1310
      ? mlx5_unload_one+0x1e/0xa0 [mlx5_core]
      ? lock_is_held_type+0x98/0x110
      ? mlx5_unload_one+0x1e/0xa0 [mlx5_core]
      ? find_held_lock+0x2d/0x110
      ? mutex_lock_io_nested+0x1160/0x1160
      ? mlx5_lag_is_active+0x72/0x90 [mlx5_core]
      ? lock_downgrade+0x6d0/0x6d0
      ? do_raw_spin_lock+0x12e/0x270
      ? rwlock_bug.part.0+0x90/0x90
      ? mlx5_unload_one+0x1e/0xa0 [mlx5_core]
      mlx5_unload_one+0x1e/0xa0 [mlx5_core]
      mlx5_devlink_reload_down+0x185/0x2b0 [mlx5_core]
      ? netlink_broadcast_filtered+0x308/0xac0
      ? mlx5_devlink_info_get+0x1f0/0x1f0 [mlx5_core]
      ? __build_skb_around+0x110/0x2b0
      ? __alloc_skb+0x113/0x2b0
      devlink_reload+0x1f2/0x640
      ? devlink_unregister+0x1e0/0x1e0
      ? security_capable+0x51/0x90
      devlink_nl_cmd_reload+0x6c3/0x10d0
      ? devlink_nl_cmd_get_doit+0x1e0/0x1e0
      ? devlink_nl_pre_doit+0x72/0x8d0
      genl_family_rcv_msg_doit+0x1e9/0x2f0
      ? __lock_acquire+0x15e2/0x5a40
      ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240
      ? mutex_lock_io_nested+0x1160/0x1160
      ? security_capable+0x51/0x90
      genl_rcv_msg+0x27f/0x4a0
      ? genl_get_cmd+0x3c0/0x3c0
      ? lock_acquire+0x1a9/0x4a0
      ? devlink_nl_cmd_get_doit+0x1e0/0x1e0
      ? lock_release+0x6c0/0x6c0
      netlink_rcv_skb+0x11e/0x340
      ? genl_get_cmd+0x3c0/0x3c0
      ? netlink_ack+0x930/0x930
      genl_rcv+0x24/0x40
      netlink_unicast+0x433/0x700
      ? netlink_attachskb+0x750/0x750
      ? __alloc_skb+0x113/0x2b0
      netlink_sendmsg+0x6fb/0xbe0
      ? netlink_unicast+0x700/0x700
      ? netlink_unicast+0x700/0x700
      sock_sendmsg+0xb0/0xe0
      __sys_sendto+0x192/0x240
      ? __x64_sys_getpeername+0xb0/0xb0
      ? do_sys_openat2+0x10a/0x370
      ? down_write_nested+0x150/0x150
      ? do_user_addr_fault+0x215/0xd50
      ? __x64_sys_openat+0x11f/0x1d0
      ? __x64_sys_open+0x1a0/0x1a0
      __x64_sys_sendto+0xdc/0x1b0
      ? syscall_enter_from_user_mode+0x1d/0x50
      do_syscall_64+0x3d/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f50b50b6b3a
     Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 c3 0f 1f 44 00 00 55 48 83 ec 30 44 89 4c
     RSP: 002b:00007fff6c0d3f38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
     RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f50b50b6b3a
     RDX: 0000000000000038 RSI: 000055763ac08440 RDI: 0000000000000003
     RBP: 000055763ac08410 R08: 00007f50b5192200 R09: 000000000000000c
     R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
     R13: 0000000000000000 R14: 000055763ac08410 R15: 000055763ac08440
     mlx5_core 0000:00:09.0: firmware version: 4.8.9999
     mlx5_core 0000:00:09.0: 0.000 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x255 link)
     mlx5_core 0000:00:09.0 eth1: Link up
    
    Fixes: a6f3b62386a0 ("net/mlx5: Move devlink registration before interfaces load")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfaf70338314e153327b873dc0f332c59d34a7c0
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Sep 27 13:11:06 2021 +0200

    cfg80211: always free wiphy specific regdomain
    
    [ Upstream commit e53e9828a8d2c6545e01ff9711f1221f2fd199ce ]
    
    In the (somewhat unlikely) event that we allocate a wiphy, then
    add a regdomain to it, and then fail registration, we leak the
    regdomain. Fix this by just always freeing it at the end, in the
    normal cases we'll free (and NULL) it during wiphy_unregister().
    This happened when the wiphy settings were bad, and since they
    can be controlled by userspace with hwsim, syzbot was able to
    find this issue.
    
    Reported-by: syzbot+1638e7c770eef6b6c0d0@syzkaller.appspotmail.com
    Fixes: 3e0c3ff36c4c ("cfg80211: allow multiple driver regulatory_hints()")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://lore.kernel.org/r/20210927131105.68b70cef4674.I4b9f0aa08c2af28555963b9fe3d34395bb72e0cc@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6adf16c2e5a2d32ca29c097282c18a51da5f9b60
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Sep 27 11:51:24 2021 +0200

    mac80211: twt: don't use potentially unaligned pointer
    
    [ Upstream commit 7ff379ba2d4b7b205240e666601fe302207d73f8 ]
    
    Since we're pointing into a frame, the pointer to the
    twt_agrt->req_type struct member is potentially not
    aligned properly. Open-code le16p_replace_bits() to
    avoid passing an unaligned pointer.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: f5a4c24e689f ("mac80211: introduce individual TWT support in AP mode")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://lore.kernel.org/r/20210927115124.e1208694f37b.Ie3de9bcc5dde5a79e3ac81f3185beafe4d214e57@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80adbd8c450235c6618311103ab578190a80bfd0
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Aug 2 10:25:01 2021 -0700

    fortify: Fix dropped strcpy() compile-time write overflow check
    
    [ Upstream commit 072af0c638dc8a5c7db2edc4dddbd6d44bee3bdb ]
    
    The implementation for intra-object overflow in str*-family functions
    accidentally dropped compile-time write overflow checking in strcpy(),
    leaving it entirely to run-time. Add back the intended check.
    
    Fixes: 6a39e62abbaf ("lib: string.h: detect intra-object overflow in fortified string functions")
    Cc: Daniel Axtens <dja@axtens.net>
    Cc: Francis Laniel <laniel_francis@privacyrequired.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9f95c678318e47be6c0981c305b39d0276e687c
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Sep 24 14:12:34 2021 -0700

    mptcp: do not shrink snd_nxt when recovering
    
    [ Upstream commit 0d199e4363b482badcedba764e2aceab53a4a10a ]
    
    When recovering after a link failure, snd_nxt should not be set to a
    lower value.  Else, update of snd_nxt is broken because:
    
      msk->snd_nxt += ret; (where ret is number of bytes sent)
    
    assumes that snd_nxt always moves forward.
    After reduction, its possible that snd_nxt update gets out of sync:
    dfrag we just sent might have had a data sequence number even past
    recovery_snd_nxt.
    
    This change factors the common msk state update to a helper
    and updates snd_nxt based on the current dfrag data sequence number.
    
    The conditional is required for the recovery phase where we may
    re-transmit old dfrags that are before current snd_nxt.
    
    After this change, snd_nxt only moves forward and covers all in-sequence
    data that was transmitted.
    
    recovery_snd_nxt is retained to detect when recovery has completed.
    
    Fixes: 1e1d9d6f119c5 ("mptcp: handle pending data on closed subflow")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eade470b4351f9989cac161ee96531a40fa19825
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Sep 24 03:18:37 2021 +0000

    rxrpc: Fix _usecs_to_jiffies() by using usecs_to_jiffies()
    
    [ Upstream commit acde891c243c1ed85b19d4d5042bdf00914f5739 ]
    
    Directly using _usecs_to_jiffies() might be unsafe, so it's
    better to use usecs_to_jiffies() instead.
    Because we can see that the result of _usecs_to_jiffies()
    could be larger than MAX_JIFFY_OFFSET values without the
    check of the input.
    
    Fixes: c410bf01933e ("Fix the excessive initial retransmission timeout")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fcd75ee91592bc61f19adedc26c5a40ae88352e
Author: Leon Romanovsky <leon@kernel.org>
Date:   Thu Sep 23 21:12:53 2021 +0300

    qed: Don't ignore devlink allocation failures
    
    [ Upstream commit e6a54d6f221301347aaf9d83bb1f23129325c1c5 ]
    
    devlink is a software interface that doesn't depend on any hardware
    capabilities. The failure in SW means memory issues, wrong parameters,
    programmer error e.t.c.
    
    Like any other such interface in the kernel, the returned status of
    devlink APIs should be checked and propagated further and not ignored.
    
    Fixes: 755f982bb1ff ("qed/qede: make devlink survive recovery")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af484a1cde06f46b575a49743fda89faf4f33f64
Author: Leon Romanovsky <leon@kernel.org>
Date:   Thu Sep 23 21:12:48 2021 +0300

    bnxt_en: Check devlink allocation and registration status
    
    [ Upstream commit e624c70e1131e145bd0510b8a700b5e2d112e377 ]
    
    devlink is a software interface that doesn't depend on any hardware
    capabilities. The failure in SW means memory issues, wrong parameters,
    programmer error e.t.c.
    
    Like any other such interface in the kernel, the returned status of
    devlink APIs should be checked and propagated further and not ignored.
    
    Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4ecf64c0d10d57cf9b3a52247234d7dd7a3fa9b
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Sep 20 14:57:39 2021 +0200

    Bluetooth: hci_h5: Fix (runtime)suspend issues on RTL8723BS HCIs
    
    [ Upstream commit 9a9023f314873241a43b5a2b96e9c0caaa958433 ]
    
    The recently added H5_WAKEUP_DISABLE h5->flags flag gets checked in
    h5_btrtl_open(), but it gets set in h5_serdev_probe() *after*
    calling  hci_uart_register_device() and thus after h5_btrtl_open()
    is called, set this flag earlier.
    
    Also on devices where suspend/resume involves fully re-probing the HCI,
    runtime-pm suspend should not be used, make the runtime-pm setup
    conditional on the H5_WAKEUP_DISABLE flag too.
    
    This fixes the HCI being removed and then re-added every 10 seconds
    because it was being reprobed as soon as it was runtime-suspended.
    
    Fixes: 66f077dde749 ("Bluetooth: hci_h5: add WAKEUP_DISABLE flag")
    Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Archie Pusaka <apusaka@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56dc065545169a27e8e03c75f7f4d4e9adb060fa
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Sep 16 15:45:41 2021 +0100

    crypto: qat - power up 4xxx device
    
    [ Upstream commit ca605f97dae4bf070b7c584aec23c1c922e4d823 ]
    
    After reset or boot, QAT 4xxx devices are inactive and require to be
    explicitly activated.
    This is done by writing the DRV_ACTIVE bit in the PM_INTERRUPT register
    and polling the PM_INIT_STATE to make sure that the transaction has
    completed properly.
    
    If this is not done, the driver will fail the initialization sequence
    reporting the following message:
        [   22.081193] 4xxx 0000:f7:00.0: enabling device (0140 -> 0142)
        [   22.720285] QAT: AE0 is inactive!!
        [   22.720287] QAT: failed to get device out of reset
        [   22.720288] 4xxx 0000:f7:00.0: qat_hal_clr_reset error
        [   22.720290] 4xxx 0000:f7:00.0: Failed to init the AEs
        [   22.720290] 4xxx 0000:f7:00.0: Failed to initialise Acceleration Engine
        [   22.720789] 4xxx 0000:f7:00.0: Resetting device qat_dev0
        [   22.825099] 4xxx: probe of 0000:f7:00.0 failed with error -14
    
    The patch also temporarily disables the power management source of
    interrupt, to avoid possible spurious interrupts as the power management
    feature is not fully supported.
    
    The device init function has been added to adf_dev_init(), and not in the
    probe of 4xxx to make sure that the device is re-enabled in case of
    reset.
    
    Note that the error code reported by hw_data->init_device() in
    adf_dev_init() has been shadowed for consistency with the other calls
    in the same function.
    
    Fixes: 8c8268166e83 ("crypto: qat - add qat_4xxx driver")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Wojciech Ziemba <wojciech.ziemba@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 891fec9f116c0584d76bafcf0daddbd603ad1f0b
Author: Michael Walle <michael@walle.cc>
Date:   Thu Sep 16 00:03:07 2021 +0200

    crypto: caam - disable pkc for non-E SoCs
    
    [ Upstream commit f20311cc9c58052e0b215013046cbf390937910c ]
    
    On newer CAAM versions, not all accelerators are disabled if the SoC is
    a non-E variant. While the driver checks most of the modules for
    availability, there is one - PKHA - which sticks out. On non-E variants
    it is still reported as available, that is the number of instances is
    non-zero, but it has limited functionality. In particular it doesn't
    support encryption and decryption, but just signing and verifying. This
    is indicated by a bit in the PKHA_MISC field. Take this bit into account
    if we are checking for availability.
    
    This will the following error:
    [    8.167817] caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected.
    
    Tested on an NXP LS1028A (non-E) SoC.
    
    Fixes: d239b10d4ceb ("crypto: caam - add register map changes cf. Era 10")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adce47a6405cc894204c2bf92e4f87b39c894c45
Author: Guchun Chen <guchun.chen@amd.com>
Date:   Sat Sep 18 13:43:41 2021 +0800

    drm/amdgpu: move amdgpu_virt_release_full_gpu to fini_early stage
    
    [ Upstream commit 6effad8abe0ba4db3d9c58ed585127858a990f35 ]
    
    adev->rmmio is set to be NULL in amdgpu_device_unmap_mmio to prevent
    access after pci_remove, however, in SRIOV case, amdgpu_virt_release_full_gpu
    will still use adev->rmmio for access after amdgpu_device_unmap_mmio.
    The patch is to move such SRIOV calling earlier to fini_early stage.
    
    Fixes: 07775fc13878 ("drm/amdgpu: Unmap all MMIO mappings")
    Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Signed-off-by: Leslie Shi <Yuliang.Shi@amd.com>
    Signed-off-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63c1435cab9b06333862d6af0e1aca0a905e0d17
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Tue Sep 7 19:40:06 2021 -0400

    drm/amd/display: Pass display_pipe_params_st as const in DML
    
    [ Upstream commit 22667e6ec6b2ce9ca706e9061660b059725d009c ]
    
    [Why]
    This neither needs to be on the stack nor passed by value
    to each function call. In fact, when building with clang
    it seems to break the Linux's default 1024 byte stack
    frame limit.
    
    [How]
    We can simply pass this as a const pointer.
    
    This patch fixes these Coverity IDs
    Addresses-Coverity-ID: 1424031: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1423970: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1423941: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1451742: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1451887: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1454146: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1454152: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1454413: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1466144: ("Big parameter passed by value")
    Addresses-Coverity-ID: 1487237: ("Big parameter passed by value")
    
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Fixes: 3fe617ccafd6 ("Enable '-Werror' by default for all kernel builds")
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: amd-gfx@lists.freedesktop.org
    Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
    Cc: Arnd Bergmann <arnd@kernel.org>
    Cc: Leo Li <sunpeng.li@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Xinhui Pan <Xinhui.Pan@amd.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: llvm@lists.linux.dev
    Acked-by: Christian König <christian.koenig@amd.com>
    Build-tested-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Leo Li <sunpeng.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24b4d71021256f6ab5e25fe9322d5f15b7d3d810
Author: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Date:   Wed Sep 15 15:27:18 2021 -0400

    drm/amdgpu: Fix crash on device remove/driver unload
    
    [ Upstream commit d82e2c249c8ffaec20fa618611ea2ab4dcfd4d01 ]
    
    Crash:
    BUG: unable to handle page fault for address: 00000000000010e1
    RIP: 0010:vega10_power_gate_vce+0x26/0x50 [amdgpu]
    Call Trace:
    pp_set_powergating_by_smu+0x16a/0x2b0 [amdgpu]
    amdgpu_dpm_set_powergating_by_smu+0x92/0xf0 [amdgpu]
    amdgpu_dpm_enable_vce+0x2e/0xc0 [amdgpu]
    vce_v4_0_hw_fini+0x95/0xa0 [amdgpu]
    amdgpu_device_fini_hw+0x232/0x30d [amdgpu]
    amdgpu_driver_unload_kms+0x5c/0x80 [amdgpu]
    amdgpu_pci_remove+0x27/0x40 [amdgpu]
    pci_device_remove+0x3e/0xb0
    device_release_driver_internal+0x103/0x1d0
    device_release_driver+0x12/0x20
    pci_stop_bus_device+0x79/0xa0
    pci_stop_and_remove_bus_device_locked+0x1b/0x30
    remove_store+0x7b/0x90
    dev_attr_store+0x17/0x30
    sysfs_kf_write+0x4b/0x60
    kernfs_fop_write_iter+0x151/0x1e0
    
    Why:
    VCE/UVD had dependency on SMC block for their suspend but
    SMC block is the first to do HW fini due to some constraints
    
    How:
    Since the original patch was dealing with suspend issues
    move the SMC block dependency back into suspend hooks as
    was done in V1 of the original patches.
    Keep flushing idle work both in suspend and HW fini seuqnces
    since it's essential in both cases.
    
    Fixes: 859e4659273f1d ("drm/amdgpu: add missing cleanups for more ASICs on UVD/VCE suspend")
    Fixes: bf756fb833cbe8 ("drm/amdgpu: add missing cleanups for Polaris12 UVD/VCE on suspend")
    Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5481612c471f513b9142ddfc67229dd53f7f09e4
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Wed Sep 22 21:49:45 2021 +0800

    Bluetooth: btmtkuart: fix a memleak in mtk_hci_wmt_sync
    
    [ Upstream commit 3e5f2d90c28f9454e421108554707620bc23269d ]
    
    bdev->evt_skb will get freed in the normal path and one error path
    of mtk_hci_wmt_sync, while the other error paths do not free it,
    which may cause a memleak. This bug is suggested by a static analysis
    tool, please advise.
    
    Fixes: e0b67035a90b ("Bluetooth: mediatek: update the common setup between MT7622 and other devices")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bcbced2534bed9b95e31b356bd0426c01a3c42e
Author: Ajay Singh <ajay.kathat@microchip.com>
Date:   Thu Sep 16 16:49:18 2021 +0000

    wilc1000: fix possible memory leak in cfg_scan_result()
    
    [ Upstream commit 3c719fed0f3a5e95b1d164609ecc81c4191ade70 ]
    
    When the BSS reference holds a valid reference, it is not freed. The 'if'
    condition is wrong. Instead of the 'if (bss)' check, the 'if (!bss)' check
    is used.
    The issue is solved by removing the unnecessary 'if' check because
    cfg80211_put_bss() already performs the NULL validation.
    
    Fixes: 6cd4fa5ab691 ("staging: wilc1000: make use of cfg80211_inform_bss_frame()")
    Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210916164902.74629-3-ajay.kathat@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c4415e819f1c171f1ccdad6959607f18abe9784
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Thu Sep 9 15:44:27 2021 +0100

    wcn36xx: Fix Antenna Diversity Switching
    
    [ Upstream commit 701668d3bfa03dabc5095fc383d5315544ee5b31 ]
    
    We have been tracking a strange bug with Antenna Diversity Switching (ADS)
    on wcn3680b for a while.
    
    ADS is configured like this:
       A. Via a firmware configuration table baked into the NV area.
           1. Defines if ADS is enabled.
           2. Defines which GPIOs are connected to which antenna enable pin.
           3. Defines which antenna/GPIO is primary and which is secondary.
    
       B. WCN36XX_CFG_VAL(ANTENNA_DIVERSITY, N)
          N is a bitmask of available antenna.
    
          Setting N to 3 indicates a bitmask of enabled antenna (1 | 2).
    
          Obviously then we can set N to 1 or N to 2 to fix to a particular
          antenna and disable antenna diversity.
    
       C. WCN36XX_CFG_VAL(ASD_PROBE_INTERVAL, XX)
          XX is the number of beacons between each antenna RSSI check.
          Setting this value to 50 means, every 50 received beacons, run the
          ADS algorithm.
    
       D. WCN36XX_CFG_VAL(ASD_TRIGGER_THRESHOLD, YY)
          YY is a two's complement integer which specifies the RSSI decibel
          threshold below which ADS will run.
          We default to -60db here, meaning a measured RSSI <= -60db will
          trigger an ADS probe.
    
       E. WCN36XX_CFG_VAL(ASD_RTT_RSSI_HYST_THRESHOLD, Z)
          Z is a hysteresis value, indicating a delta which the RSSI must
          exceed for the antenna switch to be valid.
    
          For example if HYST_THRESHOLD == 3 AntennaId1-RSSI == -60db and
          AntennaId-2-RSSI == -58db then firmware will not switch antenna.
          The threshold needs to be -57db or better to satisfy the criteria.
    
       F. A firmware feature bit also exists ANTENNA_DIVERSITY_SELECTION.
          This feature bit is used by the firmware to report if
          ANTENNA_DIVERSITY_SELECTION is supported. The host is not required to
          toggle this bit to enable or disable ADS.
    
    ADS works like this:
    
        A. Every XX beacons the firmware switches to or remains on the primary
           antenna.
    
        B. The firmware then sends a Request-To-Send (RTS) packet to the AP.
    
        C. The firmware waits for a Clear-To-Send (CTS) response from the AP.
    
        D. The firmware then notes the received RSSI on the CTS packet.
    
        E. The firmware then repeats steps A-D on the secondary antenna.
    
        F. Subsequently if the RSSI on the measured antenna is better than
           ASD_TRIGGER_THRESHOLD + the active antenna's RSSI then the
           measured antenna becomes the active antenna.
    
        G. If RSSI rises past ASD_TRIGGER_THRESHOLD then ADS doesn't run at
           all even if there is a substantially better RSSI on the alternative
           antenna.
    
    What we have been observing is that the RTS packet is being sent but the
    MAC address is a byte-swapped version of the target MAC. The ADS/RTS MAC is
    corrupted only when the link is encrypted, if the AP is open the RTS MAC is
    correct. Similarly if we configure the firmware to an RTS/CTS sequence for
    regular data - the transmitted RTS MAC is correctly formatted.
    
    Internally the wcn36xx firmware uses the indexes in the SMD commands to
    populate and extract data from specific entries in an STA lookup table. The
    AP's MAC appears a number of times in different indexes within this lookup
    table, so the MAC address extracted for the data-transmit RTS and the MAC
    address extracted for the ADS/RTS packet are not the same STA table index.
    
    Our analysis indicates the relevant firmware STA table index is
    "bssSelfStaIdx".
    
    There is an STA populate function responsible for formatting the MAC
    address of the bssSelfStaIdx including byte-swapping the MAC address.
    
    Its clear then that the required STA populate command did not run for
    bssSelfStaIdx.
    
    So taking a look at the sequence of SMD commands sent to the firmware we
    see the following downstream when moving from an unencrypted to encrypted
    BSS setup.
    
    - WLAN_HAL_CONFIG_BSS_REQ
    - WLAN_HAL_CONFIG_STA_REQ
    - WLAN_HAL_SET_STAKEY_REQ
    
    Upstream in wcn36xx we have
    
    - WLAN_HAL_CONFIG_BSS_REQ
    - WLAN_HAL_SET_STAKEY_REQ
    
    The solution then is to add the missing WLAN_HAL_CONFIG_STA_REQ between
    WLAN_HAL_CONFIG_BSS_REQ and WLAN_HAL_SET_STAKEY_REQ.
    
    No surprise WLAN_HAL_CONFIG_STA_REQ is the routine responsible for
    populating the STA lookup table in the firmware and once done the MAC sent
    by the ADS routine is in the correct byte-order.
    
    This bug is apparent with ADS but it is also the case that any other
    firmware routine that depends on the "bssSelfStaIdx" would retrieve
    malformed data on an encrypted link.
    
    Fixes: 3e977c5c523d ("wcn36xx: Define wcn3680 specific firmware parameters")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Tested-by: Benjamin Li <benl@squareup.com>
    Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210909144428.2564650-2-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26d3bf38ae3edeb126d2a23cfdbfd85eebafc358
Author: Waiman Long <longman@redhat.com>
Date:   Sat Sep 18 18:53:08 2021 -0400

    cgroup: Make rebind_subsystems() disable v2 controllers all at once
    
    [ Upstream commit 7ee285395b211cad474b2b989db52666e0430daf ]
    
    It was found that the following warning was displayed when remounting
    controllers from cgroup v2 to v1:
    
    [ 8042.997778] WARNING: CPU: 88 PID: 80682 at kernel/cgroup/cgroup.c:3130 cgroup_apply_control_disable+0x158/0x190
       :
    [ 8043.091109] RIP: 0010:cgroup_apply_control_disable+0x158/0x190
    [ 8043.096946] Code: ff f6 45 54 01 74 39 48 8d 7d 10 48 c7 c6 e0 46 5a a4 e8 7b 67 33 00 e9 41 ff ff ff 49 8b 84 24 e8 01 00 00 0f b7 40 08 eb 95 <0f> 0b e9 5f ff ff ff 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3
    [ 8043.115692] RSP: 0018:ffffba8a47c23d28 EFLAGS: 00010202
    [ 8043.120916] RAX: 0000000000000036 RBX: ffffffffa624ce40 RCX: 000000000000181a
    [ 8043.128047] RDX: ffffffffa63c43e0 RSI: ffffffffa63c43e0 RDI: ffff9d7284ee1000
    [ 8043.135180] RBP: ffff9d72874c5800 R08: ffffffffa624b090 R09: 0000000000000004
    [ 8043.142314] R10: ffffffffa624b080 R11: 0000000000002000 R12: ffff9d7284ee1000
    [ 8043.149447] R13: ffff9d7284ee1000 R14: ffffffffa624ce70 R15: ffffffffa6269e20
    [ 8043.156576] FS:  00007f7747cff740(0000) GS:ffff9d7a5fc00000(0000) knlGS:0000000000000000
    [ 8043.164663] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 8043.170409] CR2: 00007f7747e96680 CR3: 0000000887d60001 CR4: 00000000007706e0
    [ 8043.177539] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 8043.184673] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 8043.191804] PKRU: 55555554
    [ 8043.194517] Call Trace:
    [ 8043.196970]  rebind_subsystems+0x18c/0x470
    [ 8043.201070]  cgroup_setup_root+0x16c/0x2f0
    [ 8043.205177]  cgroup1_root_to_use+0x204/0x2a0
    [ 8043.209456]  cgroup1_get_tree+0x3e/0x120
    [ 8043.213384]  vfs_get_tree+0x22/0xb0
    [ 8043.216883]  do_new_mount+0x176/0x2d0
    [ 8043.220550]  __x64_sys_mount+0x103/0x140
    [ 8043.224474]  do_syscall_64+0x38/0x90
    [ 8043.228063]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    It was caused by the fact that rebind_subsystem() disables
    controllers to be rebound one by one. If more than one disabled
    controllers are originally from the default hierarchy, it means that
    cgroup_apply_control_disable() will be called multiple times for the
    same default hierarchy. A controller may be killed by css_kill() in
    the first round. In the second round, the killed controller may not be
    completely dead yet leading to the warning.
    
    To avoid this problem, we collect all the ssid's of controllers that
    needed to be disabled from the default hierarchy and then disable them
    in one go instead of one by one.
    
    Fixes: 334c3679ec4b ("cgroup: reimplement rebind_subsystems() using cgroup_apply_control() and friends")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3409f88809a685fbf9ff6a3cd5599110370e647d
Author: Yoshitaka Ikeda <ikeda@nskint.co.jp>
Date:   Wed Sep 8 05:29:12 2021 +0000

    spi: Fixed division by zero warning
    
    [ Upstream commit 09134c5322df9f105d9ed324051872d5d0e162aa ]
    
    The reason for dividing by zero is because the dummy bus width is zero,
    but if the dummy n bytes is zero, it indicates that there is no data transfer,
    so there is no need for calculation.
    
    Fixes: 7512eaf54190 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1")
    Signed-off-by: Yoshitaka Ikeda <ikeda@nskint.co.jp>
    Acked-by: Pratyush Yadav <p.yadav@ti.com>
    Link: https://lore.kernel.org/r/OSZPR01MB70049C8F56ED8902852DF97B8BD49@OSZPR01MB7004.jpnprd01.prod.outlook.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc79831b426b12d8e7b0b8e4c5226171085e4a73
Author: Alex Bee <knaerzche@gmail.com>
Date:   Sat Sep 18 16:04:20 2021 +0200

    drm: bridge: it66121: Fix return value it66121_probe
    
    [ Upstream commit f3bc07eba481942a246926c5b934199e7ccd567b ]
    
    Currently it66121_probe returns -EPROBE_DEFER if the there is no remote
    endpoint found in the device tree which doesn't seem helpful, since this
    is not going to change later and it is never checked if the next bridge
    has been initialized yet. It will fail in that case later while doing
    drm_bridge_attach for the next bridge in it66121_bridge_attach.
    
    Since the bindings documentation for it66121 bridge driver states
    there has to be a remote endpoint defined, its safe to return -EINVAL
    in that case.
    This additonally adds a check, if the remote endpoint is enabled and
    returns -EPROBE_DEFER, if the remote bridge hasn't been initialized
    (yet).
    
    Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
    Signed-off-by: Alex Bee <knaerzche@gmail.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210918140420.231346-1-knaerzche@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a1028f896465d19d26f93fe16e6b4a0b5ba903b
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Sep 17 14:36:31 2021 +0100

    net: phylink: don't call netif_carrier_off() with NULL netdev
    
    [ Upstream commit cbcca2e3961eac736566ac13ef0d0bf6f0b764ec ]
    
    Dan Carpenter points out that we have a code path that permits a NULL
    netdev pointer to be passed to netif_carrier_off(), which will cause
    a kernel oops. In any case, we need to set pl->old_link_state to false
    to have the desired effect when there is no netdev present.
    
    Fixes: f97493657c63 ("net: phylink: add suspend/resume support")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02113c83f405c37896d57856a7e1d2fc492e7d36
Author: Yajun Deng <yajun.deng@linux.dev>
Date:   Sat Sep 18 17:04:10 2021 +0800

    net: net_namespace: Fix undefined member in key_remove_domain()
    
    [ Upstream commit aed0826b0cf2e488900ab92193893e803d65c070 ]
    
    The key_domain member in struct net only exists if we define CONFIG_KEYS.
    So we should add the define when we used key_domain.
    
    Fixes: 9b242610514f ("keys: Network namespace domain tag")
    Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c401830b0125c30740da5784c3489d449a987572
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Sep 3 10:40:01 2021 +0200

    lockdep: Let lock_is_held_type() detect recursive read as read
    
    [ Upstream commit 2507003a1d10917c9158077bf6030719d02c941e ]
    
    lock_is_held_type(, 1) detects acquired read locks. It only recognized
    locks acquired with lock_acquire_shared(). Read locks acquired with
    lock_acquire_shared_recursive() are not recognized because a `2' is
    stored as the read value.
    
    Rework the check to additionally recognise lock's read value one and two
    as a read held lock.
    
    Fixes: e918188611f07 ("locking: More accurate annotations for read_lock()")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Boqun Feng <boqun.feng@gmail.com>
    Acked-by: Waiman Long <longman@redhat.com>
    Link: https://lkml.kernel.org/r/20210903084001.lblecrvz4esl4mrr@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 255c569eeb468224c907a12438cc849bb124ef30
Author: liuyuntao <liuyuntao10@huawei.com>
Date:   Sat Aug 28 18:43:21 2021 +0800

    virtio-gpu: fix possible memory allocation failure
    
    [ Upstream commit 5bd4f20de8acad37dbb3154feb34dbc36d506c02 ]
    
    When kmem_cache_zalloc in virtio_gpu_get_vbuf fails, it will return
    an error code. But none of its callers checks this error code, and
    a core dump will take place.
    
    Considering many of its callers can't handle such error, I add
    a __GFP_NOFAIL flag when calling kmem_cache_zalloc to make sure
    it won't fail, and delete those unused error handlings.
    
    Fixes: dc5698e80cf724 ("Add virtio gpu driver.")
    Signed-off-by: Yuntao Liu <liuyuntao10@huawei.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20210828104321.3410312-1-liuyuntao10@huawei.com
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a496b70908816206af54ba8dfbec01feb3f5716c
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Aug 25 13:38:59 2021 -0700

    crypto: sm4 - Do not change section of ck and sbox
    
    [ Upstream commit 4a7e1e5fc294687a8941fa3eeb4a7e8539ca5e2f ]
    
    When building with clang and GNU as, there is a warning about ignored
    changed section attributes:
    
    /tmp/sm4-c916c8.s: Assembler messages:
    /tmp/sm4-c916c8.s:677: Warning: ignoring changed section attributes for
    .data..cacheline_aligned
    
    "static const" places the data in .rodata but __cacheline_aligned has
    the section attribute to place it in .data..cacheline_aligned, in
    addition to the aligned attribute.
    
    To keep the alignment but avoid attempting to change sections, use the
    ____cacheline_aligned attribute, which is just the aligned attribute.
    
    Fixes: 2b31277af577 ("crypto: sm4 - create SM4 library based on sm4 generic code")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1441
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41cfb139c36cdba99ab3440625a85ada3680be3d
Author: Iago Toral Quiroga <itoral@igalia.com>
Date:   Wed Sep 15 12:05:07 2021 +0200

    drm/v3d: fix wait for TMU write combiner flush
    
    [ Upstream commit e4f868191138975f2fdf2f37c11318b47db4acc9 ]
    
    The hardware sets the TMUWCF bit back to 0 when the TMU write
    combiner flush completes so we should be checking for that instead
    of the L2TFLS bit.
    
    v2 (Melissa Wen):
      - Add Signed-off-by and Fixes tags.
      - Change the error message for the timeout to be more clear.
    
    Fixes spurious Vulkan CTS failures in:
    dEQP-VK.binding_model.descriptorset_random.*
    
    Fixes: d223f98f02099 ("drm/v3d: Add support for compute shader dispatch.")
    Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
    Reviewed-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210915100507.3945-1-itoral@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a97e2fb96906424c1a3dd24cb184e3725601c81
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Sep 14 15:58:28 2021 +0300

    net/mlx5: Publish and unpublish all devlink parameters at once
    
    [ Upstream commit e9310aed8e6a5003abb2aa6b9229d2fb9ceb9e85 ]
    
    The devlink parameters were published in two steps despite being static
    and known in advance.
    
    First step was to use devlink_params_publish() which iterated over all
    known up to that point parameters and sent notification messages.
    In second step, the call was devlink_param_publish() that looped over
    same parameters list and sent notification for new parameters.
    
    In order to simplify the API, move devlink_params_publish() to be called
    when all parameters were already added and save the need to iterate over
    parameters list again.
    
    As a side effect, this change fixes the error unwind flow in which
    parameters were not marked as unpublished.
    
    Fixes: 82e6c96f04e1 ("net/mlx5: Register to devlink ingress VLAN filter trap")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9b17a030a1bd165a4e396340e7d442f63cfa36c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 24 11:41:02 2021 +0200

    objtool: Handle __sanitize_cov*() tail calls
    
    [ Upstream commit f56dae88a81fded66adf2bea9922d1d98d1da14f ]
    
    Turns out the compilers also generate tail calls to __sanitize_cov*(),
    make sure to also patch those out in noinstr code.
    
    Fixes: 0f1441b44e82 ("objtool: Fix noinstr vs KCOV")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Marco Elver <elver@google.com>
    Link: https://lore.kernel.org/r/20210624095147.818783799@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8a2b96d755c4abcb8189b01d6aefb15a45d0525
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 24 11:41:00 2021 +0200

    x86/xen: Mark cpu_bringup_and_idle() as dead_end_function
    
    [ Upstream commit 9af9dcf11bda3e2c0e24c1acaacb8685ad974e93 ]
    
    The asm_cpu_bringup_and_idle() function is required to push the return
    value on the stack in order to make ORC happy, but the only reason
    objtool doesn't complain is because of a happy accident.
    
    The thing is that asm_cpu_bringup_and_idle() doesn't return, so
    validate_branch() never terminates and falls through to the next
    function, which in the normal case is the hypercall_page. And that, as
    it happens, is 4095 NOPs and a RET.
    
    Make asm_cpu_bringup_and_idle() terminate on it's own, by making the
    function it calls as a dead-end. This way we no longer rely on what
    code happens to come after.
    
    Fixes: c3881eb58d56 ("x86/xen: Make the secondary CPU idle tasks reliable")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Link: https://lore.kernel.org/r/20210624095147.693801717@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6e4b75f977ecf4817682a35f762e0b4b00a33e7
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Tue Sep 14 23:21:00 2021 +0200

    MIPS: lantiq: dma: fix burst length for DEU
    
    [ Upstream commit 5ad74d39c51dd41b3c819f4f5396655f0629b4fd ]
    
    The current definition of 2W burst length is invalid.
    This patch fixes it. Current downstream DEU driver doesn't
    use DMA. An incorrect burst length value doesn't cause any
    errors. This patch also adds other burst length values.
    
    Fixes: dfec1a827d2b ("MIPS: Lantiq: Add DMA support")
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a9334d04ba646e6e5d9e242c0836c2acf475dd9
Author: Neeraj Upadhyay <neeraju@codeaurora.org>
Date:   Wed Aug 18 13:34:00 2021 +0530

    rcu: Fix existing exp request check in sync_sched_exp_online_cleanup()
    
    [ Upstream commit f0b2b2df5423fb369ac762c77900bc7765496d58 ]
    
    The sync_sched_exp_online_cleanup() checks to see if RCU needs
    an expedited quiescent state from the incoming CPU, sending it
    an IPI if so. Before sending IPI, it checks whether expedited
    qs need has been already requested for the incoming CPU, by
    checking rcu_data.cpu_no_qs.b.exp for the current cpu, on which
    sync_sched_exp_online_cleanup() is running. This works for the
    case where incoming CPU is same as self. However, for the case
    where incoming CPU is different from self, expedited request
    won't get marked, which can potentially delay reporting of
    expedited quiescent state for the incoming CPU.
    
    Fixes: e015a3411220 ("rcu: Avoid self-IPI in sync_sched_exp_online_cleanup()")
    Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3998e06d9511d639892f9f515c3a50f7591ff1ba
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Sep 2 23:27:56 2021 +0300

    Bluetooth: hci_uart: fix GPF in h5_recv
    
    [ Upstream commit 2fc7acb69fa3573d4bf7a90c323296d840daf330 ]
    
    Syzbot hit general protection fault in h5_recv(). The problem was in
    missing NULL check.
    
    hu->serdev can be NULL and we cannot blindly pass &serdev->dev
    somewhere, since it can cause GPF.
    
    Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend")
    Reported-and-tested-by: syzbot+7d41312fe3f123a6f605@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fc04208643f8ccedf1195e41f9c26ca9621bb90
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Wed Sep 1 13:48:12 2021 +0200

    libbpf: Don't crash on object files with no symbol tables
    
    [ Upstream commit 03e601f48b2da6fb44d0f7b86957a8f6bacfb347 ]
    
    If libbpf encounters an ELF file that has been stripped of its symbol
    table, it will crash in bpf_object__add_programs() when trying to
    dereference the obj->efile.symbols pointer.
    
    Fix this by erroring out of bpf_object__elf_collect() if it is not able
    able to find the symbol table.
    
    v2:
      - Move check into bpf_object__elf_collect() and add nice error message
    
    Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions")
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20210901114812.204720-1-toke@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11080de0a75cba7e00c1060d60ea484615d7a3d3
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date:   Thu Sep 2 23:13:06 2021 -0400

    Bluetooth: fix init and cleanup of sco_conn.timeout_work
    
    [ Upstream commit 49d8a5606428ca0962d09050a5af81461ff90fbb ]
    
    Before freeing struct sco_conn, all delayed timeout work should be
    cancelled. Otherwise, sco_sock_timeout could potentially use the
    sco_conn after it has been freed.
    
    Additionally, sco_conn.timeout_work should be initialized when the
    connection is allocated, not when the channel is added. This is
    because an sco_conn can create channels with multiple sockets over its
    lifetime, which happens if sockets are released but the connection
    isn't deleted.
    
    Fixes: ba316be1b6a0 ("Bluetooth: schedule SCO timeouts with delayed_work")
    Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f14a2c4648cb7001fd20de0cc0429bfcd92bf7e
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Aug 27 17:39:56 2021 +0100

    drm/bridge: it66121: Wait for next bridge to be probed
    
    [ Upstream commit 8b03e3fc79189b17d31a82f5e175698802a11e87 ]
    
    If run before the next bridge is initialized, of_drm_find_bridge() will
    give us a NULL pointer.
    
    If that's the case, return -EPROBE_DEFER; we may have more luck next
    time.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210827163956.27517-2-paul@crapouillou.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c1ccfcae8a962d1c11a1e4a55feb08f8733e311
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Aug 27 17:39:55 2021 +0100

    drm/bridge: it66121: Initialize {device,vendor}_ids
    
    [ Upstream commit 3a5f3d61de657bc1c2b53b77d065c5526f982e10 ]
    
    These two arrays are populated with data read from the I2C device
    through regmap_read(), and the data is then compared with hardcoded
    vendor/product ID values of supported chips.
    
    However, the return value of regmap_read() was never checked. This is
    fine, as long as the two arrays are zero-initialized, so that we don't
    compare the vendor/product IDs against whatever garbage is left on the
    stack.
    
    Address this issue by zero-initializing these two arrays.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210827163956.27517-1-paul@crapouillou.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 848df133cc4274ad443a592211dcbda89ed4d8b8
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:43 2021 -0700

    perf/x86/intel/uncore: Fix Intel SPR M3UPI event constraints
    
    [ Upstream commit 4034fb207e302cc0b1f304084d379640c1fb1436 ]
    
    SPR M3UPI have the exact same event constraints as ICX, so add the
    constraints.
    
    Fixes: 2a8e51eae7c8 ("perf/x86/intel/uncore: Add Sapphire Rapids server M3UPI support")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/1629991963-102621-8-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4a2da864e2a64eaa155645b4f10497077207318
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:42 2021 -0700

    perf/x86/intel/uncore: Fix Intel SPR M2PCIE event constraints
    
    [ Upstream commit f01d7d558e1855d4aa8e927b86111846536dd476 ]
    
    Similar to the ICX M2PCIE  events, some of the SPR M2PCIE events also
    have constraints. Add the constraints for SPR M2PCIE.
    
    Fixes: f85ef898f884 ("perf/x86/intel/uncore: Add Sapphire Rapids server M2PCIe support")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/1629991963-102621-7-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ced11c1b40cacd4c0ccba452ea4c84e1a3cc9a42
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:41 2021 -0700

    perf/x86/intel/uncore: Fix Intel SPR IIO event constraints
    
    [ Upstream commit 67c5d44384f8dc57e1c1b3040423cfce99b578cd ]
    
    SPR IIO events have the exact same event constraints as ICX, so add the
    constraints.
    
    Fixes: 3ba7095beaec ("perf/x86/intel/uncore: Add Sapphire Rapids server IIO support")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/1629991963-102621-6-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdba93ecbbd2da6fbf14ed170db4dd8975e11225
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:40 2021 -0700

    perf/x86/intel/uncore: Fix Intel SPR CHA event constraints
    
    [ Upstream commit 9d756e408e080d40e7916484b00c802026e6d1ad ]
    
    SPR CHA events have the exact same event constraints as SKX, so add the
    constraints.
    
    Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support")
    Reported-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/1629991963-102621-5-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a31df7d0f9feef89b121439a42334c52e1cefb5
Author: Robert Foss <robert.foss@linaro.org>
Date:   Wed Aug 18 19:13:17 2021 +0200

    drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()
    
    [ Upstream commit 7f16d0f3b8e2d13f940e944cd17044ca8eeb8b32 ]
    
    The return value of sp_tx_rst_aux() is not propagated, which means
    both compiler warnings and potential errors not being handled.
    
    Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
    
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210818171318.1848272-1-robert.foss@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3b39825ed0813f787cb3ebdc5ecaa5131623647
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Aug 9 16:31:46 2021 +0300

    fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
    
    [ Upstream commit 55285e21f04517939480966164a33898c34b2af2 ]
    
    Atm the EFI FB platform driver gets a runtime PM reference for the
    associated GFX PCI device during probing the EFI FB platform device and
    releases it only when the platform device gets unbound.
    
    When fbcon switches to the FB provided by the PCI device's driver (for
    instance i915/drmfb), the EFI FB will get only unregistered without the
    EFI FB platform device getting unbound, keeping the runtime PM reference
    acquired during the platform device probing. This reference will prevent
    the PCI driver from runtime suspending the device.
    
    Fix this by releasing the RPM reference from the EFI FB's destroy hook,
    called when the FB gets unregistered.
    
    While at it assert that pm_runtime_get_sync() didn't fail.
    
    v2:
    - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
      race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
    - Assert that pm_runtime_get_sync() didn't fail.
    - Clarify commit message wrt. platform/PCI device/driver and driver
      removal vs. device unbinding.
    
    Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0")
    Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210809133146.2478382-1-imre.deak@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8085f032541bde9bde40592bc7ba7fc8d87b69db
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Fri Oct 29 11:29:07 2021 -0700

    selftests/bpf: Fix strobemeta selftest regression
    
    [ Upstream commit 0133c20480b14820d43c37c0e9502da4bffcad3a ]
    
    After most recent nightly Clang update strobemeta selftests started
    failing with the following error (relevant portion of assembly included):
    
      1624: (85) call bpf_probe_read_user_str#114
      1625: (bf) r1 = r0
      1626: (18) r2 = 0xfffffffe
      1628: (5f) r1 &= r2
      1629: (55) if r1 != 0x0 goto pc+7
      1630: (07) r9 += 104
      1631: (6b) *(u16 *)(r9 +0) = r0
      1632: (67) r0 <<= 32
      1633: (77) r0 >>= 32
      1634: (79) r1 = *(u64 *)(r10 -456)
      1635: (0f) r1 += r0
      1636: (7b) *(u64 *)(r10 -456) = r1
      1637: (79) r1 = *(u64 *)(r10 -368)
      1638: (c5) if r1 s< 0x1 goto pc+778
      1639: (bf) r6 = r8
      1640: (0f) r6 += r7
      1641: (b4) w1 = 0
      1642: (6b) *(u16 *)(r6 +108) = r1
      1643: (79) r3 = *(u64 *)(r10 -352)
      1644: (79) r9 = *(u64 *)(r10 -456)
      1645: (bf) r1 = r9
      1646: (b4) w2 = 1
      1647: (85) call bpf_probe_read_user_str#114
    
      R1 unbounded memory access, make sure to bounds check any such access
    
    In the above code r0 and r1 are implicitly related. Clang knows that,
    but verifier isn't able to infer this relationship.
    
    Yonghong Song narrowed down this "regression" in code generation to
    a recent Clang optimization change ([0]), which for BPF target generates
    code pattern that BPF verifier can't handle and loses track of register
    boundaries.
    
    This patch works around the issue by adding an BPF assembly-based helper
    that helps to prove to the verifier that upper bound of the register is
    a given constant by controlling the exact share of generated BPF
    instruction sequence. This fixes the immediate issue for strobemeta
    selftest.
    
      [0] https://github.com/llvm/llvm-project/commit/acabad9ff6bf13e00305d9d8621ee8eafc1f8b08
    
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20211029182907.166910-1-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c7a147b876aec512bc1c3fcf0e2acee3efc534a
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Oct 25 11:26:49 2021 +0200

    netfilter: conntrack: set on IPS_ASSURED if flows enters internal stream state
    
    [ Upstream commit b7b1d02fc43925a4d569ec221715db2dfa1ce4f5 ]
    
    The internal stream state sets the timeout to 120 seconds 2 seconds
    after the creation of the flow, attach this internal stream state to the
    IPS_ASSURED flag for consistent event reporting.
    
    Before this patch:
    
          [NEW] udp      17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 [UNREPLIED] src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282
       [UPDATE] udp      17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282
       [UPDATE] udp      17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED]
      [DESTROY] udp      17 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED]
    
    Note IPS_ASSURED for the flow not yet in the internal stream state.
    
    after this update:
    
          [NEW] udp      17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 [UNREPLIED] src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282
       [UPDATE] udp      17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282
       [UPDATE] udp      17 120 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED]
      [DESTROY] udp      17 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED]
    
    Before this patch, short-lived UDP flows never entered IPS_ASSURED, so
    they were already candidate flow to be deleted by early_drop under
    stress.
    
    Before this patch, IPS_ASSURED is set on regardless the internal stream
    state, attach this internal stream state to IPS_ASSURED.
    
    packet #1 (original direction) enters NEW state
    packet #2 (reply direction) enters ESTABLISHED state, sets on IPS_SEEN_REPLY
    paclet #3 (any direction) sets on IPS_ASSURED (if 2 seconds since the
              creation has passed by).
    
    Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad04ebbe715c97d80528137ca8a18b1291f0feda
Author: Sven Schnelle <svens@stackframe.org>
Date:   Fri Oct 15 21:49:23 2021 +0200

    parisc/kgdb: add kgdb_roundup() to make kgdb work with idle polling
    
    [ Upstream commit 66e29fcda1824f0427966fbee2bd2c85bf362c82 ]
    
    With idle polling, IPIs are not sent when a CPU idle, but queued
    and run later from do_idle(). The default kgdb_call_nmi_hook()
    implementation gets the pointer to struct pt_regs from get_irq_reqs(),
    which doesn't work in that case because it was not called from the
    IPI interrupt handler. Fix it by defining our own kgdb_roundup()
    function which sents an IPI_ENTER_KGDB. When that IPI is received
    on the target CPU kgdb_nmicallback() is called.
    
    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 028459fab9a637c18202077e667c33a0a096c192
Author: Sven Schnelle <svens@stackframe.org>
Date:   Sat Oct 9 23:15:17 2021 +0200

    parisc/unwind: fix unwinder when CONFIG_64BIT is enabled
    
    [ Upstream commit 8e0ba125c2bf1030af3267058019ba86da96863f ]
    
    With 64 bit kernels unwind_special() is not working because
    it compares the pc to the address of the function descriptor.
    Add a helper function that compares pc with the dereferenced
    address. This fixes all of the backtraces on my c8000. Without
    this changes, a lot of backtraces are missing in kdb or the
    show-all-tasks command from /proc/sysrq-trigger.
    
    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab7ce95a04d6718a09e8e7f1cb2ab57911ad4304
Author: Gao Xiang <hsiangkao@linux.alibaba.com>
Date:   Mon Oct 25 15:43:11 2021 +0800

    erofs: don't trigger WARN() when decompression fails
    
    [ Upstream commit a0961f351d82d43ab0b845304caa235dfe249ae9 ]
    
    syzbot reported a WARNING [1] due to corrupted compressed data.
    
    As Dmitry said, "If this is not a kernel bug, then the code should
    not use WARN. WARN if for kernel bugs and is recognized as such by
    all testing systems and humans."
    
    [1] https://lore.kernel.org/r/000000000000b3586105cf0ff45e@google.com
    
    Link: https://lore.kernel.org/r/20211025074311.130395-1-hsiangkao@linux.alibaba.com
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Reported-by: syzbot+d8aaffc3719597e8cfb4@syzkaller.appspotmail.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6ca0ac23202d55bcad44907aa720e7d9ee786fa
Author: Helge Deller <deller@gmx.de>
Date:   Tue Oct 5 00:05:43 2021 +0200

    task_stack: Fix end_of_stack() for architectures with upwards-growing stack
    
    [ Upstream commit 9cc2fa4f4a92ccc6760d764e7341be46ee8aaaa1 ]
    
    The function end_of_stack() returns a pointer to the last entry of a
    stack. For architectures like parisc where the stack grows upwards
    return the pointer to the highest address in the stack.
    
    Without this change I faced a crash on parisc, because the stackleak
    functionality wrote STACKLEAK_POISON to the lowest address and thus
    overwrote the first 4 bytes of the task_struct which included the
    TIF_FLAGS.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b935cca35e461ca725d8cda9a4ea2b4259239d3
Author: Sven Schnelle <svens@stackframe.org>
Date:   Sat Oct 9 20:24:39 2021 +0200

    parisc: fix warning in flush_tlb_all
    
    [ Upstream commit 1030d681319b43869e0d5b568b9d0226652d1a6f ]
    
    I've got the following splat after enabling preemption:
    
    [    3.724721] BUG: using __this_cpu_add() in preemptible [00000000] code: swapper/0/1
    [    3.734630] caller is __this_cpu_preempt_check+0x38/0x50
    [    3.740635] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc4-64bit+ #324
    [    3.744605] Hardware name: 9000/785/C8000
    [    3.744605] Backtrace:
    [    3.744605]  [<00000000401d9d58>] show_stack+0x74/0xb0
    [    3.744605]  [<0000000040c27bd4>] dump_stack_lvl+0x10c/0x188
    [    3.744605]  [<0000000040c27c84>] dump_stack+0x34/0x48
    [    3.744605]  [<0000000040c33438>] check_preemption_disabled+0x178/0x1b0
    [    3.744605]  [<0000000040c334f8>] __this_cpu_preempt_check+0x38/0x50
    [    3.744605]  [<00000000401d632c>] flush_tlb_all+0x58/0x2e0
    [    3.744605]  [<00000000401075c0>] 0x401075c0
    [    3.744605]  [<000000004010b8fc>] 0x4010b8fc
    [    3.744605]  [<00000000401080fc>] 0x401080fc
    [    3.744605]  [<00000000401d5224>] do_one_initcall+0x128/0x378
    [    3.744605]  [<0000000040102de8>] 0x40102de8
    [    3.744605]  [<0000000040c33864>] kernel_init+0x60/0x3a8
    [    3.744605]  [<00000000401d1020>] ret_from_kernel_thread+0x20/0x28
    [    3.744605]
    
    Fix this by moving the __inc_irq_stat() into the locked section.
    
    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec6ceae80a4280b8626501f50b2bbfbaaf4098e7
Author: Stephane Eranian <eranian@google.com>
Date:   Wed Oct 13 17:12:14 2021 -0700

    perf/x86/intel: Fix ICL/SPR INST_RETIRED.PREC_DIST encodings
    
    [ Upstream commit 2de71ee153efa93099d2ab864acffeec70a8dcd5 ]
    
    This patch fixes the encoding for INST_RETIRED.PREC_DIST as published by Intel
    (download.01.org/perfmon/) for Icelake. The official encoding
    is event code 0x00 umask 0x1, a change from Skylake where it was code 0xc0
    umask 0x1.
    
    With this patch applied it is possible to run:
    $ perf record -a -e cpu/event=0x00,umask=0x1/pp .....
    
    Whereas before this would fail.
    
    To avoid problems with tools which may use the old code, we maintain the old
    encoding for Icelake.
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20211014001214.2680534-1-eranian@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0f6689591df3c75d90b74d3548091ae69d0c56d
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Wed Oct 27 13:26:19 2021 -0600

    selftests/core: fix conflicting types compile error for close_range()
    
    [ Upstream commit f35dcaa0a8a29188ed61083d153df1454cf89d08 ]
    
    close_range() test type conflicts with close_range() library call in
    x86_64-linux-gnu/bits/unistd_ext.h. Fix it by changing the name to
    core_close_range().
    
    gcc -g -I../../../../usr/include/    close_range_test.c  -o ../tools/testing/selftests/core/close_range_test
    In file included from close_range_test.c:16:
    close_range_test.c:57:6: error: conflicting types for ‘close_range’; have ‘void(struct __test_metadata *)’
       57 | TEST(close_range)
          |      ^~~~~~~~~~~
    ../kselftest_harness.h:181:21: note: in definition of macro ‘__TEST_IMPL’
      181 |         static void test_name(struct __test_metadata *_metadata); \
          |                     ^~~~~~~~~
    close_range_test.c:57:1: note: in expansion of macro ‘TEST’
       57 | TEST(close_range)
          | ^~~~
    In file included from /usr/include/unistd.h:1204,
                     from close_range_test.c:13:
    /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:56:12: note: previous declaration of ‘close_range’ with type ‘int(unsigned int,  unsigned int,  int)’
       56 | extern int close_range (unsigned int __fd, unsigned int __max_fd,
          |            ^~~~~~~~~~~
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 116b6202b29abcfc1617d27faf5f2214780786d5
Author: Anson Jacob <Anson.Jacob@amd.com>
Date:   Fri Sep 17 18:29:36 2021 -0400

    drm/amd/display: dcn20_resource_construct reduce scope of FPU enabled
    
    [ Upstream commit bc39a69a2ac484e6575a958567c162ef56c9f278 ]
    
    Limit when FPU is enabled to only functions that does FPU operations for
    dcn20_resource_construct, which gets called during driver
    initialization.
    
    Enabling FPU operation disables preemption.  Sleeping functions(mutex
    (un)lock, memory allocation using GFP_KERNEL, etc.) should not be called
    when preemption is disabled.
    
    Fixes the following case caught by enabling
    CONFIG_DEBUG_ATOMIC_SLEEP in kernel config
    [    1.338434] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281
    [    1.347395] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 197, name: systemd-udevd
    [    1.356356] CPU: 7 PID: 197 Comm: systemd-udevd Not tainted 5.13.0+ #3
    [    1.356358] Hardware name: System manufacturer System Product Name/PRIME X570-PRO, BIOS 3405 02/01/2021
    [    1.356360] Call Trace:
    [    1.356361]  dump_stack+0x6b/0x86
    [    1.356366]  ___might_sleep.cold+0x87/0x98
    [    1.356370]  __might_sleep+0x4b/0x80
    [    1.356372]  mutex_lock+0x21/0x50
    [    1.356376]  smu_get_uclk_dpm_states+0x3f/0x80 [amdgpu]
    [    1.356538]  pp_nv_get_uclk_dpm_states+0x35/0x50 [amdgpu]
    [    1.356711]  init_soc_bounding_box+0xf9/0x210 [amdgpu]
    [    1.356892]  ? create_object+0x20d/0x340
    [    1.356897]  ? dcn20_resource_construct+0x46f/0xd30 [amdgpu]
    [    1.357077]  dcn20_resource_construct+0x4b1/0xd30 [amdgpu]
    ...
    
    Tested on: 5700XT (NAVI10 0x1002:0x731F 0x1DA2:0xE410 0xC1)
    
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Hersen Wu <hersenxs.wu@amd.com>
    Cc: Anson Jacob <Anson.Jacob@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Acked-by: Agustin Gutierrez <agustin.gutierrez@amd.com>
    Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed515eea770182d73e11c6fa328b3928fa828eb3
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Tue Oct 12 17:50:05 2021 +0200

    x86/hyperv: Protect set_hv_tscchange_cb() against getting preempted
    
    [ Upstream commit 285f68afa8b20f752b0b7194d54980b5e0e27b75 ]
    
    The following issue is observed with CONFIG_DEBUG_PREEMPT when KVM loads:
    
     KVM: vmx: using Hyper-V Enlightened VMCS
     BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/488
     caller is set_hv_tscchange_cb+0x16/0x80
     CPU: 1 PID: 488 Comm: systemd-udevd Not tainted 5.15.0-rc5+ #396
     Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
     Call Trace:
      dump_stack_lvl+0x6a/0x9a
      check_preemption_disabled+0xde/0xe0
      ? kvm_gen_update_masterclock+0xd0/0xd0 [kvm]
      set_hv_tscchange_cb+0x16/0x80
      kvm_arch_init+0x23f/0x290 [kvm]
      kvm_init+0x30/0x310 [kvm]
      vmx_init+0xaf/0x134 [kvm_intel]
      ...
    
    set_hv_tscchange_cb() can get preempted in between acquiring
    smp_processor_id() and writing to HV_X64_MSR_REENLIGHTENMENT_CONTROL. This
    is not an issue by itself: HV_X64_MSR_REENLIGHTENMENT_CONTROL is a
    partition-wide MSR and it doesn't matter which particular CPU will be
    used to receive reenlightenment notifications. The only real problem can
    (in theory) be observed if the CPU whose id was acquired with
    smp_processor_id() goes offline before we manage to write to the MSR,
    the logic in hv_cpu_die() won't be able to reassign it correctly.
    
    Reported-by: Michael Kelley <mikelley@microsoft.com>
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Link: https://lore.kernel.org/r/20211012155005.1613352-1-vkuznets@redhat.com
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f421e257e498357b6648b767694f7f7d3190db5
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 26 14:30:14 2021 -0700

    inet: remove races in inet{6}_getname()
    
    [ Upstream commit 9dfc685e0262d4c5e44e13302f89841fa75173ca ]
    
    syzbot reported data-races in inet_getname() multiple times,
    it is time we fix this instead of pretending applications
    should not trigger them.
    
    getsockname() and getpeername() are not really considered fast path.
    
    v2: added the missing BPF_CGROUP_RUN_SA_PROG() declaration
        needed when CONFIG_CGROUP_BPF=n, as reported by
        kernel test robot <lkp@intel.com>
    
    syzbot typical report:
    
    BUG: KCSAN: data-race in __inet_hash_connect / inet_getname
    
    write to 0xffff888136d66cf8 of 2 bytes by task 14374 on cpu 1:
     __inet_hash_connect+0x7ec/0x950 net/ipv4/inet_hashtables.c:831
     inet_hash_connect+0x85/0x90 net/ipv4/inet_hashtables.c:853
     tcp_v4_connect+0x782/0xbb0 net/ipv4/tcp_ipv4.c:275
     __inet_stream_connect+0x156/0x6e0 net/ipv4/af_inet.c:664
     inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:728
     __sys_connect_file net/socket.c:1896 [inline]
     __sys_connect+0x254/0x290 net/socket.c:1913
     __do_sys_connect net/socket.c:1923 [inline]
     __se_sys_connect net/socket.c:1920 [inline]
     __x64_sys_connect+0x3d/0x50 net/socket.c:1920
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xa0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff888136d66cf8 of 2 bytes by task 14408 on cpu 0:
     inet_getname+0x11f/0x170 net/ipv4/af_inet.c:790
     __sys_getsockname+0x11d/0x1b0 net/socket.c:1946
     __do_sys_getsockname net/socket.c:1961 [inline]
     __se_sys_getsockname net/socket.c:1958 [inline]
     __x64_sys_getsockname+0x3e/0x50 net/socket.c:1958
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xa0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x0000 -> 0xdee0
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 5.15.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Link: https://lore.kernel.org/r/20211026213014.3026708-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b58be9a0495f88bf7b89f0e044071fe2db75457c
Author: 王贇 <yun.wang@linux.alibaba.com>
Date:   Wed Oct 27 11:15:11 2021 +0800

    ftrace: do CPU checking after preemption disabled
    
    [ Upstream commit d33cc657372366a8959f099c619a208b4c5dc664 ]
    
    With CONFIG_DEBUG_PREEMPT we observed reports like:
    
      BUG: using smp_processor_id() in preemptible
      caller is perf_ftrace_function_call+0x6f/0x2e0
      CPU: 1 PID: 680 Comm: a.out Not tainted
      Call Trace:
       <TASK>
       dump_stack_lvl+0x8d/0xcf
       check_preemption_disabled+0x104/0x110
       ? optimize_nops.isra.7+0x230/0x230
       ? text_poke_bp_batch+0x9f/0x310
       perf_ftrace_function_call+0x6f/0x2e0
       ...
       __text_poke+0x5/0x620
       text_poke_bp_batch+0x9f/0x310
    
    This telling us the CPU could be changed after task is preempted, and
    the checking on CPU before preemption will be invalid.
    
    Since now ftrace_test_recursion_trylock() will help to disable the
    preemption, this patch just do the checking after trylock() to address
    the issue.
    
    Link: https://lkml.kernel.org/r/54880691-5fe2-33e7-d12f-1fa6136f5183@linux.alibaba.com
    
    CC: Steven Rostedt <rostedt@goodmis.org>
    Cc: Guo Ren <guoren@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Albert Ou <aou@eecs.berkeley.edu>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Miroslav Benes <mbenes@suse.cz>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Joe Lawrence <joe.lawrence@redhat.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Jisheng Zhang <jszhang@kernel.org>
    Reported-by: Abaci <abaci@linux.alibaba.com>
    Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e24f9679c3c039cc8ec80beff2239a3240176e37
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Mon Oct 25 10:30:37 2021 +0100

    Revert "wcn36xx: Enable firmware link monitoring"
    
    [ Upstream commit 43ea9bd84f27d06482cc823d9749cc9dd2993bc8 ]
    
    Firmware link offload monitoring can be made to work in 3/4 cases by
    switching on firmware feature bit WLANACTIVE_OFFLOAD
    
    - Secure power-save on
    - Secure power-save off
    - Open power-save on
    
    However, with an open AP if we switch off power-saving - thus never
    entering Beacon Mode Power Save - BMPS, firmware never forwards loss
    of beacon upwards.
    
    We had hoped that WLANACTIVE_OFFLOAD and some fixes for sequence numbers
    would unblock this but, it hasn't and further investigation is required.
    
    Its possible to have a complete set of Secure power-save on/off and Open
    power-save on/off provided we use Linux' link monitoring mechanism.
    
    While we debug the Open AP failure we need to fix upstream.
    
    This reverts commit c973fdad79f6eaf247d48b5fc77733e989eb01e1.
    
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211025093037.3966022-2-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 194e8d7ad91fc465e40f55219208bf6166324fe9
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Mon Oct 25 10:28:16 2021 +0200

    wcn36xx: Fix packet drop on resume
    
    [ Upstream commit df0697801d8aa2eebfe7f0b7388879639f8fe7cc ]
    
    If the system is resumed because of an incoming packet, the wcn36xx RX
    interrupts is fired before actual resuming of the wireless/mac80211
    stack, causing any received packets to be simply dropped. E.g. a ping
    request causes a system resume, but is dropped and so never forwarded
    to the IP stack.
    
    This change fixes that, disabling DMA interrupts on suspend to no pass
    packets until mac80211 is resumed and ready to handle them.
    
    Note that it's not incompatible with RX irq wake.
    
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1635150496-19290-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 397fec25850c7b4fd466c66043043cec07b63a00
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Mon Oct 18 12:57:57 2021 +0200

    wcn36xx: Correct band/freq reporting on RX
    
    [ Upstream commit 8a27ca39478270e07baf9c09aa0c99709769ba03 ]
    
    For packets originating from hardware scan, the channel and band is
    included in the buffer descriptor (bd->rf_band & bd->rx_ch).
    
    For 2Ghz band the channel value is directly reported in the 4-bit
    rx_ch field. For 5Ghz band, the rx_ch field contains a mapping
    index (given the 4-bit limitation).
    
    The reserved0 value field is also used to extend 4-bit mapping to
    5-bit mapping to support more than 16 5Ghz channels.
    
    This change adds correct reporting of the frequency/band, that is
    used in scan mechanism. And is required for 5Ghz hardware scan
    support.
    
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1634554678-7993-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51421f89b90909c3e86c06a773ff1b3e056489c8
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 18 15:34:13 2021 +0800

    spi: bcm-qspi: Fix missing clk_disable_unprepare() on error in bcm_qspi_probe()
    
    [ Upstream commit ca9b8f56ec089d3a436050afefd17b7237301f47 ]
    
    Fix the missing clk_disable_unprepare() before return
    from bcm_qspi_probe() in the error handling case.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211018073413.2029081-1-yangyingliang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6039fcd858964e4aea75c3875c9262b793c441ab
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue Jul 27 17:01:14 2021 -0400

    btrfs: do not take the uuid_mutex in btrfs_rm_device
    
    [ Upstream commit 8ef9dc0f14ba6124c62547a4fdc59b163d8b864e ]
    
    We got the following lockdep splat while running fstests (specifically
    btrfs/003 and btrfs/020 in a row) with the new rc.  This was uncovered
    by 87579e9b7d8d ("loop: use worker per cgroup instead of kworker") which
    converted loop to using workqueues, which comes with lockdep
    annotations that don't exist with kworkers.  The lockdep splat is as
    follows:
    
      WARNING: possible circular locking dependency detected
      5.14.0-rc2-custom+ #34 Not tainted
      ------------------------------------------------------
      losetup/156417 is trying to acquire lock:
      ffff9c7645b02d38 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x84/0x600
    
      but task is already holding lock:
      ffff9c7647395468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x650 [loop]
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #5 (&lo->lo_mutex){+.+.}-{3:3}:
             __mutex_lock+0xba/0x7c0
             lo_open+0x28/0x60 [loop]
             blkdev_get_whole+0x28/0xf0
             blkdev_get_by_dev.part.0+0x168/0x3c0
             blkdev_open+0xd2/0xe0
             do_dentry_open+0x163/0x3a0
             path_openat+0x74d/0xa40
             do_filp_open+0x9c/0x140
             do_sys_openat2+0xb1/0x170
             __x64_sys_openat+0x54/0x90
             do_syscall_64+0x3b/0x90
             entry_SYSCALL_64_after_hwframe+0x44/0xae
    
      -> #4 (&disk->open_mutex){+.+.}-{3:3}:
             __mutex_lock+0xba/0x7c0
             blkdev_get_by_dev.part.0+0xd1/0x3c0
             blkdev_get_by_path+0xc0/0xd0
             btrfs_scan_one_device+0x52/0x1f0 [btrfs]
             btrfs_control_ioctl+0xac/0x170 [btrfs]
             __x64_sys_ioctl+0x83/0xb0
             do_syscall_64+0x3b/0x90
             entry_SYSCALL_64_after_hwframe+0x44/0xae
    
      -> #3 (uuid_mutex){+.+.}-{3:3}:
             __mutex_lock+0xba/0x7c0
             btrfs_rm_device+0x48/0x6a0 [btrfs]
             btrfs_ioctl+0x2d1c/0x3110 [btrfs]
             __x64_sys_ioctl+0x83/0xb0
             do_syscall_64+0x3b/0x90
             entry_SYSCALL_64_after_hwframe+0x44/0xae
    
      -> #2 (sb_writers#11){.+.+}-{0:0}:
             lo_write_bvec+0x112/0x290 [loop]
             loop_process_work+0x25f/0xcb0 [loop]
             process_one_work+0x28f/0x5d0
             worker_thread+0x55/0x3c0
             kthread+0x140/0x170
             ret_from_fork+0x22/0x30
    
      -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}:
             process_one_work+0x266/0x5d0
             worker_thread+0x55/0x3c0
             kthread+0x140/0x170
             ret_from_fork+0x22/0x30
    
      -> #0 ((wq_completion)loop0){+.+.}-{0:0}:
             __lock_acquire+0x1130/0x1dc0
             lock_acquire+0xf5/0x320
             flush_workqueue+0xae/0x600
             drain_workqueue+0xa0/0x110
             destroy_workqueue+0x36/0x250
             __loop_clr_fd+0x9a/0x650 [loop]
             lo_ioctl+0x29d/0x780 [loop]
             block_ioctl+0x3f/0x50
             __x64_sys_ioctl+0x83/0xb0
             do_syscall_64+0x3b/0x90
             entry_SYSCALL_64_after_hwframe+0x44/0xae
    
      other info that might help us debug this:
      Chain exists of:
        (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex
       Possible unsafe locking scenario:
             CPU0                    CPU1
             ----                    ----
        lock(&lo->lo_mutex);
                                     lock(&disk->open_mutex);
                                     lock(&lo->lo_mutex);
        lock((wq_completion)loop0);
    
       *** DEADLOCK ***
      1 lock held by losetup/156417:
       #0: ffff9c7647395468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x650 [loop]
    
      stack backtrace:
      CPU: 8 PID: 156417 Comm: losetup Not tainted 5.14.0-rc2-custom+ #34
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      Call Trace:
       dump_stack_lvl+0x57/0x72
       check_noncircular+0x10a/0x120
       __lock_acquire+0x1130/0x1dc0
       lock_acquire+0xf5/0x320
       ? flush_workqueue+0x84/0x600
       flush_workqueue+0xae/0x600
       ? flush_workqueue+0x84/0x600
       drain_workqueue+0xa0/0x110
       destroy_workqueue+0x36/0x250
       __loop_clr_fd+0x9a/0x650 [loop]
       lo_ioctl+0x29d/0x780 [loop]
       ? __lock_acquire+0x3a0/0x1dc0
       ? update_dl_rq_load_avg+0x152/0x360
       ? lock_is_held_type+0xa5/0x120
       ? find_held_lock.constprop.0+0x2b/0x80
       block_ioctl+0x3f/0x50
       __x64_sys_ioctl+0x83/0xb0
       do_syscall_64+0x3b/0x90
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7f645884de6b
    
    Usually the uuid_mutex exists to protect the fs_devices that map
    together all of the devices that match a specific uuid.  In rm_device
    we're messing with the uuid of a device, so it makes sense to protect
    that here.
    
    However in doing that it pulls in a whole host of lockdep dependencies,
    as we call mnt_may_write() on the sb before we grab the uuid_mutex, thus
    we end up with the dependency chain under the uuid_mutex being added
    under the normal sb write dependency chain, which causes problems with
    loop devices.
    
    We don't need the uuid mutex here however.  If we call
    btrfs_scan_one_device() before we scratch the super block we will find
    the fs_devices and not find the device itself and return EBUSY because
    the fs_devices is open.  If we call it after the scratch happens it will
    not appear to be a valid btrfs file system.
    
    We do not need to worry about other fs_devices modifying operations here
    because we're protected by the exclusive operations locking.
    
    So drop the uuid_mutex here in order to fix the lockdep splat.
    
    A more detailed explanation from the discussion:
    
    We are worried about rm and scan racing with each other, before this
    change we'll zero the device out under the UUID mutex so when scan does
    run it'll make sure that it can go through the whole device scan thing
    without rm messing with us.
    
    We aren't worried if the scratch happens first, because the result is we
    don't think this is a btrfs device and we bail out.
    
    The only case we are concerned with is we scratch _after_ scan is able
    to read the superblock and gets a seemingly valid super block, so lets
    consider this case.
    
    Scan will call device_list_add() with the device we're removing.  We'll
    call find_fsid_with_metadata_uuid() and get our fs_devices for this
    UUID.  At this point we lock the fs_devices->device_list_mutex.  This is
    what protects us in this case, but we have two cases here.
    
    1. We aren't to the device removal part of the RM.  We found our device,
       and device name matches our path, we go down and we set total_devices
       to our super number of devices, which doesn't affect anything because
       we haven't done the remove yet.
    
    2. We are past the device removal part, which is protected by the
       device_list_mutex.  Scan doesn't find the device, it goes down and
       does the
    
       if (fs_devices->opened)
               return -EBUSY;
    
       check and we bail out.
    
    Nothing about this situation is ideal, but the lockdep splat is real,
    and the fix is safe, tho admittedly a bit scary looking.
    
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ copy more from the discussion ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bfc4788e44818798afe87a1920af26d52050e50b
Author: Sidong Yang <realwakka@gmail.com>
Date:   Thu Aug 26 14:44:36 2021 +0000

    btrfs: reflink: initialize return value to 0 in btrfs_extent_same()
    
    [ Upstream commit 44bee215f72f13874c0e734a0712c2e3264c0108 ]
    
    Fix a warning reported by smatch that ret could be returned without
    initialized.  The dedupe operations are supposed to to return 0 for a 0
    length range but the caller does not pass olen == 0. To keep this
    behaviour and also fix the warning initialize ret to 0.
    
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Sidong Yang <realwakka@gmail.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91f8e91d93cee34b93beca6ed396c5745f384310
Author: Hui Wang <hui.wang@canonical.com>
Date:   Mon Oct 25 14:16:01 2021 +0800

    ACPI: resources: Add one more Medion model in IRQ override quirk
    
    [ Upstream commit 1b26ae40092b43bb6e9c5df376227382b390b953 ]
    
    The Medion s17 series laptops have the same issue on the keyboard
    as the s15 series, if skipping to call acpi_get_override_irq(), the
    keyboard could work well. So put the DMI info of s17 series in the
    IRQ override quirk table as well.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213031
    Tested-by: dirksche <dirksche@posteo.de>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59f3feb05cfdd32582c81de20c0b91d89ec8ea1b
Author: Stefan Schaeckeler <schaecsn@gmx.net>
Date:   Sun Oct 24 15:04:45 2021 -0700

    ACPI: AC: Quirk GK45 to skip reading _PSR
    
    [ Upstream commit 3d730ee686800d71ecc5c3cb8460dcdcdeaf38a3 ]
    
    Let GK45 not go into BIOS for determining the AC power state.
    
    The BIOS wrongly returns 0, so hardcode the power state to 1.
    
    The mini PC GK45 by Besstar Tech Lld. (aka Kodlix) just runs
    off AC. It does not include any batteries. Nevertheless BIOS
    reports AC off:
    
    root@kodlix:/usr/src/linux# cat /sys/class/power_supply/ADP1/online
    0
    
    root@kodlix:/usr/src/linux# modprobe acpi_dbg
    root@kodlix:/usr/src/linux# tools/power/acpi/acpidbg
    
    - find _PSR
       \_SB.PCI0.SBRG.H_EC.ADP1._PSR Method       000000009283cee8 001 Args 0 Len 001C Aml 00000000f54e5f67
    
    - execute \_SB.PCI0.SBRG.H_EC.ADP1._PSR
    Evaluating \_SB.PCI0.SBRG.H_EC.ADP1._PSR
    Evaluation of \_SB.PCI0.SBRG.H_EC.ADP1._PSR returned object 00000000dc08c187, external buffer length 18
     [Integer] = 0000000000000000
    
    that should be
    
     [Integer] = 0000000000000001
    
    Signed-off-by: Stefan Schaeckeler <schaecsn@gmx.net>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0914663ac127b52001971218e684b3a81ffdc426
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 25 11:15:55 2021 -0700

    net: annotate data-race in neigh_output()
    
    [ Upstream commit d18785e213866935b4c3dc0c33c3e18801ce0ce8 ]
    
    neigh_output() reads n->nud_state and hh->hh_len locklessly.
    
    This is fine, but we need to add annotations and document this.
    
    We evaluate skip_cache first to avoid reading these fields
    if the cache has to by bypassed.
    
    syzbot report:
    
    BUG: KCSAN: data-race in __neigh_event_send / ip_finish_output2
    
    write to 0xffff88810798a885 of 1 bytes by interrupt on cpu 1:
     __neigh_event_send+0x40d/0xac0 net/core/neighbour.c:1128
     neigh_event_send include/net/neighbour.h:444 [inline]
     neigh_resolve_output+0x104/0x410 net/core/neighbour.c:1476
     neigh_output include/net/neighbour.h:510 [inline]
     ip_finish_output2+0x80a/0xaa0 net/ipv4/ip_output.c:221
     ip_finish_output+0x3b5/0x510 net/ipv4/ip_output.c:309
     NF_HOOK_COND include/linux/netfilter.h:296 [inline]
     ip_output+0xf3/0x1a0 net/ipv4/ip_output.c:423
     dst_output include/net/dst.h:450 [inline]
     ip_local_out+0x164/0x220 net/ipv4/ip_output.c:126
     __ip_queue_xmit+0x9d3/0xa20 net/ipv4/ip_output.c:525
     ip_queue_xmit+0x34/0x40 net/ipv4/ip_output.c:539
     __tcp_transmit_skb+0x142a/0x1a00 net/ipv4/tcp_output.c:1405
     tcp_transmit_skb net/ipv4/tcp_output.c:1423 [inline]
     tcp_xmit_probe_skb net/ipv4/tcp_output.c:4011 [inline]
     tcp_write_wakeup+0x4a9/0x810 net/ipv4/tcp_output.c:4064
     tcp_send_probe0+0x2c/0x2b0 net/ipv4/tcp_output.c:4079
     tcp_probe_timer net/ipv4/tcp_timer.c:398 [inline]
     tcp_write_timer_handler+0x394/0x520 net/ipv4/tcp_timer.c:626
     tcp_write_timer+0xb9/0x180 net/ipv4/tcp_timer.c:642
     call_timer_fn+0x2e/0x1d0 kernel/time/timer.c:1421
     expire_timers+0x135/0x240 kernel/time/timer.c:1466
     __run_timers+0x368/0x430 kernel/time/timer.c:1734
     run_timer_softirq+0x19/0x30 kernel/time/timer.c:1747
     __do_softirq+0x12c/0x26e kernel/softirq.c:558
     invoke_softirq kernel/softirq.c:432 [inline]
     __irq_exit_rcu kernel/softirq.c:636 [inline]
     irq_exit_rcu+0x4e/0xa0 kernel/softirq.c:648
     sysvec_apic_timer_interrupt+0x69/0x80 arch/x86/kernel/apic/apic.c:1097
     asm_sysvec_apic_timer_interrupt+0x12/0x20
     native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
     arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
     acpi_safe_halt drivers/acpi/processor_idle.c:109 [inline]
     acpi_idle_do_entry drivers/acpi/processor_idle.c:553 [inline]
     acpi_idle_enter+0x258/0x2e0 drivers/acpi/processor_idle.c:688
     cpuidle_enter_state+0x2b4/0x760 drivers/cpuidle/cpuidle.c:237
     cpuidle_enter+0x3c/0x60 drivers/cpuidle/cpuidle.c:351
     call_cpuidle kernel/sched/idle.c:158 [inline]
     cpuidle_idle_call kernel/sched/idle.c:239 [inline]
     do_idle+0x1a3/0x250 kernel/sched/idle.c:306
     cpu_startup_entry+0x15/0x20 kernel/sched/idle.c:403
     secondary_startup_64_no_verify+0xb1/0xbb
    
    read to 0xffff88810798a885 of 1 bytes by interrupt on cpu 0:
     neigh_output include/net/neighbour.h:507 [inline]
     ip_finish_output2+0x79a/0xaa0 net/ipv4/ip_output.c:221
     ip_finish_output+0x3b5/0x510 net/ipv4/ip_output.c:309
     NF_HOOK_COND include/linux/netfilter.h:296 [inline]
     ip_output+0xf3/0x1a0 net/ipv4/ip_output.c:423
     dst_output include/net/dst.h:450 [inline]
     ip_local_out+0x164/0x220 net/ipv4/ip_output.c:126
     __ip_queue_xmit+0x9d3/0xa20 net/ipv4/ip_output.c:525
     ip_queue_xmit+0x34/0x40 net/ipv4/ip_output.c:539
     __tcp_transmit_skb+0x142a/0x1a00 net/ipv4/tcp_output.c:1405
     tcp_transmit_skb net/ipv4/tcp_output.c:1423 [inline]
     tcp_xmit_probe_skb net/ipv4/tcp_output.c:4011 [inline]
     tcp_write_wakeup+0x4a9/0x810 net/ipv4/tcp_output.c:4064
     tcp_send_probe0+0x2c/0x2b0 net/ipv4/tcp_output.c:4079
     tcp_probe_timer net/ipv4/tcp_timer.c:398 [inline]
     tcp_write_timer_handler+0x394/0x520 net/ipv4/tcp_timer.c:626
     tcp_write_timer+0xb9/0x180 net/ipv4/tcp_timer.c:642
     call_timer_fn+0x2e/0x1d0 kernel/time/timer.c:1421
     expire_timers+0x135/0x240 kernel/time/timer.c:1466
     __run_timers+0x368/0x430 kernel/time/timer.c:1734
     run_timer_softirq+0x19/0x30 kernel/time/timer.c:1747
     __do_softirq+0x12c/0x26e kernel/softirq.c:558
     invoke_softirq kernel/softirq.c:432 [inline]
     __irq_exit_rcu kernel/softirq.c:636 [inline]
     irq_exit_rcu+0x4e/0xa0 kernel/softirq.c:648
     sysvec_apic_timer_interrupt+0x69/0x80 arch/x86/kernel/apic/apic.c:1097
     asm_sysvec_apic_timer_interrupt+0x12/0x20
     native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
     arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
     acpi_safe_halt drivers/acpi/processor_idle.c:109 [inline]
     acpi_idle_do_entry drivers/acpi/processor_idle.c:553 [inline]
     acpi_idle_enter+0x258/0x2e0 drivers/acpi/processor_idle.c:688
     cpuidle_enter_state+0x2b4/0x760 drivers/cpuidle/cpuidle.c:237
     cpuidle_enter+0x3c/0x60 drivers/cpuidle/cpuidle.c:351
     call_cpuidle kernel/sched/idle.c:158 [inline]
     cpuidle_idle_call kernel/sched/idle.c:239 [inline]
     do_idle+0x1a3/0x250 kernel/sched/idle.c:306
     cpu_startup_entry+0x15/0x20 kernel/sched/idle.c:403
     rest_init+0xee/0x100 init/main.c:734
     arch_call_rest_init+0xa/0xb
     start_kernel+0x5e4/0x669 init/main.c:1142
     secondary_startup_64_no_verify+0xb1/0xbb
    
    value changed: 0x20 -> 0x01
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-rc6-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c90eb23eb7096595f33cfd071127586280b0bb83
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Oct 25 16:14:00 2021 +0200

    vrf: run conntrack only in context of lower/physdev for locally generated packets
    
    [ Upstream commit 8c9c296adfae9ea05f655d69e9f6e13daa86fb4a ]
    
    The VRF driver invokes netfilter for output+postrouting hooks so that users
    can create rules that check for 'oif $vrf' rather than lower device name.
    
    This is a problem when NAT rules are configured.
    
    To avoid any conntrack involvement in round 1, tag skbs as 'untracked'
    to prevent conntrack from picking them up.
    
    This gets cleared before the packet gets handed to the ip stack so
    conntrack will be active on the second iteration.
    
    One remaining issue is that a rule like
    
      output ... oif $vrfname notrack
    
    won't propagate to the second round because we can't tell
    'notrack set via ruleset' and 'notrack set by vrf driver' apart.
    However, this isn't a regression: the 'notrack' removal happens
    instead of unconditional nf_reset_ct().
    I'd also like to avoid leaking more vrf specific conditionals into the
    netfilter infra.
    
    For ingress, conntrack has already been done before the packet makes it
    to the vrf driver, with this patch egress does connection tracking with
    lower/physical device as well.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85a1da3d7a842944af9888c65c4a9f1ac9e0be0a
Author: Viktor Rosendahl <Viktor.Rosendahl@bmw.de>
Date:   Tue Oct 19 18:07:01 2021 +0200

    tools/latency-collector: Use correct size when writing queue_full_warning
    
    [ Upstream commit f604de20c0a47e0e9518940a1810193678c92fa8 ]
    
    queue_full_warning is a pointer, so it is wrong to use sizeof to calculate
    the number of characters of the string it points to. The effect is that we
    only print out the first few characters of the warning string.
    
    The correct way is to use strlen(). We don't need to add 1 to the strlen()
    because we don't want to write the terminating null character to stdout.
    
    Link: https://lkml.kernel.org/r/20211019160701.15587-1-Viktor.Rosendahl@bmw.de
    
    Link: https://lore.kernel.org/r/8fd4bb65ef3da67feac9ce3258cdbe9824752cf1.1629198502.git.jing.yangyang@zte.com.cn
    Link: https://lore.kernel.org/r/20211012025424.180781-1-davidcomponentone@gmail.com
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: Viktor Rosendahl <Viktor.Rosendahl@bmw.de>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0db6161eacdac8bdda0a614b52dae073dc8cc34a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 18 15:30:06 2021 +0100

    ARM: 9136/1: ARMv7-M uses BE-8, not BE-32
    
    [ Upstream commit 345dac33f58894a56d17b92a41be10e16585ceff ]
    
    When configuring the kernel for big-endian, we set either BE-8 or BE-32
    based on the CPU architecture level. Until linux-4.4, we did not have
    any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
    is in that category, adn we get a build error because of this:
    
    arch/arm/kernel/module-plts.c: In function 'get_module_plt':
    arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]
    
    This comes down to picking the wrong default, ARMv7-M uses BE8
    like ARMv7-A does. Changing the default gets the kernel to compile
    and presumably works.
    
    https://lore.kernel.org/all/1455804123-2526139-2-git-send-email-arnd@arndb.de/
    
    Tested-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2ab6689ed0dfca61db8aaa1a3c09617d72b842b
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Thu Oct 7 15:57:44 2021 +0200

    gfs2: Fix glock_hash_walk bugs
    
    [ Upstream commit 7427f3bb49d81525b7dd1d0f7c5f6bbc752e6f0e ]
    
    So far, glock_hash_walk took a reference on each glock it iterated over, and it
    was the examiner's responsibility to drop those references.  Dropping the final
    reference to a glock can sleep and the examiners are called in a RCU critical
    section with spin locks held, so examiners that didn't need the extra reference
    had to drop it asynchronously via gfs2_glock_queue_put or similar.  This wasn't
    done correctly in thaw_glock which did call gfs2_glock_put, and not at all in
    dump_glock_func.
    
    Change glock_hash_walk to not take glock references at all.  That way, the
    examiners that don't need them won't have to bother with slow asynchronous
    puts, and the examiners that do need references can take them themselves.
    
    Reported-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e10e8f490d6edd985620189b856cb2835149a8ed
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Oct 11 20:53:02 2021 +0200

    gfs2: Cancel remote delete work asynchronously
    
    [ Upstream commit 486408d690e130c3adacf816754b97558d715f46 ]
    
    In gfs2_inode_lookup and gfs2_create_inode, we're calling
    gfs2_cancel_delete_work which currently cancels any remote delete work
    (delete_work_func) synchronously.  This means that if the work is
    currently running, it will wait for it to finish.  We're doing this to
    pevent a previous instance of an inode from having any influence on the
    next instance.
    
    However, delete_work_func uses gfs2_inode_lookup internally, and we can
    end up in a deadlock when delete_work_func gets interrupted at the wrong
    time.  For example,
    
      (1) An inode's iopen glock has delete work queued, but the inode
          itself has been evicted from the inode cache.
    
      (2) The delete work is preempted before reaching gfs2_inode_lookup.
    
      (3) Another process recreates the inode (gfs2_create_inode).  It tries
          to cancel any outstanding delete work, which blocks waiting for
          the ongoing delete work to finish.
    
      (4) The delete work calls gfs2_inode_lookup, which blocks waiting for
          gfs2_create_inode to instantiate and unlock the new inode =>
          deadlock.
    
    It turns out that when the delete work notices that its inode has been
    re-instantiated, it will do nothing.  This means that it's safe to
    cancel the delete work asynchronously.  This prevents the kind of
    deadlock described above.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af6f6ff3a78c005b37aaa3ff31840fb13f2e51db
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 13 15:00:10 2021 +0200

    can: bittiming: can_fixup_bittiming(): change type of tseg1 and alltseg to unsigned int
    
    [ Upstream commit e346290439609a8ac67122418ca2efbad8d0a7e7 ]
    
    All timing calculation is done with unsigned integers, so change type
    of tseg1 and alltseg to unsigned int, too.
    
    Link: https://lore.kernel.org/all/20211013130653.1513627-1-mkl@pengutronix.de
    Link: https://github.com/linux-can/can-utils/pull/314
    Reported-by: Gary Bisson <bisson.gary@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b697bb86020d5e3ec255ecfa0f6f79628cf1823
Author: Stephen Suryaputra <ssuryaextr@gmail.com>
Date:   Wed Oct 20 16:06:18 2021 -0400

    gre/sit: Don't generate link-local addr if addr_gen_mode is IN6_ADDR_GEN_MODE_NONE
    
    [ Upstream commit 61e18ce7348bfefb5688a8bcd4b4d6b37c0f9b2a ]
    
    When addr_gen_mode is set to IN6_ADDR_GEN_MODE_NONE, the link-local addr
    should not be generated. But it isn't the case for GRE (as well as GRE6)
    and SIT tunnels. Make it so that tunnels consider the addr_gen_mode,
    especially for IN6_ADDR_GEN_MODE_NONE.
    
    Do this in add_v4_addrs() to cover both GRE and SIT only if the addr
    scope is link.
    
    Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
    Acked-by: Antonio Quartulli <a@unstable.cc>
    Link: https://lore.kernel.org/r/20211020200618.467342-1-ssuryaextr@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d341b27013e183e002043b2ec0db6ec6f24fa80
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Oct 21 09:55:17 2021 +0900

    ARM: clang: Do not rely on lr register for stacktrace
    
    [ Upstream commit b3ea5d56f212ad81328c82454829a736197ebccc ]
    
    Currently the stacktrace on clang compiled arm kernel uses the 'lr'
    register to find the first frame address from pt_regs. However, that
    is wrong after calling another function, because the 'lr' register
    is used by 'bl' instruction and never be recovered.
    
    As same as gcc arm kernel, directly use the frame pointer (r11) of
    the pt_regs to find the first frame address.
    
    Note that this fixes kretprobe stacktrace issue only with
    CONFIG_UNWINDER_FRAME_POINTER=y. For the CONFIG_UNWINDER_ARM,
    we need another fix.
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f11e51f0c9d158e06eb240b5316b60e80a49fc1
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Tue Oct 19 20:54:31 2021 +0900

    smackfs: use __GFP_NOFAIL for smk_cipso_doi()
    
    [ Upstream commit f91488ee15bd3cac467e2d6a361fc2d34d1052ae ]
    
    syzbot is reporting kernel panic at smk_cipso_doi() due to memory
    allocation fault injection [1]. The reason for need to use panic() was
    not explained. But since no fix was proposed for 18 months, for now
    let's use __GFP_NOFAIL for utilizing syzbot resource on other bugs.
    
    Link: https://syzkaller.appspot.com/bug?extid=89731ccb6fec15ce1c22 [1]
    Reported-by: syzbot <syzbot+89731ccb6fec15ce1c22@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b94d328763785738d052d176c345d8cc9d999e9a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Oct 17 11:43:40 2021 +0300

    iwlwifi: mvm: disable RX-diversity in powersave
    
    [ Upstream commit e5322b9ab5f63536c41301150b7ce64605ce52cc ]
    
    Just like we have default SMPS mode as dynamic in powersave,
    we should not enable RX-diversity in powersave, to reduce
    power consumption when connected to a non-MIMO AP.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20211017113927.fc896bc5cdaa.I1d11da71b8a5cbe921a37058d5f578f1b14a2023@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c430f6255375e87603976929473313cfdcc6150e
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Thu Oct 21 13:41:30 2021 +0200

    selftests/bpf: Fix perf_buffer test on system with offline cpus
    
    [ Upstream commit d4121376ac7a9c81a696d7558789b2f29ef3574e ]
    
    The perf_buffer fails on system with offline cpus:
    
      # test_progs -t perf_buffer
      test_perf_buffer:PASS:nr_cpus 0 nsec
      test_perf_buffer:PASS:nr_on_cpus 0 nsec
      test_perf_buffer:PASS:skel_load 0 nsec
      test_perf_buffer:PASS:attach_kprobe 0 nsec
      test_perf_buffer:PASS:perf_buf__new 0 nsec
      test_perf_buffer:PASS:epoll_fd 0 nsec
      skipping offline CPU #24
      skipping offline CPU #25
      skipping offline CPU #26
      skipping offline CPU #27
      skipping offline CPU #28
      skipping offline CPU #29
      skipping offline CPU #30
      skipping offline CPU #31
      test_perf_buffer:PASS:perf_buffer__poll 0 nsec
      test_perf_buffer:PASS:seen_cpu_cnt 0 nsec
      test_perf_buffer:FAIL:buf_cnt got 24, expected 32
      Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
    
    Changing the test to check online cpus instead of possible.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20211021114132.8196-2-jolsa@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19074f05307b1de40f8f6a364db8db3930f2c693
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Thu Oct 21 11:56:03 2021 -0600

    selftests: kvm: fix mismatched fclose() after popen()
    
    [ Upstream commit c3867ab5924b7a9a0b4a117902a08669d8be7c21 ]
    
    get_warnings_count() does fclose() using File * returned from popen().
    Fix it to call pclose() as it should.
    
    tools/testing/selftests/kvm/x86_64/mmio_warning_test
    x86_64/mmio_warning_test.c: In function ‘get_warnings_count’:
    x86_64/mmio_warning_test.c:87:9: warning: ‘fclose’ called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
       87 |         fclose(f);
          |         ^~~~~~~~~
    x86_64/mmio_warning_test.c:84:13: note: returned from ‘popen’
       84 |         f = popen("dmesg | grep \"WARNING:\" | wc -l", "r");
          |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df0b6862b795f5cf98d77e615df4c99f90ab192c
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed Oct 13 20:19:14 2021 +0800

    PM: hibernate: Get block device exclusively in swsusp_check()
    
    [ Upstream commit 39fbef4b0f77f9c89c8f014749ca533643a37c9f ]
    
    The following kernel crash can be triggered:
    
    [   89.266592] ------------[ cut here ]------------
    [   89.267427] kernel BUG at fs/buffer.c:3020!
    [   89.268264] invalid opcode: 0000 [#1] SMP KASAN PTI
    [   89.269116] CPU: 7 PID: 1750 Comm: kmmpd-loop0 Not tainted 5.10.0-862.14.0.6.x86_64-08610-gc932cda3cef4-dirty #20
    [   89.273169] RIP: 0010:submit_bh_wbc.isra.0+0x538/0x6d0
    [   89.277157] RSP: 0018:ffff888105ddfd08 EFLAGS: 00010246
    [   89.278093] RAX: 0000000000000005 RBX: ffff888124231498 RCX: ffffffffb2772612
    [   89.279332] RDX: 1ffff11024846293 RSI: 0000000000000008 RDI: ffff888124231498
    [   89.280591] RBP: ffff8881248cc000 R08: 0000000000000001 R09: ffffed1024846294
    [   89.281851] R10: ffff88812423149f R11: ffffed1024846293 R12: 0000000000003800
    [   89.283095] R13: 0000000000000001 R14: 0000000000000000 R15: ffff8881161f7000
    [   89.284342] FS:  0000000000000000(0000) GS:ffff88839b5c0000(0000) knlGS:0000000000000000
    [   89.285711] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   89.286701] CR2: 00007f166ebc01a0 CR3: 0000000435c0e000 CR4: 00000000000006e0
    [   89.287919] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   89.289138] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   89.290368] Call Trace:
    [   89.290842]  write_mmp_block+0x2ca/0x510
    [   89.292218]  kmmpd+0x433/0x9a0
    [   89.294902]  kthread+0x2dd/0x3e0
    [   89.296268]  ret_from_fork+0x22/0x30
    [   89.296906] Modules linked in:
    
    by running the following commands:
    
     1. mkfs.ext4 -O mmp  /dev/sda -b 1024
     2. mount /dev/sda /home/test
     3. echo "/dev/sda" > /sys/power/resume
    
    That happens because swsusp_check() calls set_blocksize() on the
    target partition which confuses the file system:
    
           Thread1                       Thread2
    mount /dev/sda /home/test
    get s_mmp_bh  --> has mapped flag
    start kmmpd thread
                                    echo "/dev/sda" > /sys/power/resume
                                      resume_store
                                        software_resume
                                          swsusp_check
                                            set_blocksize
                                              truncate_inode_pages_range
                                                truncate_cleanup_page
                                                  block_invalidatepage
                                                    discard_buffer --> clean mapped flag
    write_mmp_block
      submit_bh
        submit_bh_wbc
          BUG_ON(!buffer_mapped(bh))
    
    To address this issue, modify swsusp_check() to open the target block
    device with exclusive access.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77aa339ea59f131eefd6b9c62368973b093a721f
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Tue Oct 19 15:36:45 2021 -0700

    arm64: vdso32: suppress error message for 'make mrproper'
    
    [ Upstream commit 14831fad73f5ac30ac61760487d95a538e6ab3cb ]
    
    When running the following command without arm-linux-gnueabi-gcc in
    one's $PATH, the following warning is observed:
    
    $ ARCH=arm64 CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make -j72 LLVM=1 mrproper
    make[1]: arm-linux-gnueabi-gcc: No such file or directory
    
    This is because KCONFIG is not run for mrproper, so CONFIG_CC_IS_CLANG
    is not set, and we end up eagerly evaluating various variables that try
    to invoke CC_COMPAT.
    
    This is a similar problem to what was observed in
    commit dc960bfeedb0 ("h8300: suppress error messages for 'make clean'")
    
    Reported-by: Lucas Henneman <henneman@google.com>
    Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20211019223646.1146945-4-ndesaulniers@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d890ac58a855a5a92518e9f4b5f3b224bf2f1f1
Author: David Yang <davidcomponentone@gmail.com>
Date:   Tue Oct 12 19:16:49 2021 +0800

    samples/bpf: Fix application of sizeof to pointer
    
    [ Upstream commit b599015f044df53e93ad0a2957b615bc1a26bf73 ]
    
    The coccinelle check report:
    "./samples/bpf/xdp_redirect_cpu_user.c:397:32-38:
    ERROR: application of sizeof to pointer"
    Using the "strlen" to fix it.
    
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: David Yang <davidcomponentone@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20211012111649.983253-1-davidcomponentone@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54718ee9b8eed43ab5e20df936a6e638416a4bcf
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Oct 20 07:59:10 2021 +0200

    nvme: drop scan_lock and always kick requeue list when removing namespaces
    
    [ Upstream commit 2b81a5f015199f3d585ce710190a9e87714d3c1e ]
    
    When reading the partition table on initial scan hits an I/O error the
    I/O will hang with the scan_mutex held:
    
    [<0>] do_read_cache_page+0x49b/0x790
    [<0>] read_part_sector+0x39/0xe0
    [<0>] read_lba+0xf9/0x1d0
    [<0>] efi_partition+0xf1/0x7f0
    [<0>] bdev_disk_changed+0x1ee/0x550
    [<0>] blkdev_get_whole+0x81/0x90
    [<0>] blkdev_get_by_dev+0x128/0x2e0
    [<0>] device_add_disk+0x377/0x3c0
    [<0>] nvme_mpath_set_live+0x130/0x1b0 [nvme_core]
    [<0>] nvme_mpath_add_disk+0x150/0x160 [nvme_core]
    [<0>] nvme_alloc_ns+0x417/0x950 [nvme_core]
    [<0>] nvme_validate_or_alloc_ns+0xe9/0x1e0 [nvme_core]
    [<0>] nvme_scan_work+0x168/0x310 [nvme_core]
    [<0>] process_one_work+0x231/0x420
    
    and trying to delete the controller will deadlock as it tries to grab
    the scan mutex:
    
    [<0>] nvme_mpath_clear_ctrl_paths+0x25/0x80 [nvme_core]
    [<0>] nvme_remove_namespaces+0x31/0xf0 [nvme_core]
    [<0>] nvme_do_delete_ctrl+0x4b/0x80 [nvme_core]
    
    As we're now properly ordering the namespace list there is no need to
    hold the scan_mutex in nvme_mpath_clear_ctrl_paths() anymore.
    And we always need to kick the requeue list as the path will be marked
    as unusable and I/O will be requeued _without_ a current path.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0703920365d306b9bee2760ce59f32a385404967
Author: Israel Rukshin <israelr@nvidia.com>
Date:   Wed Oct 6 08:09:45 2021 +0000

    nvmet-tcp: fix use-after-free when a port is removed
    
    [ Upstream commit 2351ead99ce9164fb42555aee3f96af84c4839e9 ]
    
    When removing a port, all its controllers are being removed, but there
    are queues on the port that doesn't belong to any controller (during
    connection time). This causes a use-after-free bug for any command
    that dereferences req->port (like in nvmet_alloc_ctrl). Those queues
    should be destroyed before freeing the port via configfs. Destroy
    the remaining queues after the accept_work was cancelled guarantees
    that no new queue will be created.
    
    Signed-off-by: Israel Rukshin <israelr@nvidia.com>
    Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c82292ee9bc0d3144d03ed0f96344ebf9e27453
Author: Israel Rukshin <israelr@nvidia.com>
Date:   Wed Oct 6 08:09:44 2021 +0000

    nvmet-rdma: fix use-after-free when a port is removed
    
    [ Upstream commit fcf73a804c7d6bbf0ea63531c6122aa363852e04 ]
    
    When removing a port, all its controllers are being removed, but there
    are queues on the port that doesn't belong to any controller (during
    connection time). This causes a use-after-free bug for any command
    that dereferences req->port (like in nvmet_alloc_ctrl). Those queues
    should be destroyed before freeing the port via configfs. Destroy the
    remaining queues after the RDMA-CM was destroyed guarantees that no
    new queue will be created.
    
    Signed-off-by: Israel Rukshin <israelr@nvidia.com>
    Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3d5ebee9c058ccb46a4ae161998a106397980c9
Author: Israel Rukshin <israelr@nvidia.com>
Date:   Wed Oct 6 08:09:43 2021 +0000

    nvmet: fix use-after-free when a port is removed
    
    [ Upstream commit e3e19dcc4c416d65f99f13d55be2b787f8d0050e ]
    
    When a port is removed through configfs, any connected controllers
    are starting teardown flow asynchronously and can still send commands.
    This causes a use-after-free bug for any command that dereferences
    req->port (like in nvmet_parse_io_cmd).
    
    To fix this, wait for all the teardown scheduled works to complete
    (like release_work at rdma/tcp drivers). This ensures there are no
    active controllers when the port is eventually removed.
    
    Signed-off-by: Israel Rukshin <israelr@nvidia.com>
    Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e7edd183481e719df76e86798b1a4bc20882d2b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Oct 4 11:33:00 2021 -0400

    drm/amdgpu/pm: properly handle sclk for profiling modes on vangogh
    
    [ Upstream commit 68e3871dcd6e547f6c47454492bc452356cb9eac ]
    
    When selecting between levels in the force performance levels interface
    sclk (gfxclk) was not set correctly for all levels.  Select the proper
    sclk settings for all levels.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1726
    Reviewed-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 451be8bcdc17c12e01a28d95ec5d8578a13b543a
Author: Michael Tretter <m.tretter@pengutronix.de>
Date:   Wed Sep 8 14:03:10 2021 +0100

    media: allegro: ignore interrupt if mailbox is not initialized
    
    [ Upstream commit 1ecda6393db4be44aba27a243e648dc98c9b92e3 ]
    
    The mailbox is initialized after the interrupt handler is installed. As
    the firmware is loaded and started even later, it should not happen that
    the interrupt occurs without the mailbox being initialized.
    
    As the Linux Driver Verification project (linuxtesting.org) keeps
    reporting this as an error, add a check to ignore interrupts before the
    mailbox is initialized to fix this potential null pointer dereference.
    
    Reported-by: Yuri Savinykh <s02190703@gse.cs.msu.ru>
    Reported-by: Nadezda Lutovinova <lutovinova@ispras.ru>
    Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3d08aae18054fcafaf7efd2a53ffa451aa9c1af
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Oct 20 08:21:40 2021 -0600

    block: remove inaccurate requeue check
    
    [ Upstream commit 037057a5a979c7eeb2ee5d12cf4c24b805192c75 ]
    
    This check is meant to catch cases where a requeue is attempted on a
    request that is still inserted. It's never really been useful to catch any
    misuse, and now it's actively wrong. Outside of that, this should not be a
    BUG_ON() to begin with.
    
    Remove the check as it's now causing active harm, as requeue off the plug
    path will trigger it even though the request state is just fine.
    
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Link: https://lore.kernel.org/linux-block/CAHj4cs80zAUc2grnCZ015-2Rvd-=gXRfB_dFKy=RTm+wRo09HQ@mail.gmail.com/
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22d5a9add83b05e124db81936ae87e258d335cca
Author: Yaara Baruch <yaara.baruch@intel.com>
Date:   Sat Oct 16 11:43:56 2021 +0300

    iwlwifi: change all JnP to NO-160 configuration
    
    [ Upstream commit 70382b0897eeecfcd35ba5f6161dbceeb556ea1e ]
    
    JnP should not have the 160 MHz.
    
    Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ee163f4a7513.I7f87bd969a0b038c7f3a1a962d9695ffd18c5da1@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 819efcac7c3c51db40d2b3acb4fc6208c0f10ca2
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sat Oct 16 04:02:59 2021 +0000

    mwl8k: Fix use-after-free in mwl8k_fw_state_machine()
    
    [ Upstream commit 257051a235c17e33782b6e24a4b17f2d7915aaec ]
    
    When the driver fails to request the firmware, it calls its error
    handler. In the error handler, the driver detaches device from driver
    first before releasing the firmware, which can cause a use-after-free bug.
    
    Fix this by releasing firmware first.
    
    The following log reveals it:
    
    [    9.007301 ] BUG: KASAN: use-after-free in mwl8k_fw_state_machine+0x320/0xba0
    [    9.010143 ] Workqueue: events request_firmware_work_func
    [    9.010830 ] Call Trace:
    [    9.010830 ]  dump_stack_lvl+0xa8/0xd1
    [    9.010830 ]  print_address_description+0x87/0x3b0
    [    9.010830 ]  kasan_report+0x172/0x1c0
    [    9.010830 ]  ? mutex_unlock+0xd/0x10
    [    9.010830 ]  ? mwl8k_fw_state_machine+0x320/0xba0
    [    9.010830 ]  ? mwl8k_fw_state_machine+0x320/0xba0
    [    9.010830 ]  __asan_report_load8_noabort+0x14/0x20
    [    9.010830 ]  mwl8k_fw_state_machine+0x320/0xba0
    [    9.010830 ]  ? mwl8k_load_firmware+0x5f0/0x5f0
    [    9.010830 ]  request_firmware_work_func+0x172/0x250
    [    9.010830 ]  ? read_lock_is_recursive+0x20/0x20
    [    9.010830 ]  ? process_one_work+0x7a1/0x1100
    [    9.010830 ]  ? request_firmware_nowait+0x460/0x460
    [    9.010830 ]  ? __this_cpu_preempt_check+0x13/0x20
    [    9.010830 ]  process_one_work+0x9bb/0x1100
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1634356979-6211-1-git-send-email-zheyuma97@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c794f4b483a23531cefe0427d982fabb37d59b8
Author: Ryder Lee <ryder.lee@mediatek.com>
Date:   Wed Jul 14 15:56:10 2021 +0800

    mt76: mt7915: fix an off-by-one bound check
    
    [ Upstream commit d45dac0732a287fc371a23f257cce04e65627947 ]
    
    The bounds check on datalen is off-by-one, so fix it.
    
    Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84afcec2ca5a67cec81a13d3f8dcbc480489f621
Author: Kalesh Singh <kaleshsingh@google.com>
Date:   Wed Oct 13 21:52:17 2021 -0700

    tracing/cfi: Fix cmp_entries_* functions signature mismatch
    
    [ Upstream commit 7ce1bb83a14019f8c396d57ec704d19478747716 ]
    
    If CONFIG_CFI_CLANG=y, attempting to read an event histogram will cause
    the kernel to panic due to failed CFI check.
    
        1. echo 'hist:keys=common_pid' >> events/sched/sched_switch/trigger
        2. cat events/sched/sched_switch/hist
        3. kernel panics on attempting to read hist
    
    This happens because the sort() function expects a generic
    int (*)(const void *, const void *) pointer for the compare function.
    To prevent this CFI failure, change tracing map cmp_entries_* function
    signatures to match this.
    
    Also, fix the build error reported by the kernel test robot [1].
    
    [1] https://lore.kernel.org/r/202110141140.zzi4dRh4-lkp@intel.com/
    
    Link: https://lkml.kernel.org/r/20211014045217.3265162-1-kaleshsingh@google.com
    
    Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b09a201b714d698d712ba8af1052548df0350d1e
Author: Menglong Dong <imagedong@tencent.com>
Date:   Sun Oct 17 20:04:02 2021 +0800

    workqueue: make sysfs of unbound kworker cpumask more clever
    
    [ Upstream commit d25302e46592c97d29f70ccb1be558df31a9a360 ]
    
    Some unfriendly component, such as dpdk, write the same mask to
    unbound kworker cpumask again and again. Every time it write to
    this interface some work is queue to cpu, even though the mask
    is same with the original mask.
    
    So, fix it by return success and do nothing if the cpumask is
    equal with the old one.
    
    Signed-off-by: Mengen Sun <mengensun@tencent.com>
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b1a4d0ff911edb4579f9d17f6d7ae04e6fc1582
Author: Lasse Collin <lasse.collin@tukaani.org>
Date:   Mon Oct 11 05:31:40 2021 +0800

    lib/xz: Validate the value before assigning it to an enum variable
    
    [ Upstream commit 4f8d7abaa413c34da9d751289849dbfb7c977d05 ]
    
    This might matter, for example, if the underlying type of enum xz_check
    was a signed char. In such a case the validation wouldn't have caught an
    unsupported header. I don't know if this problem can occur in the kernel
    on any arch but it's still good to fix it because some people might copy
    the XZ code to their own projects from Linux instead of the upstream
    XZ Embedded repository.
    
    This change may increase the code size by a few bytes. An alternative
    would have been to use an unsigned int instead of enum xz_check but
    using an enumeration looks cleaner.
    
    Link: https://lore.kernel.org/r/20211010213145.17462-3-xiang@kernel.org
    Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5329376ce6ae6ebda1433ba857c75f8ffbc9275b
Author: Lasse Collin <lasse.collin@tukaani.org>
Date:   Mon Oct 11 05:31:39 2021 +0800

    lib/xz: Avoid overlapping memcpy() with invalid input with in-place decompression
    
    [ Upstream commit 83d3c4f22a36d005b55f44628f46cc0d319a75e8 ]
    
    With valid files, the safety margin described in lib/decompress_unxz.c
    ensures that these buffers cannot overlap. But if the uncompressed size
    of the input is larger than the caller thought, which is possible when
    the input file is invalid/corrupt, the buffers can overlap. Obviously
    the result will then be garbage (and usually the decoder will return
    an error too) but no other harm will happen when such an over-run occurs.
    
    This change only affects uncompressed LZMA2 chunks and so this
    should have no effect on performance.
    
    Link: https://lore.kernel.org/r/20211010213145.17462-2-xiang@kernel.org
    Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 562d350a88097ab7c314dbf90b7bfc07704284f2
Author: Yanfei Xu <yanfei.xu@windriver.com>
Date:   Wed Oct 13 21:41:53 2021 +0800

    locking/rwsem: Disable preemption for spinning region
    
    [ Upstream commit 7cdacc5f52d68a9370f182c844b5b3e6cc975cc1 ]
    
    The spinning region rwsem_spin_on_owner() should not be preempted,
    however the rwsem_down_write_slowpath() invokes it and don't disable
    preemption. Fix it by adding a pair of preempt_disable/enable().
    
    Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
    [peterz: Fix CONFIG_RWSEM_SPIN_ON_OWNER=n build]
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Waiman Long <longman@redhat.com>
    Link: https://lore.kernel.org/r/20211013134154.1085649-3-yanfei.xu@windriver.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5d5e53171506141ff598187ea0c26b4122a4a4d
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sat Oct 16 11:26:21 2021 +0000

    memstick: r592: Fix a UAF bug when removing the driver
    
    [ Upstream commit 738216c1953e802aa9f930c5d15b8f9092c847ff ]
    
    In r592_remove(), the driver will free dma after freeing the host, which
    may cause a UAF bug.
    
    The following log reveals it:
    
    [   45.361796 ] BUG: KASAN: use-after-free in r592_remove+0x269/0x350 [r592]
    [   45.364286 ] Call Trace:
    [   45.364472 ]  dump_stack_lvl+0xa8/0xd1
    [   45.364751 ]  print_address_description+0x87/0x3b0
    [   45.365137 ]  kasan_report+0x172/0x1c0
    [   45.365415 ]  ? r592_remove+0x269/0x350 [r592]
    [   45.365834 ]  ? r592_remove+0x269/0x350 [r592]
    [   45.366168 ]  __asan_report_load8_noabort+0x14/0x20
    [   45.366531 ]  r592_remove+0x269/0x350 [r592]
    [   45.378785 ]
    [   45.378903 ] Allocated by task 4674:
    [   45.379162 ]  ____kasan_kmalloc+0xb5/0xe0
    [   45.379455 ]  __kasan_kmalloc+0x9/0x10
    [   45.379730 ]  __kmalloc+0x150/0x280
    [   45.379984 ]  memstick_alloc_host+0x2a/0x190
    [   45.380664 ]
    [   45.380781 ] Freed by task 5509:
    [   45.381014 ]  kasan_set_track+0x3d/0x70
    [   45.381293 ]  kasan_set_free_info+0x23/0x40
    [   45.381635 ]  ____kasan_slab_free+0x10b/0x140
    [   45.381950 ]  __kasan_slab_free+0x11/0x20
    [   45.382241 ]  slab_free_freelist_hook+0x81/0x150
    [   45.382575 ]  kfree+0x13e/0x290
    [   45.382805 ]  memstick_free+0x1c/0x20
    [   45.383070 ]  device_release+0x9c/0x1d0
    [   45.383349 ]  kobject_put+0x2ef/0x4c0
    [   45.383616 ]  put_device+0x1f/0x30
    [   45.383865 ]  memstick_free_host+0x24/0x30
    [   45.384162 ]  r592_remove+0x242/0x350 [r592]
    [   45.384473 ]  pci_device_remove+0xa9/0x250
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/1634383581-11055-1-git-send-email-zheyuma97@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fff6457afad538e6768cbe5ccd93df09751c149
Author: Xiao Ni <xni@redhat.com>
Date:   Wed Oct 13 22:59:33 2021 +0800

    md: update superblock after changing rdev flags in state_store
    
    [ Upstream commit 8b9e2291e355a0eafdd5b1e21a94a6659f24b351 ]
    
    When the in memory flag is changed, we need to persist the change in the
    rdev superblock flags. This is needed for "writemostly" and "failfast".
    
    Reviewed-by: Li Feng <fengli@smartx.com>
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22b68b015d44e249b04b7c77b269991922d46bc4
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon Sep 27 15:02:52 2021 -0700

    floppy: fix calling platform_device_unregister() on invalid drives
    
    [ Upstream commit 662167e59d2f3c15a44a88088fc6c1a67c8a3650 ]
    
    platform_device_unregister() should only be called when
    a respective platform_device_register() is called. However
    the floppy driver currently allows failures when registring
    a drive and a bail out could easily cause an invalid call
    to platform_device_unregister() where it was not intended.
    
    Fix this by adding a bool to keep track of when the platform
    device was registered for a drive.
    
    This does not fix any known panic / bug. This issue was found
    through code inspection while preparing the driver to use the
    up and coming support for device_add_disk() error handling.
    From what I can tell from code inspection, chances of this
    ever happening should be insanely small, perhaps OOM.
    
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20210927220302.1073499-5-mcgrof@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 396c9e834d6981164fa112c4bcf97283cf2410e0
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Oct 6 12:01:07 2021 -0600

    block: bump max plugged deferred size from 16 to 32
    
    [ Upstream commit ba0ffdd8ce48ad7f7e85191cd29f9674caca3745 ]
    
    Particularly for NVMe with efficient deferred submission for many
    requests, there are nice benefits to be seen by bumping the default max
    plug count from 16 to 32. This is especially true for virtualized setups,
    where the submit part is more expensive. But can be noticed even on
    native hardware.
    
    Reduce the multiple queue factor from 4 to 2, since we're changing the
    default size.
    
    While changing it, move the defines into the block layer private header.
    These aren't values that anyone outside of the block layer uses, or
    should use.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3792174592b6650884d397c1b1e4e98153a00a2c
Author: Ansuel Smith <ansuelsmth@gmail.com>
Date:   Thu Oct 7 19:28:59 2021 +0200

    thermal/drivers/tsens: Add timeout to get_temp_tsens_valid
    
    [ Upstream commit d012f9189fda0f3a1b303780ba0bbc7298d0d349 ]
    
    The function can loop and lock the system if for whatever reason the bit
    for the target sensor is NEVER valid. This is the case if a sensor is
    disabled by the factory and the valid bit is never reported as actually
    valid. Add a timeout check and exit if a timeout occurs. As this is
    a very rare condition, handle the timeout only if the first read fails.
    While at it also rework the function to improve readability and convert
    to poll_timeout generic macro.
    
    Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20211007172859.583-1-ansuelsmth@gmail.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 660446ff86ca4f3617438f076f92cfb123cce3d4
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Wed Sep 29 10:25:54 2021 -0600

    drm/msm: prevent NULL dereference in msm_gpu_crashstate_capture()
    
    [ Upstream commit b220c154832c5cd0df34cbcbcc19d7135c16e823 ]
    
    Coverity complains of a possible NULL dereference:
    
    CID 120718 (#1 of 1): Dereference null return value (NULL_RETURNS)
    23. dereference: Dereferencing a pointer that might be NULL state->bos when
        calling msm_gpu_crashstate_get_bo. [show details]
    301                        msm_gpu_crashstate_get_bo(state, submit->bos[i].obj,
    302                                submit->bos[i].iova, submit->bos[i].flags);
    
    Fix this by employing the same state->bos NULL check as is used in the next
    for loop.
    
    Cc: Rob Clark <robdclark@gmail.com>
    Cc: Sean Paul <sean@poorly.run>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: linux-arm-msm@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: freedreno@lists.freedesktop.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20210929162554.14295-1-tim.gardner@canonical.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38ef472ca8e59c971984922ad3b60d5338c16deb
Author: Yuanzheng Song <songyuanzheng@huawei.com>
Date:   Fri Oct 15 08:32:30 2021 +0000

    thermal/core: Fix null pointer dereference in thermal_release()
    
    [ Upstream commit 1dd7128b839f631b31a9e9dce3aaf639bef74e9d ]
    
    If both dev_set_name() and device_register() failed, then null pointer
    dereference occurs in thermal_release() which will use strncmp() to
    compare the name.
    
    So fix it by adding dev_set_name() return value check.
    
    Signed-off-by: Yuanzheng Song <songyuanzheng@huawei.com>
    Link: https://lore.kernel.org/r/20211015083230.67658-1-songyuanzheng@huawei.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c0caa7e26368639f19f54b343b4a7d7d1f5b200
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 29 15:02:18 2021 -0700

    leaking_addresses: Always print a trailing newline
    
    [ Upstream commit cf2a85efdade117e2169d6e26641016cbbf03ef0 ]
    
    For files that lack trailing newlines and match a leaking address (e.g.
    wchan[1]), the leaking_addresses.pl report would run together with the
    next line, making things look corrupted.
    
    Unconditionally remove the newline on input, and write it back out on
    output.
    
    [1] https://lore.kernel.org/all/20210103142726.GC30643@xsang-OptiPlex-9020/
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20211008111626.151570317@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9796eb9137b3326ec5fd551dc11828badd0a1d52
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Tue Oct 12 12:34:02 2021 +0200

    net: phy: micrel: make *-skew-ps check more lenient
    
    [ Upstream commit 67ca5159dbe2edb5dae7544447b8677d2596933a ]
    
    It seems reasonable to fine-tune only some of the skew values when using
    one of the rgmii-*id PHY modes, and even when all skew values are
    specified, using the correct ID PHY mode makes sense for documentation
    purposes. Such a configuration also appears in the binding docs in
    Documentation/devicetree/bindings/net/micrel-ksz90x1.txt, so the driver
    should not warn about it.
    
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20211012103402.21438-1-matthias.schiffer@ew.tq-group.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abbc58deaab6883a0a4011f12a6d7f96b29668eb
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Mon Oct 11 20:42:31 2021 +0800

    drm/amdkfd: fix resume error when iommu disabled in Picasso
    
    [ Upstream commit 6f4b590aae217da16cfa44039a2abcfb209137ab ]
    
    When IOMMU disabled in sbios and kfd in iommuv2 path,
    IOMMU resume failure blocks system resume. Don't allow kfd to
    use iommu v2 when iommu is disabled.
    
    Reported-by: youling <youling257@gmail.com>
    Tested-by: youling <youling257@gmail.com>
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: James Zhu <James.Zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5837c23f7ddd6a32866d2f64b6e117ba31e97146
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Fri Oct 8 16:07:45 2021 -0400

    drm/amd/display: fix null pointer deref when plugging in display
    
    [ Upstream commit 1f3b22e4eb162e0b1d423106a47484943a22a309 ]
    
    [Why&How]
    When system boots in headless mode, connecting a 4k display creates a
    null pointer dereference due to hubp for a certain plane being null.
    Add a condition to check for null hubp before dereferencing it.
    
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfc1a472a8d89c0d0bbb3600501eeeebc5ec8039
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Oct 9 16:22:09 2021 +0200

    ACPI: scan: Release PM resources blocked by unused objects
    
    [ Upstream commit c10383e8ddf4810b9a5c1595404c2724d925a0a6 ]
    
    On some systems the ACPI namespace contains device objects that are
    not used in certain configurations of the system.  If they start off
    in the D0 power state configuration, they will stay in it until the
    system reboots, because of the lack of any mechanism possibly causing
    their configuration to change.  If that happens, they may prevent
    some power resources from being turned off or generally they may
    prevent the platform from getting into the deepest low-power states
    thus causing some energy to be wasted.
    
    Address this issue by changing the configuration of unused ACPI
    device objects to the D3cold power state one after carrying out
    the ACPI-based enumeration of devices.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091
    Link: https://lore.kernel.org/linux-acpi/20211007205126.11769-1-mario.limonciello@amd.com/
    Reported-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37f2aebf16564c2e8bd3845eea7ad054711e4e96
Author: André Almeida <andrealmeid@collabora.com>
Date:   Fri Oct 8 00:05:29 2021 -0300

    ACPI: battery: Accept charges over the design capacity as full
    
    [ Upstream commit 2835f327bd1240508db2c89fe94a056faa53c49a ]
    
    Some buggy firmware and/or brand new batteries can support a charge that's
    slightly over the reported design capacity. In such cases, the kernel will
    report to userspace that the charging state of the battery is "Unknown",
    when in reality the battery charge is "Full", at least from the design
    capacity point of view. Make the fallback condition accepts capacities
    over the designed capacity so userspace knows that is full.
    
    Signed-off-by: André Almeida <andrealmeid@collabora.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c45c83c1716f3eac30bfdf21c60f1f09b8e598c2
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Wed Jul 21 19:03:47 2021 +0200

    iov_iter: Fix iov_iter_get_pages{,_alloc} page fault return value
    
    [ Upstream commit 814a66741b9ffb5e1ba119e368b178edb0b7322d ]
    
    Both iov_iter_get_pages and iov_iter_get_pages_alloc return the number
    of bytes of the iovec they could get the pages for.  When they cannot
    get any pages, they're supposed to return 0, but when the start of the
    iovec isn't page aligned, the calculation goes wrong and they return a
    negative value.  Fix both functions.
    
    In addition, change iov_iter_get_pages_alloc to return NULL in that case
    to prevent resource leaks.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d78de051ff328f98cd534d4bc1bfee1f4f829f61
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Sat Oct 9 12:19:18 2021 +0800

    mmc: moxart: Fix reference count leaks in moxart_probe
    
    [ Upstream commit 8105c2abbf36296bf38ca44f55ee45d160db476a ]
    
    The issue happens in several error handling paths on two refcounted
    object related to the object "host" (dma_chan_rx, dma_chan_tx). In
    these paths, the function forgets to decrement one or both objects'
    reference count increased earlier by dma_request_chan(), causing
    reference count leaks.
    
    Fix it by balancing the refcounts of both objects in some error
    handling paths. In correspondence with the changes in moxart_probe(),
    IS_ERR() is replaced with IS_ERR_OR_NULL() in moxart_remove() as well.
    
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Link: https://lore.kernel.org/r/20211009041918.28419-1-xiongx18@fudan.edu.cn
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e41d46fe0954ec4ae806f8b815bf70929d5c5657
Author: Will Deacon <will@kernel.org>
Date:   Fri Oct 8 14:58:37 2021 +0100

    KVM: arm64: Propagate errors from __pkvm_prot_finalize hypercall
    
    [ Upstream commit 2f2e1a5069679491d18cf9021da19b40c56a17f3 ]
    
    If the __pkvm_prot_finalize hypercall returns an error, we WARN but fail
    to propagate the failure code back to kvm_arch_init().
    
    Pass a pointer to a zero-initialised return variable so that failure
    to finalise the pKVM protections on a host CPU can be reported back to
    KVM.
    
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Quentin Perret <qperret@google.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20211008135839.1193-5-will@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd267d35d82a523c9f7f953fe7efad42fedc82f7
Author: Tuo Li <islituo@gmail.com>
Date:   Thu Aug 5 08:38:53 2021 -0700

    ath: dfs_pattern_detector: Fix possible null-pointer dereference in channel_detector_create()
    
    [ Upstream commit 4b6012a7830b813799a7faf40daa02a837e0fd5b ]
    
    kzalloc() is used to allocate memory for cd->detectors, and if it fails,
    channel_detector_exit() behind the label fail will be called:
      channel_detector_exit(dpd, cd);
    
    In channel_detector_exit(), cd->detectors is dereferenced through:
      struct pri_detector *de = cd->detectors[i];
    
    To fix this possible null-pointer dereference, check cd->detectors before
    the for loop to dereference cd->detectors.
    
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Tuo Li <islituo@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210805153854.154066-1-islituo@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e4f6e33d6f22b073697098ef6fa0f33e44c391c
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Aug 18 11:24:51 2021 -0400

    tracing: Disable "other" permission bits in the tracefs files
    
    [ Upstream commit 21ccc9cd72116289469e5519b6159c675a2fa58f ]
    
    When building the files in the tracefs file system, do not by default set
    any permissions for OTH (other). This will make it easier for admins who
    want to define a group for accessing tracefs and not having to first
    disable all the permission bits for "other" in the file system.
    
    As tracing can leak sensitive information, it should never by default
    allowing all users access. An admin can still set the permission bits for
    others to have access, which may be useful for creating a honeypot and
    seeing who takes advantage of it and roots the machine.
    
    Link: https://lkml.kernel.org/r/20210818153038.864149276@goodmis.org
    
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1067f23c1ee7b00852c14ed543bbee9874d6867c
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Aug 18 11:24:50 2021 -0400

    tracefs: Have tracefs directories not set OTH permission bits by default
    
    [ Upstream commit 49d67e445742bbcb03106b735b2ab39f6e5c56bc ]
    
    The tracefs file system is by default mounted such that only root user can
    access it. But there are legitimate reasons to create a group and allow
    those added to the group to have access to tracing. By changing the
    permissions of the tracefs mount point to allow access, it will allow
    group access to the tracefs directory.
    
    There should not be any real reason to allow all access to the tracefs
    directory as it contains sensitive information. Have the default
    permission of directories being created not have any OTH (other) bits set,
    such that an admin that wants to give permission to a group has to first
    disable all OTH bits in the file system.
    
    Link: https://lkml.kernel.org/r/20210818153038.664127804@goodmis.org
    
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5425f404b527b04ca6ce5eb01e2b9b92e9d1853b
Author: Alex Sierra <alex.sierra@amd.com>
Date:   Thu Oct 7 12:04:09 2021 -0500

    drm/amdkfd: rm BO resv on validation to avoid deadlock
    
    [ Upstream commit ec6abe831a843208e99a59adf108adba22166b3f ]
    
    This fix the deadlock with the BO reservations during SVM_BO evictions
    while allocations in VRAM are concurrently performed. More specific,
    while the ttm waits for the fence to be signaled (ttm_bo_wait), it
    already has the BO reserved. In parallel, the restore worker might be
    running, prefetching memory to VRAM. This also requires to reserve the
    BO, but blocks the mmap semaphore first. The deadlock happens when the
    SVM_BO eviction worker kicks in and waits for the mmap semaphore held
    in restore worker. Preventing signal the fence back, causing the
    deadlock until the ttm times out.
    
    We don't need to hold the BO reservation anymore during validation
    and mapping. Now the physical addresses are taken from hmm_range_fault.
    We also take migrate_mutex to prevent range migration while
    validate_and_map update GPU page table.
    
    Signed-off-by: Alex Sierra <alex.sierra@amd.com>
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Reviewed-by: Philip Yang <philip.yang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3aa4e54add8d2bf32a8a060688751970289f04f
Author: Antoine Tenart <atenart@kernel.org>
Date:   Thu Oct 7 16:00:51 2021 +0200

    net-sysfs: try not to restart the syscall if it will fail eventually
    
    [ Upstream commit 146e5e733310379f51924111068f08a3af0db830 ]
    
    Due to deadlocks in the networking subsystem spotted 12 years ago[1],
    a workaround was put in place[2] to avoid taking the rtnl lock when it
    was not available and restarting the syscall (back to VFS, letting
    userspace spin). The following construction is found a lot in the net
    sysfs and sysctl code:
    
      if (!rtnl_trylock())
              return restart_syscall();
    
    This can be problematic when multiple userspace threads use such
    interfaces in a short period, making them to spin a lot. This happens
    for example when adding and moving virtual interfaces: userspace
    programs listening on events, such as systemd-udevd and NetworkManager,
    do trigger actions reading files in sysfs. It gets worse when a lot of
    virtual interfaces are created concurrently, say when creating
    containers at boot time.
    
    Returning early without hitting the above pattern when the syscall will
    fail eventually does make things better. While it is not a fix for the
    issue, it does ease things.
    
    [1] https://lore.kernel.org/netdev/49A4D5D5.5090602@trash.net/
        https://lore.kernel.org/netdev/m14oyhis31.fsf@fess.ebiederm.org/
        and https://lore.kernel.org/netdev/20090226084924.16cb3e08@nehalam/
    [2] Rightfully, those deadlocks are *hard* to solve.
    
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74339549c8dcfa87c571de0a7d46b5e92cc3d537
Author: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Date:   Mon Dec 7 07:16:06 2020 +0100

    media: usb: dvd-usb: fix uninit-value bug in dibusb_read_eeprom_byte()
    
    [ Upstream commit 899a61a3305d49e8a712e9ab20d0db94bde5929f ]
    
    In dibusb_read_eeprom_byte(), if dibusb_i2c_msg() fails, val gets
    assigned an value that's not properly initialized.
    Using kzalloc() in place of kmalloc() for the buffer fixes this issue,
    as the val can now be set to 0 in the event dibusb_i2c_msg() fails.
    
    Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com
    Tested-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com
    Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 688ac68a23d460dfaa510c33bfa606949299d464
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Oct 7 00:26:22 2021 +0200

    media: ipu3-imgu: VIDIOC_QUERYCAP: Fix bus_info
    
    [ Upstream commit ea2b9a33711604e91f8c826f4dcb3c12baa1990a ]
    
    bus_info field had a different value for the media entity and the video
    device.
    
    Fixes v4l2-compliance:
    
    v4l2-compliance.cpp(637): media bus_info 'PCI:0000:00:05.0' differs from
                              V4L2 bus_info 'PCI:viewfinder'
    
    Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb795fd959acf150216d1cf0b52a6035529b85b5
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Oct 7 00:26:21 2021 +0200

    media: ipu3-imgu: imgu_fmt: Handle properly try
    
    [ Upstream commit 553481e38045f349bb9aa596d03bebd020020c9c ]
    
    For a try_fmt call, the node noes not need to be enabled.
    
    Fixes v4l2-compliance
    
    fail: v4l2-test-formats.cpp(717): Video Output Multiplanar is valid, but
                                      no TRY_FMT was implemented
    test VIDIOC_TRY_FMT: FAIL
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c2a4bad39e1645991f1d3f7e14c30fbdd5c775d
Author: Mirela Rabulea <mirela.rabulea@nxp.com>
Date:   Mon Sep 27 20:56:32 2021 +0200

    media: imx-jpeg: Fix possible null pointer dereference
    
    [ Upstream commit 83f5f0633b156c636f5249d3c10f2a9423dd4c96 ]
    
    Found by Coverity scan.
    
    Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
    Reviewed-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a56e9d7609ee951df3087cd61ea08c62459851cc
Author: Wojciech Drewek <wojciech.drewek@intel.com>
Date:   Thu Aug 19 17:08:49 2021 -0700

    ice: Move devlink port to PF/VF struct
    
    [ Upstream commit 2ae0aa4758b0f4a247d45cb3bf01548a7f396751 ]
    
    Keeping devlink port inside VSI data structure causes some issues.
    Since VF VSI is released during reset that means that we have to
    unregister devlink port and register it again every time reset is
    triggered. With the new changes in devlink API it
    might cause deadlock issues. After calling
    devlink_port_register/devlink_port_unregister devlink API is going to
    lock rtnl_mutex. It's an issue when VF reset is triggered in netlink
    operation context (like setting VF MAC address or VLAN),
    because rtnl_lock is already taken by netlink. Another call of
    rtnl_lock from devlink API results in dead-lock.
    
    By moving devlink port to PF/VF we avoid creating/destroying it
    during reset. Since this patch, devlink ports are created during
    ice_probe, destroyed during ice_remove for PF and created during
    ice_repr_add, destroyed during ice_repr_rem for VF.
    
    Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9053ab4dfc1b4e2b41f623f0efc69afeb38b0ec0
Author: Vincent Donnefort <vincent.donnefort@arm.com>
Date:   Wed Sep 8 15:05:26 2021 +0100

    cpufreq: Make policy min/max hard requirements
    
    [ Upstream commit 15171769069408789a72f9aa9a52cc931b839b56 ]
    
    When applying the policy min/max limits, the requested frequency is
    simply clamped to not be out of range. It means, however, if one of the
    boundaries isn't an available frequency, the frequency resolution can
    return a value out of those limits, depending on the relation used.
    
    e.g. freq{0,1,2} being available frequencies.
    
              freq0  policy->min  freq1  policy->max   freq2
                |        |          |        |           |
              17kHz     18kHz     19kHz     20kHz      21kHz
    
         __resolve_freq(21kHz, CPUFREQ_RELATION_L) -> 21kHz (out of bounds)
         __resolve_freq(17kHz, CPUFREQ_RELATION_H) -> 17kHz (out of bounds)
    
    If, during the policy init, we resolve the requested min/max to existing
    frequencies, we ensure that any CPUFREQ_RELATION_* would resolve to a
    frequency which is inside the policy min/max range.
    
    Making the policy limits rigid helps to introduce the inefficient
    frequencies support. Resolving an inefficient frequency to an efficient
    one should not transgress policy->max (which can be set for thermal
    reason) and having a value we can trust simplify this comparison.
    
    Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8e98aa12411604360c4da14b83753cba581b5ca
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Sep 29 18:31:25 2021 +0200

    ACPICA: Avoid evaluating methods too early during system resume
    
    [ Upstream commit d3c4b6f64ad356c0d9ddbcf73fa471e6a841cc5c ]
    
    ACPICA commit 0762982923f95eb652cf7ded27356b247c9774de
    
    During wakeup from system-wide sleep states, acpi_get_sleep_type_data()
    is called and it tries to get memory from the slab allocator in order
    to evaluate a control method, but if KFENCE is enabled in the kernel,
    the memory allocation attempt causes an IRQ work to be queued and a
    self-IPI to be sent to the CPU running the code which requires the
    memory controller to be ready, so if that happens too early in the
    wakeup path, it doesn't work.
    
    Prevent that from taking place by calling acpi_get_sleep_type_data()
    for S0 upfront, when preparing to enter a given sleep state, and
    saving the data obtained by it for later use during system wakeup.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214271
    Reported-by: Reik Keutterling <spielkind@gmail.com>
    Tested-by: Reik Keutterling <spielkind@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fc13c5d43f517b5eb03feaae5e38efb863fba66
Author: Li Zhijian <lizhijian@cn.fujitsu.com>
Date:   Thu Sep 2 10:43:33 2021 +0800

    kselftests/sched: cleanup the child processes
    
    [ Upstream commit 1c36432b278cecf1499f21fae19836e614954309 ]
    
    Previously, 'make -C sched run_tests' will block forever when it occurs
    something wrong where the *selftests framework* is waiting for its child
    processes to exit.
    
    [root@iaas-rpma sched]# ./cs_prctl_test
    
     ## Create a thread/process/process group hiearchy
    Not a core sched system
    tid=74985, / tgid=74985 / pgid=74985: ffffffffffffffff
    Not a core sched system
        tid=74986, / tgid=74986 / pgid=74985: ffffffffffffffff
    Not a core sched system
            tid=74988, / tgid=74986 / pgid=74985: ffffffffffffffff
    Not a core sched system
            tid=74989, / tgid=74986 / pgid=74985: ffffffffffffffff
    Not a core sched system
            tid=74990, / tgid=74986 / pgid=74985: ffffffffffffffff
    Not a core sched system
        tid=74987, / tgid=74987 / pgid=74985: ffffffffffffffff
    Not a core sched system
            tid=74991, / tgid=74987 / pgid=74985: ffffffffffffffff
    Not a core sched system
            tid=74992, / tgid=74987 / pgid=74985: ffffffffffffffff
    Not a core sched system
            tid=74993, / tgid=74987 / pgid=74985: ffffffffffffffff
    
    Not a core sched system
    (268) FAILED: get_cs_cookie(0) == 0
    
     ## Set a cookie on entire process group
    -1 = prctl(62, 1, 0, 2, 0)
    core_sched create failed -- PGID: Invalid argument
    (cs_prctl_test.c:272) -
    [root@iaas-rpma sched]# ps
        PID TTY          TIME CMD
       4605 pts/2    00:00:00 bash
      74986 pts/2    00:00:00 cs_prctl_test
      74987 pts/2    00:00:00 cs_prctl_test
      74999 pts/2    00:00:00 ps
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Chris Hyser <chris.hyser@oracle.com>
    Link: https://lore.kernel.org/r/20210902024333.75983-1-lizhijian@cn.fujitsu.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a803c35d0b3868d8d54e2c1787989ec58688cee7
Author: Josh Don <joshdon@google.com>
Date:   Fri Aug 27 09:54:38 2021 -0700

    fs/proc/uptime.c: Fix idle time reporting in /proc/uptime
    
    [ Upstream commit a130e8fbc7de796eb6e680724d87f4737a26d0ac ]
    
    /proc/uptime reports idle time by reading the CPUTIME_IDLE field from
    the per-cpu kcpustats. However, on NO_HZ systems, idle time is not
    continually updated on idle cpus, leading this value to appear
    incorrectly small.
    
    /proc/stat performs an accounting update when reading idle time; we
    can use the same approach for uptime.
    
    With this patch, /proc/stat and /proc/uptime now agree on idle time.
    Additionally, the following shows idle time tick up consistently on an
    idle machine:
    
      (while true; do cat /proc/uptime; sleep 1; done) | awk '{print $2-prev; prev=$2}'
    
    Reported-by: Luigi Rizzo <lrizzo@google.com>
    Signed-off-by: Josh Don <joshdon@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lkml.kernel.org/r/20210827165438.3280779-1-joshdon@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c379a77ae33619a131c185257b07ab97d444485
Author: Corey Minyard <cminyard@mvista.com>
Date:   Thu Sep 16 11:36:20 2021 -0500

    ipmi: Disable some operations during a panic
    
    [ Upstream commit b36eb5e7b75a756baa64909a176dd4269ee05a8b ]
    
    Don't do kfree or other risky things when oops_in_progress is set.
    It's easy enough to avoid doing them
    
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60cbd3e635f05c1133451d2d9d6840e55e676cc3
Author: Nadezda Lutovinova <lutovinova@ispras.ru>
Date:   Wed Aug 11 19:18:16 2021 +0200

    media: rcar-csi2: Add checking to rcsi2_start_receiver()
    
    [ Upstream commit fc41665498332ad394b7db37f23e9394096ddc71 ]
    
    If rcsi2_code_to_fmt() return NULL, then null pointer dereference occurs
    in the next cycle. That should not be possible now but adding checking
    protects from future bugs.
    The patch adds checking if format is NULL.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
    Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77da4492ad9335cdefb449cbe9ae9671f16961c1
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Sep 28 18:06:33 2021 +0200

    brcmfmac: Add DMI nvram filename quirk for Cyberbook T116 tablet
    
    [ Upstream commit 49c3eb3036e6359c5c20fe76c611a2c0e0d4710e ]
    
    The Cyberbook T116 tablet contains quite generic names in the sys_vendor
    and product_name DMI strings, without this patch brcmfmac will try to load:
    "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which
    is way too generic.
    
    The nvram file shipped on the factory Android image contains the exact
    same settings as those used on the AcePC T8 mini PC, so point the new
    DMI nvram filename quirk to the acepc-t8 nvram file.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210928160633.96928-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f25c2738d68a083dcda78e743bfe64ac297b95bb
Author: Zong-Zhe Yang <kevin_yang@realtek.com>
Date:   Mon Sep 27 19:18:30 2021 +0800

    rtw88: fix RX clock gate setting while fifo dump
    
    [ Upstream commit c5a8e90730a322f236731fc347dd3afa5db5550e ]
    
    When fw fifo dumps, RX clock gating should be disabled to avoid
    something unexpected. However, the register operation ran into
    a mistake. So, we fix it.
    
    Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210927111830.5354-1-pkshih@realtek.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ea446e3363e71935f2307c99dc37fc2cc8ed4e4
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Sep 26 10:12:24 2021 -0700

    ia64: don't do IA64_CMPXCHG_DEBUG without CONFIG_PRINTK
    
    [ Upstream commit c15b5fc054c3d6c97e953617605235c5cb8ce979 ]
    
    When CONFIG_PRINTK is not set, the CMPXCHG_BUGCHECK() macro calls
    _printk(), but _printk() is a static inline function, not available
    as an extern.
    Since the purpose of the macro is to print the BUGCHECK info,
    make this config option depend on PRINTK.
    
    Fixes multiple occurrences of this build error:
    
    ../include/linux/printk.h:208:5: error: static declaration of '_printk' follows non-static declaration
      208 | int _printk(const char *s, ...)
          |     ^~~~~~~
    In file included from ../arch/ia64/include/asm/cmpxchg.h:5,
    ../arch/ia64/include/uapi/asm/cmpxchg.h:146:28: note: previous declaration of '_printk' with type 'int(const char *, ...)'
      146 |                 extern int _printk(const char *fmt, ...);
    
    Cc: linux-ia64@vger.kernel.org
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Chris Down <chris@chrisdown.name>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b55e15b663659a286bc98f3a0d9307e2280cfe1
Author: Rajat Asthana <rajatasthana4@gmail.com>
Date:   Wed Aug 18 22:31:10 2021 +0200

    media: mceusb: return without resubmitting URB in case of -EPROTO error.
    
    [ Upstream commit 476db72e521983ecb847e4013b263072bb1110fc ]
    
    Syzkaller reported a warning called "rcu detected stall in dummy_timer".
    
    The error seems to be an error in mceusb_dev_recv(). In the case of
    -EPROTO error, the routine immediately resubmits the URB. Instead it
    should return without resubmitting URB.
    
    Reported-by: syzbot+4d3749e9612c2cfab956@syzkaller.appspotmail.com
    Signed-off-by: Rajat Asthana <rajatasthana4@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51ae7f96267256f67d3a93ceac0c03ef7feaa956
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Date:   Sat Sep 11 21:19:58 2021 +0200

    media: rcar-vin: Use user provided buffers when starting
    
    [ Upstream commit a5991c4e947153418f71f4689614b87ca0551b81 ]
    
    When adding an internal scratch buffer to improve buffer handling when
    stopping it was also erroneously used when syncing at capture start.
    This led to that the first three buffers captured were always dropped
    as they were captured in the scratch buffer instead of in a buffer
    provided by the user.
    
    Allow the hardware to be given user provided buffers when preparing for
    capture in the stopped state. This still allows the driver to sync with
    the hardware and always completes the buffers to user-space in the
    correct order as no buffers are completed before the sync is complete.
    This change improves the driver as buffers are completed and given to
    the user three frames earlier than before.
    
    The change also fixes a warning produced by v4l2-compliance,
    
        warn: v4l2-test-buffers.cpp(448): got sequence number 3, expected 0
    
    [hverkuil: fixed some typos in the Subject and the log message]
    
    Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88dcc2d14960a650e863f46ccb0465531538f423
Author: Martin Kepplinger <martink@posteo.de>
Date:   Wed Sep 8 10:47:46 2021 +0200

    media: imx: set a media_device bus_info string
    
    [ Upstream commit 6d0d779b212c27293d9ccb4da092ff0ccb6efa39 ]
    
    Some tools like v4l2-compliance let users select a media device based
    on the bus_info string which can be quite convenient. Use a unique
    string for that.
    
    This also fixes the following v4l2-compliance warning:
    warn: v4l2-test-media.cpp(52): empty bus_info
    
    Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e922d0b6e6a67a34a4638681b90955dfd2091991
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date:   Thu Sep 9 13:24:23 2021 +0200

    media: videobuf2: rework vb2_mem_ops API
    
    [ Upstream commit a4b83deb3e76fb9385ca58e2c072a145b3a320d6 ]
    
    With the new DMA API we need an extension of the videobuf2 API.
    Previously, videobuf2 core would set the non-coherent DMA bit
    in the vb2_queue dma_attr field (if user-space would pass a
    corresponding memory hint); the vb2 core then would pass the
    vb2_queue dma_attrs to the vb2 allocators. The vb2 allocator
    would use the queue's dma_attr and the DMA API would allocate
    either coherent or non-coherent memory.
    
    But we cannot do this anymore, since there is no corresponding DMA
    attr flag and, hence, there is no way for the allocator to become
    aware of what type of allocation user-space has requested. So we
    need to pass more context from videobuf2 core to the allocators.
    
    Fix this by changing the call_ptr_memop() macro to pass the
    vb2 pointer to the corresponding op callbacks.
    
    Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdf5c3f846072f244cb66f34c2ef7b122ccca0a0
Author: Nadezda Lutovinova <lutovinova@ispras.ru>
Date:   Wed Aug 11 15:32:28 2021 +0200

    media: s5p-mfc: Add checking to s5p_mfc_probe().
    
    [ Upstream commit cdfaf4752e6915a4b455ad4400133e540e4dc965 ]
    
    If of_device_get_match_data() return NULL,
    then null pointer dereference occurs in  s5p_mfc_init_pm().
    The patch adds checking if dev->variant is NULL.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb2cb679699ee42aff4142d081c2a57655c06b6d
Author: Tuo Li <islituo@gmail.com>
Date:   Thu Aug 5 09:55:35 2021 +0200

    media: s5p-mfc: fix possible null-pointer dereference in s5p_mfc_probe()
    
    [ Upstream commit 8515965e5e33f4feb56134348c95953f3eadfb26 ]
    
    The variable pdev is assigned to dev->plat_dev, and dev->plat_dev is
    checked in:
      if (!dev->plat_dev)
    
    This indicates both dev->plat_dev and pdev can be NULL. If so, the
    function dev_err() is called to print error information.
      dev_err(&pdev->dev, "No platform data specified\n");
    
    However, &pdev->dev is an illegal address, and it is dereferenced in
    dev_err().
    
    To fix this possible null-pointer dereference, replace dev_err() with
    mfc_err().
    
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Tuo Li <islituo@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bd28fe587a5c8267b7030e33c9bcc7776130a36
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Thu May 27 11:26:24 2021 +0200

    media: vidtv: Fix memory leak in remove
    
    [ Upstream commit 76e21bb8be4f5f987f3006d197196fe6af63f656 ]
    
    vidtv_bridge_remove() releases and cleans up everything except for dvb
    itself. The patch adds this missed release.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18c4e5e59f82f6fa6348b60433822da02e88ce23
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Fri Jun 18 14:29:13 2021 +0200

    media: uvcvideo: Set unique vdev name based in type
    
    [ Upstream commit e3f60e7e1a2b451f538f9926763432249bcf39c4 ]
    
    All the entities must have a unique name. We can have a descriptive and
    unique name by appending the function and the entity->id.
    
    This is even resilent to multi chain devices.
    
    Fixes v4l2-compliance:
    Media Controller ioctls:
                    fail: v4l2-test-media.cpp(205): v2_entity_names_set.find(key) != v2_entity_names_set.end()
            test MEDIA_IOC_G_TOPOLOGY: FAIL
                    fail: v4l2-test-media.cpp(394): num_data_links != num_links
            test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 477f767b947263fc6722fdc6862254629ff4e948
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Fri Jun 18 14:29:09 2021 +0200

    media: uvcvideo: Return -EIO for control errors
    
    [ Upstream commit ffccdde5f0e17d2f0d788a9d831a027187890eaa ]
    
    The device is doing something unexpected with the control. Either because
    the protocol is not properly implemented or there has been a HW error.
    
    Fixes v4l2-compliance:
    
    Control ioctls (Input 0):
                    fail: v4l2-test-controls.cpp(448): s_ctrl returned an error (22)
            test VIDIOC_G/S_CTRL: FAIL
                    fail: v4l2-test-controls.cpp(698): s_ext_ctrls returned an error (22)
            test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
    
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c26956139893ed83242a5bc23a8948027592069
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Fri Jun 18 14:29:08 2021 +0200

    media: uvcvideo: Set capability in s_param
    
    [ Upstream commit 97a2777a96070afb7da5d587834086c0b586c8cc ]
    
    Fixes v4l2-compliance:
    
    Format ioctls (Input 0):
                    warn: v4l2-test-formats.cpp(1339): S_PARM is supported but doesn't report V4L2_CAP_TIMEPERFRAME
                    fail: v4l2-test-formats.cpp(1241): node->has_frmintervals && !cap->capability
    
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 673ce2812ed4a3e22baf3fd82f8b0f4004ec2462
Author: Dmitriy Ulitin <ulitin@ispras.ru>
Date:   Thu May 27 17:06:26 2021 +0200

    media: stm32: Potential NULL pointer dereference in dcmi_irq_thread()
    
    [ Upstream commit 548fa43a58696450c15b8f5564e99589c5144664 ]
    
    At the moment of enabling irq handling:
    
    1922 ret = devm_request_threaded_irq(&pdev->dev, irq, dcmi_irq_callback,
    1923                    dcmi_irq_thread, IRQF_ONESHOT,
    1924                    dev_name(&pdev->dev), dcmi);
    
    there is still uninitialized field sd_format of struct stm32_dcmi *dcmi.
    If an interrupt occurs in the interval between the installation of the
    interrupt handler and the initialization of this field, NULL pointer
    dereference happens.
    
    This field is dereferenced in the handler function without any check:
    
    457 if (dcmi->sd_format->fourcc == V4L2_PIX_FMT_JPEG &&
    458         dcmi->misr & IT_FRAME) {
    
    The patch moves interrupt handler installation
    after initialization of the sd_format field that happens in
    dcmi_graph_notify_complete() via dcmi_set_default_fmt().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Dmitriy Ulitin <ulitin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25bde3ba1a34eb981c2fac9568e7aca90777e6d2
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Tue Aug 10 18:29:43 2021 +0200

    media: atomisp: Fix error handling in probe
    
    [ Upstream commit e16f5e39acd6d10cc63ae39bc0a77188ed828f22 ]
    
    There were several issues with handling errors in lm3554_probe():
    - Probe did not set the error code when v4l2_ctrl_handler_init() failed.
    - It intermixed gotos for handling errors of v4l2_ctrl_handler_init()
      and media_entity_pads_init().
    - It did not set the error code for failures of v4l2_ctrl_new_custom().
    - Probe did not free resources in case of failures of
      atomisp_register_i2c_module().
    
    The patch fixes all these issues.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Link: https://lore.kernel.org/linux-media/20210810162943.19852-1-novikov@ispras.ru
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f92948e1e25a4d9860d040a0108bd7656bb15588
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Wed Jun 23 08:01:05 2021 +0200

    media: netup_unidvb: handle interrupt properly according to the firmware
    
    [ Upstream commit dbb4cfea6efe979ed153bd59a6a527a90d3d0ab3 ]
    
    The interrupt handling should be related to the firmware version. If
    the driver matches an old firmware, then the driver should not handle
    interrupt such as i2c or dma, otherwise it will cause some errors.
    
    This log reveals it:
    
    [   27.708641] INFO: trying to register non-static key.
    [   27.710851] The code is fine but needs lockdep annotation, or maybe
    [   27.712010] you didn't initialize this object before use?
    [   27.712396] turning off the locking correctness validator.
    [   27.712787] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4-g70e7f0549188-dirty #169
    [   27.713349] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [   27.714149] Call Trace:
    [   27.714329]  <IRQ>
    [   27.714480]  dump_stack+0xba/0xf5
    [   27.714737]  register_lock_class+0x873/0x8f0
    [   27.715052]  ? __lock_acquire+0x323/0x1930
    [   27.715353]  __lock_acquire+0x75/0x1930
    [   27.715636]  lock_acquire+0x1dd/0x3e0
    [   27.715905]  ? netup_i2c_interrupt+0x19/0x310
    [   27.716226]  _raw_spin_lock_irqsave+0x4b/0x60
    [   27.716544]  ? netup_i2c_interrupt+0x19/0x310
    [   27.716863]  netup_i2c_interrupt+0x19/0x310
    [   27.717178]  netup_unidvb_isr+0xd3/0x160
    [   27.717467]  __handle_irq_event_percpu+0x53/0x3e0
    [   27.717808]  handle_irq_event_percpu+0x35/0x90
    [   27.718129]  handle_irq_event+0x39/0x60
    [   27.718409]  handle_fasteoi_irq+0xc2/0x1d0
    [   27.718707]  __common_interrupt+0x7f/0x150
    [   27.719008]  common_interrupt+0xb4/0xd0
    [   27.719289]  </IRQ>
    [   27.719446]  asm_common_interrupt+0x1e/0x40
    [   27.719747] RIP: 0010:native_safe_halt+0x17/0x20
    [   27.720084] Code: 07 0f 00 2d 8b ee 4c 00 f4 5d c3 0f 1f 84 00 00 00 00 00 8b 05 72 95 17 02 55 48 89 e5 85 c0 7e 07 0f 00 2d 6b ee 4c 00 fb f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d 29 f6
    [   27.721386] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246
    [   27.721758] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
    [   27.722262] RDX: 0000000000000000 RSI: ffffffff85f7c054 RDI: ffffffff85ded4e6
    [   27.722770] RBP: ffffc9000008fe90 R08: 0000000000000001 R09: 0000000000000001
    [   27.723277] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86a75408
    [   27.723781] R13: 0000000000000000 R14: 0000000000000000 R15: ffff888100260000
    [   27.724289]  default_idle+0x9/0x10
    [   27.724537]  arch_cpu_idle+0xa/0x10
    [   27.724791]  default_idle_call+0x6e/0x250
    [   27.725082]  do_idle+0x1f0/0x2d0
    [   27.725326]  cpu_startup_entry+0x18/0x20
    [   27.725613]  start_secondary+0x11f/0x160
    [   27.725902]  secondary_startup_64_no_verify+0xb0/0xbb
    [   27.726272] BUG: kernel NULL pointer dereference, address: 0000000000000002
    [   27.726768] #PF: supervisor read access in kernel mode
    [   27.727138] #PF: error_code(0x0000) - not-present page
    [   27.727507] PGD 8000000118688067 P4D 8000000118688067 PUD 10feab067 PMD 0
    [   27.727999] Oops: 0000 [#1] PREEMPT SMP PTI
    [   27.728302] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4-g70e7f0549188-dirty #169
    [   27.728861] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [   27.729660] RIP: 0010:netup_i2c_interrupt+0x23/0x310
    [   27.730019] Code: 0f 1f 80 00 00 00 00 55 48 89 e5 41 55 41 54 53 48 89 fb e8 af 6e 95 fd 48 89 df e8 e7 9f 1c 01 49 89 c5 48 8b 83 48 08 00 00 <66> 44 8b 60 02 44 89 e0 48 8b 93 48 08 00 00 83 e0 f8 66 89 42 02
    [   27.731339] RSP: 0018:ffffc90000118e90 EFLAGS: 00010046
    [   27.731716] RAX: 0000000000000000 RBX: ffff88810803c4d8 RCX: 0000000000000000
    [   27.732223] RDX: 0000000000000001 RSI: ffffffff85d37b94 RDI: ffff88810803c4d8
    [   27.732727] RBP: ffffc90000118ea8 R08: 0000000000000000 R09: 0000000000000001
    [   27.733239] R10: ffff88810803c4f0 R11: 61646e6f63657320 R12: 0000000000000000
    [   27.733745] R13: 0000000000000046 R14: ffff888101041000 R15: ffff8881081b2400
    [   27.734251] FS:  0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000
    [   27.734821] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   27.735228] CR2: 0000000000000002 CR3: 0000000108194000 CR4: 00000000000006e0
    [   27.735735] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   27.736241] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   27.736744] Call Trace:
    [   27.736924]  <IRQ>
    [   27.737074]  netup_unidvb_isr+0xd3/0x160
    [   27.737363]  __handle_irq_event_percpu+0x53/0x3e0
    [   27.737706]  handle_irq_event_percpu+0x35/0x90
    [   27.738028]  handle_irq_event+0x39/0x60
    [   27.738306]  handle_fasteoi_irq+0xc2/0x1d0
    [   27.738602]  __common_interrupt+0x7f/0x150
    [   27.738899]  common_interrupt+0xb4/0xd0
    [   27.739176]  </IRQ>
    [   27.739331]  asm_common_interrupt+0x1e/0x40
    [   27.739633] RIP: 0010:native_safe_halt+0x17/0x20
    [   27.739967] Code: 07 0f 00 2d 8b ee 4c 00 f4 5d c3 0f 1f 84 00 00 00 00 00 8b 05 72 95 17 02 55 48 89 e5 85 c0 7e 07 0f 00 2d 6b ee 4c 00 fb f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d 29 f6
    [   27.741275] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246
    [   27.741647] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
    [   27.742148] RDX: 0000000000000000 RSI: ffffffff85f7c054 RDI: ffffffff85ded4e6
    [   27.742652] RBP: ffffc9000008fe90 R08: 0000000000000001 R09: 0000000000000001
    [   27.743154] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86a75408
    [   27.743652] R13: 0000000000000000 R14: 0000000000000000 R15: ffff888100260000
    [   27.744157]  default_idle+0x9/0x10
    [   27.744405]  arch_cpu_idle+0xa/0x10
    [   27.744658]  default_idle_call+0x6e/0x250
    [   27.744948]  do_idle+0x1f0/0x2d0
    [   27.745190]  cpu_startup_entry+0x18/0x20
    [   27.745475]  start_secondary+0x11f/0x160
    [   27.745761]  secondary_startup_64_no_verify+0xb0/0xbb
    [   27.746123] Modules linked in:
    [   27.746348] Dumping ftrace buffer:
    [   27.746596]    (ftrace buffer empty)
    [   27.746852] CR2: 0000000000000002
    [   27.747094] ---[ end trace ebafd46f83ab946d ]---
    [   27.747424] RIP: 0010:netup_i2c_interrupt+0x23/0x310
    [   27.747778] Code: 0f 1f 80 00 00 00 00 55 48 89 e5 41 55 41 54 53 48 89 fb e8 af 6e 95 fd 48 89 df e8 e7 9f 1c 01 49 89 c5 48 8b 83 48 08 00 00 <66> 44 8b 60 02 44 89 e0 48 8b 93 48 08 00 00 83 e0 f8 66 89 42 02
    [   27.749082] RSP: 0018:ffffc90000118e90 EFLAGS: 00010046
    [   27.749461] RAX: 0000000000000000 RBX: ffff88810803c4d8 RCX: 0000000000000000
    [   27.749966] RDX: 0000000000000001 RSI: ffffffff85d37b94 RDI: ffff88810803c4d8
    [   27.750471] RBP: ffffc90000118ea8 R08: 0000000000000000 R09: 0000000000000001
    [   27.750976] R10: ffff88810803c4f0 R11: 61646e6f63657320 R12: 0000000000000000
    [   27.751480] R13: 0000000000000046 R14: ffff888101041000 R15: ffff8881081b2400
    [   27.751986] FS:  0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000
    [   27.752560] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   27.752970] CR2: 0000000000000002 CR3: 0000000108194000 CR4: 00000000000006e0
    [   27.753481] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   27.753984] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   27.754487] Kernel panic - not syncing: Fatal exception in interrupt
    [   27.755033] Dumping ftrace buffer:
    [   27.755279]    (ftrace buffer empty)
    [   27.755534] Kernel Offset: disabled
    [   27.755785] Rebooting in 1 seconds..
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 944fc4717321cae50793dc0c5db464ed6387d855
Author: Dirk Bender <d.bender@phytec.de>
Date:   Mon Jul 26 09:35:15 2021 +0200

    media: mt9p031: Fix corrupted frame after restarting stream
    
    [ Upstream commit 0961ba6dd211a4a52d1dd4c2d59be60ac2dc08c7 ]
    
    To prevent corrupted frames after starting and stopping the sensor its
    datasheet specifies a specific pause sequence to follow:
    
    Stopping:
            Set Pause_Restart Bit -> Set Restart Bit -> Set Chip_Enable Off
    
    Restarting:
            Set Chip_Enable On -> Clear Pause_Restart Bit
    
    The Restart Bit is cleared automatically and must not be cleared
    manually as this would cause undefined behavior.
    
    Signed-off-by: Dirk Bender <d.bender@phytec.de>
    Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a0e5b13f90762a6d1c368db1280cdb9b038a19a
Author: Rakesh Babu <rsaladi2@marvell.com>
Date:   Tue Sep 28 23:13:45 2021 +0530

    octeontx2-pf: Enable promisc/allmulti match MCAM entries.
    
    [ Upstream commit ffd2f89ad05cd620d822112a07b0c5669fa9e333 ]
    
    Whenever the interface is brought up/down then set_rx_mode
    function is called by the stack which enables promisc/allmulti
    MCAM entries. But there are cases when driver brings
    interface down and then up such as while changing number
    of channels. In these cases promisc/allmulti MCAM entries
    are left disabled as set_rx_mode callback is not called.
    This patch enables these MCAM entries in all such cases.
    
    Signed-off-by: Rakesh Babu <rsaladi2@marvell.com>
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26fcf9347ab4f58830fcc76c8bfd9b48ee511456
Author: Alagu Sankar <alagusankar@silex-india.com>
Date:   Tue Sep 28 14:00:47 2021 +0300

    ath10k: high latency fixes for beacon buffer
    
    [ Upstream commit e263bdab9c0e8025fb7f41f153709a9cda51f6b6 ]
    
    Beacon buffer for high latency devices does not use DMA. other similar
    buffer allocation methods in the driver have already been modified for
    high latency path. Fix the beacon buffer allocation left out in the
    earlier high latency changes.
    
    Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
    Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
    [fabio: adapt it to use ar->bus_param.dev_type ]
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210818232627.2040121-1-festevam@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20e8a4f26534bcf078ac73bfc61aa1f095fdbf1d
Author: Baochen Qiang <bqiang@codeaurora.org>
Date:   Tue Sep 28 14:00:46 2021 +0300

    ath11k: Change DMA_FROM_DEVICE to DMA_TO_DEVICE when map reinjected packets
    
    [ Upstream commit 86a03dad0f5ad8182ed5fcf7bf3eec71cd96577c ]
    
    For fragmented packets, ath11k reassembles each fragment as a normal
    packet and then reinjects it into HW ring. In this case, the DMA
    direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE, otherwise
    invalid payload will be reinjected to HW and then delivered to host.
    What is more, since arbitrary memory could be allocated to the frame, we
    don't know what kind of data is contained in the buffer reinjected.
    Thus, as a bad result, private info may be leaked.
    
    Note that this issue is only found on Intel platform.
    
    Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
    Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210916064617.20006-1-bqiang@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 163189aa6e44aa621dd3f83f6cd6eac77fd25597
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue Sep 28 14:00:45 2021 +0300

    ath11k: add handler for scan event WMI_SCAN_EVENT_DEQUEUED
    
    [ Upstream commit 441b3b5911f8ead7f2fe2336587b340a33044d58 ]
    
    When wlan interface is up, 11d scan is sent to the firmware, and the
    firmware needs to spend couple of seconds to complete the 11d scan. If
    immediately a normal scan from user space arrives to ath11k, then the
    normal scan request is also sent to the firmware, but the scan started
    event will be reported to ath11k until the 11d scan complete. When timed
    out for the scan started in ath11k, ath11k stops the normal scan and the
    firmware reports WMI_SCAN_EVENT_DEQUEUED to ath11k for the normal scan.
    ath11k has no handler for the event and then timed out for the scan
    completed in ath11k_scan_stop(), and ath11k prints the following error
    message.
    
    [ 1491.604750] ath11k_pci 0000:02:00.0: failed to receive scan abort comple: timed out
    [ 1491.604756] ath11k_pci 0000:02:00.0: failed to stop scan: -110
    [ 1491.604758] ath11k_pci 0000:02:00.0: failed to start hw scan: -110
    
    Add a handler for WMI_SCAN_EVENT_DEQUEUED and then complete the scan to
    get rid of the above error message.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
    
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210914164226.38843-1-jouni@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ea518dfa39be1f0948def24e94e1ad4f3f0cc98
Author: Sriram R <srirrama@codeaurora.org>
Date:   Tue Sep 28 12:05:40 2021 +0300

    ath11k: Avoid reg rules update during firmware recovery
    
    [ Upstream commit 69a0fcf8a9f2273040d03e5ee77c9689c09e9d3a ]
    
    During firmware recovery, the default reg rules which are
    received via WMI_REG_CHAN_LIST_CC_EVENT can overwrite
    the currently configured user regd.
    
    See below snap for example,
    
    root@OpenWrt:/# iw reg get | grep country
    country FR: DFS-ETSI
    country FR: DFS-ETSI
    country FR: DFS-ETSI
    country FR: DFS-ETSI
    
    root@OpenWrt:/# echo assert > /sys/kernel/debug/ath11k/ipq8074\ hw2.0/simulate_f
    w_crash
    <snip>
    [ 5290.471696] ath11k c000000.wifi1: pdev 1 successfully recovered
    
    root@OpenWrt:/# iw reg get | grep country
    country FR: DFS-ETSI
    country US: DFS-FCC
    country US: DFS-FCC
    country US: DFS-FCC
    
    In the above, the user configured country 'FR' is overwritten
    when the rules of default country 'US' are received and updated during
    recovery. Hence avoid processing of these rules in general
    during firmware recovery as they have been already applied during
    driver registration or after last set user country is configured.
    
    This scenario applies for both AP and STA devices basically because
    cfg80211 is not aware of the recovery and only the driver recovers, but
    changing or resetting of the reg domain during recovery is not needed so
    as to continue with the configured regdomain currently in use.
    
    Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01460-QCAHKSWPL_SILICONZ-1
    
    Signed-off-by: Sriram R <srirrama@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210721212029.142388-3-jouni@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72d43bc26938c410f18ba5601aedee2055418058
Author: Petr Machata <petrm@nvidia.com>
Date:   Fri Sep 24 12:04:27 2021 +0200

    selftests: net: fib_nexthops: Wait before checking reported idle time
    
    [ Upstream commit b69c99463d414cc263411462d52f25205657e9af ]
    
    The purpose of this test is to verify that after a short activity passes,
    the reported time is reasonable: not zero (which could be reported by
    mistake), and not something outrageous (which would be indicative of an
    issue in used units).
    
    However, the idle time is reported in units of clock_t, or hundredths of
    second. If the initial sequence of commands is very quick, it is possible
    that the idle time is reported as just flat-out zero. When this test was
    recently enabled in our nightly regression, we started seeing spurious
    failures for exactly this reason.
    
    Therefore buffer the delay leading up to the test with a sleep, to make
    sure there is no legitimate way of reporting 0.
    
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 678e8cd1bf22e1553ebf843e6ddab74083c6e936
Author: Jimmy Kizito <Jimmy.Kizito@amd.com>
Date:   Sun Sep 12 11:21:52 2021 -0400

    drm/amd/display: Fix null pointer dereference for encoders
    
    [ Upstream commit 60f39edd897ea134a4ddb789a6795681691c3183 ]
    
    [Why]
    Links which are dynamically assigned link encoders have their link
    encoder set to NULL.
    
    [How]
    Check that a pointer to a link_encoder object is non-NULL before using
    it.
    
    Reviewed-by: Aric Cyr <aric.cyr@amd.com>
    Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
    Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 351601af203da6404d2c0d87e0c10406bdc151bd
Author: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Date:   Thu Sep 16 12:54:07 2021 -0400

    drm/amdgpu: Fix MMIO access page fault
    
    [ Upstream commit c03509cbc01559549700e14c4a6239f2572ab4ba ]
    
    Add more guards to MMIO access post device
    unbind/unplug
    
    Bug: https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1
    Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Reviewed-by: James Zhu <James.Zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9630d4d0d14dd6d3125d8385a2ad5ae7baf2a954
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 20 20:03:03 2021 -0700

    fscrypt: allow 256-bit master keys with AES-256-XTS
    
    [ Upstream commit 7f595d6a6cdc336834552069a2e0a4f6d4756ddf ]
    
    fscrypt currently requires a 512-bit master key when AES-256-XTS is
    used, since AES-256-XTS keys are 512-bit and fscrypt requires that the
    master key be at least as long any key that will be derived from it.
    
    However, this is overly strict because AES-256-XTS doesn't actually have
    a 512-bit security strength, but rather 256-bit.  The fact that XTS
    takes twice the expected key size is a quirk of the XTS mode.  It is
    sufficient to use 256 bits of entropy for AES-256-XTS, provided that it
    is first properly expanded into a 512-bit key, which HKDF-SHA512 does.
    
    Therefore, relax the check of the master key size to use the security
    strength of the derived key rather than the size of the derived key
    (except for v1 encryption policies, which don't use HKDF).
    
    Besides making things more flexible for userspace, this is needed in
    order for the use of a KDF which only takes a 256-bit key to be
    introduced into the fscrypt key hierarchy.  This will happen with
    hardware-wrapped keys support, as all known hardware which supports that
    feature uses an SP800-108 KDF using AES-256-CMAC, so the wrapped keys
    are wrapped 256-bit AES keys.  Moreover, there is interest in fscrypt
    supporting the same type of AES-256-CMAC based KDF in software as an
    alternative to HKDF-SHA512.  There is no security problem with such
    features, so fix the key length check to work properly with them.
    
    Reviewed-by: Paul Crowley <paulcrowley@google.com>
    Link: https://lore.kernel.org/r/20210921030303.5598-1-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6509627e06fff90409801cf71745ceec56d82b8
Author: Mark Brown <broonie@kernel.org>
Date:   Tue Sep 21 20:21:49 2021 +0100

    spi: Check we have a spi_device_id for each DT compatible
    
    [ Upstream commit 5fa6863ba69265cb7e45567d12614790ff26bd56 ]
    
    Currently for SPI devices we use the spi_device_id for module autoloading
    even on systems using device tree, meaning that listing a compatible string
    in the of_match_table isn't enough to have the module for a SPI driver
    autoloaded.
    
    We attempted to fix this by generating OF based modaliases for devices
    instantiated from DT in 3ce6c9e2617e ("spi: add of_device_uevent_modalias
    support") but this meant we no longer reported spi_device_id based aliases
    which broke drivers such as spi-nor which don't list all the compatible
    strings they support directly for DT, and in at least that case it's not
    super practical to do so given the very large number of compatibles
    needed, much larger than the number spi_device_ids due to vendor strings.
    As a result fell back to using spi_device_id based modalises.
    
    Try to close the gap by printing a warning when a SPI driver has a DT
    compatible that won't be matched as a SPI device ID with the goal of having
    drivers provide both. Given fallback compatibles this check is going to be
    excessive but it should be robust which is probably more important here.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210921192149.50740-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33d2d8a12f8d2d66c353fcf144a2e402a0e0d60e
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Tue Sep 14 21:59:08 2021 +0200

    mwifiex: Properly initialize private structure on interface type changes
    
    [ Upstream commit c606008b70627a2fc485732a53cc22f0f66d0981 ]
    
    When creating a new virtual interface in mwifiex_add_virtual_intf(), we
    update our internal driver states like bss_type, bss_priority, bss_role
    and bss_mode to reflect the mode the firmware will be set to.
    
    When switching virtual interface mode using
    mwifiex_init_new_priv_params() though, we currently only update bss_mode
    and bss_role. In order for the interface mode switch to actually work,
    we also need to update bss_type to its proper value, so do that.
    
    This fixes a crash of the firmware (because the driver tries to execute
    commands that are invalid in AP mode) when switching from station mode
    to AP mode.
    
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210914195909.36035-9-verdre@v0yd.nl
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcf47459ee7bf2a13977c64d92c7c41cf6939022
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Tue Sep 14 21:59:03 2021 +0200

    mwifiex: Run SET_BSS_MODE when changing from P2P to STATION vif-type
    
    [ Upstream commit c2e9666cdffd347460a2b17988db4cfaf2a68fb9 ]
    
    We currently handle changing from the P2P to the STATION virtual
    interface type slightly different than changing from P2P to ADHOC: When
    changing to STATION, we don't send the SET_BSS_MODE command. We do send
    that command on all other type-changes though, and it probably makes
    sense to send the command since after all we just changed our BSS_MODE.
    Looking at prior changes to this part of the code, it seems that this is
    simply a leftover from old refactorings.
    
    Since sending the SET_BSS_MODE command is the only difference between
    mwifiex_change_vif_to_sta_adhoc() and the current code, we can now use
    mwifiex_change_vif_to_sta_adhoc() for both switching to ADHOC and
    STATION interface type.
    
    This does not fix any particular bug and just "looked right", so there's
    a small chance it might be a regression.
    
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210914195909.36035-4-verdre@v0yd.nl
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7251782df85f8cc19ac5b14ad52f185eca201d7b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Sep 15 16:19:46 2021 +0200

    x86: Increase exception stack sizes
    
    [ Upstream commit 7fae4c24a2b84a66c7be399727aca11e7a888462 ]
    
    It turns out that a single page of stack is trivial to overflow with
    all the tracing gunk enabled. Raise the exception stacks to 2 pages,
    which is still half the interrupt stacks, which are at 4 pages.
    
    Reported-by: Michael Wang <yun.wang@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/YUIO9Ye98S5Eb68w@hirez.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5a43cde6601871fdf607486882902a886624d18
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Sep 15 17:12:59 2021 +0200

    x86/mm/64: Improve stack overflow warnings
    
    [ Upstream commit 44b979fa302cab91bdd2cc982823e5c13202cd4e ]
    
    Current code has an explicit check for hitting the task stack guard;
    but overflowing any of the other stacks will get you a non-descript
    general #DF warning.
    
    Improve matters by using get_stack_info_noinstr() to detetrmine if and
    which stack guard page got hit, enabling a better stack warning.
    
    In specific, Michael Wang reported what turned out to be an NMI
    exception stack overflow, which is now clearly reported as such:
    
      [] BUG: NMI stack guard page was hit at 0000000085fd977b (stack is 000000003a55b09e..00000000d8cce1a5)
    
    Reported-by: Michael Wang <yun.wang@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Michael Wang <yun.wang@linux.alibaba.com>
    Link: https://lkml.kernel.org/r/YUTE/NuqnaWbST8n@hirez.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 347f35130e4ee53123d2542b940ae1c857524cb1
Author: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
Date:   Sat Sep 11 16:37:59 2021 +0530

    crypto: aesni - check walk.nbytes instead of err
    
    [ Upstream commit a2d3cbc80d2527b435154ff0f89b56ef4b84370f ]
    
    In the code for xts_crypt(), we check for the err value returned by
    skcipher_walk_virt() and return from the function if it is non zero.
    However, skcipher_walk_virt() can set walk.nbytes to 0, which would cause
    us to call kernel_fpu_begin(), and then skip the kernel_fpu_end() call.
    
    This patch checks for the walk.nbytes value instead, and returns if
    walk.nbytes is 0. This prevents us from calling kernel_fpu_begin() in
    the first place and also covers the case of having a non zero err value
    returned from skcipher_walk_virt().
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53aad1ad0e69f10e807622b019e312edaf644108
Author: Seevalamuthu Mariappan <seevalam@codeaurora.org>
Date:   Wed Jul 21 00:49:22 2021 +0300

    ath11k: Align bss_chan_info structure with firmware
    
    [ Upstream commit feab5bb8f1d4621025dceae7eef62d5f92de34ac ]
    
    pdev_id in structure 'wmi_pdev_bss_chan_info_event' is wrongly placed
    at the beginning. This causes invalid values in survey dump. Hence, align
    the structure with the firmware.
    
    Note: The firmware releases follow this order since the feature was
    implemented. Also, it is not changing across the branches including
    QCA6390.
    
    Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01228-QCAHKSWPL_SILICONZ-1
    
    Signed-off-by: Ritesh Singh <ritesi@codeaurora.org>
    Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210720214922.118078-3-jouni@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e246ca955cad65982b12348887e6b4ba2c84131
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Sat Aug 28 23:41:40 2021 -0700

    smackfs: Fix use-after-free in netlbl_catmap_walk()
    
    [ Upstream commit 0817534ff9ea809fac1322c5c8c574be8483ea57 ]
    
    Syzkaller reported use-after-free bug as described in [1]. The bug is
    triggered when smk_set_cipso() tries to free stale category bitmaps
    while there are concurrent reader(s) using the same bitmaps.
    
    Wait for RCU grace period to finish before freeing the category bitmaps
    in smk_set_cipso(). This makes sure that there are no more readers using
    the stale bitmaps and freeing them should be safe.
    
    [1] https://lore.kernel.org/netdev/000000000000a814c505ca657a4e@google.com/
    
    Reported-by: syzbot+3f91de0b813cc3d19a80@syzkaller.appspotmail.com
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f85b0fe504acab831b3affa05a6ceae0ff81ff79
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Wed Aug 11 09:07:44 2021 -0700

    rcu-tasks: Move RTGS_WAIT_CBS to beginning of rcu_tasks_kthread() loop
    
    [ Upstream commit 0db7c32ad3160ae06f497d48a74bd46a2a35e6bf ]
    
    Early in debugging, it made some sense to differentiate the first
    iteration from subsequent iterations, but now this just causes confusion.
    This commit therefore moves the "set_tasks_gp_state(rtp, RTGS_WAIT_CBS)"
    statement to the beginning of the "for" loop in rcu_tasks_kthread().
    
    Reported-by: Neeraj Upadhyay <neeraju@codeaurora.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e36b7768aad63cc19bab338c7fd6e06fbfc9ad49
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Sep 15 21:09:05 2021 +0800

    ACPI: resources: Add DMI-based legacy IRQ override quirk
    
    [ Upstream commit 892a012699fc0b91a2ed6309078936191447f480 ]
    
    After the commit 0ec4e55e9f57 ("ACPI: resources: Add checks for ACPI
    IRQ override") is reverted, the keyboard on Medion laptops can't
    work again.
    
    To fix the keyboard issue, add a DMI-based override check that will
    not affect other machines along the lines of prt_quirks[] in
    drivers/acpi/pci_irq.c.
    
    If similar issues are seen on other platforms, the quirk table could
    be expanded in the future.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213031
    BugLink: http://bugs.launchpad.net/bugs/1909814
    Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reported-by: Manuel Krause <manuelkrause@netscape.net>
    Tested-by: Manuel Krause <manuelkrause@netscape.net>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae11b215aef8f4cd8143a6a0712e9849e1cc3a9c
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Sep 13 15:53:30 2021 -0700

    net: sched: update default qdisc visibility after Tx queue cnt changes
    
    [ Upstream commit 1e080f17750d1083e8a32f7b350584ae1cd7ff20 ]
    
    mq / mqprio make the default child qdiscs visible. They only do
    so for the qdiscs which are within real_num_tx_queues when the
    device is registered. Depending on order of calls in the driver,
    or if user space changes config via ethtool -L the number of
    qdiscs visible under tc qdisc show will differ from the number
    of queues. This is confusing to users and potentially to system
    configuration scripts which try to make sure qdiscs have the
    right parameters.
    
    Add a new Qdisc_ops callback and make relevant qdiscs TTRT.
    
    Note that this uncovers the "shortcut" created by
    commit 1f27cde313d7 ("net: sched: use pfifo_fast for non real queues")
    The default child qdiscs beyond initial real_num_tx are always
    pfifo_fast, no matter what the sysfs setting is. Fixing this
    gets a little tricky because we'd need to keep a reference
    on whatever the default qdisc was at the time of creation.
    In practice this is likely an non-issue the qdiscs likely have
    to be configured to non-default settings, so whatever user space
    is doing such configuration can replace the pfifos... now that
    it will see them.
    
    Reported-by: Matthew Massey <matthewmassey@fb.com>
    Reviewed-by: Dave Taht <dave.taht@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d120d005b96fd77153806d71d0d23cd37a2ad23c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 24 11:41:10 2021 +0200

    locking/lockdep: Avoid RCU-induced noinstr fail
    
    [ Upstream commit ce0b9c805dd66d5e49fd53ec5415ae398f4c56e6 ]
    
    vmlinux.o: warning: objtool: look_up_lock_class()+0xc7: call to rcu_read_lock_any_held() leaves .noinstr.text section
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20210624095148.311980536@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a244da29841869c0eb9670152fb58e50a32a1894
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Tue Sep 14 23:20:59 2021 +0200

    MIPS: lantiq: dma: reset correct number of channel
    
    [ Upstream commit 5ca9ce2ba4d5884cd94d1a856c675ab1242cd242 ]
    
    Different SoCs have a different number of channels, e.g .:
    * amazon-se has 10 channels,
    * danube+ar9 have 20 channels,
    * vr9 has 28 channels,
    * ar10 has 24 channels.
    
    We can read the ID register and, depending on the reported
    number of channels, reset the appropriate number of channels.
    
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a5b3f5dfb02e2ce9f0c98e74b18b7d1ad9cf13d
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Tue Sep 14 23:20:58 2021 +0200

    MIPS: lantiq: dma: add small delay after reset
    
    [ Upstream commit c12aa581f6d5e80c3c3675ab26a52c2b3b62f76e ]
    
    Reading the DMA registers immediately after the reset causes
    Data Bus Error. Adding a small delay fixes this issue.
    
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55bf61828ab33b959ecc41b66c6a3725fb921ec1
Author: James Zhu <James.Zhu@amd.com>
Date:   Tue Sep 7 11:32:22 2021 -0400

    drm/amdgpu: move iommu_resume before ip init/resume
    
    [ Upstream commit 9cec53c18a3170c7e5673c414da56aeecee94832 ]
    
    Separate iommu_resume from kfd_resume, and move it before
    other amdgpu ip init/resume.
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211277
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36bd10013bdfbc34c35b6eac998323168d97f474
Author: Barnabás Pőcze <pobrn@protonmail.com>
Date:   Sat Sep 4 17:56:26 2021 +0000

    platform/x86: wmi: do not fail if disabling fails
    
    [ Upstream commit 1975718c488a39128f1f515b23ae61a5a214cc3d ]
    
    Previously, `__query_block()` would fail if the
    second WCxx method call failed. However, the
    WQxx method might have succeeded, and potentially
    allocated memory for the result. Instead of
    throwing away the result and potentially
    leaking memory, ignore the result of
    the second WCxx call.
    
    Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
    Link: https://lore.kernel.org/r/20210904175450.156801-25-pobrn@protonmail.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 9508ee70d138a11895f6308b1db69ed06fb4ebc4
Author: Scott Wood <swood@redhat.com>
Date:   Fri Aug 20 09:42:36 2021 +0200

    rcutorture: Avoid problematic critical section nesting on PREEMPT_RT
    
    [ Upstream commit 71921a9606ddbcc1d98c00eca7ae82c373d1fecd ]
    
    rcutorture is generating some nesting scenarios that are not compatible on PREEMPT_RT.
    For example:
            preempt_disable();
            rcu_read_lock_bh();
            preempt_enable();
            rcu_read_unlock_bh();
    
    The problem here is that on PREEMPT_RT the bottom halves have to be
    disabled and enabled in preemptible context.
    
    Reorder locking: start with BH locking and continue with then with
    disabling preemption or interrupts. In the unlocking do it reverse by
    first enabling interrupts and preemption and BH at the very end.
    Ensure that on PREEMPT_RT BH locking remains unchanged if in
    non-preemptible context.
    
    Link: https://lkml.kernel.org/r/20190911165729.11178-6-swood@redhat.com
    Link: https://lkml.kernel.org/r/20210819182035.GF4126399@paulmck-ThinkPad-P17-Gen-1
    Signed-off-by: Scott Wood <swood@redhat.com>
    [bigeasy: Drop ATOM_BH, make it only about changing BH in atomic
    context. Allow enabling RCU in IRQ-off section. Reword commit message.]
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3135fa42b0ffc3115715a4ec55da0b93eceb541
Author: Simon Ser <contact@emersion.fr>
Date:   Sat Sep 11 10:24:40 2021 +0000

    drm/panel-orientation-quirks: add Valve Steam Deck
    
    [ Upstream commit 9eeb7b4e40bfd69d8aaa920c7e9df751c9e11dce ]
    
    Valve's Steam Deck has a 800x1280 LCD screen.
    
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Cc: Jared Baldridge <jrb@expunge.us>
    Cc: Emil Velikov <emil.l.velikov@gmail.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210911102430.253986-1-contact@emersion.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a05a18cfbf9f24fa1b23014eba3c544d6a8c8dec
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date:   Thu Sep 2 23:13:05 2021 -0400

    Bluetooth: call sock_hold earlier in sco_conn_del
    
    [ Upstream commit f4712fa993f688d0a48e0c28728fcdeb88c1ea58 ]
    
    In sco_conn_del, conn->sk is read while holding on to the
    sco_conn.lock to avoid races with a socket that could be released
    concurrently.
    
    However, in between unlocking sco_conn.lock and calling sock_hold,
    it's possible for the socket to be freed, which would cause a
    use-after-free write when sock_hold is finally called.
    
    To fix this, the reference count of the socket should be increased
    while the sco_conn.lock is still held.
    
    Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e22e4db95b04f09adcce18c75d27cbca8f53b99
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Tue Aug 31 17:35:37 2021 -0700

    Bluetooth: fix use-after-free error in lock_sock_nested()
    
    [ Upstream commit 1bff51ea59a9afb67d2dd78518ab0582a54a472c ]
    
    use-after-free error in lock_sock_nested is reported:
    
    [  179.140137][ T3731] =====================================================
    [  179.142675][ T3731] BUG: KMSAN: use-after-free in lock_sock_nested+0x280/0x2c0
    [  179.145494][ T3731] CPU: 4 PID: 3731 Comm: kworker/4:2 Not tainted 5.12.0-rc6+ #54
    [  179.148432][ T3731] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    [  179.151806][ T3731] Workqueue: events l2cap_chan_timeout
    [  179.152730][ T3731] Call Trace:
    [  179.153301][ T3731]  dump_stack+0x24c/0x2e0
    [  179.154063][ T3731]  kmsan_report+0xfb/0x1e0
    [  179.154855][ T3731]  __msan_warning+0x5c/0xa0
    [  179.155579][ T3731]  lock_sock_nested+0x280/0x2c0
    [  179.156436][ T3731]  ? kmsan_get_metadata+0x116/0x180
    [  179.157257][ T3731]  l2cap_sock_teardown_cb+0xb8/0x890
    [  179.158154][ T3731]  ? __msan_metadata_ptr_for_load_8+0x10/0x20
    [  179.159141][ T3731]  ? kmsan_get_metadata+0x116/0x180
    [  179.159994][ T3731]  ? kmsan_get_shadow_origin_ptr+0x84/0xb0
    [  179.160959][ T3731]  ? l2cap_sock_recv_cb+0x420/0x420
    [  179.161834][ T3731]  l2cap_chan_del+0x3e1/0x1d50
    [  179.162608][ T3731]  ? kmsan_get_metadata+0x116/0x180
    [  179.163435][ T3731]  ? kmsan_get_shadow_origin_ptr+0x84/0xb0
    [  179.164406][ T3731]  l2cap_chan_close+0xeea/0x1050
    [  179.165189][ T3731]  ? kmsan_internal_unpoison_shadow+0x42/0x70
    [  179.166180][ T3731]  l2cap_chan_timeout+0x1da/0x590
    [  179.167066][ T3731]  ? __msan_metadata_ptr_for_load_8+0x10/0x20
    [  179.168023][ T3731]  ? l2cap_chan_create+0x560/0x560
    [  179.168818][ T3731]  process_one_work+0x121d/0x1ff0
    [  179.169598][ T3731]  worker_thread+0x121b/0x2370
    [  179.170346][ T3731]  kthread+0x4ef/0x610
    [  179.171010][ T3731]  ? process_one_work+0x1ff0/0x1ff0
    [  179.171828][ T3731]  ? kthread_blkcg+0x110/0x110
    [  179.172587][ T3731]  ret_from_fork+0x1f/0x30
    [  179.173348][ T3731]
    [  179.173752][ T3731] Uninit was created at:
    [  179.174409][ T3731]  kmsan_internal_poison_shadow+0x5c/0xf0
    [  179.175373][ T3731]  kmsan_slab_free+0x76/0xc0
    [  179.176060][ T3731]  kfree+0x3a5/0x1180
    [  179.176664][ T3731]  __sk_destruct+0x8af/0xb80
    [  179.177375][ T3731]  __sk_free+0x812/0x8c0
    [  179.178032][ T3731]  sk_free+0x97/0x130
    [  179.178686][ T3731]  l2cap_sock_release+0x3d5/0x4d0
    [  179.179457][ T3731]  sock_close+0x150/0x450
    [  179.180117][ T3731]  __fput+0x6bd/0xf00
    [  179.180787][ T3731]  ____fput+0x37/0x40
    [  179.181481][ T3731]  task_work_run+0x140/0x280
    [  179.182219][ T3731]  do_exit+0xe51/0x3e60
    [  179.182930][ T3731]  do_group_exit+0x20e/0x450
    [  179.183656][ T3731]  get_signal+0x2dfb/0x38f0
    [  179.184344][ T3731]  arch_do_signal_or_restart+0xaa/0xe10
    [  179.185266][ T3731]  exit_to_user_mode_prepare+0x2d2/0x560
    [  179.186136][ T3731]  syscall_exit_to_user_mode+0x35/0x60
    [  179.186984][ T3731]  do_syscall_64+0xc5/0x140
    [  179.187681][ T3731]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [  179.188604][ T3731] =====================================================
    
    In our case, there are two Thread A and B:
    
    Context: Thread A:              Context: Thread B:
    
    l2cap_chan_timeout()            __se_sys_shutdown()
      l2cap_chan_close()              l2cap_sock_shutdown()
        l2cap_chan_del()                l2cap_chan_close()
          l2cap_sock_teardown_cb()        l2cap_sock_teardown_cb()
    
    Once l2cap_sock_teardown_cb() excuted, this sock will be marked as SOCK_ZAPPED,
    and can be treated as killable in l2cap_sock_kill() if sock_orphan() has
    excuted, at this time we close sock through sock_close() which end to call
    l2cap_sock_kill() like Thread C:
    
    Context: Thread C:
    
    sock_close()
      l2cap_sock_release()
        sock_orphan()
        l2cap_sock_kill()  #free sock if refcnt is 1
    
    If C completed, Once A or B reaches l2cap_sock_teardown_cb() again,
    use-after-free happened.
    
    We should set chan->data to NULL if sock is destructed, for telling teardown
    operation is not allowed in l2cap_sock_teardown_cb(), and also we should
    avoid killing an already killed socket in l2cap_sock_close_cb().
    
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    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 b990c219c4c9d4993ef65ea9db73d9497e70f697
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Aug 28 18:18:18 2021 +0200

    Bluetooth: sco: Fix lock_sock() blockage by memcpy_from_msg()
    
    [ Upstream commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 ]
    
    The sco_send_frame() also takes lock_sock() during memcpy_from_msg()
    call that may be endlessly blocked by a task with userfaultd
    technique, and this will result in a hung task watchdog trigger.
    
    Just like the similar fix for hci_sock_sendmsg() in commit
    92c685dc5de0 ("Bluetooth: reorganize functions..."), this patch moves
    the  memcpy_from_msg() out of lock_sock() for addressing the hang.
    
    This should be the last piece for fixing CVE-2021-3640 after a few
    already queued fixes.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8815bbe712f3eeecf8e6bdf0ac21ac6a3f1727fb
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun May 30 13:04:27 2021 +0200

    drm: panel-orientation-quirks: Add quirk for the Samsung Galaxy Book 10.6
    
    [ Upstream commit 88fa1fde918951c175ae5ea0f31efc4bb1736ab9 ]
    
    The Samsung Galaxy Book 10.6 uses a panel which has been mounted
    90 degrees rotated. Add a quirk for this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-4-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fe898b1ec8d10a9c4e6634f732f6edc3e37e285
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun May 30 13:04:26 2021 +0200

    drm: panel-orientation-quirks: Add quirk for KD Kurio Smart C15200 2-in-1
    
    [ Upstream commit a53f1dd3ab9fec715c6c2e8e01bf4d3c07eef8e5 ]
    
    The KD Kurio Smart C15200 2-in-1 uses  a panel which has been mounted 90
    degrees rotated. Add a quirk for this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-3-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9795f6bf0eb1dff79ef220fafe30a6a1228307b
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun May 30 13:04:25 2021 +0200

    drm: panel-orientation-quirks: Update the Lenovo Ideapad D330 quirk (v2)
    
    [ Upstream commit 820a2ab23d5eab4ccfb82581eda8ad4acf18458f ]
    
    2 improvements to the Lenovo Ideapad D330 panel-orientation quirks:
    
    1. Some versions of the Lenovo Ideapad D330 have a DMI_PRODUCT_NAME of
    "81H3" and others have "81MD". Testing has shown that the "81MD" also has
    a 90 degree mounted panel. Drop the DMI_PRODUCT_NAME from the existing
    quirk so that the existing quirk matches both variants.
    
    2. Some of the Lenovo Ideapad D330 models have a HD (800x1280) screen
    instead of a FHD (1200x1920) screen (both are mounted right-side-up) add
    a second Lenovo Ideapad D330 quirk for the HD version.
    
    Changes in v2:
    - Add a new quirk for Lenovo Ideapad D330 models with a HD screen instead
      of a FHD screen
    
    Link: https://github.com/systemd/systemd/pull/18884
    Acked-by: Simon Ser <contact@emersion.fr>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ff10b430ca0a02092b30f2d11ef8cfb11499913
Author: Charan Teja Reddy <charante@codeaurora.org>
Date:   Fri Jul 23 18:01:08 2021 +0530

    dma-buf: WARN on dmabuf release with pending attachments
    
    [ Upstream commit f492283b157053e9555787262f058ae33096f568 ]
    
    It is expected from the clients to follow the below steps on an imported
    dmabuf fd:
    a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd
    b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf
       o Here the kernel does some slab allocations, say for
    dma_buf_attachment and may be some other slab allocation in the
    dmabuf->ops->attach().
    c) Client may need to do dma_buf_map_attachment().
    d) Accordingly dma_buf_unmap_attachment() should be called.
    e) dma_buf_detach () // Clients detach to the dmabuf.
       o Here the slab allocations made in b) are freed.
    f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last
    reference.
    
    Now say an erroneous client failed at step c) above thus it directly
    called dma_buf_put(), step f) above. Considering that it may be the last
    reference to the dmabuf, buffer will be freed with pending attachments
    left to the dmabuf which can show up as the 'memory leak'. This should
    at least be reported as the WARN().
    
    Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-email-charante@codeaurora.org
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 061a8677ab37446125c51f6ba3d2f6450789d2f3
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Wed Oct 13 19:13:45 2021 +0300

    component: do not leave master devres group open after bind
    
    commit c87761db2100677a69be551365105125d872af5b upstream.
    
    In current code, the devres group for aggregate master is left open
    after call to component_master_add_*(). This leads to problems when the
    master does further managed allocations on its own. When any
    participating driver calls component_del(), this leads to immediate
    release of resources.
    
    This came up when investigating a page fault occurring with i915 DRM
    driver unbind with 5.15-rc1 kernel. The following sequence occurs:
    
     i915_pci_remove()
       -> intel_display_driver_unregister()
         -> i915_audio_component_cleanup()
           -> component_del()
             -> component.c:take_down_master()
               -> hdac_component_master_unbind() [via master->ops->unbind()]
               -> devres_release_group(master->parent, NULL)
    
    With older kernels this has not caused issues, but with audio driver
    moving to use managed interfaces for more of its allocations, this no
    longer works. Devres log shows following to occur:
    
    component_master_add_with_match()
    [  126.886032] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000323ccdc5 devm_component_match_release (24 bytes)
    [  126.886045] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000865cdb29 grp< (0 bytes)
    [  126.886049] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 grp< (0 bytes)
    
    audio driver completes its PCI probe()
    [  126.892238] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 pcim_iomap_release (48 bytes)
    
    component_del() called() at DRM/i915 unbind()
    [  137.579422] i915 0000:00:02.0: DEVRES REL 00000000ef44c293 grp< (0 bytes)
    [  137.579445] snd_hda_intel 0000:00:1f.3: DEVRES REL 00000000865cdb29 grp< (0 bytes)
    [  137.579458] snd_hda_intel 0000:00:1f.3: DEVRES REL 000000001b480725 pcim_iomap_release (48 bytes)
    
    So the "devres_release_group(master->parent, NULL)" ends up freeing the
    pcim_iomap allocation. Upon next runtime resume, the audio driver will
    cause a page fault as the iomap alloc was released without the driver
    knowing about it.
    
    Fix this issue by using the "struct master" pointer as identifier for
    the devres group, and by closing the devres group after
    the master->ops->bind() call is done. This allows devres allocations
    done by the driver acting as master to be isolated from the binding state
    of the aggregate driver. This modifies the logic originally introduced in
    commit 9e1ccb4a7700 ("drivers/base: fix devres handling for master device")
    
    Fixes: 9e1ccb4a7700 ("drivers/base: fix devres handling for master device")
    Cc: stable@vger.kernel.org
    Acked-by: Imre Deak <imre.deak@intel.com>
    Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/4136
    Link: https://lore.kernel.org/r/20211013161345.3755341-1-kai.vehmanen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c264dfbb6a453a6c837d404a5997329598786ca
Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Date:   Tue Sep 14 14:18:05 2021 +0200

    power: supply: max17042_battery: Clear status bits in interrupt handler
    
    commit 0cf48167b87e388fa1268c9fe6d2443ae7f43d8a upstream.
    
    The gauge requires us to clear the status bits manually for some alerts
    to be properly dismissed. Previously the IRQ was configured to react only
    on falling edge, which wasn't technically correct (the ALRT line is active
    low), but it had a happy side-effect of preventing interrupt storms
    on uncleared alerts from happening.
    
    Fixes: 7fbf6b731bca ("power: supply: max17042: Do not enforce (incorrect) interrupt trigger type")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc49ca4dbae1d2bb56a5a1e50f5b6eb4d3394ea8
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 21 10:34:47 2021 +0200

    USB: chipidea: fix interrupt deadlock
    
    commit 9aaa81c3366e8393a62374e3a1c67c69edc07b8a upstream.
    
    Chipidea core was calling the interrupt handler from non-IRQ context
    with interrupts enabled, something which can lead to a deadlock if
    there's an actual interrupt trying to take a lock that's already held
    (e.g. the controller lock in udc_irq()).
    
    Add a wrapper that can be used to fake interrupts instead of calling the
    handler directly.
    
    Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect")
    Fixes: 876d4e1e8298 ("usb: chipidea: core: add wakeup support for extcon")
    Cc: Peter Chen <peter.chen@kernel.org>
    Cc: stable@vger.kernel.org      # 4.4
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211021083447.20078-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 273a85ac422dd5701aa82f89b04c9df89424915c
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 13:51:59 2021 +0200

    USB: iowarrior: fix control-message timeouts
    
    commit 79a4479a17b83310deb0b1a2a274fe5be12d2318 upstream.
    
    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.
    
    Use the common control-message timeout define for the five-second
    timeout and drop the driver-specific one.
    
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Cc: stable@vger.kernel.org      # 2.6.21
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211025115159.4954-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fbf746092c2aabab6a2bc81448d97c690b0bc55
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 13:58:11 2021 +0200

    most: fix control-message timeouts
    
    commit 63b3e810eff65fb8587fcb26fa0b56802be12dcf upstream.
    
    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.
    
    Use the common control-message timeout defines for the five-second
    timeouts.
    
    Fixes: 97a6f772f36b ("drivers: most: add USB adapter driver")
    Cc: stable@vger.kernel.org      # 5.9
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211025115811.5410-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b09d36daf476ad2a03d691a6336d0d1c515e04c
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 7 15:31:46 2021 +0200

    Revert "serial: 8250: Fix reporting real baudrate value in c_ospeed field"
    
    commit d02b006b29de14968ba4afa998bede0d55469e29 upstream.
    
    This reverts commit 32262e2e429cdb31f9e957e997d53458762931b7.
    
    The commit in question claims to determine the inverse of
    serial8250_get_divisor() but failed to notice that some drivers override
    the default implementation using a get_divisor() callback.
    
    This means that the computed line-speed values can be completely wrong
    and results in regular TCSETS requests failing (the incorrect values
    would also be passed to any overridden set_divisor() callback).
    
    Similarly, it also failed to honour the old (deprecated) ASYNC_SPD_FLAGS
    and would break applications relying on those when re-encoding the
    actual line speed.
    
    There are also at least two quirks, UART_BUG_QUOT and an OMAP1510
    workaround, which were happily ignored and that are now broken.
    
    Finally, even if the offending commit were to be implemented correctly,
    this is a new feature and not something which should be backported to
    stable.
    
    Cc: Pali Rohár <pali@kernel.org>
    Fixes: 32262e2e429c ("serial: 8250: Fix reporting real baudrate value in c_ospeed field")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211007133146.28949-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02981a96642fbdfbeaeaa659db54f3375c54e69d
Author: Pali Rohár <pali@kernel.org>
Date:   Mon Sep 27 11:37:04 2021 +0200

    serial: 8250: Fix reporting real baudrate value in c_ospeed field
    
    commit 32262e2e429cdb31f9e957e997d53458762931b7 upstream.
    
    In most cases it is not possible to set exact baudrate value to hardware.
    
    So fix reporting real baudrate value which was set to hardware via c_ospeed
    termios field. It can be retrieved by ioctl(TCGETS2) from userspace.
    
    Real baudrate value is calculated from chosen hardware divisor and base
    clock. It is implemented in a new function serial8250_compute_baud_rate()
    which is inverse of serial8250_get_divisor() function.
    
    With this change is fixed also UART timeout value (it is updated via
    uart_update_timeout() function), which is calculated from the now fixed
    baudrate value too.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20210927093704.19768-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 670f1f30ed706e192448a6b3f4f0af73fdc22591
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Nov 11 17:32:53 2021 -0700

    io-wq: serialize hash clear with wakeup
    
    commit d3e3c102d107bb84251455a298cf475f24bab995 upstream.
    
    We need to ensure that we serialize the stalled and hash bits with the
    wait_queue wait handler, or we could be racing with someone modifying
    the hashed state after we find it busy, but before we then give up and
    wait for it to be cleared. This can cause random delays or stalls when
    handling buffered writes for many files, where some of these files cause
    hash collisions between the worker threads.
    
    Cc: stable@vger.kernel.org
    Reported-by: Daniel Black <daniel@mariadb.org>
    Fixes: e941894eae31 ("io-wq: make buffered file write hashed work map per-ctx")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bfa57795dc13b28375a5780914c8ae34dab44cc
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Oct 31 09:53:50 2021 +0900

    ksmbd: set unique value to volume serial field in FS_VOLUME_INFORMATION
    
    commit 5d2f0b1083eb158bdff01dd557e2c25046c0a7d2 upstream.
    
    Steve French reported ksmbd set fixed value to volume serial field in
    FS_VOLUME_INFORMATION. Volume serial value needs to be set to a unique
    value for client fscache. This patch set crc value that is generated
    with share name, path name and netbios name to volume serial.
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org # v5.15
    Reported-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15e904c149512f7ad32df87dc8e5368e281097ee
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Oct 15 13:14:20 2021 +0200

    serial: 8250: fix racy uartclk update
    
    commit 211cde4f5817dc88ef7f8f2fa286e57fbf14c8ee upstream.
    
    Commit 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method")
    added a hack to support SoCs where the UART reference clock can
    change behind the back of the driver but failed to add the proper
    locking.
    
    First, make sure to take a reference to the tty struct to avoid
    dereferencing a NULL pointer if the clock change races with a hangup.
    
    Second, the termios semaphore must be held during the update to prevent
    a racing termios change.
    
    Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method")
    Fixes: c8dff3aa8241 ("serial: 8250: Skip uninitialized TTY port baud rate update")
    Cc: stable@vger.kernel.org      # 5.9
    Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Tested-by: Serge Semin <fancer.lancer@gmail.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211015111422.1027-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cefb16b7b2d5378b0661f45211ad8e3c34aec480
Author: Wang Hai <wanghai38@huawei.com>
Date:   Fri Oct 15 16:55:43 2021 +0800

    USB: serial: keyspan: fix memleak on probe errors
    
    commit 910c996335c37552ee30fcb837375b808bb4f33b upstream.
    
    I got memory leak as follows when doing fault injection test:
    
    unreferenced object 0xffff888258228440 (size 64):
      comm "kworker/7:2", pid 2005, jiffies 4294989509 (age 824.540s)
      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:
        [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490
        [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470
        [<ffffffffa02ac0e4>] keyspan_port_probe+0xa4/0x5d0 [keyspan]
        [<ffffffffa0294c07>] usb_serial_device_probe+0x97/0x1d0 [usbserial]
        [<ffffffff82b50ca7>] really_probe+0x167/0x460
        [<ffffffff82b51099>] __driver_probe_device+0xf9/0x180
        [<ffffffff82b51173>] driver_probe_device+0x53/0x130
        [<ffffffff82b516f5>] __device_attach_driver+0x105/0x130
        [<ffffffff82b4cfe9>] bus_for_each_drv+0x129/0x190
        [<ffffffff82b50a69>] __device_attach+0x1c9/0x270
        [<ffffffff82b518d0>] device_initial_probe+0x20/0x30
        [<ffffffff82b4f062>] bus_probe_device+0x142/0x160
        [<ffffffff82b4a4e9>] device_add+0x829/0x1300
        [<ffffffffa0295fda>] usb_serial_probe.cold+0xc9b/0x14ac [usbserial]
        [<ffffffffa02266aa>] usb_probe_interface+0x1aa/0x3c0 [usbcore]
        [<ffffffff82b50ca7>] really_probe+0x167/0x460
    
    If keyspan_port_probe() fails to allocate memory for an out_buffer[i] or
    in_buffer[i], the previously allocated memory for out_buffer or
    in_buffer needs to be freed on the error handling path, otherwise a
    memory leak will result.
    
    Fixes: bad41a5bf177 ("USB: keyspan: fix port DMA-buffer allocations")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Link: https://lore.kernel.org/r/20211015085543.1203011-1-wanghai38@huawei.com
    Cc: stable@vger.kernel.org      # 3.12
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 309d6b5d45c9fd48ae98906d33f0d0d51257f98d
Author: Mihail Chindris <mihail.chindris@analog.com>
Date:   Thu Oct 7 08:00:36 2021 +0000

    Documentation:devicetree:bindings:iio:dac: Fix val
    
    commit 8fc4f038fa832ec3543907fdcbe1334e1b0a8950 upstream.
    
    A correct value for output-range-microvolts is -5 to 5 Volts
    not -5 to 5 milivolts
    
    Fixes: e904cc899293f ("dt-bindings: iio: dac: AD5766 yaml documentation")
    Signed-off-by: Mihail Chindris <mihail.chindris@analog.com>
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Link: https://lore.kernel.org/r/20211007080035.2531-6-mihail.chindris@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df56942798c48598e06e56624152e1715127516e
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Wed Aug 18 10:05:25 2021 +0200

    iio: ad5770r: make devicetree property reading consistent
    
    commit 26df977a909f818b7d346b3990735513e7e0bf93 upstream.
    
    The bindings file for this driver is defining the property as 'reg' but
    the driver was reading it with the 'num' name. The bindings actually had
    the 'num' property when added in
    commit ea52c21268e6 ("dt-bindings: iio: dac: Add docs for AD5770R DAC")
    and then changed it to 'reg' in
    commit 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors").
    However, both these commits landed in v5.7 so the assumption is
    that either 'num' is not being used or if it is, the validations were not
    done.
    
    Anyways, if someone comes back yelling about this, we might just support
    both of the properties in the future. Not ideal, but that's life...
    
    Fixes: 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210818080525.62790-1-nuno.sa@analog.com
    Cc: Stable@vger.kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a92d075cb4b5be5f6be75e9f128e8fb32fc5257a
Author: Pekka Korpinen <pekka.korpinen@iki.fi>
Date:   Wed Sep 29 21:57:55 2021 +0300

    iio: dac: ad5446: Fix ad5622_write() return value
    
    commit 558df982d4ead9cac628153d0d7b60feae05ddc8 upstream.
    
    On success i2c_master_send() returns the number of bytes written. The
    call from iio_write_channel_info(), however, expects the return value to
    be zero on success.
    
    This bug causes incorrect consumption of the sysfs buffer in
    iio_write_channel_info(). When writing more than two characters to
    out_voltage0_raw, the ad5446 write handler is called multiple times
    causing unexpected behavior.
    
    Fixes: 3ec36a2cf0d5 ("iio:ad5446: Add support for I2C based DACs")
    Signed-off-by: Pekka Korpinen <pekka.korpinen@iki.fi>
    Link: https://lore.kernel.org/r/20210929185755.2384-1-pekka.korpinen@iki.fi
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd297200b747908f4725880e34f0298e313b4634
Author: Mihail Chindris <mihail.chindris@analog.com>
Date:   Thu Oct 7 08:00:34 2021 +0000

    drivers: iio: dac: ad5766: Fix dt property name
    
    commit d9de0fbdeb0103a204055efb69cb5cc8f5f12a6a upstream.
    
    In the documentation the name for the property is
    output-range-microvolts which is a standard name, therefore this name
    must be used.
    
    Fixes: fd9373e41b9ba ("iio: dac: ad5766: add driver support for AD5766")
    Signed-off-by: Mihail Chindris <mihail.chindris@analog.com>
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Link: https://lore.kernel.org/r/20211007080035.2531-5-mihail.chindris@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c32c68ac7ba1d480e21501ea50e659b0ad310e82
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Oct 13 22:42:42 2021 +0800

    iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups()
    
    commit 604faf9a2ecd1addcc0c10a47e5aaef3c4d4fd6b upstream.
    
    If the second iio_device_register_sysfs_group() fails,
    'legacy_buffer_group.attrs' need be freed too or it will
    cause memory leak:
    
    unreferenced object 0xffff888003618280 (size 64):
      comm "xrun", pid 357, jiffies 4294907259 (age 22.296s)
      hex dump (first 32 bytes):
        80 f6 8c 03 80 88 ff ff 80 fb 8c 03 80 88 ff ff  ................
        00 f9 8c 03 80 88 ff ff 80 fc 8c 03 80 88 ff ff  ................
      backtrace:
        [<00000000076bfd43>] __kmalloc+0x1a3/0x2f0
        [<00000000c32e4886>] iio_buffers_alloc_sysfs_and_mask+0xc31/0x1290 [industrialio]
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211013144242.1685060-1-yangyingliang@huawei.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 289884de9ff62d193ac8874c50d1a8986be633a3
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Oct 13 17:43:43 2021 +0800

    iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask()
    
    commit 9a2ff8009e53296e47de72d5af0bc31cd53274ff upstream.
    
    When iio_buffer_wrap_attr() returns NULL or buffer->buffer_group.name alloc
    fails, the 'attr' which is allocated in __iio_buffer_alloc_sysfs_and_mask()
    is not freed, and cause memory leak.
    
    unreferenced object 0xffff888014882a00 (size 64):
      comm "i2c-adjd_s311-8", pid 424, jiffies 4294907737 (age 44.396s)
      hex dump (first 32 bytes):
        00 0f 8a 15 80 88 ff ff 00 0e 8a 15 80 88 ff ff  ................
        80 04 8a 15 80 88 ff ff 80 05 8a 15 80 88 ff ff  ................
      backtrace:
        [<0000000021752e67>] __kmalloc+0x1af/0x3c0
        [<0000000043e8305c>] iio_buffers_alloc_sysfs_and_mask+0xe73/0x1570 [industrialio]
        [<00000000b7aa5a17>] __iio_device_register+0x483/0x1a30 [industrialio]
        [<000000003fa0fb2f>] __devm_iio_device_register+0x23/0x90 [industrialio]
        [<000000003ab040cf>] adjd_s311_probe+0x19c/0x200 [adjd_s311]
        [<0000000080458969>] i2c_device_probe+0xa31/0xbe0
        [<00000000e20678ad>] really_probe+0x299/0xc30
        [<000000006bea9b27>] __driver_probe_device+0x357/0x500
        [<00000000e1df10d4>] driver_probe_device+0x4e/0x140
        [<0000000003661beb>] __device_attach_driver+0x257/0x340
        [<000000005bb4aa26>] bus_for_each_drv+0x166/0x1e0
        [<00000000272c5236>] __device_attach+0x272/0x420
        [<00000000d52a96ae>] bus_probe_device+0x1eb/0x2a0
        [<00000000129f7737>] device_add+0xbf0/0x1f90
        [<000000005eed4e52>] i2c_new_client_device+0x622/0xb20
        [<00000000b85a9c43>] new_device_store+0x1fa/0x420
    
    This patch fix to free it before the error return.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr")
    Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211013094343.315275-1-yangyingliang@huawei.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6444e89525dc064542f15cd739d2a1170109501
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 18 14:37:18 2021 +0800

    iio: buffer: Fix memory leak in iio_buffers_alloc_sysfs_and_mask()
    
    commit 486a25084155bf633768c26f022201c051d6fd95 upstream.
    
    When 'iio_dev_opaque->buffer_ioctl_handler' alloc fails in
    iio_buffers_alloc_sysfs_and_mask(), the 'attrs' allocated in
    iio_buffer_register_legacy_sysfs_groups() will be leaked:
    
    unreferenced object 0xffff888108568d00 (size 128):
      comm "88", pid 2014, jiffies 4294963294 (age 26.920s)
      hex dump (first 32 bytes):
        80 3e da 02 80 88 ff ff 00 3a da 02 80 88 ff ff  .>.......:......
        00 35 da 02 80 88 ff ff 00 38 da 02 80 88 ff ff  .5.......8......
      backtrace:
        [<0000000095a9e51e>] __kmalloc+0x1a3/0x2f0
        [<00000000faa3735e>] iio_buffers_alloc_sysfs_and_mask+0xfa3/0x1480 [industrialio]
        [<00000000a46384dc>] __iio_device_register+0x52e/0x1b40 [industrialio]
        [<00000000210af05e>] __devm_iio_device_register+0x22/0x80 [industrialio]
        [<00000000730d7b41>] adjd_s311_probe+0x195/0x200 [adjd_s311]
        [<00000000c0f70eb9>] i2c_device_probe+0xa07/0xbb0
    
    The iio_buffer_register_legacy_sysfs_groups() is
    called in __iio_buffer_alloc_sysfs_and_mask(),
    so move the iio_buffer_unregister_legacy_sysfs_groups()
    into __iio_buffer_free_sysfs_and_mask(), then the memory
    will be freed.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211018063718.1971240-1-yangyingliang@huawei.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7652924a1328841a80382f7bb0e8a6a178fcd2e
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Oct 13 12:04:38 2021 +0800

    iio: buffer: check return value of kstrdup_const()
    
    commit 2c0ad3f0cc04dec489552a21b80cd6d708bea96d upstream.
    
    Check return value of kstrdup_const() in iio_buffer_wrap_attr(),
    or it will cause null-ptr-deref in kernfs_name_hash() when calling
    device_add() as follows:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    RIP: 0010:strlen+0x0/0x20
    Call Trace:
     kernfs_name_hash+0x22/0x110
     kernfs_find_ns+0x11d/0x390
     kernfs_remove_by_name_ns+0x3b/0xb0
     remove_files.isra.1+0x7b/0x190
     internal_create_group+0x7f1/0xbb0
     internal_create_groups+0xa3/0x150
     device_add+0x8f0/0x2020
     cdev_device_add+0xc3/0x160
     __iio_device_register+0x1427/0x1b40 [industrialio]
     __devm_iio_device_register+0x22/0x80 [industrialio]
     adjd_s311_probe+0x195/0x200 [adjd_s311]
     i2c_device_probe+0xa07/0xbb0
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211013040438.1689277-1-yangyingliang@huawei.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c531289b74ebfaf9d94260b5e904cb8e85bd3cd
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 14 15:22:38 2021 +0100

    coresight: trbe: Defer the probe on offline CPUs
    
    commit a08025b3fe56185290a1ea476581f03ca733f967 upstream.
    
    If a CPU is offline during the driver init, we could end up causing
    a kernel crash trying to register the coresight device for the TRBE
    instance. The trbe_cpudata for the TRBE instance is initialized only
    when it is probed. Otherwise, we could end up dereferencing a NULL
    cpudata->drvdata.
    
    e.g:
    
    [    0.149999] coresight ete0: CPU0: ete v1.1 initialized
    [    0.149999] coresight-etm4x ete_1: ETM arch init failed
    [    0.149999] coresight-etm4x: probe of ete_1 failed with error -22
    [    0.150085] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
    [    0.150085] Mem abort info:
    [    0.150085]   ESR = 0x96000005
    [    0.150085]   EC = 0x25: DABT (current EL), IL = 32 bits
    [    0.150085]   SET = 0, FnV = 0
    [    0.150085]   EA = 0, S1PTW = 0
    [    0.150085] Data abort info:
    [    0.150085]   ISV = 0, ISS = 0x00000005
    [    0.150085]   CM = 0, WnR = 0
    [    0.150085] [0000000000000050] user address but active_mm is swapper
    [    0.150085] Internal error: Oops: 96000005 [#1] PREEMPT SMP
    [    0.150085] Modules linked in:
    [    0.150085] Hardware name: FVP Base RevC (DT)
    [    0.150085] pstate: 00800009 (nzcv daif -PAN +UAO -TCO BTYPE=--)
    [    0.150155] pc : arm_trbe_register_coresight_cpu+0x74/0x144
    [    0.150155] lr : arm_trbe_register_coresight_cpu+0x48/0x144
      ...
    
    [    0.150237] Call trace:
    [    0.150237]  arm_trbe_register_coresight_cpu+0x74/0x144
    [    0.150237]  arm_trbe_device_probe+0x1c0/0x2d8
    [    0.150259]  platform_drv_probe+0x94/0xbc
    [    0.150259]  really_probe+0x1bc/0x4a8
    [    0.150266]  driver_probe_device+0x7c/0xb8
    [    0.150266]  device_driver_attach+0x6c/0xac
    [    0.150266]  __driver_attach+0xc4/0x148
    [    0.150266]  bus_for_each_dev+0x7c/0xc8
    [    0.150266]  driver_attach+0x24/0x30
    [    0.150266]  bus_add_driver+0x100/0x1e0
    [    0.150266]  driver_register+0x78/0x110
    [    0.150266]  __platform_driver_register+0x44/0x50
    [    0.150266]  arm_trbe_init+0x28/0x84
    [    0.150266]  do_one_initcall+0x94/0x2bc
    [    0.150266]  do_initcall_level+0xa4/0x158
    [    0.150266]  do_initcalls+0x54/0x94
    [    0.150319]  do_basic_setup+0x24/0x30
    [    0.150319]  kernel_init_freeable+0xe8/0x14c
    [    0.150319]  kernel_init+0x14/0x18c
    [    0.150319]  ret_from_fork+0x10/0x30
    [    0.150319] Code: f94012c8 b0004ce2 9134a442 52819801 (f9402917)
    [    0.150319] ---[ end trace d23e0cfe5098535e ]---
    [    0.150346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    
    Fix this by skipping the step, if we are unable to probe the CPU.
    
    Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
    Reported-by: Bransilav Rankov <branislav.rankov@arm.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: stable <stable@vger.kernel.org>
    Tested-by: Branislav Rankov <branislav.rankov@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Link: https://lore.kernel.org/r/20211014142238.2221248-1-suzuki.poulose@arm.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea64104287cbec2ddeb75493e8aa0e855de3fc56
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Tue Sep 21 14:41:05 2021 +0100

    coresight: trbe: Fix incorrect access of the sink specific data
    
    commit bb5293e334af51b19b62d8bef1852ea13e935e9b upstream.
    
    The TRBE driver wrongly treats the aux private data as the TRBE driver
    specific buffer for a given perf handle, while it is the ETM PMU's
    event specific data. Fix this by correcting the instance to use
    appropriate helper.
    
    Cc: stable <stable@vger.kernel.org>
    Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Link: https://lore.kernel.org/r/20210921134121.2423546-2-suzuki.poulose@arm.com
    [Fixed 13 character SHA down to 12]
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d27fc5ba46fc01cf1501c0ec54436c202f5d4235
Author: Tao Zhang <quic_taozha@quicinc.com>
Date:   Thu Aug 19 17:29:37 2021 +0800

    coresight: cti: Correct the parameter for pm_runtime_put
    
    commit 692c9a499b286ea478f41b23a91fe3873b9e1326 upstream.
    
    The input parameter of the function pm_runtime_put should be the
    same in the function cti_enable_hw and cti_disable_hw. The correct
    parameter to use here should be dev->parent.
    
    Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
    Reviewed-by: Leo Yan <leo.yan@linaro.org>
    Fixes: 835d722ba10a ("coresight: cti: Initial CoreSight CTI Driver")
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1629365377-5937-1-git-send-email-quic_taozha@quicinc.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76d6bf233c7e3731b0fe7c83f082360d78b399f4
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Oct 22 09:43:23 2021 +0800

    pinctrl: core: fix possible memory leak in pinctrl_enable()
    
    commit c7892ae13e461ed20154321eb792e07ebe38f5b3 upstream.
    
    I got memory leak as follows when doing fault injection test:
    
    unreferenced object 0xffff888020a7a680 (size 64):
      comm "i2c-mcp23018-41", pid 23090, jiffies 4295160544 (age 8.680s)
      hex dump (first 32 bytes):
        00 48 d3 1e 80 88 ff ff 00 1a 56 c1 ff ff ff ff  .H........V.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<0000000083c79b35>] kmem_cache_alloc_trace+0x16d/0x360
        [<0000000051803c95>] pinctrl_init_controller+0x6ed/0xb70
        [<0000000064346707>] pinctrl_register+0x27/0x80
        [<0000000029b0e186>] devm_pinctrl_register+0x5b/0xe0
        [<00000000391f5a3e>] mcp23s08_probe_one+0x968/0x118a [pinctrl_mcp23s08]
        [<000000006112c039>] mcp230xx_probe+0x266/0x560 [pinctrl_mcp23s08_i2c]
    
    If pinctrl_claim_hogs() fails, the 'pindesc' allocated in pinctrl_register_one_pin()
    need be freed.
    
    Cc: stable@vger.kernel.org
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 950b0d91dc10 ("pinctrl: core: Fix regression caused by delayed work for hogs")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211022014323.1156924-1-yangyingliang@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb4102bb3821677eaf5b418f310fede04ba29232
Author: Robert Marko <robert.marko@sartura.hr>
Date:   Tue Nov 2 11:04:20 2021 +0100

    mfd: simple-mfd-i2c: Select MFD_CORE to fix build error
    
    commit 5dc6dafe62099ade0e7232ce9db4013b7673d860 upstream.
    
    MFD_SIMPLE_MFD_I2C should select the MFD_CORE to a prevent build error:
    
    aarch64-linux-ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe':
    drivers/mfd/simple-mfd-i2c.c:55: undefined reference to `devm_mfd_add_devices'
    
    Cc: <stable@vger.kernel.org>
    Fixes: c753ea31781aa ("mfd: simple-mfd-i2c: Add support for registering devices via MFD cells")
    Signed-off-by: Robert Marko <robert.marko@sartura.hr>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20211102100420.112215-1-robert.marko@sartura.hr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63dc291ab5e0284cc7e6c18ee4423b1d01fbff3f
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Thu Nov 4 13:13:28 2021 -0300

    cifs: set a minimum of 120s for next dns resolution
    
    commit 4ac0536f8874a903a72bddc57eb88db774261e3a upstream.
    
    With commit 506c1da44fee ("cifs: use the expiry output of dns_query to
    schedule next resolution") and after triggering the first reconnect,
    the next async dns resolution of tcp server's hostname would be
    scheduled based on dns_resolver's key expiry default, which happens to
    default to 5s on most systems that use key.dns_resolver for upcall.
    
    As per key.dns_resolver.conf(5):
    
           default_ttl=<number>
                  The  number  of  seconds  to  set  as the expiration on a cached
                  record.  This will be overridden if the program manages  to  re-
                  trieve  TTL  information along with the addresses (if, for exam-
                  ple, it accesses the DNS directly).  The default is  5  seconds.
                  The value must be in the range 1 to INT_MAX.
    
    Make the next async dns resolution no shorter than 120s as we do not
    want to be upcalling too often.
    
    Cc: stable@vger.kernel.org
    Fixes: 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution")
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Reviewed-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 1c35a216ef77db708178ca225d796271f2f60a7a
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Thu Oct 14 11:52:39 2021 +0000

    cifs: To match file servers, make sure the server hostname matches
    
    commit 7be3248f313930ff3d3436d4e9ddbe9fccc1f541 upstream.
    
    We generally rely on a bunch of factors to differentiate between servers.
    For example, IP address, port etc.
    
    For certain server types (like Azure), it is important to make sure
    that the server hostname matches too, even if the both hostnames currently
    resolve to the same IP address.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 120d9dca7d512ed3d36327fa95ba41747563595b
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri Oct 8 17:38:21 2021 +0800

    quota: correct error number in free_dqentry()
    
    commit d0e36a62bd4c60c09acc40e06ba4831a4d0bc75b upstream.
    
    Fix the error path in free_dqentry(), pass out the error number if the
    block to free is not correct.
    
    Fixes: 1ccd14b9c271 ("quota: Split off quota tree handling into a separate file")
    Link: https://lore.kernel.org/r/20211008093821.1001186-3-yi.zhang@huawei.com
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Cc: stable@kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 332db0909293f3f4d853ee2ea695272c75082d87
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri Oct 8 17:38:20 2021 +0800

    quota: check block number when reading the block in quota file
    
    commit 9bf3d20331295b1ecb81f4ed9ef358c51699a050 upstream.
    
    The block number in the quota tree on disk should be smaller than the
    v2_disk_dqinfo.dqi_blocks. If the quota file was corrupted, we may be
    allocating an 'allocated' block and that would lead to a loop in a tree,
    which will probably trigger oops later. This patch adds a check for the
    block number in the quota tree to prevent such potential issue.
    
    Link: https://lore.kernel.org/r/20211008093821.1001186-2-yi.zhang@huawei.com
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Cc: stable@kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddfea4b7d13b3d3455bfbb60ebafedacff7ba94b
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Oct 28 20:56:59 2021 +0200

    PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge
    
    commit 239edf686c14a9ff926dec2f350289ed7adfefe2 upstream.
    
    This register is exported at address offset 0x30.
    
    Link: https://lore.kernel.org/r/20211028185659.20329-8-kabel@kernel.org
    Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c7ebe1ec81f9b6a28b2c16ddfac69ef8dee348c
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Oct 28 20:56:57 2021 +0200

    PCI: aardvark: Set PCI Bridge Class Code to PCI Bridge
    
    commit 84e1b4045dc887b78bdc87d92927093dc3a465aa upstream.
    
    Aardvark controller has something like config space of a Root Port
    available at offset 0x0 of internal registers - these registers are used
    for implementation of the emulated bridge.
    
    The default value of Class Code of this bridge corresponds to a RAID Mass
    storage controller, though. (This is probably intended for when the
    controller is used as Endpoint.)
    
    Change the Class Code to correspond to a PCI Bridge.
    
    Add comment explaining this change.
    
    Link: https://lore.kernel.org/r/20211028185659.20329-6-kabel@kernel.org
    Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19a6b2b2f0fe1a1d6310f131c46ea1f54602e52e
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Oct 28 20:56:58 2021 +0200

    PCI: aardvark: Fix support for PCI_BRIDGE_CTL_BUS_RESET on emulated bridge
    
    commit bc4fac42e5f8460af09c0a7f2f1915be09e20c71 upstream.
    
    Aardvark supports PCIe Hot Reset via PCIE_CORE_CTRL1_REG.
    
    Use it for implementing PCI_BRIDGE_CTL_BUS_RESET bit of PCI_BRIDGE_CONTROL
    register on emulated bridge.
    
    With this, the function pci_reset_secondary_bus() starts working and can
    reset connected PCIe card. Custom userspace script [1] which uses setpci
    can trigger PCIe Hot Reset and reset the card manually.
    
    [1] https://alexforencich.com/wiki/en/pcie/hot-reset-linux
    
    Link: https://lore.kernel.org/r/20211028185659.20329-7-kabel@kernel.org
    Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25540fbe785805a2f4b888c2fb09b428b3ba3477
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Oct 28 20:56:56 2021 +0200

    PCI: aardvark: Fix support for bus mastering and PCI_COMMAND on emulated bridge
    
    commit 771153fc884f566a89af2d30033b7f3bc6e24e84 upstream.
    
    From very vague, ambiguous and incomplete information from Marvell we
    deduced that the 32-bit Aardvark register at address 0x4
    (PCIE_CORE_CMD_STATUS_REG), which is not documented for Root Complex mode
    in the Functional Specification (only for Endpoint mode), controls two
    16-bit PCIe registers: Command Register and Status Registers of PCIe Root
    Port.
    
    This means that bit 2 controls bus mastering and forwarding of memory and
    I/O requests in the upstream direction. According to PCI specifications
    bits [0:2] of Command Register, this should be by default disabled on
    reset. So explicitly disable these bits at early setup of the Aardvark
    driver.
    
    Remove code which unconditionally enables all 3 bits and let kernel code
    (via pci_set_master() function) to handle bus mastering of Root PCIe
    Bridge via emulated PCI_COMMAND on emulated bridge.
    
    Link: https://lore.kernel.org/r/20211028185659.20329-5-kabel@kernel.org
    Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org # b2a56469d550 ("PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7aaf8585eebca18399467b4fd04fc928da1125fd
Author: Marek Behún <kabel@kernel.org>
Date:   Thu Oct 28 20:56:55 2021 +0200

    PCI: aardvark: Read all 16-bits from PCIE_MSI_PAYLOAD_REG
    
    commit 95997723b6402cd6c53e0f9e7ac640ec64eaaff8 upstream.
    
    The PCIE_MSI_PAYLOAD_REG contains 16-bit MSI number, not only lower
    8 bits. Fix reading content of this register and add a comment
    describing the access to this register.
    
    Link: https://lore.kernel.org/r/20211028185659.20329-4-kabel@kernel.org
    Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce44e532b96e5308cd59f4610de2fde85c6ef40e
Author: Marek Behún <kabel@kernel.org>
Date:   Thu Oct 28 20:56:54 2021 +0200

    PCI: aardvark: Fix return value of MSI domain .alloc() method
    
    commit e4313be1599d397625c14fb7826996813622decf upstream.
    
    MSI domain callback .alloc() (implemented by advk_msi_irq_domain_alloc()
    function) should return zero on success, since non-zero value indicates
    failure.
    
    When the driver was converted to generic MSI API in commit f21a8b1b6837
    ("PCI: aardvark: Move to MSI handling using generic MSI support"), it
    was converted so that it returns hwirq number.
    
    Fix this.
    
    Link: https://lore.kernel.org/r/20211028185659.20329-3-kabel@kernel.org
    Fixes: f21a8b1b6837 ("PCI: aardvark: Move to MSI handling using generic MSI support")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 643a20110083f5a78d5e05e9a72ba404bce93425
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:44 2021 +0200

    PCI: aardvark: Fix configuring Reference clock
    
    commit 46ef6090dbf590711cb12680b6eafde5fa21fe87 upstream.
    
    Commit 366697018c9a ("PCI: aardvark: Add PHY support") introduced
    configuration of PCIe Reference clock via PCIE_CORE_REF_CLK_REG register,
    but did it incorrectly.
    
    PCIe Reference clock differential pair is routed from system board to
    endpoint card, so on CPU side it has output direction. Therefore it is
    required to enable transmitting and disable receiving.
    
    Default configuration according to Armada 3700 Functional Specifications is
    enabled receiver part and disabled transmitter.
    
    We need this change because otherwise PCIe Reference clock is configured to
    some undefined state when differential pair is used for both transmitting
    and receiving.
    
    Fix this by disabling receiver part.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-6-kabel@kernel.org
    Fixes: 366697018c9a ("PCI: aardvark: Add PHY support")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39579eb4f1f8cf05b58c62c3d13f3d51b6f59e55
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:52 2021 +0200

    PCI: aardvark: Fix reporting Data Link Layer Link Active
    
    commit 2b650b7ff20eb7ea8ef9031d20fb657286ab90cc upstream.
    
    Add support for reporting PCI_EXP_LNKSTA_DLLLA bit in Link Control register
    on emulated bridge via current LTSSM state. Also correctly indicate DLLLA
    capability via PCI_EXP_LNKCAP_DLLLARC bit in Link Control Capability
    register.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-14-kabel@kernel.org
    Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cb9b2bb7ab6e685927ee087b8d436a6b935b362
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:46 2021 +0200

    PCI: aardvark: Do not unmask unused interrupts
    
    commit 1fb95d7d3c7a926b002fe8a6bd27a1cb428b46dc upstream.
    
    There are lot of undocumented interrupt bits. To prevent unwanted
    spurious interrupts, fix all *_ALL_MASK macros to define all interrupt
    bits, so that driver can properly mask all interrupts, including those
    which are undocumented.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-8-kabel@kernel.org
    Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c6b530a0e3c8b7b15001475966e6db2e4e0befa
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:51 2021 +0200

    PCI: aardvark: Fix checking for link up via LTSSM state
    
    commit 661c399a651c11aaf83c45cbfe0b4a1fb7bc3179 upstream.
    
    Current implementation of advk_pcie_link_up() is wrong as it marks also
    link disabled or hot reset states as link up.
    
    Fix it by marking link up only to those states which are defined in PCIe
    Base specification 3.0, Table 4-14: Link Status Mapped to the LTSSM.
    
    To simplify implementation, Define macros for every LTSSM state which
    aardvark hardware can return in CFG_REG register.
    
    Fix also checking for link training according to the same Table 4-14.
    Define a new function advk_pcie_link_training() for this purpose.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-13-kabel@kernel.org
    Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Cc: Remi Pommarel <repk@triplefau.lt>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da478902acec8fdf6ac23425b54f46f4b1a93c2b
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Oct 5 20:09:45 2021 +0200

    PCI: aardvark: Do not clear status bits of masked interrupts
    
    commit a7ca6d7fa3c02c032db5440ff392d96c04684c21 upstream.
    
    The PCIE_ISR1_REG says which interrupts are currently set / active,
    including those which are masked.
    
    The driver currently reads this register and looks if some unmasked
    interrupts are active, and if not, it clears status bits of _all_
    interrupts, including the masked ones.
    
    This is incorrect, since, for example, some drivers may poll these bits.
    
    Remove this clearing, and also remove this early return statement
    completely, since it does not change functionality in any way.
    
    Link: https://lore.kernel.org/r/20211005180952.6812-7-kabel@kernel.org
    Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39c5465c36394a6b7d41e53168cf8d323984ef48
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Oct 15 14:29:58 2021 -0700

    cxl/pci: Fix NULL vs ERR_PTR confusion
    
    commit ca76a3a8052b71c0334d5c094859cfa340c290a8 upstream.
    
    cxl_pci_map_regblock() may return an ERR_PTR(), but cxl_pci_setup_regs()
    is only prepared for NULL as the error case. Pick the minimal fix for
    -stable backport purposes and just have cxl_pci_map_regblock() return
    NULL for errors.
    
    Fixes: f8a7e8c29be8 ("cxl/pci: Reserve all device regions at once")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/163433325724.834522.17809774578178224149.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afa7885b56e8d6b85d256594819b480a63a9eeb9
Author: Li Chen <lchen@ambarella.com>
Date:   Thu Oct 21 02:50:19 2021 +0000

    PCI: cadence: Add cdns_plat_pcie_probe() missing return
    
    commit 27cd7e3c9bb1ae13bc16f08138edd6e4df3cd211 upstream.
    
    When cdns_plat_pcie_probe() succeeds, return success instead of falling
    into the error handling code.
    
    Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
    Link: https://lore.kernel.org/r/DM6PR19MB40271B93057D949310F0B0EDA0BF9@DM6PR19MB4027.namprd19.prod.outlook.com
    Signed-off-by: Xuliang Zhang <xlzhanga@ambarella.com>
    Signed-off-by: Li Chen <lchen@ambarella.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 228028b01dab762945a198aa8ecbc0d2e47e1590
Author: Marek Behún <kabel@kernel.org>
Date:   Thu Oct 28 20:56:53 2021 +0200

    PCI: pci-bridge-emul: Fix emulation of W1C bits
    
    commit 7a41ae80bdcb17e14dd7d83239b8a0cf368f18be upstream.
    
    The pci_bridge_emul_conf_write() function correctly clears W1C bits in
    cfgspace cache, but it does not inform the underlying implementation
    about the clear request: the .write_op() method is given the value with
    these bits cleared.
    
    This is wrong if the .write_op() needs to know which bits were requested
    to be cleared.
    
    Fix the value to be passed into the .write_op() method to have requested
    W1C bits set, so that it can clear them.
    
    Both pci-bridge-emul users (mvebu and aardvark) are compatible with this
    change.
    
    Link: https://lore.kernel.org/r/20211028185659.20329-2-kabel@kernel.org
    Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Cc: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cffa333a2b263821561328cc75a3ffc8097d093
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Nov 4 14:04:52 2021 +0100

    ovl: fix filattr copy-up failure
    
    commit 5b0a414d06c3ed2097e32ef7944a4abb644b89bd upstream.
    
    This regression can be reproduced with ntfs-3g and overlayfs:
    
      mkdir lower upper work overlay
      dd if=/dev/zero of=ntfs.raw bs=1M count=2
      mkntfs -F ntfs.raw
      mount ntfs.raw lower
      touch lower/file.txt
      mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work - overlay
      mv overlay/file.txt overlay/file2.txt
    
    mv fails and (misleadingly) prints
    
      mv: cannot move 'overlay/file.txt' to a subdirectory of itself, 'overlay/file2.txt'
    
    The reason is that ovl_copy_fileattr() is triggered due to S_NOATIME being
    set on all inodes (by fuse) regardless of fileattr.
    
    ovl_copy_fileattr() tries to retrieve file attributes from lower file, but
    that fails because filesystem does not support this ioctl (this should fail
    with ENOTTY, but ntfs-3g return EINVAL instead).  This failure is
    propagated to origial operation (in this case rename) that triggered the
    copy-up.
    
    The fix is to ignore ENOTTY and EINVAL errors from fileattr_get() in copy
    up.  This also requires turning the internal ENOIOCTLCMD into ENOTTY.
    
    As a further measure to prevent unnecessary failures, only try the
    fileattr_get/set on upper if there are any flags to copy up.
    
    Side note: a number of filesystems set S_NOATIME (and sometimes other inode
    flags) irrespective of fileattr flags.  This causes unnecessary calls
    during copy up, which might lead to a performance issue, especially if
    latency is high.  To fix this, the kernel would need to differentiate
    between the two cases.  E.g. introduce SB_NOATIME_UPDATE, a per-sb variant
    of S_NOATIME.  SB_NOATIME doesn't work, because that's interpreted as
    "filesystem doesn't store an atime attribute"
    
    Reported-and-tested-by: Kevin Locke <kevin@kevinlocke.name>
    Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags")
    Cc: <stable@vger.kernel.org> # v5.15
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f372e38f5724301056e005353c8beecc3f8d257
Author: yangerkun <yangerkun@huawei.com>
Date:   Thu Sep 30 11:22:28 2021 +0800

    ovl: fix use after free in struct ovl_aio_req
    
    commit 9a254403760041528bc8f69fe2f5e1ef86950991 upstream.
    
    Example for triggering use after free in a overlay on ext4 setup:
    
    aio_read
      ovl_read_iter
        vfs_iter_read
          ext4_file_read_iter
            ext4_dio_read_iter
              iomap_dio_rw -> -EIOCBQUEUED
              /*
               * Here IO is completed in a separate thread,
               * ovl_aio_cleanup_handler() frees aio_req which has iocb embedded
               */
              file_accessed(iocb->ki_filp); /**BOOM**/
    
    Fix by introducing a refcount in ovl_aio_req similarly to aio_kiocb.  This
    guarantees that iocb is only freed after vfs_read/write_iter() returns on
    underlying fs.
    
    Fixes: 2406a307ac7d ("ovl: implement async IO routines")
    Signed-off-by: yangerkun <yangerkun@huawei.com>
    Link: https://lore.kernel.org/r/20210930032228.3199690-3-yangerkun@huawei.com/
    Cc: <stable@vger.kernel.org> # v5.6
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90817d78388cb1572a4a5cabba5923ba41fdb502
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Nov 2 10:19:44 2021 +0100

    xen/balloon: add late_initcall_sync() for initial ballooning done
    
    commit 40fdea0284bb20814399da0484a658a96c735d90 upstream.
    
    When running as PVH or HVM guest with actual memory < max memory the
    hypervisor is using "populate on demand" in order to allow the guest
    to balloon down from its maximum memory size. For this to work
    correctly the guest must not touch more memory pages than its target
    memory size as otherwise the PoD cache will be exhausted and the guest
    is crashed as a result of that.
    
    In extreme cases ballooning down might not be finished today before
    the init process is started, which can consume lots of memory.
    
    In order to avoid random boot crashes in such cases, add a late init
    call to wait for ballooning down having finished for PVH/HVM guests.
    
    Warn on console if initial ballooning fails, panic() after stalling
    for more than 3 minutes per default. Add a module parameter for
    changing this timeout.
    
    [boris: replaced pr_info() with pr_notice()]
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20211102091944.17487-1-jgross@suse.com
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 013fa93c79bd97fc2956797e1ed8e57f3e28e1bc
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Oct 29 13:30:51 2021 +0200

    ifb: fix building without CONFIG_NET_CLS_ACT
    
    commit 7444d706be31753f65052c7f6325fc8470cc1789 upstream.
    
    The driver no longer depends on this option, but it fails to
    build if it's disabled because the skb->tc_skip_classify is
    hidden behind an #ifdef:
    
    drivers/net/ifb.c:81:8: error: no member named 'tc_skip_classify' in 'struct sk_buff'
                    skb->tc_skip_classify = 1;
    
    Use the same #ifdef around the assignment.
    
    Fixes: 046178e726c2 ("ifb: Depend on netfilter alternatively to tc")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea531d52fa0843eeffd8d9c09ed236f627e12361
Author: Pali Rohár <pali@kernel.org>
Date:   Sat Oct 2 15:09:00 2021 +0200

    serial: core: Fix initializing and restoring termios speed
    
    commit 027b57170bf8bb6999a28e4a5f3d78bf1db0f90c upstream.
    
    Since commit edc6afc54968 ("tty: switch to ktermios and new framework")
    termios speed is no longer stored only in c_cflag member but also in new
    additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag
    then termios speed is stored only in these new members.
    
    Therefore to correctly restore termios speed it is required to store also
    ispeed and ospeed members, not only cflag member.
    
    In case only cflag member with BOTHER flag is restored then functions
    tty_termios_baud_rate() and tty_termios_input_baud_rate() returns baudrate
    stored in c_ospeed / c_ispeed member, which is zero as it was not restored
    too. If reported baudrate is invalid (e.g. zero) then serial core functions
    report fallback baudrate value 9600. So it means that in this case original
    baudrate is lost and kernel changes it to value 9600.
    
    Simple reproducer of this issue is to boot kernel with following command
    line argument: "console=ttyXXX,86400" (where ttyXXX is the device name).
    For speed 86400 there is no Bnnn constant and therefore kernel has to
    represent this speed via BOTHER c_cflag. Which means that speed is stored
    only in c_ospeed and c_ispeed members, not in c_cflag anymore.
    
    If bootloader correctly configures serial device to speed 86400 then kernel
    prints boot log to early console at speed speed 86400 without any issue.
    But after kernel starts initializing real console device ttyXXX then speed
    is changed to fallback value 9600 because information about speed was lost.
    
    This patch fixes above issue by storing and restoring also ispeed and
    ospeed members, which are required for BOTHER flag.
    
    Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20211002130900.9518-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34c2a0d0a70a794ab35780062eef04f498fd8da7
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Nov 8 10:58:10 2021 -0500

    ring-buffer: Protect ring_buffer_reset() from reentrancy
    
    commit 51d157946666382e779f94c39891e8e9a020da78 upstream.
    
    The resetting of the entire ring buffer use to simply go through and reset
    each individual CPU buffer that had its own protection and synchronization.
    But this was very slow, due to performing a synchronization for each CPU.
    The code was reshuffled to do one disabling of all CPU buffers, followed
    by a single RCU synchronization, and then the resetting of each of the CPU
    buffers. But unfortunately, the mutex that prevented multiple occurrences
    of resetting the buffer was not moved to the upper function, and there is
    nothing to protect from it.
    
    Take the ring buffer mutex around the global reset.
    
    Cc: stable@vger.kernel.org
    Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU")
    Reported-by: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cac487a4730e4b8e4a106a3258660d49a239fa1
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Nov 8 15:10:03 2021 +0000

    io_uring: honour zeroes as io-wq worker limits
    
    commit bad119b9a00019054f0c9e2045f312ed63ace4f4 upstream.
    
    When we pass in zero as an io-wq worker number limit it shouldn't
    actually change the limits but return the old value, follow that
    behaviour with deferred limits setup as well.
    
    Cc: stable@kernel.org # 5.15
    Reported-by: Beld Zhang <beldzhang@gmail.com>
    Fixes: e139a1ec92f8d ("io_uring: apply max_workers limit to all future users")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/1b222a92f7a78a24b042763805e891a4cdd4b544.1636384034.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1bb995036c7611177e4d7ac5e932e0fca06cf88
Author: Xiaoming Ni <nixiaoming@huawei.com>
Date:   Wed Sep 29 11:36:45 2021 +0800

    powerpc/85xx: Fix oops when mpc85xx_smp_guts_ids node cannot be found
    
    commit 3c2172c1c47b4079c29f0e6637d764a99355ebcd upstream.
    
    When the field described in mpc85xx_smp_guts_ids[] is not configured in
    dtb, the mpc85xx_setup_pmc() does not assign a value to the "guts"
    variable. As a result, the oops is triggered when
    mpc85xx_freeze_time_base() is executed.
    
    Fixes: 56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations")
    Cc: stable@vger.kernel.org # v4.6+
    Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210929033646.39630-2-nixiaoming@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4b49c3f9d58c501dcf8fb211c754b0c0aca08dc
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Thu Oct 7 11:30:06 2021 +0200

    iio: adc: tsc2046: fix scan interval warning
    
    commit 69b31fd7a61784692db6433c05d46915b1b1a680 upstream.
    
    Sync if statement with the actual warning.
    
    Fixes: 9504db5765e8 ("iio: adc: tsc2046: fix a warning message in tsc2046_adc_update_scan_mode()")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/r/20211007093007.1466-2-o.rempel@pengutronix.de
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24d8a24f5641a32600cc203ae87260b1dfab448d
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Thu Oct 28 22:38:27 2021 +0800

    can: j1939: j1939_tp_cmd_recv(): check the dst address of TP.CM_BAM
    
    commit 164051a6ab5445bd97f719f50b16db8b32174269 upstream.
    
    The TP.CM_BAM message must be sent to the global address [1], so add a
    check to drop TP.CM_BAM sent to a non-global address.
    
    Without this patch, the receiver will treat the following packets as
    normal RTS/CTS transport:
    18EC0102#20090002FF002301
    18EB0102#0100000000000000
    18EB0102#020000FFFFFFFFFF
    
    [1] SAE-J1939-82 2015 A.3.3 Row 1.
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Link: https://lore.kernel.org/all/1635431907-15617-4-git-send-email-zhangchangzhong@huawei.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e35f3d74bf06fdd302d8308799b1804d7be543df
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Thu Oct 28 22:38:26 2021 +0800

    can: j1939: j1939_can_recv(): ignore messages with invalid source address
    
    commit a79305e156db3d24fcd8eb649cdb3c3b2350e5c2 upstream.
    
    According to SAE-J1939-82 2015 (A.3.6 Row 2), a receiver should never
    send TP.CM_CTS to the global address, so we can add a check in
    j1939_can_recv() to drop messages with invalid source address.
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Link: https://lore.kernel.org/all/1635431907-15617-3-git-send-email-zhangchangzhong@huawei.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1be2ab083540b57083139fe358f1efbcfb5d9a8
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Thu Oct 28 22:38:25 2021 +0800

    can: j1939: j1939_tp_cmd_recv(): ignore abort message in the BAM transport
    
    commit c0f49d98006f2db3333b917caac65bce2af9865c upstream.
    
    This patch prevents BAM transport from being closed by receiving abort
    message, as specified in SAE-J1939-82 2015 (A.3.3 Row 4).
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Link: https://lore.kernel.org/all/1635431907-15617-2-git-send-email-zhangchangzhong@huawei.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c10d5d395632c314c6356812728a73f88f0f5e8
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Oct 15 19:46:59 2021 +0200

    can: mcp251xfd: mcp251xfd_irq(): add missing can_rx_offload_threaded_irq_finish() in case of bus off
    
    commit 691204bd66b34ba982e19988e6eba9f6321dfe6c upstream.
    
    The function can_rx_offload_threaded_irq_finish() is needed to trigger
    the NAPI thread to deliver read CAN frames to the networking stack.
    
    This patch adds the missing call to can_rx_offload_threaded_irq_finish()
    in case of a bus off, before leaving the interrupt handler to avoid
    packet starvation.
    
    Link: https://lore.kernel.org/all/20211106201526.44292-1-mkl@pengutronix.de
    Fixes: 30bfec4fec59 ("can: rx-offload: can_rx_offload_threaded_irq_finish(): add new function to be called from threaded interrupt")
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dac06227e1a3869800dd3618aaa068d5d777931c
Author: Stephane Grosjean <s.grosjean@peak-system.com>
Date:   Thu Oct 21 10:15:04 2021 +0200

    can: peak_usb: always ask for BERR reporting for PCAN-USB devices
    
    commit 3f1c7aa28498e52a5e6aa2f1b89bf35c63352cfd upstream.
    
    Since for the PCAN-USB, the management of the transition to the
    ERROR_WARNING or ERROR_PASSIVE state is done according to the error
    counters, these must be requested unconditionally.
    
    Link: https://lore.kernel.org/all/20211021081505.18223-2-s.grosjean@peak-system.com
    Fixes: c11dcee75830 ("can: peak_usb: pcan_usb_decode_error(): upgrade handling of bus state changes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df093c18bdb194ad3a1865644d54c98b1fe7c8e0
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Nov 9 01:30:45 2021 +0000

    KVM: nVMX: Handle dynamic MSR intercept toggling
    
    commit 67f4b9969c305be515e47f809ecacfd86bd20a9c upstream.
    
    Always check vmcs01's MSR bitmap when merging L0 and L1 bitmaps for L2,
    and always update the relevant bits in vmcs02.  This fixes two distinct,
    but intertwined bugs related to dynamic MSR bitmap modifications.
    
    The first issue is that KVM fails to enable MSR interception in vmcs02
    for the FS/GS base MSRs if L1 first runs L2 with interception disabled,
    and later enables interception.
    
    The second issue is that KVM fails to honor userspace MSR filtering when
    preparing vmcs02.
    
    Fix both issues simultaneous as fixing only one of the issues (doesn't
    matter which) would create a mess that no one should have to bisect.
    Fixing only the first bug would exacerbate the MSR filtering issue as
    userspace would see inconsistent behavior depending on the whims of L1.
    Fixing only the second bug (MSR filtering) effectively requires fixing
    the first, as the nVMX code only knows how to transition vmcs02's
    bitmap from 1->0.
    
    Move the various accessor/mutators that are currently buried in vmx.c
    into vmx.h so that they can be shared by the nested code.
    
    Fixes: 1a155254ff93 ("KVM: x86: Introduce MSR filtering")
    Fixes: d69129b4e46a ("KVM: nVMX: Disable intercept for FS/GS base MSRs in vmcs02 when possible")
    Cc: stable@vger.kernel.org
    Cc: Alexander Graf <graf@amazon.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211109013047.2041518-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c98d5e42be2cde10130b2b95a7d6944724552b75
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Nov 9 01:30:44 2021 +0000

    KVM: nVMX: Query current VMCS when determining if MSR bitmaps are in use
    
    commit 7dfbc624eb5726367900c8d86deff50836240361 upstream.
    
    Check the current VMCS controls to determine if an MSR write will be
    intercepted due to MSR bitmaps being disabled.  In the nested VMX case,
    KVM will disable MSR bitmaps in vmcs02 if they're disabled in vmcs12 or
    if KVM can't map L1's bitmaps for whatever reason.
    
    Note, the bad behavior is relatively benign in the current code base as
    KVM sets all bits in vmcs02's MSR bitmap by default, clears bits if and
    only if L0 KVM also disables interception of an MSR, and only uses the
    buggy helper for MSR_IA32_SPEC_CTRL.  Because KVM explicitly tests WRMSR
    before disabling interception of MSR_IA32_SPEC_CTRL, the flawed check
    will only result in KVM reading MSR_IA32_SPEC_CTRL from hardware when it
    isn't strictly necessary.
    
    Tag the fix for stable in case a future fix wants to use
    msr_write_intercepted(), in which case a buggy implementation in older
    kernels could prove subtly problematic.
    
    Fixes: d28b387fb74d ("KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211109013047.2041518-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35da6d291aca6ac0368bace8e54ccc17ac0a3074
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Nov 5 09:51:00 2021 +0000

    KVM: x86: Add helper to consolidate core logic of SET_CPUID{2} flows
    
    commit 8b44b174f6aca815fc84c2038e4523ef8e32fabb upstream.
    
    Move the core logic of SET_CPUID and SET_CPUID2 to a common helper, the
    only difference between the two ioctls() is the format of the userspace
    struct.  A future fix will add yet more code to the core logic.
    
    No functional change intended.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211105095101.5384-2-pdurrant@amazon.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d12bf19b2783300a617f849aed7c16404c77a3a
Author: David Woodhouse <dwmw2@infradead.org>
Date:   Tue Nov 2 17:36:39 2021 +0000

    KVM: x86: Fix recording of guest steal time / preempted status
    
    commit 7e2175ebd695f17860c5bd4ad7616cce12ed4591 upstream.
    
    In commit b043138246a4 ("x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is
    not missed") we switched to using a gfn_to_pfn_cache for accessing the
    guest steal time structure in order to allow for an atomic xchg of the
    preempted field. This has a couple of problems.
    
    Firstly, kvm_map_gfn() doesn't work at all for IOMEM pages when the
    atomic flag is set, which it is in kvm_steal_time_set_preempted(). So a
    guest vCPU using an IOMEM page for its steal time would never have its
    preempted field set.
    
    Secondly, the gfn_to_pfn_cache is not invalidated in all cases where it
    should have been. There are two stages to the GFN->PFN conversion;
    first the GFN is converted to a userspace HVA, and then that HVA is
    looked up in the process page tables to find the underlying host PFN.
    Correct invalidation of the latter would require being hooked up to the
    MMU notifiers, but that doesn't happen---so it just keeps mapping and
    unmapping the *wrong* PFN after the userspace page tables change.
    
    In the !IOMEM case at least the stale page *is* pinned all the time it's
    cached, so it won't be freed and reused by anyone else while still
    receiving the steal time updates. The map/unmap dance only takes care
    of the KVM administrivia such as marking the page dirty.
    
    Until the gfn_to_pfn cache handles the remapping automatically by
    integrating with the MMU notifiers, we might as well not get a
    kernel mapping of it, and use the perfectly serviceable userspace HVA
    that we already have.  We just need to implement the atomic xchg on
    the userspace address with appropriate exception handling, which is
    fairly trivial.
    
    Cc: stable@vger.kernel.org
    Fixes: b043138246a4 ("x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is not missed")
    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
    Message-Id: <3645b9b889dac6438394194bb5586a46b68d581f.camel@infradead.org>
    [I didn't entirely agree with David's assessment of the
     usefulness of the gfn_to_pfn cache, and integrated the outcome
     of the discussion in the above commit message. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23e989b977e0f1fe57ebc3ef20f7ab77ce5bbc27
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Nov 3 11:05:45 2021 +0000

    KVM: arm64: Extract ESR_ELx.EC only
    
    commit 8bb084119f1acc2ec55ea085a97231e3ddb30782 upstream.
    
    Since ARMv8.0 the upper 32 bits of ESR_ELx have been RES0, and recently
    some of the upper bits gained a meaning and can be non-zero. For
    example, when FEAT_LS64 is implemented, ESR_ELx[36:32] contain ISS2,
    which for an ST64BV or ST64BV0 can be non-zero. This can be seen in ARM
    DDI 0487G.b, page D13-3145, section D13.2.37.
    
    Generally, we must not rely on RES0 bit remaining zero in future, and
    when extracting ESR_ELx.EC we must mask out all other bits.
    
    All C code uses the ESR_ELx_EC() macro, which masks out the irrelevant
    bits, and therefore no alterations are required to C code to avoid
    consuming irrelevant bits.
    
    In a couple of places the KVM assembly extracts ESR_ELx.EC using LSR on
    an X register, and so could in theory consume previously RES0 bits. In
    both cases this is for comparison with EC values ESR_ELx_EC_HVC32 and
    ESR_ELx_EC_HVC64, for which the upper bits of ESR_ELx must currently be
    zero, but this could change in future.
    
    This patch adjusts the KVM vectors to use UBFX rather than LSR to
    extract ESR_ELx.EC, ensuring these are robust to future additions to
    ESR_ELx.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Acked-by: Will Deacon <will@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20211103110545.4613-1-mark.rutland@arm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ff8dae30188fbb56455db865bb76acf7a92a4aa
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Oct 12 14:36:24 2021 +0800

    iio: core: check return value when calling dev_set_name()
    
    commit fe6f45f6ba22d625a8500cbad0237c60dd3117ee upstream.
    
    I got a null-ptr-deref report when doing fault injection test:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    RIP: 0010:strlen+0x0/0x20
    Call Trace:
     start_creating+0x199/0x2f0
     debugfs_create_dir+0x25/0x430
     __iio_device_register+0x4da/0x1b40 [industrialio]
     __devm_iio_device_register+0x22/0x80 [industrialio]
     max1027_probe+0x639/0x860 [max1027]
     spi_probe+0x183/0x210
     really_probe+0x285/0xc30
    
    If dev_set_name() fails, the dev_name() is null, check the return
    value of dev_set_name() to avoid the null-ptr-deref.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support...")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211012063624.3167460-1-yangyingliang@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91410e2a28ac4cd03d4ae1dd28074d03970fac09
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Oct 13 11:05:32 2021 +0800

    iio: core: fix double free in iio_device_unregister_sysfs()
    
    commit 19833c40d0415d6fe4340b5b9c46239abbf718f6 upstream.
    
    I got the double free report:
    
    BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
     iio_device_unregister_sysfs+0x108/0x13b [industrialio]
     iio_dev_release+0x9e/0x10e [industrialio]
     device_release+0xa5/0x240
    
    If __iio_device_register() fails, iio_dev_opaque->groups will be freed
    in error path in iio_device_unregister_sysfs(), then iio_dev_release()
    will call iio_device_unregister_sysfs() again, it causes double free.
    Set iio_dev_opaque->groups to NULL when it's freed to fix this double free.
    
    Not this is a local work around for a more general mess around life time
    management that will get cleaned up and should make this handling
    unnecesarry.
    
    Fixes: 32f171724e5c ("iio: core: rework iio device group creation")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ee77bdef8e4a118184a722c695882fcd8b79903
Author: Henrik Grimler <henrik@grimler.se>
Date:   Wed Sep 29 20:14:17 2021 +0200

    power: supply: max17042_battery: use VFSOC for capacity when no rsns
    
    commit 223a3b82834f036a62aa831f67cbf1f1d644c6e2 upstream.
    
    On Galaxy S3 (i9300/i9305), which has the max17047 fuel gauge and no
    current sense resistor (rsns), the RepSOC register does not provide an
    accurate state of charge value. The reported value is wrong, and does
    not change over time. VFSOC however, which uses the voltage fuel gauge
    to determine the state of charge, always shows an accurate value.
    
    For devices without current sense, VFSOC is already used for the
    soc-alert (0x0003 is written to MiscCFG register), so with this change
    the source of the alert and the PROP_CAPACITY value match.
    
    Fixes: 359ab9f5b154 ("power_supply: Add MAX17042 Fuel Gauge Driver")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Suggested-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
    Signed-off-by: Henrik Grimler <henrik@grimler.se>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 165ca6e8ac5bb208f8b72c4e39e0b0f5ff4d6009
Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Date:   Tue Sep 14 14:18:06 2021 +0200

    power: supply: max17042_battery: Prevent int underflow in set_soc_threshold
    
    commit e660dbb68c6b3f7b9eb8b9775846a44f9798b719 upstream.
    
    max17042_set_soc_threshold gets called with offset set to 1, which means
    that minimum threshold value would underflow once SOC got down to 0,
    causing invalid alerts from the gauge.
    
    Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aaf0562f7147e5345f41a26fa08aa04d37f175f5
Author: Eugene Syromiatnikov <esyr@redhat.com>
Date:   Wed Nov 3 20:09:42 2021 +0100

    mctp: handle the struct sockaddr_mctp padding fields
    
    commit 1e4b50f06d970d8da3474d2a0354450416710bda upstream.
    
    In order to have the padding fields actually usable in the future,
    there have to be checks that user space doesn't supply non-zero garbage
    there.  It is also worth setting these padding fields to zero, unless
    it is known that they have been already zeroed.
    
    Cc: stable@vger.kernel.org # v5.15
    Fixes: 5a20dd46b8b84593 ("mctp: Be explicit about struct sockaddr_mctp padding")
    Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
    Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22584cf24a510d538a688782cd98bfb3b5de1d7c
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Sep 29 00:22:47 2021 +0200

    mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines
    
    commit b4ebddd6540d78a7f977b3fea0261bd575c6ffe2 upstream.
    
    Following the introduction of the generic ECC engine infrastructure, it
    was necessary to reorganize the code and move the ECC configuration in
    the ->attach_chip() hook. Failing to do that properly lead to a first
    series of fixes supposed to stabilize the situation. Unfortunately, this
    only fixed the use of software ECC engines, preventing any other kind of
    engine to be used, including on-die ones.
    
    It is now time to (finally) fix the situation by ensuring that we still
    provide a default (eg. software ECC) but will still support different
    ECC engines such as on-die ECC engines if properly described in the
    device tree.
    
    There are no changes needed on the core side in order to do this, but we
    just need to leverage the logic there which allows:
    1- a subsystem default (set to Host engines in the raw NAND world)
    2- a driver specific default (here set to software ECC engines)
    3- any type of engine requested by the user (ie. described in the DT)
    
    As the raw NAND subsystem has not yet been fully converted to the ECC
    engine infrastructure, in order to provide a default ECC engine for this
    driver we need to set chip->ecc.engine_type *before* calling
    nand_scan(). During the initialization step, the core will consider this
    entry as the default engine for this driver. This value may of course
    be overloaded by the user if the usual DT properties are provided.
    
    Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-9-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b523b232e46ad1f02f0d89ece59a0dcbc17537d6
Author: Meng Li <Meng.Li@windriver.com>
Date:   Tue Oct 19 11:05:55 2021 +0800

    soc: fsl: dpio: use the combined functions to protect critical zone
    
    commit dc7e5940aad6641bd5ab33ea8b21c4b3904d989f upstream.
    
    In orininal code, use 2 function spin_lock() and local_irq_save() to
    protect the critical zone. But when enable the kernel debug config,
    there are below inconsistent lock state detected.
    ================================
    WARNING: inconsistent lock state
    5.10.63-yocto-standard #1 Not tainted
    --------------------------------
    inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
    lock_torture_wr/226 [HC0[0]:SC1[5]:HE1:SE0] takes:
    ffff002005b2dd80 (&p->access_spinlock){+.?.}-{3:3}, at: qbman_swp_enqueue_multiple_mem_back+0x44/0x270
    {SOFTIRQ-ON-W} state was registered at:
      lock_acquire.part.0+0xf8/0x250
      lock_acquire+0x68/0x84
      _raw_spin_lock+0x68/0x90
      qbman_swp_enqueue_multiple_mem_back+0x44/0x270
      ......
      cryptomgr_test+0x38/0x60
      kthread+0x158/0x164
      ret_from_fork+0x10/0x38
    irq event stamp: 4498
    hardirqs last  enabled at (4498): [<ffff800010fcf980>] _raw_spin_unlock_irqrestore+0x90/0xb0
    hardirqs last disabled at (4497): [<ffff800010fcffc4>] _raw_spin_lock_irqsave+0xd4/0xe0
    softirqs last  enabled at (4458): [<ffff8000100108c4>] __do_softirq+0x674/0x724
    softirqs last disabled at (4465): [<ffff80001005b2a4>] __irq_exit_rcu+0x190/0x19c
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
           CPU0
           ----
      lock(&p->access_spinlock);
      <Interrupt>
        lock(&p->access_spinlock);
     *** DEADLOCK ***
    
    So, in order to avoid deadlock, use the combined functions
    spin_lock_irqsave/spin_unlock_irqrestore() to protect critical zone.
    
    Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with ring mode enqueue")
    Cc: stable@vger.kernel.org
    Signed-off-by: Meng Li <Meng.Li@windriver.com>
    Signed-off-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7c39e85f184907cfd4cc40f57b12cfee68f4622
Author: Meng Li <Meng.Li@windriver.com>
Date:   Tue Oct 19 10:32:41 2021 +0800

    soc: fsl: dpio: replace smp_processor_id with raw_smp_processor_id
    
    commit e775eb9fc2a4107f03222fa48bc95c2c82427e64 upstream.
    
    When enable debug kernel configs,there will be calltrace as below:
    
    BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
    caller is debug_smp_processor_id+0x20/0x30
    CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.10.63-yocto-standard #1
    Hardware name: NXP Layerscape LX2160ARDB (DT)
    Call trace:
     dump_backtrace+0x0/0x1a0
     show_stack+0x24/0x30
     dump_stack+0xf0/0x13c
     check_preemption_disabled+0x100/0x110
     debug_smp_processor_id+0x20/0x30
     dpaa2_io_query_fq_count+0xdc/0x154
     dpaa2_eth_stop+0x144/0x314
     __dev_close_many+0xdc/0x160
     __dev_change_flags+0xe8/0x220
     dev_change_flags+0x30/0x70
     ic_close_devs+0x50/0x78
     ip_auto_config+0xed0/0xf10
     do_one_initcall+0xac/0x460
     kernel_init_freeable+0x30c/0x378
     kernel_init+0x20/0x128
     ret_from_fork+0x10/0x38
    
    Based on comment in the context, it doesn't matter whether
    preemption is disable or not. So, replace smp_processor_id()
    with raw_smp_processor_id() to avoid above call trace.
    
    Fixes: c89105c9b390 ("staging: fsl-mc: Move DPIO from staging to drivers/soc/fsl")
    Cc: stable@vger.kernel.org
    Signed-off-by: Meng Li <Meng.Li@windriver.com>
    Signed-off-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22c84fe73e646248fb94c503987d14195381a6ca
Author: David Virag <virag.david003@gmail.com>
Date:   Fri Sep 10 00:28:12 2021 +0200

    soc: samsung: exynos-pmu: Fix compilation when nothing selects CONFIG_MFD_CORE
    
    commit e37ef6dcdb1f4738b01cec7fb7be46af07816af9 upstream.
    
    Commit 93618e344a5e ("soc: samsung: exynos-pmu: instantiate clkout
    driver as MFD") adds a "devm_mfd_add_devices" call in the exynos-pmu
    driver which depends on CONFIG_MFD_CORE. If no driver selects that
    config, the build will fail if CONFIG_EXYNOS_PMU is enabled with the
    following error:
    
      drivers/soc/samsung/exynos-pmu.c:137: undefined reference to `devm_mfd_add_devices'
    
    Fix this by making CONFIG_EXYNOS_PMU select CONFIG_MFD_CORE.
    
    Fixes: 93618e344a5e ("soc: samsung: exynos-pmu: instantiate clkout driver as MFD")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: David Virag <virag.david003@gmail.com>
    Link: https://lore.kernel.org/r/20210909222812.108614-1-virag.david003@gmail.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82d43437f88ca8e977dcfbcc5d4774948d1f936a
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Oct 29 09:14:19 2021 -0500

    signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed
    
    commit 00b06da29cf9dc633cdba87acd3f57f4df3fd5c7 upstream.
    
    As Andy pointed out that there are races between
    force_sig_info_to_task and sigaction[1] when force_sig_info_task.  As
    Kees discovered[2] ptrace is also able to change these signals.
    
    In the case of seeccomp killing a process with a signal it is a
    security violation to allow the signal to be caught or manipulated.
    
    Solve this problem by introducing a new flag SA_IMMUTABLE that
    prevents sigaction and ptrace from modifying these forced signals.
    This flag is carefully made kernel internal so that no new ABI is
    introduced.
    
    Longer term I think this can be solved by guaranteeing short circuit
    delivery of signals in this case.  Unfortunately reliable and
    guaranteed short circuit delivery of these signals is still a ways off
    from being implemented, tested, and merged.  So I have implemented a much
    simpler alternative for now.
    
    [1] https://lkml.kernel.org/r/b5d52d25-7bde-4030-a7b1-7c6f8ab90660@www.fastmail.com
    [2] https://lkml.kernel.org/r/202110281136.5CE65399A7@keescook
    Cc: stable@vger.kernel.org
    Fixes: 307d522f5eb8 ("signal/seccomp: Refactor seccomp signal and coredump generation")
    Tested-by: Andrea Righi <andrea.righi@canonical.com>
    Tested-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e87f4856a2c4d0dfabe714ad6693e1224d04a99f
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Oct 20 12:43:51 2021 -0500

    signal/mips: Update (_save|_restore)_fp_context to fail with -EFAULT
    
    commit 95bf9d646c3c3f95cb0be7e703b371db8da5be68 upstream.
    
    When an instruction to save or restore a register from the stack fails
    in _save_fp_context or _restore_fp_context return with -EFAULT.  This
    change was made to r2300_fpu.S[1] but it looks like it got lost with
    the introduction of EX2[2].  This is also what the other implementation
    of _save_fp_context and _restore_fp_context in r4k_fpu.S does, and
    what is needed for the callers to be able to handle the error.
    
    Furthermore calling do_exit(SIGSEGV) from bad_stack is wrong because
    it does not terminate the entire process it just terminates a single
    thread.
    
    As the changed code was the only caller of arch/mips/kernel/syscall.c:bad_stack
    remove the problematic and now unused helper function.
    
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Maciej Rozycki <macro@orcam.me.uk>
    Cc: linux-mips@vger.kernel.org
    [1] 35938a00ba86 ("MIPS: Fix ISA I FP sigcontext access violation handling")
    [2] f92722dc4545 ("MIPS: Correct MIPS I FP sigcontext layout")
    Cc: stable@vger.kernel.org
    Fixes: f92722dc4545 ("MIPS: Correct MIPS I FP sigcontext layout")
    Acked-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Link: https://lkml.kernel.org/r/20211020174406.17889-5-ebiederm@xmission.com
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9098de58b6d9125447a9857e376481f74623a8a0
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Sep 22 11:10:06 2021 +0200

    memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
    
    commit fff53a551db50f5edecaa0b29a64056ab8d2bbca upstream.
    
    This patch fixes 2 problems:
    [1] The output warning logs and data loss when performing
    mount/umount then remount the device with jffs2 format.
    [2] The access width of SMWDR[0:1]/SMRDR[0:1] register is wrong.
    
    This is the sample warning logs when performing mount/umount then
    remount the device with jffs2 format:
    jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x031c51d4:
    Read 0x00034e00, calculated 0xadb272a7
    
    The reason for issue [1] is that the writing data seems to
    get messed up.
    Data is only completed when the number of bytes is divisible by 4.
    If you only have 3 bytes of data left to write, 1 garbage byte
    is inserted after the end of the write stream.
    If you only have 2 bytes of data left to write, 2 bytes of '00'
    are added into the write stream.
    If you only have 1 byte of data left to write, 2 bytes of '00'
    are added into the write stream. 1 garbage byte is inserted after
    the end of the write stream.
    
    To solve problem [1], data must be written continuously in serial
    and the write stream ends when data is out.
    
    Following HW manual 62.2.15, access to SMWDR0 register should be
    in the same size as the transfer size specified in the SPIDE[3:0]
    bits in the manual mode enable setting register (SMENR).
    Be sure to access from address 0.
    
    So, in 16-bit transfer (SPIDE[3:0]=b'1100), SMWDR0 should be
    accessed by 16-bit width.
    Similar to SMWDR1, SMDDR0/1 registers.
    In current code, SMWDR0 register is accessed by regmap_write()
    that only set up to do 32-bit width.
    
    To solve problem [2], data must be written 16-bit or 8-bit when
    transferring 1-byte or 2-byte.
    
    Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Duc Nguyen <duc.nguyen.ub@renesas.com>
    [wsa: refactored to use regmap only via reg_read/reg_write]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Link: https://lore.kernel.org/r/20210922091007.5516-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a2aba3252e85784c266c77050771d3808c6f680
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Sep 1 13:21:34 2021 -0500

    signal: Remove the bogus sigkill_pending in ptrace_stop
    
    commit 7d613f9f72ec8f90ddefcae038fdae5adb8404b3 upstream.
    
    The existence of sigkill_pending is a little silly as it is
    functionally a duplicate of fatal_signal_pending that is used in
    exactly one place.
    
    Checking for pending fatal signals and returning early in ptrace_stop
    is actively harmful.  It casues the ptrace_stop called by
    ptrace_signal to return early before setting current->exit_code.
    Later when ptrace_signal reads the signal number from
    current->exit_code is undefined, making it unpredictable what will
    happen.
    
    Instead rely on the fact that schedule will not sleep if there is a
    pending signal that can awaken a task.
    
    Removing the explict sigkill_pending test fixes fixes ptrace_signal
    when ptrace_stop does not stop because current->exit_code is always
    set to to signr.
    
    Cc: stable@vger.kernel.org
    Fixes: 3d749b9e676b ("ptrace: simplify ptrace_stop()->sigkill_pending() path")
    Fixes: 1a669c2f16d4 ("Add arch_ptrace_stop")
    Link: https://lkml.kernel.org/r/87pmsyx29t.fsf@disp2133
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6a38dd58e4d44cc13fb80b44be8ad402c155e44
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun Oct 24 22:28:52 2021 +0300

    ASoC: tegra: Restore AC97 support
    
    commit de8fc2b0a3f9930f3cbe801d40758bb1d80b0ad8 upstream.
    
    The device-tree of AC97 codecs need to be parsed differently from I2S
    codecs, plus codec device may need to be created. This was missed by the
    patch that unified machine drivers into a single driver, fix it. It should
    restore audio on Toradex Colibri board.
    
    Cc: <stable@vger.kernel.org>
    Fixes: cc8f70f56039 ("ASoC: tegra: Unify ASoC machine drivers")
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/20211024192853.21957-1-digetx@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ed4b15a50fb0f212000970cc6299a9b9f5287c2
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun Oct 24 22:28:53 2021 +0300

    ASoC: tegra: Set default card name for Trimslice
    
    commit 824edd866a13db7dbb0d8e26d2142f10271b6460 upstream.
    
    The default card name for Trimslice device should be "tegra-trimslice".
    It got lost by accident during unification of machine sound drivers,
    fix it.
    
    Cc: <stable@vger.kernel.org>
    Fixes: cc8f70f56039 ("ASoC: tegra: Unify ASoC machine drivers")
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/20211024192853.21957-2-digetx@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f0d86c4fd2e181f0d43362a8470003e94f70235
Author: Alok Prasad <palok@marvell.com>
Date:   Wed Oct 27 18:43:29 2021 +0000

    RDMA/qedr: Fix NULL deref for query_qp on the GSI QP
    
    commit 4f960393a0ee9a39469ceb7c8077ae8db665cc12 upstream.
    
    This patch fixes a crash caused by querying the QP via netlink, and
    corrects the state of GSI qp. GSI qp's have a NULL qed_qp.
    
    The call trace is generated by:
     $ rdma res show
    
     BUG: kernel NULL pointer dereference, address: 0000000000000034
     Hardware name: Dell Inc. PowerEdge R720/0M1GCR, BIOS 1.2.6 05/10/2012
     RIP: 0010:qed_rdma_query_qp+0x33/0x1a0 [qed]
     RSP: 0018:ffffba560a08f580 EFLAGS: 00010206
     RAX: 0000000200000000 RBX: ffffba560a08f5b8 RCX: 0000000000000000
     RDX: ffffba560a08f5b8 RSI: 0000000000000000 RDI: ffff9807ee458090
     RBP: ffffba560a08f5a0 R08: 0000000000000000 R09: ffff9807890e7048
     R10: ffffba560a08f658 R11: 0000000000000000 R12: 0000000000000000
     R13: ffff9807ee458090 R14: ffff9807f0afb000 R15: ffffba560a08f7ec
     FS:  00007fbbf8bfe740(0000) GS:ffff980aafa00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000034 CR3: 00000001720ba001 CR4: 00000000000606f0
     Call Trace:
      qedr_query_qp+0x82/0x360 [qedr]
      ib_query_qp+0x34/0x40 [ib_core]
      ? ib_query_qp+0x34/0x40 [ib_core]
      fill_res_qp_entry_query.isra.26+0x47/0x1d0 [ib_core]
      ? __nla_put+0x20/0x30
      ? nla_put+0x33/0x40
      fill_res_qp_entry+0xe3/0x120 [ib_core]
      res_get_common_dumpit+0x3f8/0x5d0 [ib_core]
      ? fill_res_cm_id_entry+0x1f0/0x1f0 [ib_core]
      nldev_res_get_qp_dumpit+0x1a/0x20 [ib_core]
      netlink_dump+0x156/0x2f0
      __netlink_dump_start+0x1ab/0x260
      rdma_nl_rcv+0x1de/0x330 [ib_core]
      ? nldev_res_get_cm_id_dumpit+0x20/0x20 [ib_core]
      netlink_unicast+0x1b8/0x270
      netlink_sendmsg+0x33e/0x470
      sock_sendmsg+0x63/0x70
      __sys_sendto+0x13f/0x180
      ? setup_sgl.isra.12+0x70/0xc0
      __x64_sys_sendto+0x28/0x30
      do_syscall_64+0x3a/0xb0
      entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Cc: stable@vger.kernel.org
    Fixes: cecbcddf6461 ("qedr: Add support for QP verbs")
    Link: https://lore.kernel.org/r/20211027184329.18454-1-palok@marvell.com
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: Shai Malin <smalin@marvell.com>
    Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
    Signed-off-by: Alok Prasad <palok@marvell.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c0abfa673a7d9e7fc44bb155dedbd7712dee533
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:39 2021 -0700

    perf/x86/intel/uncore: Fix Intel ICX IIO event constraints
    
    commit f42e8a603c88f72bf047a710b9fc1d3579f31e71 upstream.
    
    According to the latest uncore document, both NUM_OUTSTANDING_REQ_OF_CPU
    (0x88) event and COMP_BUF_OCCUPANCY(0xd5) event also have constraints. Add
    them into the event constraints table.
    
    Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1629991963-102621-4-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54cabed24b73d3b7e46ece357d170eb5e502b53c
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:38 2021 -0700

    perf/x86/intel/uncore: Fix invalid unit check
    
    commit e2bb9fab08cbcc7922050c7eb0bd650807abfa4e upstream.
    
    The uncore unit with the type ID 0 and the unit ID 0 is missed.
    
    The table3 of the uncore unit maybe 0. The
    uncore_discovery_invalid_unit() mistakenly treated it as an invalid
    value.
    
    Remove the !unit.table3 check.
    
    Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1629991963-102621-3-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 398318fb96c8d0bc5517994c2d94791078328313
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Thu Aug 26 08:32:37 2021 -0700

    perf/x86/intel/uncore: Support extra IMC channel on Ice Lake server
    
    commit 496a18f09374ad89b3ab4366019bc3975db90234 upstream.
    
    There are three channels on a Ice Lake server, but only two channels
    will ever be active. Current perf only enables two channels.
    
    Support the extra IMC channel, which may be activated on some Ice Lake
    machines. For a non-activated channel, the SW can still access it. The
    write will be ignored by the HW. 0 is always returned for the reading.
    
    Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support")
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1629991963-102621-2-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a71f98f1b7a4ae3cfd76e20d3c205695a3be4aae
Author: Marek Vasut <marex@denx.de>
Date:   Thu Sep 16 16:42:45 2021 +0200

    rsi: Fix module dev_oper_mode parameter description
    
    commit 31f97cf9f0c31143a2a6fcc89c4a1286ce20157e upstream.
    
    The module parameters are missing dev_oper_mode 12, BT classic alone,
    add it. Moreover, the parameters encode newlines, which ends up being
    printed malformed e.g. by modinfo, so fix that too.
    
    However, the module parameter string is duplicated in both USB and SDIO
    modules and the dev_oper_mode mode enumeration in those module parameters
    is a duplicate of macros used by the driver. Furthermore, the enumeration
    is confusing.
    
    So, deduplicate the module parameter string and use __stringify() to
    encode the correct mode enumeration values into the module parameter
    string. Finally, replace 'Wi-Fi' with 'Wi-Fi alone' and 'BT' with
    'BT classic alone' to clarify what those modes really mean.
    
    Fixes: 898b255339310 ("rsi: add module parameter operating mode")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
    Cc: Angus Ainslie <angus@akkea.ca>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: Karun Eagalapati <karun256@gmail.com>
    Cc: Martin Fuzzey <martin.fuzzey@flowbird.group>
    Cc: Martin Kepplinger <martink@posteo.de>
    Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
    Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Cc: Siva Rebbagondla <siva8118@gmail.com>
    Cc: netdev@vger.kernel.org
    Cc: <stable@vger.kernel.org> # 4.17+
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210916144245.10181-1-marex@denx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a72ebbbc0f4f54a1c9fa0c4a0f4aebbdc6748eb5
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date:   Mon Aug 30 17:26:46 2021 +0200

    rsi: fix rate mask set leading to P2P failure
    
    commit b515d097053a71d624e0c5840b42cd4caa653941 upstream.
    
    P2P client mode was only working the first time.
    On subsequent connection attempts the group was successfully created but
    no data was sent (no transmitted data packets were seen with a sniffer).
    
    The reason for this was that the hardware was being configured in fixed
    rate mode with rate RSI_RATE_1 (1Mbps) which is not valid in the 5GHz band.
    
    In P2P mode wpa_supplicant uses NL80211_CMD_SET_TX_BITRATE_MASK to disallow
    the 11b rates in the 2.4GHz band which updated common->fixedrate_mask.
    
    rsi_set_min_rate() then used the fixedrate_mask to calculate the minimum
    allowed rate, or 0xffff = auto if none was found.
    However that calculation did not account for the different rate sets
    allowed in the different bands leading to the error.
    
    Fixing set_min_rate() would result in 6Mb/s being used all the time
    which is not what we want either.
    
    The reason the problem did not occur on the first connection is that
    rsi_mac80211_set_rate_mask() only updated the fixedrate_mask for
    the *current* band. When it was called that was still 2.4GHz as the
    switch is done later. So the when set_min_rate() was subsequently
    called after the switch to 5GHz it still had a mask of zero, leading
    to defaulting to auto mode.
    
    Fix this by differentiating the case of a single rate being
    requested, in which case the hardware will be used in fixed rate
    mode with just that rate, and multiple rates being requested,
    in which case we remain in auto mode but the firmware rate selection
    algorithm is configured with a restricted set of rates.
    
    Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver")
    Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
    CC: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a23cb5f914e1f8d9c39ed78e967f0dc23a7480d1
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date:   Mon Aug 30 17:26:45 2021 +0200

    rsi: fix key enabled check causing unwanted encryption for vap_id > 0
    
    commit 99ac6018821253ec67f466086afb63fc18ea48e2 upstream.
    
    My previous patch checked if encryption should be enabled by directly
    checking info->control.hw_key (like the downstream driver).
    However that missed that the control and driver_info members of
    struct ieee80211_tx_info are union fields.
    
    Due to this when rsi_core_xmit() updates fields in "tx_params"
    (driver_info) it can overwrite the control.hw_key, causing the result
    of the later test to be incorrect.
    
    With the current structure layout the first byte of control.hw_key is
    overlayed with the vap_id so, since we only test if control.hw_key is
    NULL / non NULL, a non zero vap_id will incorrectly enable encryption.
    
    In basic STA and AP modes the vap_id is always zero so it works but in
    P2P client mode a second VIF is created causing vap_id to be non zero
    and hence encryption to be enabled before keys have been set.
    
    Fix this by extracting the key presence flag to a new field in the driver
    private tx_params structure and populating it first.
    
    Fixes: 314538041b56 ("rsi: fix AP mode with WPA failure due to encrypted EAPOL")
    Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
    CC: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1630337206-12410-3-git-send-email-martin.fuzzey@flowbird.group
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d63343e5aa173264082a3912c38684afb3721097
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date:   Mon Aug 30 17:26:44 2021 +0200

    rsi: fix occasional initialisation failure with BT coex
    
    commit 9b14ed6e11b72dd4806535449ca6c6962cb2369d upstream.
    
    When BT coexistence is enabled (eg oper mode 13, which is the default)
    the initialisation on startup sometimes silently fails.
    
    In a normal initialisation we see
            usb 1-1.3: Product: Wireless USB Network Module
            usb 1-1.3: Manufacturer: Redpine Signals, Inc.
            usb 1-1.3: SerialNumber: 000000000001
            rsi_91x: rsi_probe: Initialized os intf ops
            rsi_91x: rsi_load_9116_firmware: Loading chunk 0
            rsi_91x: rsi_load_9116_firmware: Loading chunk 1
            rsi_91x: rsi_load_9116_firmware: Loading chunk 2
            rsi_91x: Max Stations Allowed = 1
    
    But sometimes the last log is missing and the wlan net device is
    not created.
    
    Running a userspace loop that resets the hardware via a GPIO shows the
    problem occurring ~5/100 resets.
    
    The problem does not occur in oper mode 1 (wifi only).
    
    Adding logs shows that the initialisation state machine requests a MAC
    reset via rsi_send_reset_mac() but the firmware does not reply, leading
    to the initialisation sequence being incomplete.
    
    Fix this by delaying attaching the BT adapter until the wifi
    initialisation has completed.
    
    With this applied I have done > 300 reset loops with no errors.
    
    Fixes: 716b840c7641 ("rsi: handle BT traffic in driver")
    Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
    CC: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60cbc288f8f3facc9e76e96d6e58dce4a2eb4150
Author: Benjamin Li <benl@squareup.com>
Date:   Wed Sep 1 11:06:05 2021 -0700

    wcn36xx: handle connection loss indication
    
    commit d6dbce453b19c64b96f3e927b10230f9a704b504 upstream.
    
    Firmware sends delete_sta_context_ind when it detects the AP has gone
    away in STA mode. Right now the handler for that indication only handles
    AP mode; fix it to also handle STA mode.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Li <benl@squareup.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210901180606.11686-1-benl@squareup.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a41c6373c38e62601b5daee78da0b4dea5a9f91
Author: Christian König <christian.koenig@amd.com>
Date:   Tue Jun 15 13:12:33 2021 +0200

    dma-buf: fix and rework dma_buf_poll v7
    
    commit 6b51b02a3a0ac49dfe302818d0746a799545e4e9 upstream.
    
    Daniel pointed me towards this function and there are multiple obvious problems
    in the implementation.
    
    First of all the retry loop is not working as intended. In general the retry
    makes only sense if you grab the reference first and then check the sequence
    values.
    
    Then we should always also wait for the exclusive fence.
    
    It's also good practice to keep the reference around when installing callbacks
    to fences you don't own.
    
    And last the whole implementation was unnecessary complex and rather hard to
    understand which could lead to probably unexpected behavior of the IOCTL.
    
    Fix all this by reworking the implementation from scratch. Dropping the
    whole RCU approach and taking the lock instead.
    
    Only mildly tested and needs a thoughtful review of the code.
    
    Pushing through drm-misc-next to avoid merge conflicts and give the code
    another round of testing.
    
    v2: fix the reference counting as well
    v3: keep the excl fence handling as is for stable
    v4: back to testing all fences, drop RCU
    v5: handle in and out separately
    v6: add missing clear of events
    v7: change coding style as suggested by Michel, drop unused variables
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Tested-by: Michel Dänzer <mdaenzer@redhat.com>
    CC: stable@vger.kernel.org
    Link: https://patchwork.freedesktop.org/patch/msgid/20210720131110.88512-1-christian.koenig@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5e659a7a6cb3ac4d78ff089d145a345af6d4274
Author: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Date:   Tue Oct 12 08:27:44 2021 +0200

    libata: fix checking of DMA state
    
    commit f971a85439bd25dc7b4d597cf5e4e8dc7ffc884b upstream.
    
    Checking if DMA is enabled should be done via the
    ata_dma_enabled helper function, since the init state
    0xff indicates disabled.
    This meant that ATA_CMD_READ_LOG_DMA_EXT was used and probed
    for before DMA was enabled, which caused hangs for some combinations
    of controllers and devices.
    It might also have caused it to be incorrectly disabled as broken,
    but there have been no reports of that.
    
    Cc: stable@vger.kernel.org
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195895
    Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 023d9d9e74d66182733d9e5bc8bf2e4671890110
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Mon Oct 11 15:32:24 2021 +0200

    mwifiex: Try waking the firmware until we get an interrupt
    
    commit 8e3e59c31fea5de95ffc52c46f0c562c39f20c59 upstream.
    
    It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the
    88W8897 card sometimes ignores or misses when we try to wake it up by
    writing to the firmware status register. This leads to the firmware
    wakeup timeout expiring and the driver resetting the card because we
    assume the firmware has hung up or crashed.
    
    Turns out that the firmware actually didn't hang up, but simply "missed"
    our wakeup request and didn't send us an interrupt with an AWAKE event.
    
    Trying again to read the firmware status register after a short timeout
    usually makes the firmware wake up as expected, so add a small retry
    loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to
    check whether the card woke up.
    
    The number of tries and timeout lengths for this were determined
    experimentally: The firmware usually takes about 500 us to wake up
    after we attempt to read the status register. In some cases where the
    firmware is very busy (for example while doing a bluetooth scan) it
    might even miss our requests for multiple milliseconds, which is why
    after 15 tries the waiting time gets increased to 10 ms. The maximum
    number of tries it took to wake the firmware when testing this was
    around 20, so a maximum number of 50 tries should give us plenty of
    safety margin.
    
    Here's a reproducer for those firmware wakeup failures I've found:
    
    1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on)
    2) Connect to any wifi network (makes firmware go into wifi powersaving
    mode, not deep sleep)
    3) Make sure bluetooth is turned off (to ensure the firmware actually
    enters powersave mode and doesn't keep the radio active doing bluetooth
    stuff)
    4) To confirm that wifi powersaving is entered ping a device on the LAN,
    pings should be a few ms higher than without powersaving
    5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and
    suspends the firmware extremely often
    6) Wait until things explode, for me it consistently takes <5 minutes
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211011133224.15561-3-verdre@v0yd.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5240b74b3fe1088f95b9893569f75686846803f8
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Mon Oct 11 15:32:23 2021 +0200

    mwifiex: Read a PCI register after writing the TX ring write pointer
    
    commit e5f4eb8223aa740237cd463246a7debcddf4eda1 upstream.
    
    On the 88W8897 PCIe+USB card the firmware randomly crashes after setting
    the TX ring write pointer. The issue is present in the latest firmware
    version 15.68.19.p21 of the PCIe+USB card.
    
    Those firmware crashes can be worked around by reading any PCI register
    of the card after setting that register, so read the PCI_VENDOR_ID
    register here. The reason this works is probably because we keep the bus
    from entering an ASPM state for a bit longer, because that's what causes
    the cards firmware to crash.
    
    This fixes a bug where during RX/TX traffic and with ASPM L1 substates
    enabled (the specific substates where the issue happens appear to be
    platform dependent), the firmware crashes and eventually a command
    timeout appears in the logs.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211011133224.15561-2-verdre@v0yd.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8e31bfb355601cf8e876ad1a647acd0b7366660
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Oct 22 14:58:23 2021 +0200

    PM: sleep: Do not let "syscore" devices runtime-suspend during system transitions
    
    commit 928265e3601cde78c7e0a3e518a93b27defed3b1 upstream.
    
    There is no reason to allow "syscore" devices to runtime-suspend
    during system-wide PM transitions, because they are subject to the
    same possible failure modes as any other devices in that respect.
    
    Accordingly, change device_prepare() and device_complete() to call
    pm_runtime_get_noresume() and pm_runtime_put(), respectively, for
    "syscore" devices too.
    
    Fixes: 057d51a1268f ("Merge branch 'pm-sleep'")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3883dbfcce484e383f9a1e93d3549db66dfc17c6
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Mon Oct 25 16:12:18 2021 +0300

    wcn36xx: Fix (QoS) null data frame bitrate/modulation
    
    commit d3fd2c95c1c13ec217d43ebef3c61cfa00a6cd37 upstream.
    
    We observe unexpected connection drops with some APs due to
    non-acked mac80211 generated null data frames (keep-alive).
    After debugging and capture, we noticed that null frames are
    submitted at standard data bitrate and that the given APs are
    in trouble with that.
    
    After setting the null frame bitrate to control bitrate, all
    null frames are acked as expected and connection is maintained.
    
    Not sure if it's a requirement of the specification, but it seems
    the right thing to do anyway, null frames are mostly used for control
    purpose (power-saving, keep-alive...), and submitting them with
    a slower/simpler bitrate/modulation is more robust.
    
    Cc: stable@vger.kernel.org
    Fixes: 512b191d9652 ("wcn36xx: Fix TX data path")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfe4950d90e2a2ca2ef5475e021c8c54b7c38818
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Mon Oct 25 16:12:18 2021 +0300

    wcn36xx: Fix tx_status mechanism
    
    commit a9e79b116cc4d0057e912be8f40b2c2e5bdc7c43 upstream.
    
    This change fix the TX ack mechanism in various ways:
    
    - For NO_ACK tagged packets, we don't need to wait for TX_ACK indication
    and so are not subject to the single packet ack limitation. So we don't
    have to stop the tx queue, and can call the tx status callback as soon
    as DMA transfer has completed.
    
    - Fix skb ownership/reference. Only start status indication timeout
    once the DMA transfer has been completed. This avoids the skb to be
    both referenced in the DMA tx ring and by the tx_ack_skb pointer,
    preventing any use-after-free or double-free.
    
    - This adds a sanity (paranoia?) check on the skb tx ack pointer.
    
    - Resume TX queue if TX status tagged packet TX fails.
    
    Cc: stable@vger.kernel.org
    Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fc610c422c12ae0b27eb1f916215913ce1eb3ff
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Wed Oct 20 15:38:53 2021 +0200

    wcn36xx: Fix HT40 capability for 2Ghz band
    
    commit 960ae77f25631bbe4e3aafefe209b52e044baf31 upstream.
    
    All wcn36xx controllers are supposed to support HT40 (and SGI40),
    This doubles the maximum bitrate/throughput with compatible APs.
    
    Tested with wcn3620 & wcn3680B.
    
    Cc: stable@vger.kernel.org
    Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1634737133-22336-1-git-send-email-loic.poulain@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c7f6d6154c41154d851c4bded00d4ae411932aa
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Thu Oct 21 15:09:04 2021 +0200

    HID: surface-hid: Allow driver matching for target ID 1 devices
    
    commit ab5fe33925c6b03f646a1153771dab047548e4d8 upstream.
    
    Until now we have only ever seen HID devices with target ID 2. The new
    Surface Laptop Studio however uses HID devices with target ID 1. Allow
    matching this driver to those as well.
    
    Cc: stable@vger.kernel.org # 5.14+
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Link: https://lore.kernel.org/r/20211021130904.862610-4-luzmaximilian@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31d61c42f116133b86fe5bacb1dad1feaca666ca
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Thu Oct 21 15:09:03 2021 +0200

    HID: surface-hid: Use correct event registry for managing HID events
    
    commit dc0fd0acb6e0e8025a0a43ada54513b216254fac upstream.
    
    Until now, we have only ever seen the REG-category registry being used
    on devices addressed with target ID 2. In fact, we have only ever seen
    Surface Aggregator Module (SAM) HID devices with target ID 2. For those
    devices, the registry also has to be addressed with target ID 2.
    
    Some devices, like the new Surface Laptop Studio, however, address their
    HID devices on target ID 1. As a result of this, any target ID 2
    commands time out. This includes event management commands addressed to
    the target ID 2 REG-category registry. For these devices, the registry
    has to be addressed via target ID 1 instead.
    
    We therefore assume that the target ID of the registry to be used
    depends on the target ID of the respective device. Implement this
    accordingly.
    
    Note that we currently allow the surface HID driver to only load against
    devices with target ID 2, so these timeouts are not happening (yet).
    This is just a preparation step before we allow the driver to load
    against all target IDs.
    
    Cc: stable@vger.kernel.org # 5.14+
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Link: https://lore.kernel.org/r/20211021130904.862610-3-luzmaximilian@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37200a451d7e06776ed3a64ab85e5426f799dafc
Author: Felix Fietkau <nbd@nbd.name>
Date:   Wed Jul 21 07:23:46 2021 +0200

    mt76: mt7615: fix skb use-after-free on mac reset
    
    commit b5cd1fd6043bbb7c5810067b5f93f3016bfd8a6f upstream.
    
    When clearing all existing pending tx slots, mt76_tx_complete_skb needs to
    be used to free the skbs, to ensure that they are cleared from the status
    list as well.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc1e276eea3de20691468052ba4d1029c75b8b34
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Thu Oct 21 15:09:02 2021 +0200

    platform/surface: aggregator_registry: Add support for Surface Laptop Studio
    
    commit 4f042e40199ce8bac6bc2b853e81744ee4ea759c upstream.
    
    Add support for the Surface Laptop Studio.
    
    In contrast to previous Surface Laptop models, this one has its HID
    devices attached to target ID 1 (instead of 2). It also has a couple
    more of them, including a new notifier for when the pen is stashed /
    taken out of its place, a "Sys Control" device, and two other
    unidentified HID devices with unknown usages.
    
    Battery and performance profile interfaces remain the same.
    
    Cc: stable@vger.kernel.org # 5.14+
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Link: https://lore.kernel.org/r/20211021130904.862610-2-luzmaximilian@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e094a99911da13909607278ac60f7aa874f715d3
Author: Lukas Wunner <lukas@wunner.de>
Date:   Tue Oct 26 07:15:32 2021 +0200

    ifb: Depend on netfilter alternatively to tc
    
    commit 046178e726c2977d686ba5e07105d5a6685c830e upstream.
    
    IFB originally depended on NET_CLS_ACT for traffic redirection.
    But since v4.5, that may be achieved with NFT_FWD_NETDEV as well.
    
    Fixes: 39e6dea28adc ("netfilter: nf_tables: add forward expression to the netdev family")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.5+: bcfabee1afd9: netfilter: nft_fwd_netdev: allow to redirect to ifb via ingress
    Cc: <stable@vger.kernel.org> # v4.5+
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11b37df34aa8230862c3ead753542f384a923450
Author: Austin Kim <austin.kim@lge.com>
Date:   Thu Oct 28 12:26:42 2021 +0100

    evm: mark evm_fixmode as __ro_after_init
    
    commit 32ba540f3c2a7ef61ed5a577ce25069a3d714fc9 upstream.
    
    The evm_fixmode is only configurable by command-line option and it is never
    modified outside initcalls, so declaring it with __ro_after_init is better.
    
    Signed-off-by: Austin Kim <austin.kim@lge.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 364b9bf060f95969b12dd76309ada9db81d7906e
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 14:05:21 2021 +0200

    rtl8187: fix control-message timeouts
    
    commit 2e9be536a213e838daed6ba42024dd68954ac061 upstream.
    
    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.
    
    Fixes: 605bebe23bf6 ("[PATCH] Add rtl8187 wireless driver")
    Cc: stable@vger.kernel.org      # 2.6.23
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211025120522.6045-4-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 422cef7904480ef06e3fa759934c894f7cce6f0b
Author: Ingmar Klein <ingmar_klein@web.de>
Date:   Fri Apr 9 11:26:33 2021 +0200

    PCI: Mark Atheros QCA6174 to avoid bus reset
    
    commit e3f4bd3462f6f796594ecc0dda7144ed2d1e5a26 upstream.
    
    When passing the Atheros QCA6174 through to a virtual machine, the VM hangs
    at the point where the ath10k driver loads.
    
    Add a quirk to avoid bus resets on this device, which avoids the hang.
    
    [bhelgaas: commit log]
    Link: https://lore.kernel.org/r/08982e05-b6e8-5a8d-24ab-da1488ee50a8@web.de
    Signed-off-by: Ingmar Klein <ingmar_klein@web.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Pali Rohár <pali@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 003ec78e77fc3275c9047096d5edbc32f42c9f2c
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Oct 27 10:08:17 2021 +0200

    ath10k: fix division by zero in send path
    
    commit a006acb931317aad3a8dd41333ebb0453caf49b8 upstream.
    
    Add the missing endpoint max-packet sanity check to probe() to avoid
    division by zero in ath10k_usb_hif_tx_sg() in case a malicious device
    has broken descriptors (or when doing descriptor fuzz testing).
    
    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).
    
    Fixes: 4db66499df91 ("ath10k: add initial USB support")
    Cc: stable@vger.kernel.org      # 4.14
    Cc: Erik Stromdahl <erik.stromdahl@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211027080819.6675-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee8f6a4b40807ff00e11db7a4c974df1112fbf04
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 14:05:19 2021 +0200

    ath10k: fix control-message timeout
    
    commit 5286132324230168d3fab6ffc16bfd7de85bdfb4 upstream.
    
    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.
    
    Fixes: 4db66499df91 ("ath10k: add initial USB support")
    Cc: stable@vger.kernel.org      # 4.14
    Cc: Erik Stromdahl <erik.stromdahl@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211025120522.6045-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb7c750c3d85af5395ba2831e8877c3ee1d88cab
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 14:05:20 2021 +0200

    ath6kl: fix control-message timeout
    
    commit a066d28a7e729f808a3e6eff22e70c003091544e upstream.
    
    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.
    
    Fixes: 241b128b6b69 ("ath6kl: add back beginnings of USB support")
    Cc: stable@vger.kernel.org      # 3.4
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211025120522.6045-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d52fb54f0cf70299d4b0f37f38a27ee1d467507
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Oct 27 10:08:18 2021 +0200

    ath6kl: fix division by zero in send path
    
    commit c1b9ca365deae667192be9fe24db244919971234 upstream.
    
    Add the missing endpoint max-packet sanity check to probe() to avoid
    division by zero in ath10k_usb_hif_tx_sg() in case a malicious device
    has broken descriptors (or when doing descriptor fuzz testing).
    
    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).
    
    Fixes: 9cbee358687e ("ath6kl: add full USB support")
    Cc: stable@vger.kernel.org      # 3.5
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211027080819.6675-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d52b152a1f4ab4c7e68e339761d43dc2ce4be82c
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Oct 27 10:08:19 2021 +0200

    mwifiex: fix division by zero in fw download path
    
    commit 89f8765a11d8df49296d92c404067f9b5c58ee26 upstream.
    
    Add the missing endpoint sanity checks to probe() to avoid division by
    zero in mwifiex_write_data_sync() in case a malicious device has broken
    descriptors (or when doing descriptor fuzz testing).
    
    Only add checks for the firmware-download boot stage, which require both
    command endpoints, for now. The driver looks like it will handle a
    missing endpoint during normal operation without oopsing, albeit not
    very gracefully as it will try to submit URBs to the default pipe and
    fail.
    
    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).
    
    Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset")
    Cc: stable@vger.kernel.org      # 3.5
    Cc: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211027080819.6675-4-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54d7dd1697450191c49d3859b65da541cf977542
Author: Eric Badger <ebadger@purestorage.com>
Date:   Sun Oct 10 10:06:56 2021 -0700

    EDAC/sb_edac: Fix top-of-high-memory value for Broadwell/Haswell
    
    commit 537bddd069c743759addf422d0b8f028ff0f8dbc upstream.
    
    The computation of TOHM is off by one bit. This missed bit results in
    too low a value for TOHM, which can cause errors in regular memory to
    incorrectly report:
    
      EDAC MC0: 1 CE Error at MMIOH area, on addr 0x000000207fffa680 on any memory
    
    Fixes: 50d1bb93672f ("sb_edac: add support for Haswell based systems")
    Cc: stable@vger.kernel.org
    Reported-by: Meeta Saggi <msaggi@purestorage.com>
    Signed-off-by: Eric Badger <ebadger@purestorage.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20211010170127.848113-1-ebadger@purestorage.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79f21b74070b13fdd08b587231d514d15af7c6c1
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Fri Oct 8 13:37:14 2021 +0200

    regulator: dt-bindings: samsung,s5m8767: correct s5m8767,pmic-buck-default-dvs-idx property
    
    commit a7fda04bc9b6ad9da8e19c9e6e3b1dab773d068a upstream.
    
    The driver was always parsing "s5m8767,pmic-buck-default-dvs-idx", not
    "s5m8767,pmic-buck234-default-dvs-idx".
    
    Cc: <stable@vger.kernel.org>
    Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Message-Id: <20211008113723.134648-3-krzysztof.kozlowski@canonical.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e61d145a08254846a8a0ee0d58767b1376a1f7c6
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Fri Oct 8 13:37:13 2021 +0200

    regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled
    
    commit b16bef60a9112b1e6daf3afd16484eb06e7ce792 upstream.
    
    The driver and its bindings, before commit 04f9f068a619 ("regulator:
    s5m8767: Modify parsing method of the voltage table of buck2/3/4") were
    requiring to provide at least one safe/default voltage for DVS registers
    if DVS GPIO is not being enabled.
    
    IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the
    s5m8767,pmic-buck2-dvs-voltage should still be present and contain one
    voltage.
    
    This requirement was coming from driver behavior matching this condition
    (none of DVS GPIO is enabled): it was always initializing the DVS
    selector pins to 0 and keeping the DVS enable setting at reset value
    (enabled).  Therefore if none of DVS GPIO is enabled in devicetree,
    driver was configuring the first DVS voltage for buck[234].
    
    Mentioned commit 04f9f068a619 ("regulator: s5m8767: Modify parsing
    method of the voltage table of buck2/3/4") broke it because DVS voltage
    won't be parsed from devicetree if DVS GPIO is not enabled.  After the
    change, driver will configure bucks to use the register reset value as
    voltage which might have unpleasant effects.
    
    Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled
    in devicetree (therefore DVS voltage is also not parsed), explicitly
    disable it.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4ffc1e0df1fbf0fb226514de3331a682e614377
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Tue Sep 28 02:22:35 2021 -0700

    hwmon: (pmbus/lm25066) Add offset coefficients
    
    commit ae59dc455a78fb73034dd1fbb337d7e59c27cbd8 upstream.
    
    With the exception of the lm5066i, all the devices handled by this
    driver had been missing their offset ('b') coefficients for direct
    format readings.
    
    Cc: stable@vger.kernel.org
    Fixes: 58615a94f6a1 ("hwmon: (pmbus/lm25066) Add support for LM25056")
    Fixes: e53e6497fc9f ("hwmon: (pmbus/lm25066) Refactor device specific coefficients")
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Link: https://lore.kernel.org/r/20210928092242.30036-2-zev@bewilderbeest.net
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c0049a01b2176413696177f837b3ef33860ec13
Author: Guoqing Jiang <guoqing.jiang@linux.dev>
Date:   Mon Oct 4 23:34:48 2021 +0800

    md/raid1: only allocate write behind bio for WriteMostly device
    
    commit fd3b6975e9c11c4fa00965f82a0bfbb3b7b44101 upstream.
    
    Commit 6607cd319b6b91bff94e90f798a61c031650b514 ("raid1: ensure write
    behind bio has less than BIO_MAX_VECS sectors") tried to guarantee the
    size of behind bio is not bigger than BIO_MAX_VECS sectors.
    
    Unfortunately the same calltrace still could happen since an array could
    enable write-behind without write mostly device.
    
    To match the manpage of mdadm (which says "write-behind is only attempted
    on drives marked as write-mostly"), we need to check WriteMostly flag to
    avoid such unexpected behavior.
    
    [1]. https://bugzilla.kernel.org/show_bug.cgi?id=213181#c25
    
    Cc: stable@vger.kernel.org # v5.12+
    Cc: Jens Stutte <jens@chianterastutte.eu>
    Reported-by: Jens Stutte <jens@chianterastutte.eu>
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 805d775fe6bc8bdb1ec1bb017e4913f361044fb8
Author: Corey Minyard <cminyard@mvista.com>
Date:   Mon Sep 20 06:25:37 2021 -0500

    ipmi:watchdog: Set panic count to proper value on a panic
    
    commit db05ddf7f321634c5659a0cf7ea56594e22365f7 upstream.
    
    You will get two decrements when the messages on a panic are sent, not
    one, since commit 2033f6858970 ("ipmi: Free receive messages when in an
    oops") was added, but the watchdog code had a bug where it didn't set
    the value properly.
    
    Reported-by: Anton Lundin <glance@acc.umu.se>
    Cc: <Stable@vger.kernel.org> # v5.4+
    Fixes: 2033f6858970 ("ipmi: Free receive messages when in an oops")
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcfba48960699357299082aa46e5afc457601e8b
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Wed Jul 28 16:03:13 2021 +0200

    selinux: fix race condition when computing ocontext SIDs
    
    commit cbfcd13be5cb2a07868afe67520ed181956579a7 upstream.
    
    Current code contains a lot of racy patterns when converting an
    ocontext's context structure to an SID. This is being done in a "lazy"
    fashion, such that the SID is looked up in the SID table only when it's
    first needed and then cached in the "sid" field of the ocontext
    structure. However, this is done without any locking or memory barriers
    and is thus unsafe.
    
    Between commits 24ed7fdae669 ("selinux: use separate table for initial
    SID lookup") and 66f8e2f03c02 ("selinux: sidtab reverse lookup hash
    table"), this race condition lead to an actual observable bug, because a
    pointer to the shared sid field was passed directly to
    sidtab_context_to_sid(), which was using this location to also store an
    intermediate value, which could have been read by other threads and
    interpreted as an SID. In practice this caused e.g. new mounts to get a
    wrong (seemingly random) filesystem context, leading to strange denials.
    This bug has been spotted in the wild at least twice, see [1] and [2].
    
    Fix the race condition by making all the racy functions use a common
    helper that ensures the ocontext::sid accesses are made safely using the
    appropriate SMP constructs.
    
    Note that security_netif_sid() was populating the sid field of both
    contexts stored in the ocontext, but only the first one was actually
    used. The SELinux wiki's documentation on the "netifcon" policy
    statement [3] suggests that using only the first context is intentional.
    I kept only the handling of the first context here, as there is really
    no point in doing the SID lookup for the unused one.
    
    I wasn't able to reproduce the bug mentioned above on any kernel that
    includes commit 66f8e2f03c02, even though it has been reported that the
    issue occurs with that commit, too, just less frequently. Thus, I wasn't
    able to verify that this patch fixes the issue, but it makes sense to
    avoid the race condition regardless.
    
    [1] https://github.com/containers/container-selinux/issues/89
    [2] https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/6DMTAMHIOAOEMUAVTULJD45JZU7IBAFM/
    [3] https://selinuxproject.org/page/NetworkStatements#netifcon
    
    Cc: stable@vger.kernel.org
    Cc: Xinjie Zheng <xinjie@google.com>
    Reported-by: Sujithra Periasamy <sujithra@google.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ae00ac03dd7f34abd32d5d9a04c5e4b40052613
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Tue Sep 14 23:40:27 2021 +0900

    ia64: kprobes: Fix to pass correct trampoline address to the handler
    
    commit a7fe2378454cf46cd5e2776d05e72bbe8f0a468c upstream.
    
    The following commit:
    
       Commit e792ff804f49 ("ia64: kprobes: Use generic kretprobe trampoline handler")
    
    Passed the wrong trampoline address to __kretprobe_trampoline_handler(): it
    passes the descriptor address instead of function entry address.
    
    Pass the right parameter.
    
    Also use correct symbol dereference function to get the function address
    from 'kretprobe_trampoline' - an IA64 special.
    
    Link: https://lkml.kernel.org/r/163163042696.489837.12551102356265354730.stgit@devnote2
    
    Fixes: e792ff804f49 ("ia64: kprobes: Use generic kretprobe trampoline handler")
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: X86 ML <x86@kernel.org>
    Cc: Daniel Xu <dxu@dxuuu.xyz>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Abhishek Sagar <sagar.abhishek@gmail.com>
    Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
    Cc: Paul McKenney <paulmck@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e47821087deca8813257299f7c10cce0dcf3692
Author: Laurent Vivier <lvivier@redhat.com>
Date:   Thu Oct 28 00:21:50 2021 +1000

    KVM: PPC: Tick accounting should defer vtime accounting 'til after IRQ handling
    
    commit 235cee162459d96153d63651ce7ff51752528c96 upstream.
    
    Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
    context before enabling irqs") moved guest_exit() into the interrupt
    protected area to avoid wrong context warning (or worse). The problem is
    that tick-based time accounting has not yet been updated at this point
    (because it depends on the timer interrupt firing), so the guest time
    gets incorrectly accounted to system time.
    
    To fix the problem, follow the x86 fix in commit 160457140187 ("Defer
    vtime accounting 'til after IRQ handling"), and allow host IRQs to run
    before accounting the guest exit time.
    
    In the case vtime accounting is enabled, this is not required because TB
    is used directly for accounting.
    
    Before this patch, with CONFIG_TICK_CPU_ACCOUNTING=y in the host and a
    guest running a kernel compile, the 'guest' fields of /proc/stat are
    stuck at zero. With the patch they can be observed increasing roughly as
    expected.
    
    Fixes: e233d54d4d97 ("KVM: booke: use __kvm_guest_exit")
    Fixes: 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest context before enabling irqs")
    Cc: stable@vger.kernel.org # 5.12+
    Signed-off-by: Laurent Vivier <lvivier@redhat.com>
    [np: only required for tick accounting, add Book3E fix, tweak changelog]
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211027142150.3711582-1-npiggin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df4d4868d164d8a14c34ee7624beb6365e459c1a
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Oct 8 17:11:05 2021 -0700

    KVM: VMX: Unregister posted interrupt wakeup handler on hardware unsetup
    
    commit ec5a4919fa7b7d8c7a2af1c7e799b1fe4be84343 upstream.
    
    Unregister KVM's posted interrupt wakeup handler during unsetup so that a
    spurious interrupt that arrives after kvm_intel.ko is unloaded doesn't
    call into freed memory.
    
    Fixes: bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU is blocked")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211009001107.3936588-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a8f76177494c3cca1bb151bdfa61cd8b70e6e65
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Oct 21 18:00:03 2021 -0700

    KVM: x86/mmu: Drop a redundant, broken remote TLB flush
    
    commit bc3b3c1002ea684e618ff6d8c387b1b8b319f140 upstream.
    
    A recent commit to fix the calls to kvm_flush_remote_tlbs_with_address()
    in kvm_zap_gfn_range() inadvertantly added yet another flush instead of
    fixing the existing flush.  Drop the redundant flush, and fix the params
    for the existing flush.
    
    Cc: stable@vger.kernel.org
    Fixes: 2822da446640 ("KVM: x86/mmu: fix parameters to kvm_flush_remote_tlbs_with_address")
    Cc: Maxim Levitsky <mlevitsk@redhat.com>
    Cc: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211022010005.1454978-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aba42e1ab1882ba09220b32ffff316502825b4cb
Author: Anand Jain <anand.jain@oracle.com>
Date:   Tue Oct 19 18:43:38 2021 +0800

    btrfs: call btrfs_check_rw_degradable only if there is a missing device
    
    commit 5c78a5e7aa835c4f08a7c90fe02d19f95a776f29 upstream.
    
    In open_ctree() in btrfs_check_rw_degradable() [1], we check each block
    group individually if at least the minimum number of devices is available
    for that profile. If all the devices are available, then we don't have to
    check degradable.
    
    [1]
    open_ctree()
    ::
    3559 if (!sb_rdonly(sb) && !btrfs_check_rw_degradable(fs_info, NULL)) {
    
    Also before calling btrfs_check_rw_degradable() in open_ctee() at the
    line number shown below [2] we call btrfs_read_chunk_tree() and down to
    add_missing_dev() to record number of missing devices.
    
    [2]
    open_ctree()
    ::
    3454         ret = btrfs_read_chunk_tree(fs_info);
    
    btrfs_read_chunk_tree()
      read_one_chunk() / read_one_dev()
        add_missing_dev()
    
    So, check if there is any missing device before btrfs_check_rw_degradable()
    in open_ctree().
    
    Also, with this the mount command could save ~16ms.[3] in the most
    common case, that is no device is missing.
    
    [3]
     1) * 16934.96 us | btrfs_check_rw_degradable [btrfs]();
    
    CC: stable@vger.kernel.org # 4.19+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1084e628b8c5602d7c2091afda867030edc342b8
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Oct 14 17:26:04 2021 +0100

    btrfs: fix lost error handling when replaying directory deletes
    
    commit 10adb1152d957a4d570ad630f93a88bb961616c1 upstream.
    
    At replay_dir_deletes(), if find_dir_range() returns an error we break out
    of the main while loop and then assign a value of 0 (success) to the 'ret'
    variable, resulting in completely ignoring that an error happened. Fix
    that by jumping to the 'out' label when find_dir_range() returns an error
    (negative value).
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e94f785f6ef42662f6cc54ea4376552c0331bc09
Author: Li Zhang <zhanglikernel@gmail.com>
Date:   Tue Oct 5 01:15:33 2021 +0800

    btrfs: clear MISSING device status bit in btrfs_close_one_device
    
    commit 5d03dbebba2594d2e6fbf3b5dd9060c5a835de3b upstream.
    
    Reported bug: https://github.com/kdave/btrfs-progs/issues/389
    
    There's a problem with scrub reporting aborted status but returning
    error code 0, on a filesystem with missing and readded device.
    
    Roughly these steps:
    
    - mkfs -d raid1 dev1 dev2
    - fill with data
    - unmount
    - make dev1 disappear
    - mount -o degraded
    - copy more data
    - make dev1 appear again
    
    Running scrub afterwards reports that the command was aborted, but the
    system log message says the exit code was 0.
    
    It seems that the cause of the error is decrementing
    fs_devices->missing_devices but not clearing device->dev_state.  Every
    time we umount filesystem, it would call close_ctree, And it would
    eventually involve btrfs_close_one_device to close the device, but it
    only decrements fs_devices->missing_devices but does not clear the
    device BTRFS_DEV_STATE_MISSING bit. Worse, this bug will cause Integer
    Overflow, because every time umount, fs_devices->missing_devices will
    decrease. If fs_devices->missing_devices value hit 0, it would overflow.
    
    With added debugging:
    
       loop1: detected capacity change from 0 to 20971520
       BTRFS: device fsid 56ad51f1-5523-463b-8547-c19486c51ebb devid 1 transid 21 /dev/loop1 scanned by systemd-udevd (2311)
       loop2: detected capacity change from 0 to 20971520
       BTRFS: device fsid 56ad51f1-5523-463b-8547-c19486c51ebb devid 2 transid 17 /dev/loop2 scanned by systemd-udevd (2313)
       BTRFS info (device loop1): flagging fs with big metadata feature
       BTRFS info (device loop1): allowing degraded mounts
       BTRFS info (device loop1): using free space tree
       BTRFS info (device loop1): has skinny extents
       BTRFS info (device loop1):  before clear_missing.00000000f706684d /dev/loop1 0
       BTRFS warning (device loop1): devid 2 uuid 6635ac31-56dd-4852-873b-c60f5e2d53d2 is missing
       BTRFS info (device loop1):  before clear_missing.0000000000000000 /dev/loop2 1
       BTRFS info (device loop1): flagging fs with big metadata feature
       BTRFS info (device loop1): allowing degraded mounts
       BTRFS info (device loop1): using free space tree
       BTRFS info (device loop1): has skinny extents
       BTRFS info (device loop1):  before clear_missing.00000000f706684d /dev/loop1 0
       BTRFS warning (device loop1): devid 2 uuid 6635ac31-56dd-4852-873b-c60f5e2d53d2 is missing
       BTRFS info (device loop1):  before clear_missing.0000000000000000 /dev/loop2 0
       BTRFS info (device loop1): flagging fs with big metadata feature
       BTRFS info (device loop1): allowing degraded mounts
       BTRFS info (device loop1): using free space tree
       BTRFS info (device loop1): has skinny extents
       BTRFS info (device loop1):  before clear_missing.00000000f706684d /dev/loop1 18446744073709551615
       BTRFS warning (device loop1): devid 2 uuid 6635ac31-56dd-4852-873b-c60f5e2d53d2 is missing
       BTRFS info (device loop1):  before clear_missing.0000000000000000 /dev/loop2 18446744073709551615
    
    If fs_devices->missing_devices is 0, next time it would be 18446744073709551615
    
    After apply this patch, the fs_devices->missing_devices seems to be
    right:
    
      $ truncate -s 10g test1
      $ truncate -s 10g test2
      $ losetup /dev/loop1 test1
      $ losetup /dev/loop2 test2
      $ mkfs.btrfs -draid1 -mraid1 /dev/loop1 /dev/loop2 -f
      $ losetup -d /dev/loop2
      $ mount -o degraded /dev/loop1 /mnt/1
      $ umount /mnt/1
      $ mount -o degraded /dev/loop1 /mnt/1
      $ umount /mnt/1
      $ mount -o degraded /dev/loop1 /mnt/1
      $ umount /mnt/1
      $ dmesg
    
       loop1: detected capacity change from 0 to 20971520
       loop2: detected capacity change from 0 to 20971520
       BTRFS: device fsid 15aa1203-98d3-4a66-bcae-ca82f629c2cd devid 1 transid 5 /dev/loop1 scanned by mkfs.btrfs (1863)
       BTRFS: device fsid 15aa1203-98d3-4a66-bcae-ca82f629c2cd devid 2 transid 5 /dev/loop2 scanned by mkfs.btrfs (1863)
       BTRFS info (device loop1): flagging fs with big metadata feature
       BTRFS info (device loop1): allowing degraded mounts
       BTRFS info (device loop1): disk space caching is enabled
       BTRFS info (device loop1): has skinny extents
       BTRFS info (device loop1):  before clear_missing.00000000975bd577 /dev/loop1 0
       BTRFS warning (device loop1): devid 2 uuid 8b333791-0b3f-4f57-b449-1c1ab6b51f38 is missing
       BTRFS info (device loop1):  before clear_missing.0000000000000000 /dev/loop2 1
       BTRFS info (device loop1): checking UUID tree
       BTRFS info (device loop1): flagging fs with big metadata feature
       BTRFS info (device loop1): allowing degraded mounts
       BTRFS info (device loop1): disk space caching is enabled
       BTRFS info (device loop1): has skinny extents
       BTRFS info (device loop1):  before clear_missing.00000000975bd577 /dev/loop1 0
       BTRFS warning (device loop1): devid 2 uuid 8b333791-0b3f-4f57-b449-1c1ab6b51f38 is missing
       BTRFS info (device loop1):  before clear_missing.0000000000000000 /dev/loop2 1
       BTRFS info (device loop1): flagging fs with big metadata feature
       BTRFS info (device loop1): allowing degraded mounts
       BTRFS info (device loop1): disk space caching is enabled
       BTRFS info (device loop1): has skinny extents
       BTRFS info (device loop1):  before clear_missing.00000000975bd577 /dev/loop1 0
       BTRFS warning (device loop1): devid 2 uuid 8b333791-0b3f-4f57-b449-1c1ab6b51f38 is missing
       BTRFS info (device loop1):  before clear_missing.0000000000000000 /dev/loop2 1
    
    CC: stable@vger.kernel.org # 4.19+
    Signed-off-by: Li Zhang <zhanglikernel@gmail.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5742269ad0cd4b5ce4972e8222e2832120baea55
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Sep 17 11:20:04 2021 +0200

    x86/iopl: Fake iopl(3) CLI/STI usage
    
    commit b968e84b509da593c50dc3db679e1d33de701f78 upstream.
    
    Since commit c8137ace5638 ("x86/iopl: Restrict iopl() permission
    scope") it's possible to emulate iopl(3) using ioperm(), except for
    the CLI/STI usage.
    
    Userspace CLI/STI usage is very dubious (read broken), since any
    exception taken during that window can lead to rescheduling anyway (or
    worse). The IOPL(2) manpage even states that usage of CLI/STI is highly
    discouraged and might even crash the system.
    
    Of course, that won't stop people and HP has the dubious honour of
    being the first vendor to be found using this in their hp-health
    package.
    
    In order to enable this 'software' to still 'work', have the #GP treat
    the CLI/STI instructions as NOPs when iopl(3). Warn the user that
    their program is doing dubious things.
    
    Fixes: a24ca9976843 ("x86/iopl: Remove legacy IOPL option")
    Reported-by: Ondrej Zary <linux@zary.sk>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@kernel.org # v5.5+
    Link: https://lkml.kernel.org/r/20210918090641.GD5106@worktop.programming.kicks-ass.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dead44f5c5a0f815c9ad755ec1e8cbb232776474
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Oct 8 17:11:04 2021 -0700

    x86/irq: Ensure PI wakeup handler is unregistered before module unload
    
    commit 6ff53f6a438f72998f56e82e76694a1df9d1ea2c upstream.
    
    Add a synchronize_rcu() after clearing the posted interrupt wakeup handler
    to ensure all readers, i.e. in-flight IRQ handlers, see the new handler
    before returning to the caller.  If the caller is an exiting module and
    is unregistering its handler, failure to wait could result in the IRQ
    handler jumping into an unloaded module.
    
    The registration path doesn't require synchronization, as it's the
    caller's responsibility to not generate interrupts it cares about until
    after its handler is registered.
    
    Fixes: f6b3c72c2366 ("x86/irq: Define a global vector for VT-d Posted-Interrupts")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211009001107.3936588-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90c6b8fe3b49030faabf3f0c01a6d86ea578991
Author: Jane Malalane <jane.malalane@citrix.com>
Date:   Thu Oct 21 11:47:44 2021 +0100

    x86/cpu: Fix migration safety with X86_BUG_NULL_SEL
    
    commit 415de44076640483648d6c0f6d645a9ee61328ad upstream.
    
    Currently, Linux probes for X86_BUG_NULL_SEL unconditionally which
    makes it unsafe to migrate in a virtualised environment as the
    properties across the migration pool might differ.
    
    To be specific, the case which goes wrong is:
    
    1. Zen1 (or earlier) and Zen2 (or later) in a migration pool
    2. Linux boots on Zen2, probes and finds the absence of X86_BUG_NULL_SEL
    3. Linux is then migrated to Zen1
    
    Linux is now running on a X86_BUG_NULL_SEL-impacted CPU while believing
    that the bug is fixed.
    
    The only way to address the problem is to fully trust the "no longer
    affected" CPUID bit when virtualised, because in the above case it would
    be clear deliberately to indicate the fact "you might migrate to
    somewhere which has this behaviour".
    
    Zen3 adds the NullSelectorClearsBase CPUID bit to indicate that loading
    a NULL segment selector zeroes the base and limit fields, as well as
    just attributes. Zen2 also has this behaviour but doesn't have the NSCB
    bit.
    
     [ bp: Minor touchups. ]
    
    Signed-off-by: Jane Malalane <jane.malalane@citrix.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    CC: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20211021104744.24126-1-jane.malalane@citrix.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f75068bc67967cdebfe14991ad2e98145c51bd84
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Fri Oct 15 12:24:16 2021 -0500

    x86/sme: Use #define USE_EARLY_PGTABLE_L5 in mem_encrypt_identity.c
    
    commit e7d445ab26db833d6640d4c9a08bee176777cc82 upstream.
    
    When runtime support for converting between 4-level and 5-level pagetables
    was added to the kernel, the SME code that built pagetables was updated
    to use the pagetable functions, e.g. p4d_offset(), etc., in order to
    simplify the code. However, the use of the pagetable functions in early
    boot code requires the use of the USE_EARLY_PGTABLE_L5 #define in order to
    ensure that the proper definition of pgtable_l5_enabled() is used.
    
    Without the #define, pgtable_l5_enabled() is #defined as
    cpu_feature_enabled(X86_FEATURE_LA57). In early boot, the CPU features
    have not yet been discovered and populated, so pgtable_l5_enabled() will
    return false even when 5-level paging is enabled. This causes the SME code
    to always build 4-level pagetables to perform the in-place encryption.
    If 5-level paging is enabled, switching to the SME pagetables results in
    a page-fault that kills the boot.
    
    Adding the #define results in pgtable_l5_enabled() using the
    __pgtable_l5_enabled variable set in early boot and the SME code building
    pagetables for the proper paging level.
    
    Fixes: aad983913d77 ("x86/mm/encrypt: Simplify sme_populate_pgd() and sme_populate_pgd_large()")
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: <stable@vger.kernel.org> # 4.18.x
    Link: https://lkml.kernel.org/r/2cb8329655f5c753905812d951e212022a480475.1634318656.git.thomas.lendacky@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 729bcb4c92ca03d39c62586ad40bd8aba65a84dd
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Nov 2 11:10:37 2021 +0100

    fuse: fix page stealing
    
    commit 712a951025c0667ff00b25afc360f74e639dfabe upstream.
    
    It is possible to trigger a crash by splicing anon pipe bufs to the fuse
    device.
    
    The reason for this is that anon_pipe_buf_release() will reuse buf->page if
    the refcount is 1, but that page might have already been stolen and its
    flags modified (e.g. PG_lru added).
    
    This happens in the unlikely case of fuse_dev_splice_write() getting around
    to calling pipe_buf_release() after a page has been stolen, added to the
    page cache and removed from the page cache.
    
    Fix by calling pipe_buf_release() right after the page was inserted into
    the page cache.  In this case the page has an elevated refcount so any
    release function will know that the page isn't reusable.
    
    Reported-by: Frank Dinoff <fdinoff@google.com>
    Link: https://lore.kernel.org/r/CAAmZXrsGg2xsP1CK+cbuEMumtrqdvD-NKnWzhNcvn71RV3c1yw@mail.gmail.com/
    Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device")
    Cc: <stable@vger.kernel.org> # v2.6.35
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cc2e56d9042adffd648b5bc715fc35e7313b21d
Author: yangerkun <yangerkun@huawei.com>
Date:   Fri Sep 3 14:27:48 2021 +0800

    ext4: refresh the ext4_ext_path struct after dropping i_data_sem.
    
    commit 1811bc401aa58c7bdb0df3205aa6613b49d32127 upstream.
    
    After we drop i_data sem, we need to reload the ext4_ext_path
    structure since the extent tree can change once i_data_sem is
    released.
    
    This addresses the BUG:
    
    [52117.465187] ------------[ cut here ]------------
    [52117.465686] kernel BUG at fs/ext4/extents.c:1756!
    ...
    [52117.478306] Call Trace:
    [52117.478565]  ext4_ext_shift_extents+0x3ee/0x710
    [52117.479020]  ext4_fallocate+0x139c/0x1b40
    [52117.479405]  ? __do_sys_newfstat+0x6b/0x80
    [52117.479805]  vfs_fallocate+0x151/0x4b0
    [52117.480177]  ksys_fallocate+0x4a/0xa0
    [52117.480533]  __x64_sys_fallocate+0x22/0x30
    [52117.480930]  do_syscall_64+0x35/0x80
    [52117.481277]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [52117.481769] RIP: 0033:0x7fa062f855ca
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20210903062748.4118886-4-yangerkun@huawei.com
    Signed-off-by: yangerkun <yangerkun@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e33566bb00a78d344a18fe2586eb5ccee3def5e
Author: yangerkun <yangerkun@huawei.com>
Date:   Fri Sep 3 14:27:47 2021 +0800

    ext4: ensure enough credits in ext4_ext_shift_path_extents
    
    commit 4268496e48dc681cfa53b92357314b5d7221e625 upstream.
    
    Like ext4_ext_rm_leaf, we can ensure that there are enough credits
    before every call that will consume credits.  As part of this fix we
    fold the functionality of ext4_access_path() into
    ext4_ext_shift_path_extents().  This change is needed as a preparation
    for the next bugfix patch.
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20210903062748.4118886-3-yangerkun@huawei.com
    Signed-off-by: yangerkun <yangerkun@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5be67d04989325abecf594942db3da21cd563c3
Author: Shaoying Xu <shaoyi@amazon.com>
Date:   Thu Sep 2 16:44:12 2021 +0000

    ext4: fix lazy initialization next schedule time computation in more granular unit
    
    commit 39fec6889d15a658c3a3ebb06fd69d3584ddffd3 upstream.
    
    Ext4 file system has default lazy inode table initialization setup once
    it is mounted. However, it has issue on computing the next schedule time
    that makes the timeout same amount in jiffies but different real time in
    secs if with various HZ values. Therefore, fix by measuring the current
    time in a more granular unit nanoseconds and make the next schedule time
    independent of the HZ value.
    
    Fixes: bfff68738f1c ("ext4: add support for lazy inode table initialization")
    Signed-off-by: Shaoying Xu <shaoyi@amazon.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Link: https://lore.kernel.org/r/20210902164412.9994-2-shaoyi@amazon.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46fd62b26822e1a33cffd8c22340e829b00c9d4c
Author: Eric Whitney <enwlinux@gmail.com>
Date:   Tue Oct 12 13:19:01 2021 -0400

    Revert "ext4: enforce buffer head state assertion in ext4_da_map_blocks"
    
    commit 3eda41df05d6ad5c825cbc7fef03d563597b1afa upstream.
    
    This reverts commit 948ca5f30e1df0c11eb5b0f410b9ceb97fa77ad9.
    
    Two crash reports from users running variations on 5.15-rc4 kernels
    suggest that it is premature to enforce the state assertion in the
    original commit.  Both crashes were triggered by BUG calls in that
    code, indicating that under some rare circumstance the buffer head
    state did not match a delayed allocated block at the time the
    block was written out.  No reproducer is available.  Resolving this
    problem will require more time than remains in the current release
    cycle, so reverting the original patch for the time being is necessary
    to avoid any instability it may cause.
    
    Signed-off-by: Eric Whitney <enwlinux@gmail.com>
    Link: https://lore.kernel.org/r/20211012171901.5352-1-enwlinux@gmail.com
    Fixes: 948ca5f30e1d ("ext4: enforce buffer head state assertion in ext4_da_map_blocks")
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d90b9f87968a61113795cbaddec3a969c5dde0e6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 5 10:15:17 2021 +0100

    ALSA: timer: Unconditionally unlink slave instances, too
    
    commit ffdd98277f0a1d15a67a74ae09bee713df4c0dbc upstream.
    
    Like the previous fix (commit c0317c0e8709 "ALSA: timer: Fix
    use-after-free problem"), we have to unlink slave timer instances
    immediately at snd_timer_stop(), too.  Otherwise it may leave a stale
    entry in the list if the slave instance is freed before actually
    running.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211105091517.21733-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1bcad600319d88e53bbea13bcea92dba102c769
Author: Wang Wensheng <wangwensheng4@huawei.com>
Date:   Wed Nov 3 03:35:17 2021 +0000

    ALSA: timer: Fix use-after-free problem
    
    commit c0317c0e87094f5b5782b6fdef5ae0a4b150496c upstream.
    
    When the timer instance was add into ack_list but was not currently in
    process, the user could stop it via snd_timer_stop1() without delete it
    from the ack_list. Then the user could free the timer instance and when
    it was actually processed UAF occurred.
    
    This issue could be reproduced via testcase snd_timer01 in ltp - running
    several instances of that testcase at the same time.
    
    What I actually met was that the ack_list of the timer broken and the
    kernel went into deadloop with irqoff. That could be detected by
    hardlockup detector on board or when we run it on qemu, we could use gdb
    to dump the ack_list when the console has no response.
    
    To fix this issue, we delete the timer instance from ack_list and
    active_list unconditionally in snd_timer_stop1().
    
    Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com>
    Suggested-by: Takashi Iwai <tiwai@suse.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47047ae0b779bf8c2a3e18313110f2a89586e477
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Nov 7 17:39:11 2021 +0100

    ALSA: PCM: Fix NULL dereference at mmap checks
    
    commit 8e537d5dec34cac746dd6abf6a83e5de3aa471fc upstream.
    
    The recent refactoring of mmap handling caused Oops on some devices
    that don't use the standard memory allocations.  This patch addresses
    it by allowing snd_dma_buffer_mmap() helper to receive the NULL
    pointer dmab argument (and return an error appropriately).
    
    Fixes: a202bd1ad86d ("ALSA: core: Move mmap handler into memalloc ops")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211107163911.13534-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9d4a8993500dd2e95fa336c6b003a4f28880973
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Nov 8 15:57:52 2021 +0100

    ALSA: pci: rme: Fix unaligned buffer addresses
    
    commit 43d35ccc36dad52377dd349b2e3ea803b72c3906 upstream.
    
    The recent fix for setting up the DMA buffer type on RME drivers tried
    to address the non-standard memory managements and changed the DMA
    buffer information to the standard snd_dma_buffer object that is
    allocated at the probe time.  However, I overlooked that the RME
    drivers handle the buffer addresses based on 64k alignment, and the
    previous conversion broke that silently.
    
    This patch is an attempt to fix the regression.  The snd_dma_buffer
    objects are copied to the original data with the correction to the
    aligned accesses, and those are passed to snd_pcm_set_runtime_buffer()
    helpers instead.  The original snd_dma_buffer objects are managed by
    devres, hence they'll be released automagically.
    
    Fixes: 0899a7a23047 ("ALSA: pci: rme: Set up buffer type properly")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211108145752.30572-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a520938980b8b7cf0e16f1ef61fac91fb0e8e31
Author: Austin Kim <austin.kim@lge.com>
Date:   Tue Nov 9 00:37:42 2021 +0000

    ALSA: synth: missing check for possible NULL after the call to kstrdup
    
    commit d159037abbe3412285c271bdfb9cdf19e62678ff upstream.
    
    If kcalloc() return NULL due to memory starvation, it is possible for
    kstrdup() to return NULL in similar case. So add null check after the call
    to kstrdup() is made.
    
    [ minor coding-style fix by tiwai ]
    
    Signed-off-by: Austin Kim <austin.kim@lge.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211109003742.GA5423@raspberrypi
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b875f9be6275a53c4532a3a649953cebb2722118
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 10 20:46:33 2021 +0100

    ALSA: hda: Free card instance properly at probe errors
    
    commit 39173303c83859723dab32c2abfb97296d6af3bf upstream.
    
    The recent change in hda-intel driver to allow repeated probes
    surfaced a problem that has been hidden until; the probe process in
    the work calls azx_free() at the error path, and this skips the card
    free process that eventually releases codec instances.  As a result,
    we get a kernel WARNING like:
    
      snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up
      ------------[ cut here ]------------
      WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73
      ....
    
    For fixing this, we need to call snd_card_free() instead of
    azx_free().  Additionally, the device drvdata has to be cleared, as
    the driver binding itself is still active.  Then the PM and other
    driver callbacks will ignore the procedure.
    
    Fixes: c0f1886de7e1 ("ALSA: hda: intel: Allow repeatedly probing on codec configuration errors")
    Reported-and-tested-by: Scott Branden <scott.branden@broadcom.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/063e2397-7edb-5f48-7b0d-618b938d9dd8@broadcom.com
    Link: https://lore.kernel.org/r/20211110194633.19098-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2f07b0d171ddcb00a6a7db144b7fade094a07c7
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Sat Oct 30 20:43:08 2021 +0300

    ALSA: usb-audio: Add registration quirk for JBL Quantum 400
    
    commit 763d92ed5dece7d439fc28a88b2d2728d525ffd9 upstream.
    
    Add another device ID for JBL Quantum 400. It requires the same quirk as
    other JBL Quantum devices.
    
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211030174308.1011825-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62448b6a73d0697e42e69cc80be651fbef095137
Author: Jason Ormes <skryking@gmail.com>
Date:   Sat Oct 30 15:04:05 2021 -0500

    ALSA: usb-audio: Line6 HX-Stomp XL USB_ID for 48k-fixed quirk
    
    commit 8f27b689066113a3e579d4df171c980c54368c4e upstream.
    
    Adding the Line6 HX-Stomp XL USB_ID as it needs this fixed frequency
    quirk as well.
    
    The device is basically just the HX-Stomp with some more buttons on
    the face.  I've done some recording with it after adding it, and it
    seems to function properly with this fix.  The Midi features appear to
    be working as well.
    
    [ a coding style fix and patch reformat by tiwai ]
    
    Signed-off-by: Jason Ormes <skryking@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211030200405.1358678-1-skryking@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41714a17a217de76755381969207dd6777859420
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Sun Oct 24 17:03:15 2021 +0300

    ALSA: mixer: fix deadlock in snd_mixer_oss_set_volume
    
    commit 3ab7992018455ac63c33e9b3eaa7264e293e40f4 upstream.
    
    In commit 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots")
    added mutex protection in snd_mixer_oss_set_volume(). Second
    mutex_lock() in same function looks like typo, fix it.
    
    Reported-by: syzbot+ace149a75a9a0a399ac7@syzkaller.appspotmail.com
    Fixes: 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/20211024140315.16704-1-paskripkin@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b13a4908f4b51f218535e2bc28f993175a60a984
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 20 18:48:46 2021 +0200

    ALSA: mixer: oss: Fix racy access to slots
    
    commit 411cef6adfb38a5bb6bd9af3941b28198e7fb680 upstream.
    
    The OSS mixer can reassign the mapping slots dynamically via proc
    file.  Although the addition and deletion of those slots are protected
    by mixer->reg_mutex, the access to slots aren't, hence this may cause
    UAF when the slots in use are deleted concurrently.
    
    This patch applies the mixer->reg_mutex in all appropriate code paths
    (i.e. the ioctl functions) that may access slots.
    
    Reported-by: syzbot+9988f17cf72a1045a189@syzkaller.appspotmail.com
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/00000000000036adc005ceca9175@google.com
    Link: https://lore.kernel.org/r/20211020164846.922-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46a2315ac327cb44cd3da654035002cd2ad905c5
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 14:11:42 2021 +0200

    ALSA: line6: fix control and interrupt message timeouts
    
    commit f4000b58b64344871d7b27c05e73932f137cfef6 upstream.
    
    USB control and interrupt message timeouts are specified in milliseconds
    and should specifically not vary with CONFIG_HZ.
    
    Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
    Cc: stable@vger.kernel.org      # 2.6.30
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211025121142.6531-3-johan@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb104cd727d9dab8c3bae0cc78c80adb6288fbee
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 25 14:11:41 2021 +0200

    ALSA: 6fire: fix control and bulk message timeouts
    
    commit 9b371c6cc37f954360989eec41c2ddc5a6b83917 upstream.
    
    USB control and bulk message timeouts are specified in milliseconds and
    should specifically not vary with CONFIG_HZ.
    
    Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
    Cc: stable@vger.kernel.org      # 2.6.39
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211025121142.6531-2-johan@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b86a54e00c2d707a981e2c1c2af4fd659f0f910
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Oct 26 11:54:01 2021 +0200

    ALSA: ua101: fix division by zero at probe
    
    commit 55f261b73a7e1cb254577c3536cef8f415de220a upstream.
    
    Add the missing endpoint max-packet sanity check to probe() to avoid
    division by zero in alloc_stream_buffers() in case a malicious device
    has broken descriptors (or when doing descriptor fuzz testing).
    
    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).
    
    Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support")
    Cc: stable@vger.kernel.org      # 2.6.34
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211026095401.26522-1-johan@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b752ce2211282a8c5788ae7359ce1e34b8490da
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Nov 10 22:40:32 2021 +0800

    ALSA: hda/realtek: Add quirk for HP EliteBook 840 G7 mute LED
    
    commit c058493df7edcef8f48c1494d9a84218519f966b upstream.
    
    The mute and micmute LEDs don't work on HP EliteBook 840 G7. The same
    quirk for other HP laptops can let LEDs work, so apply it.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211110144033.118451-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b898ef1050d05db79e48dd99b65e98a61d517f7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Nov 7 09:33:39 2021 +0100

    ALSA: hda/realtek: Add quirk for ASUS UX550VE
    
    commit 4fad4fb9871b43389e4f4bead18ec693064697bb upstream.
    
    ASUS UX550VE (SSID 1043:1970) requires a similar workaround for
    managing the routing of the 4 speakers like some other ASUS models.
    Add a corresponding quirk entry for fixing it.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212641
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211107083339.18013-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17c69c4f7f09865c0eb9311619cf20da7431b7d1
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Thu Nov 4 16:57:26 2021 +0100

    ALSA: hda/realtek: Add a quirk for Acer Spin SP513-54N
    
    commit 2a5bb694488bb6593066d46881bfd9d07edd1628 upstream.
    
    Another model requires ALC255_FIXUP_ACER_MIC_NO_PRESENCE fixup.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211853
    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211104155726.2090997-1-perex@perex.cz
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2ea7dec7785567bf21a3ca012b24323671ab948
Author: Jeremy Soller <jeremy@system76.com>
Date:   Tue Nov 2 11:21:04 2021 -0600

    ALSA: hda/realtek: Headset fixup for Clevo NH77HJQ
    
    commit 1278cc5ac2f96bab50dd55c8c05e0a6a77ce323e upstream.
    
    On Clevo NH77HJ, NH77HP, and their 15" variants, there is a headset
    microphone input attached to 0x19 that does not have a jack detect. In
    order to get it working, the pin configuration needs to be set
    correctly, and a new ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE fixup is
    applied. This is similar to the existing System76 quirk for ALC293, but
    for ALC256.
    
    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/20211102172104.10610-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cd2cfd09f506732bb79027f418714837cf94d81
Author: Tim Crawford <tcrawford@system76.com>
Date:   Mon Nov 1 10:21:34 2021 -0600

    ALSA: hda/realtek: Add quirk for Clevo PC70HS
    
    commit dbfe83507cf4ea66ce4efee2ac14c5ad420e31d3 upstream.
    
    Apply the PB51ED PCI quirk to the Clevo PC70HS. Fixes audio output from
    the internal speakers.
    
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211101162134.5336-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af31cffa09b75e4f72bf496af91ca54024a690b6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 28 09:09:11 2021 +0200

    ALSA: hda/realtek: Add a quirk for HP OMEN 15 mute LED
    
    commit 375f8426ed994addd2be4d76febc946a6fdd8280 upstream.
    
    HP OMEN 15 laptop requires the quirk to fiddle with COEF 0x0b bit 2
    for toggling the mute LED.  It's already implemented for other HP
    laptops, and we just need to add a proper fixup entry.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214735
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211028070911.18891-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13c4f0e731e73170c540666b666b4acdcfa4d1be
Author: Johnathon Clark <john.clark@cantab.net>
Date:   Wed Oct 20 14:12:51 2021 +0100

    ALSA: hda/realtek: Fix mic mute LED for the HP Spectre x360 14
    
    commit 5fc462c3aaad601d5089fd5588a5799896a6937d upstream.
    
    On the 'HP Spectre x360 Convertible 14-ea0xx' the microphone mute led is
    controlled by GPIO 0x04. The speaker mute LED does not seem to be
    exposed by GPIO and is there not set.
    
    [ a slight coding-style fix by tiwai ]
    
    Fixes: c3bb2b521944 ("ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup")
    Signed-off-by: Johnathon Clark <john.clark@cantab.net>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211020131253.35894-1-john.clark@cantab.net
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00845427c47d00517db51849eb24dc14844263e8
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Fri Jun 18 14:29:03 2021 +0200

    media: v4l2-ioctl: Fix check_ext_ctrls
    
    commit 861f92cb9160b14beef0ada047384c2340701ee2 upstream.
    
    Drivers that do not use the ctrl-framework use this function instead.
    
    Fix the following issues:
    
    - Do not check for multiple classes when getting the DEF_VAL.
    - Return -EINVAL for request_api calls
    - Default value cannot be changed, return EINVAL as soon as possible.
    - Return the right error_idx
    [If an error is found when validating the list of controls passed with
    VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to
    indicate to userspace that no actual hardware was touched.
    It would have been much nicer of course if error_idx could point to the
    control index that failed the validation, but sadly that's not how the
    API was designed.]
    
    Fixes v4l2-compliance:
    Control ioctls (Input 0):
            warn: v4l2-test-controls.cpp(834): error_idx should be equal to count
            warn: v4l2-test-controls.cpp(855): error_idx should be equal to count
                    fail: v4l2-test-controls.cpp(813): doioctl(node, VIDIOC_G_EXT_CTRLS, &ctrls)
            test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
    Buffer ioctls (Input 0):
                    fail: v4l2-test-buffers.cpp(1994): ret != EINVAL && ret != EBADR && ret != ENOTTY
            test Requests: FAIL
    
    Cc: stable@vger.kernel.org
    Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
    Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cfad3f87d803ab737d786b7664e4dfdeea8fb70
Author: Sean Young <sean@mess.org>
Date:   Wed Sep 15 18:14:07 2021 +0200

    media: ir-kbd-i2c: improve responsiveness of hauppauge zilog receivers
    
    commit c73ba202a851c0b611ef2c25e568fadeff5e667f upstream.
    
    The IR receiver has two issues:
    
     - Sometimes there is no response to a button press
     - Sometimes a button press is repeated when it should not have been
    
    Hanging the polling interval fixes this behaviour.
    
    Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994050
    
    Cc: stable@vger.kernel.org
    Suggested-by: Joaquín Alberto Calderón Pozo <kini_calderon@hotmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e37e1cad5b09b2ed3b015f12bcfc9eb10c84ffd
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Fri Oct 8 11:04:23 2021 +0100

    media: rkvdec: Support dynamic resolution changes
    
    commit 0887e9e152efbd3601d6c907e90033d25067277d upstream.
    
    The mem-to-mem stateless decoder API specifies support for dynamic
    resolution changes. In particular, the decoder should accept format
    changes on the OUTPUT queue even when buffers have been allocated,
    as long as it is not streaming.
    
    Relax restrictions for S_FMT as described in the previous paragraph,
    and as long as the codec format remains the same. This aligns it with
    the Hantro and Cedrus decoders. This change was mostly based on commit
    ae02d49493b5 ("media: hantro: Fix s_fmt for dynamic resolution changes").
    
    Since rkvdec_s_fmt() is now just a wrapper around the output/capture
    variants without any additional shared functionality, drop the wrapper
    and call the respective functions directly.
    
    Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2837d7277ea10c4f596ac9fb908b158a9cdb7d19
Author: Sean Young <sean@mess.org>
Date:   Sun Oct 17 13:01:15 2021 +0100

    media: ite-cir: IR receiver stop working after receive overflow
    
    commit fdc881783099c6343921ff017450831c8766d12a upstream.
    
    On an Intel NUC6iSYK, no IR is reported after a receive overflow.
    
    When a receiver overflow occurs, this condition is only cleared by
    reading the fifo. Make sure we read anything in the fifo.
    
    Fixes: 28c7afb07ccf ("media: ite-cir: check for receive overflow")
    Suggested-by: Bryan Pass <bryan.pass@gmail.com>
    Tested-by: Bryan Pass <bryan.pass@gmail.com>
    Cc: stable@vger.kernel.org>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09cca6f81dd1bd1d2632ad361f55946e7a60eb85
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Fri Oct 8 11:04:22 2021 +0100

    media: rkvdec: Do not override sizeimage for output format
    
    commit 298d8e8f7bcf023aceb60232d59b983255fec0df upstream.
    
    The rkvdec H.264 decoder currently overrides sizeimage for the output
    format. This causes issues when userspace requires and requests a larger
    buffer, but ends up with one of insufficient size.
    
    Instead, only provide a default size if none was requested. This fixes
    the video_decode_accelerator_tests from Chromium failing on the first
    frame due to insufficient buffer space. It also aligns the behavior
    of the rkvdec driver with the Hantro and Cedrus drivers.
    
    Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a50d9fe9227db4903c386fa6b473b409a43fae6
Author: Tang Bin <tangbin@cmss.chinamobile.com>
Date:   Thu Oct 21 09:34:22 2021 +0800

    crypto: s5p-sss - Add error handling in s5p_aes_probe()
    
    commit a472cc0dde3eb057db71c80f102556eeced03805 upstream.
    
    The function s5p_aes_probe() does not perform sufficient error
    checking after executing platform_get_resource(), thus fix it.
    
    Fixes: c2afad6c6105 ("crypto: s5p-sss - Add HASH support for Exynos")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a3ef4d6d33023e2d7f03bed8d2f2edcebf8d94d
Author: jing yangyang <cgel.zte@gmail.com>
Date:   Thu Aug 19 19:30:16 2021 -0700

    firmware/psci: fix application of sizeof to pointer
    
    commit 2ac5fb35cd520ab1851c9a4816c523b65276052f upstream.
    
    sizeof when applied to a pointer typed expression gives the size of
    the pointer.
    
    ./drivers/firmware/psci/psci_checker.c:158:41-47: ERROR application of sizeof to pointer
    
    This issue was detected with the help of Coccinelle.
    
    Fixes: 7401056de5f8 ("drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests")
    Cc: stable@vger.kernel.org
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: jing yangyang <jing.yangyang@zte.com.cn>
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4efa4181ddf1f9e55223590e84aed737d39cf04
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Sep 8 08:33:57 2021 +0300

    tpm: Check for integer overflow in tpm2_map_response_body()
    
    commit a0bcce2b2a169e10eb265c8f0ebdd5ae4c875670 upstream.
    
    The "4 * be32_to_cpu(data->count)" multiplication can potentially
    overflow which would lead to memory corruption.  Add a check for that.
    
    Cc: stable@vger.kernel.org
    Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c41492ee2014663acf7b0e6151f77fbf2480993a
Author: Helge Deller <deller@gmx.de>
Date:   Tue Oct 5 00:27:49 2021 +0200

    parisc: Fix ptrace check on syscall return
    
    commit 8779e05ba8aaffec1829872ef9774a71f44f6580 upstream.
    
    The TIF_XXX flags are stored in the flags field in the thread_info
    struct (TI_FLAGS), not in the flags field of the task_struct structure
    (TASK_FLAGS).
    
    It seems this bug didn't generate any important side-effects, otherwise it
    wouldn't have went unnoticed for 12 years (since v2.6.32).
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Fixes: ecd3d4bc06e48 ("parisc: stop using task->ptrace for {single,block}step flags")
    Cc: Kyle McMartin <kyle@mcmartin.ca>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a5125dcb0452e5ff018fc7eac46223c69ca435f
Author: Helge Deller <deller@gmx.de>
Date:   Sun Oct 31 21:58:12 2021 +0100

    parisc: Fix set_fixmap() on PA1.x CPUs
    
    commit 6e866a462867b60841202e900f10936a0478608c upstream.
    
    Fix a kernel crash which happens on PA1.x CPUs while initializing the
    FTRACE/KPROBE breakpoints.  The PTE table entries for the fixmap area
    were not created correctly.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Fixes: ccfbc68d41c2 ("parisc: add set_fixmap()/clear_fixmap()")
    Cc: stable@vger.kernel.org # v5.2+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7887fea0c0d48ec7f4137f43571468d58f12fa36
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Fri Oct 29 13:11:33 2021 +0100

    io-wq: remove worker to owner tw dependency
    
    commit 1d5f5ea7cb7d15b9fb1cc82673ebb054f02cd7d2 upstream.
    
    INFO: task iou-wrk-6609:6612 blocked for more than 143 seconds.
          Not tainted 5.15.0-rc5-syzkaller #0
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:iou-wrk-6609    state:D stack:27944 pid: 6612 ppid:  6526 flags:0x00004006
    Call Trace:
     context_switch kernel/sched/core.c:4940 [inline]
     __schedule+0xb44/0x5960 kernel/sched/core.c:6287
     schedule+0xd3/0x270 kernel/sched/core.c:6366
     schedule_timeout+0x1db/0x2a0 kernel/time/timer.c:1857
     do_wait_for_common kernel/sched/completion.c:85 [inline]
     __wait_for_common kernel/sched/completion.c:106 [inline]
     wait_for_common kernel/sched/completion.c:117 [inline]
     wait_for_completion+0x176/0x280 kernel/sched/completion.c:138
     io_worker_exit fs/io-wq.c:183 [inline]
     io_wqe_worker+0x66d/0xc40 fs/io-wq.c:597
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
    
    io-wq worker may submit a task_work to the master task and upon
    io_worker_exit() wait for the tw to get executed. The problem appears
    when the master task is waiting in coredump.c:
    
    468                     freezer_do_not_count();
    469                     wait_for_completion(&core_state->startup);
    470                     freezer_count();
    
    Apparently having some dependency on children threads getting everything
    stuck. Workaround it by cancelling the taks_work callback that causes it
    before going into io_worker_exit() waiting.
    
    p.s. probably a better option is to not submit tw elevating the refcount
    in the first place, but let's leave this excercise for the future.
    
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: syzbot+27d62ee6f256b186883e@syzkaller.appspotmail.com
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/142a716f4ed936feae868959059154362bfa8c19.1635509451.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e119d7ef5f92cdb371d25a16c8a0c6cf970765cc
Author: Sungjong Seo <sj1557.seo@samsung.com>
Date:   Tue Oct 19 15:14:21 2021 +0900

    exfat: fix incorrect loading of i_blocks for large files
    
    commit 0c336d6e33f4bedc443404c89f43c91c8bd9ee11 upstream.
    
    When calculating i_blocks, there was a mistake that was masked with a
    32-bit variable. So i_blocks for files larger than 4 GiB had incorrect
    values. Mask with a 64-bit variable instead of 32-bit one.
    
    Fixes: 5f2aa075070c ("exfat: add inode operations")
    Cc: stable@vger.kernel.org # v5.7+
    Reported-by: Ganapathi Kamath <hgkamath@hotmail.com>
    Signed-off-by: Sungjong Seo <sj1557.seo@samsung.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa0b015e87a80f93398c6c7d359f169e5743befa
Author: Christian Löhle <CLoehle@hyperstone.com>
Date:   Thu Sep 16 05:59:19 2021 +0000

    mmc: dw_mmc: Dont wait for DRTO on Write RSP error
    
    commit 43592c8736e84025d7a45e61a46c3fa40536a364 upstream.
    
    Only wait for DRTO on reads, otherwise the driver hangs.
    
    The driver prevents sending CMD12 on response errors like CRCs. According
    to the comment this is because some cards have problems with this during
    the UHS tuning sequence. Unfortunately this workaround currently also
    applies for any command with data. On reads this will set the drto timer,
    which then triggers after a while. On writes this will not set any timer
    and the tasklet will not be scheduled again.
    
    I cannot test for the UHS workarounds need, but even if so, it should at
    most apply to reads. I have observed many hangs when CMD25 response
    contained a CRC error. This patch fixes this without touching the actual
    UHS tuning workaround.
    
    Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
    Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/af8f8b8674ba4fcc9a781019e4aeb72c@hyperstone.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20af47eb7fd34f3e7859ebcd82d37d49994b1f73
Author: Derong Liu <derong.liu@mediatek.com>
Date:   Fri Aug 27 15:15:37 2021 +0800

    mmc: mtk-sd: Add wait dma stop done flow
    
    commit 43e5fee317f4b0a48992b8b07935b1a3ac20ce84 upstream.
    
    We found this issue on a 5G platform, during CMDQ error handling, if DMA
    status is active when it call msdc_reset_hw(), it means mmc host hw reset
    and DMA transfer will be parallel, mmc host may access sram region
    unexpectedly. According to the programming guide of mtk-sd host, it needs
    to wait for dma stop done after set dma stop.
    
    This change should be applied to all SoCs.
    
    Signed-off-by: Derong Liu <derong.liu@mediatek.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210827071537.1034-1-derong.liu@mediatek.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cddf1f7f7b5410931c395df4b9aa6d9892c4646
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Sat Oct 16 13:20:47 2021 +0800

    char: xillybus: fix msg_ep UAF in xillyusb_probe()
    
    commit 15c9a359094ec6251578b02387436bc64f11a477 upstream.
    
    When endpoint_alloc() return failed in xillyusb_setup_base_eps(),
    'xdev->msg_ep' will be freed but not set to NULL. That lets program
    enter fail handling to cleanup_dev() in xillyusb_probe(). Check for
    'xdev->msg_ep' is invalid in cleanup_dev() because 'xdev->msg_ep' did
    not set to NULL when was freed. So the UAF problem for 'xdev->msg_ep'
    is triggered.
    
    ==================================================================
    BUG: KASAN: use-after-free in fifo_mem_release+0x1f4/0x210
    CPU: 0 PID: 166 Comm: kworker/0:2 Not tainted 5.15.0-rc5+ #19
    Call Trace:
     dump_stack_lvl+0xe2/0x152
     print_address_description.constprop.0+0x21/0x140
     ? fifo_mem_release+0x1f4/0x210
     kasan_report.cold+0x7f/0x11b
     ? xillyusb_probe+0x530/0x700
     ? fifo_mem_release+0x1f4/0x210
     fifo_mem_release+0x1f4/0x210
     ? __sanitizer_cov_trace_pc+0x1d/0x50
     endpoint_dealloc+0x35/0x2b0
     cleanup_dev+0x90/0x120
     xillyusb_probe+0x59a/0x700
    ...
    
    Freed by task 166:
     kasan_save_stack+0x1b/0x40
     kasan_set_track+0x1c/0x30
     kasan_set_free_info+0x20/0x30
     __kasan_slab_free+0x109/0x140
     kfree+0x117/0x4c0
     xillyusb_probe+0x606/0x700
    
    Set 'xdev->msg_ep' to NULL after being freed in xillyusb_setup_base_eps()
    to fix the UAF problem.
    
    Fixes: a53d1202aef1 ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)")
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Eli Billauer <eli.billauer@gmail.com>
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Link: https://lore.kernel.org/r/20211016052047.1611983-1-william.xuanziyang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1c687148ed5bdba086536e99c54e40ec390905d
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Wed Nov 3 11:10:57 2021 +1000

    ce/gf100: fix incorrect CE0 address calculation on some GPUs
    
    commit 93f43ed81abec8c805e1b77eb1d20dbc51a24dc4 upstream.
    
    The code which constructs the modules for each engine present on the GPU
    passes -1 for 'instance' on non-instanced engines, which affects how the
    name for a sub-device is generated.  This is then stored as 'instance 0'
    in nvkm_subdev.inst, so code can potentially be shared with earlier GPUs
    that only had a single instance of an engine.
    
    However, GF100's CE constructor uses this value to calculate the address
    of its falcon before it's translated, resulting in CE0 getting the wrong
    address.
    
    This slightly modifies the approach, always passing a valid instance for
    engines that *can* have multiple copies, and having the code for earlier
    GPUs explicitly ask for non-instanced name generation.
    
    Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/91
    
    Fixes: 50551b15c760 ("drm/nouveau/ce: switch to instanced constructor")
    Cc: <stable@vger.kernel.org> # v5.12+
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Reviewed-by: Karol Herbst <kherbst@redhat.com>
    Tested-by: Karol Herbst <kherbst@redhat.com>
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211103011057.15344-1-skeggsb@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c07179037bccdbfb250210e6db56f26b1cc75e2c
Author: Quinn Tran <qutran@marvell.com>
Date:   Wed Sep 8 09:46:21 2021 -0700

    scsi: qla2xxx: Fix use after free in eh_abort path
    
    commit 3d33b303d4f3b74a71bede5639ebba3cfd2a2b4d upstream.
    
    In eh_abort path driver prematurely exits the call to upper layer. Check
    whether command is aborted / completed by firmware before exiting the call.
    
    9 [ffff8b1ebf803c00] page_fault at ffffffffb0389778
      [exception RIP: qla2x00_status_entry+0x48d]
      RIP: ffffffffc04fa62d  RSP: ffff8b1ebf803cb0  RFLAGS: 00010082
      RAX: 00000000ffffffff  RBX: 00000000000e0000  RCX: 0000000000000000
      RDX: 0000000000000000  RSI: 00000000000013d8  RDI: fffff3253db78440
      RBP: ffff8b1ebf803dd0   R8: ffff8b1ebcd9b0c0   R9: 0000000000000000
      R10: ffff8b1e38a30808  R11: 0000000000001000  R12: 00000000000003e9
      R13: 0000000000000000  R14: ffff8b1ebcd9d740  R15: 0000000000000028
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    10 [ffff8b1ebf803cb0] enqueue_entity at ffffffffafce708f
    11 [ffff8b1ebf803d00] enqueue_task_fair at ffffffffafce7b88
    12 [ffff8b1ebf803dd8] qla24xx_process_response_queue at ffffffffc04fc9a6
    [qla2xxx]
    13 [ffff8b1ebf803e78] qla24xx_msix_rsp_q at ffffffffc04ff01b [qla2xxx]
    14 [ffff8b1ebf803eb0] __handle_irq_event_percpu at ffffffffafd50714
    
    Link: https://lore.kernel.org/r/20210908164622.19240-10-njavali@marvell.com
    Fixes: f45bca8c5052 ("scsi: qla2xxx: Fix double scsi_done for abort path")
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Co-developed-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Co-developed-by: Laurence Oberman <loberman@redhat.com>
    Signed-off-by: Laurence Oberman <loberman@redhat.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb722507fb2c7d481d51b5531e1715bdc5481cb5
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Sep 8 09:46:18 2021 -0700

    scsi: qla2xxx: Fix kernel crash when accessing port_speed sysfs file
    
    commit 3ef68d4f0c9e7cb589ae8b70f07d77f528105331 upstream.
    
    Kernel crashes when accessing port_speed sysfs file.  The issue happens on
    a CNA when the local array was accessed beyond bounds. Fix this by changing
    the lookup.
    
    BUG: unable to handle kernel paging request at 0000000000004000
    PGD 0 P4D 0
    Oops: 0000 [#1] SMP PTI
    CPU: 15 PID: 455213 Comm: sosreport Kdump: loaded Not tainted
    4.18.0-305.7.1.el8_4.x86_64 #1
    RIP: 0010:string_nocheck+0x12/0x70
    Code: 00 00 4c 89 e2 be 20 00 00 00 48 89 ef e8 86 9a 00 00 4c 01
    e3 eb 81 90 49 89 f2 48 89 ce 48 89 f8 48 c1 fe 30 66 85 f6 74 4f <44> 0f b6 0a
    45 84 c9 74 46 83 ee 01 41 b8 01 00 00 00 48 8d 7c 37
    RSP: 0018:ffffb5141c1afcf0 EFLAGS: 00010286
    RAX: ffff8bf4009f8000 RBX: ffff8bf4009f9000 RCX: ffff0a00ffffff04
    RDX: 0000000000004000 RSI: ffffffffffffffff RDI: ffff8bf4009f8000
    RBP: 0000000000004000 R08: 0000000000000001 R09: ffffb5141c1afb84
    R10: ffff8bf4009f9000 R11: ffffb5141c1afce6 R12: ffff0a00ffffff04
    R13: ffffffffc08e21aa R14: 0000000000001000 R15: ffffffffc08e21aa
    FS:  00007fc4ebfff700(0000) GS:ffff8c717f7c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000004000 CR3: 000000edfdee6006 CR4: 00000000001706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
      string+0x40/0x50
      vsnprintf+0x33c/0x520
      scnprintf+0x4d/0x90
      qla2x00_port_speed_show+0xb5/0x100 [qla2xxx]
      dev_attr_show+0x1c/0x40
      sysfs_kf_seq_show+0x9b/0x100
      seq_read+0x153/0x410
      vfs_read+0x91/0x140
      ksys_read+0x4f/0xb0
      do_syscall_64+0x5b/0x1a0
      entry_SYSCALL_64_after_hwframe+0x65/0xca
    
    Link: https://lore.kernel.org/r/20210908164622.19240-7-njavali@marvell.com
    Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed")
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eafa65575e6fc02f72a7a66255193afb0a8a4964
Author: Arun Easi <aeasi@marvell.com>
Date:   Wed Sep 8 09:46:16 2021 -0700

    scsi: qla2xxx: Fix crash in NVMe abort path
    
    commit e6e22e6cc2962d3f3d71914b47f7fbc454670e8a upstream.
    
    System crash was seen when I/O was run against an NVMe target and aborts
    were occurring.
    
    Crash stack is:
    
        -- relevant crash stack --
        BUG: kernel NULL pointer dereference, address: 0000000000000010
        :
        #6 [ffffae1f8666bdd0] page_fault at ffffffffa740122e
           [exception RIP: qla_nvme_abort_work+339]
           RIP: ffffffffc0f592e3  RSP: ffffae1f8666be80  RFLAGS: 00010297
           RAX: 0000000000000000  RBX: ffff9b581fc8af80  RCX: ffffffffc0f83bd0
           RDX: 0000000000000001  RSI: ffff9b5839c6c7c8  RDI: 0000000008000000
           RBP: ffff9b6832f85000   R8: ffffffffc0f68160   R9: ffffffffc0f70652
           R10: ffffae1f862ffdc8  R11: 0000000000000300  R12: 000000000000010d
           R13: 0000000000000000  R14: ffff9b5839cea000  R15: 0ffff9b583fab170
           ORIG_RAX: ffffffffffffffff   CS: 0010  SS: 0018
        #7 [ffffae1f8666be98] process_one_work at ffffffffa6aba184
        #8 [ffffae1f8666bed8] worker_thread at ffffffffa6aba39d
        #9 [ffffae1f8666bf10] kthread at ffffffffa6ac06ed
    
    The crash was due to a stale SRB structure access after it was aborted.
    Fix the issue by removing stale access.
    
    Link: https://lore.kernel.org/r/20210908164622.19240-5-njavali@marvell.com
    Fixes: 2cabf10dbbe3 ("scsi: qla2xxx: Fix hang on NVMe command timeouts")
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bb97f2486ce4b36e5cc369c50058129e9c05641
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Sep 10 16:31:53 2021 -0700

    scsi: lpfc: Fix FCP I/O flush functionality for TMF routines
    
    commit cd8a36a90babf958082b87bc6b4df5dd70901eba upstream.
    
    A prior patch inadvertently caused lpfc_sli_sum_iocb() to exclude counting
    of outstanding aborted I/Os and ABORT IOCBs.  Thus,
    lpfc_reset_flush_io_context() called from any TMF routine does not properly
    wait to flush all outstanding FCP IOCBs leading to a block layer crash on
    an invalid scsi_cmnd->request pointer.
    
      kernel BUG at ../block/blk-core.c:1489!
      RIP: 0010:blk_requeue_request+0xaf/0xc0
      ...
      Call Trace:
      <IRQ>
      __scsi_queue_insert+0x90/0xe0 [scsi_mod]
      blk_done_softirq+0x7e/0x90
      __do_softirq+0xd2/0x280
      irq_exit+0xd5/0xe0
      do_IRQ+0x4c/0xd0
      common_interrupt+0x87/0x87
      </IRQ>
    
    Fix by separating out the LPFC_IO_FCP, LPFC_IO_ON_TXCMPLQ,
    LPFC_DRIVER_ABORTED, and CMD_ABORT_XRI_CN || CMD_CLOSE_XRI_CN checks into a
    new lpfc_sli_validate_fcp_iocb_for_abort() routine when determining to
    build an ABORT iocb.
    
    Restore lpfc_reset_flush_io_context() functionality by including counting
    of outstanding aborted IOCBs and ABORT IOCBs in lpfc_sli_sum_iocb().
    
    Link: https://lore.kernel.org/r/20210910233159.115896-9-jsmart2021@gmail.com
    Fixes: e1364711359f ("scsi: lpfc: Fix illegal memory access on Abort IOCBs")
    Cc: <stable@vger.kernel.org> # v5.12+
    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 bea230d0b26c6007c9b14044a5af5dd31457a979
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Sep 10 16:31:47 2021 -0700

    scsi: lpfc: Don't release final kref on Fport node while ABTS outstanding
    
    commit 982fc3965d1350d3332e04046b0e101006184ba9 upstream.
    
    In a rarely executed path, FLOGI failure, there is a refcounting error.  If
    FLOGI completed with an error, typically a timeout, the initial completion
    handler would remove the job reference. However, the job completion isn't
    the actual end of the job/exchange as the timeout usually initiates an
    ABTS, and upon that ABTS completion, a final completion is sent. The driver
    removes the reference again in the final completion. Thus the imbalance.
    
    In the buggy cases, if there was a link bounce while the delayed response
    is outstanding, the fport node may be referenced again but there was no
    additional reference as it is already present. The delayed completion then
    occurs and removes the last reference freeing the node and causing issues
    in the link up processed that is using the node.
    
    Fix this scenario by removing the snippet that removed the reference in the
    initial FLOGI completion. The bad snippet was poorly trying to identify the
    FLOGI as OK to do so by realizing the node was not registered with either
    SCSI or NVMe transport.
    
    Link: https://lore.kernel.org/r/20210910233159.115896-3-jsmart2021@gmail.com
    Fixes: 618e2ee146d4 ("scsi: lpfc: Fix FLOGI failure due to accessing a freed node")
    Cc: <stable@vger.kernel.org> # v5.13+
    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 cd816d01efae58bae6c523fb3fd2b9002e1c2726
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Wed Nov 3 10:06:59 2021 -0700

    scsi: core: Remove command size deduction from scsi_setup_scsi_cmnd()
    
    commit 703535e6ae1e94c89a9c1396b4c7b6b41160ef0c upstream.
    
    No need to deduce command size in scsi_setup_scsi_cmnd() anymore as
    appropriate checks have been added to scsi_fill_sghdr_rq() function and the
    cmd_len should never be zero here.  The code to do that wasn't correct
    anyway, as it used uninitialized cmd->cmnd, which caused a null-ptr-deref
    if the command size was zero as in the trace below. Fix this by removing
    the unneeded code.
    
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 0 PID: 1822 Comm: repro Not tainted 5.15.0 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
    Call Trace:
     blk_mq_dispatch_rq_list+0x7c7/0x12d0
     __blk_mq_sched_dispatch_requests+0x244/0x380
     blk_mq_sched_dispatch_requests+0xf0/0x160
     __blk_mq_run_hw_queue+0xe8/0x160
     __blk_mq_delay_run_hw_queue+0x252/0x5d0
     blk_mq_run_hw_queue+0x1dd/0x3b0
     blk_mq_sched_insert_request+0x1ff/0x3e0
     blk_execute_rq_nowait+0x173/0x1e0
     blk_execute_rq+0x15c/0x540
     sg_io+0x97c/0x1370
     scsi_ioctl+0xe16/0x28e0
     sd_ioctl+0x134/0x170
     blkdev_ioctl+0x362/0x6e0
     block_ioctl+0xb0/0xf0
     vfs_ioctl+0xa7/0xf0
     do_syscall_64+0x3d/0xb0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    ---[ end trace 8b086e334adef6d2 ]---
    Kernel panic - not syncing: Fatal exception
    
    Link: https://lore.kernel.org/r/20211103170659.22151-2-tadeusz.struk@linaro.org
    Fixes: 2ceda20f0a99 ("scsi: core: Move command size detection out of the fast path")
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: James E.J. Bottomley <jejb@linux.ibm.com>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: <linux-scsi@vger.kernel.org>
    Cc: <linux-kernel@vger.kernel.org>
    Cc: <stable@vger.kernel.org> # 5.15, 5.14, 5.10
    Reported-by: syzbot+5516b30f5401d4dcbcae@syzkaller.appspotmail.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 005838becc27cc7195c66d40b2ae2e2be9e52e85
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Fri Oct 29 15:43:10 2021 -0400

    scsi: core: Avoid leaving shost->last_reset with stale value if EH does not run
    
    commit 5ae17501bc62a49b0b193dcce003f16375f16654 upstream.
    
    The changes to issue the abort from the scmd->abort_work instead of the EH
    thread introduced a problem if eh_deadline is used.  If aborting the
    command(s) is successful, and there are never any scmds added to the
    shost->eh_cmd_q, there is no code path which will reset the ->last_reset
    value back to zero.
    
    The effect of this is that after a successful abort with no EH thread
    activity, a subsequent timeout, perhaps a long time later, might
    immediately be considered past a user-set eh_deadline time, and the host
    will be reset with no attempt at recovery.
    
    Fix this by resetting ->last_reset back to zero in scmd_eh_abort_handler()
    if it is determined that the EH thread will not run to do this.
    
    Thanks to Gopinath Marappan for investigating this problem.
    
    Link: https://lore.kernel.org/r/20211029194311.17504-2-emilne@redhat.com
    Fixes: e494f6a72839 ("[SCSI] improved eh timeout handler")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit baf27c15ee8941433d43f980bfad30071c35edd3
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Wed Nov 3 10:06:58 2021 -0700

    scsi: scsi_ioctl: Validate command size
    
    commit 20aaef52eb08f1d987d46ad26edb8f142f74d83a upstream.
    
    Need to make sure the command size is valid before copying the command from
    user space.
    
    Link: https://lore.kernel.org/r/20211103170659.22151-1-tadeusz.struk@linaro.org
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: James E.J. Bottomley <jejb@linux.ibm.com>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: <linux-scsi@vger.kernel.org>
    Cc: <linux-kernel@vger.kernel.org>
    Cc: <stable@vger.kernel.org> # 5.15, 5.14, 5.10
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dd45bf2402782f4cfdfd138c3fb92d5bf31ae1a
Author: Jan Kara <jack@suse.cz>
Date:   Fri Nov 5 13:34:55 2021 -0700

    ocfs2: fix data corruption on truncate
    
    commit 839b63860eb3835da165642923120d305925561d upstream.
    
    Patch series "ocfs2: Truncate data corruption fix".
    
    As further testing has shown, commit 5314454ea3f ("ocfs2: fix data
    corruption after conversion from inline format") didn't fix all the data
    corruption issues the customer started observing after 6dbf7bb55598
    ("fs: Don't invalidate page buffers in block_write_full_page()") This
    time I have tracked them down to two bugs in ocfs2 truncation code.
    
    One bug (truncating page cache before clearing tail cluster and setting
    i_size) could cause data corruption even before 6dbf7bb55598, but before
    that commit it needed a race with page fault, after 6dbf7bb55598 it
    started to be pretty deterministic.
    
    Another bug (zeroing pages beyond old i_size) used to be harmless
    inefficiency before commit 6dbf7bb55598.  But after commit 6dbf7bb55598
    in combination with the first bug it resulted in deterministic data
    corruption.
    
    Although fixing only the first problem is needed to stop data
    corruption, I've fixed both issues to make the code more robust.
    
    This patch (of 2):
    
    ocfs2_truncate_file() did unmap invalidate page cache pages before
    zeroing partial tail cluster and setting i_size.  Thus some pages could
    be left (and likely have left if the cluster zeroing happened) in the
    page cache beyond i_size after truncate finished letting user possibly
    see stale data once the file was extended again.  Also the tail cluster
    zeroing was not guaranteed to finish before truncate finished causing
    possible stale data exposure.  The problem started to be particularly
    easy to hit after commit 6dbf7bb55598 "fs: Don't invalidate page buffers
    in block_write_full_page()" stopped invalidation of pages beyond i_size
    from page writeback path.
    
    Fix these problems by unmapping and invalidating pages in the page cache
    after the i_size is reduced and tail cluster is zeroed out.
    
    Link: https://lkml.kernel.org/r/20211025150008.29002-1-jack@suse.cz
    Link: https://lkml.kernel.org/r/20211025151332.11301-1-jack@suse.cz
    Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d96493bd58569f62fb813c33ebdb57c0e915d55
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Thu Nov 4 17:31:58 2021 +0900

    libata: fix read log timeout value
    
    commit 68dbbe7d5b4fde736d104cbbc9a2fce875562012 upstream.
    
    Some ATA drives are very slow to respond to READ_LOG_EXT and
    READ_LOG_DMA_EXT commands issued from ata_dev_configure() when the
    device is revalidated right after resuming a system or inserting the
    ATA adapter driver (e.g. ahci). The default 5s timeout
    (ATA_EH_CMD_DFL_TIMEOUT) used for these commands is too short, causing
    errors during the device configuration. Ex:
    
    ...
    ata9: SATA max UDMA/133 abar m524288@0x9d200000 port 0x9d200400 irq 209
    ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
    ata9.00: ATA-9: XXX  XXXXXXXXXXXXXXX, XXXXXXXX, max UDMA/133
    ata9.00: qc timeout (cmd 0x2f)
    ata9.00: Read log page 0x00 failed, Emask 0x4
    ata9.00: Read log page 0x00 failed, Emask 0x40
    ata9.00: NCQ Send/Recv Log not supported
    ata9.00: Read log page 0x08 failed, Emask 0x40
    ata9.00: 27344764928 sectors, multi 16: LBA48 NCQ (depth 32), AA
    ata9.00: Read log page 0x00 failed, Emask 0x40
    ata9.00: ATA Identify Device Log not supported
    ata9.00: failed to set xfermode (err_mask=0x40)
    ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
    ata9.00: configured for UDMA/133
    ...
    
    The timeout error causes a soft reset of the drive link, followed in
    most cases by a successful revalidation as that give enough time to the
    drive to become fully ready to quickly process the read log commands.
    However, in some cases, this also fails resulting in the device being
    dropped.
    
    Fix this by using adding the ata_eh_revalidate_timeouts entries for the
    READ_LOG_EXT and READ_LOG_DMA_EXT commands. This defines a timeout
    increased to 15s, retriable one time.
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    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 82e2f47f26a2e6589c3f95956232ac0242d29a6f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 3 08:00:19 2021 +0100

    Input: i8042 - Add quirk for Fujitsu Lifebook T725
    
    commit 16e28abb7290c4ca3b3a0f333ba067f34bb18c86 upstream.
    
    Fujitsu Lifebook T725 laptop requires, like a few other similar
    models, the nomux and notimeout options to probe the touchpad
    properly.  This patch adds the corresponding quirk entries.
    
    BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191980
    Tested-by: Neal Gompa <ngompa13@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20211103070019.13374-1-tiwai@suse.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f43e1c69280313f121283cb5c16e5e0b1036b3a
Author: Phoenix Huang <phoenix@emc.com.tw>
Date:   Sun Nov 7 22:00:03 2021 -0800

    Input: elantench - fix misreporting trackpoint coordinates
    
    commit be896bd3b72b44126c55768f14c22a8729b0992e upstream.
    
    Some firmwares occasionally report bogus data from trackpoint, with X or Y
    displacement being too large (outside of [-127, 127] range). Let's drop such
    packets so that we do not generate jumps.
    
    Signed-off-by: Phoenix Huang <phoenix@emc.com.tw>
    Tested-by: Yufei Du <yufeidu@cs.unc.edu>
    Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6655277462f3aba630181eb4697bd1dccba371c9
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 9 22:58:01 2021 -0800

    Input: iforce - fix control-message timeout
    
    commit 744d0090a5f6dfa4c81b53402ccdf08313100429 upstream.
    
    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.
    
    Fixes: 487358627825 ("Input: iforce - use DMA-safe buffer when getting IDs from USB")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Cc: stable@vger.kernel.org      # 5.3
    Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb86e9884f29a9a365d38a4ff468c59bfb6c983f
Author: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
Date:   Thu Oct 14 15:12:00 2021 +0300

    usb: xhci: Enable runtime-pm by default on AMD Yellow Carp platform
    
    commit 660a92a59b9e831a0407e41ff62875656d30006e upstream.
    
    AMD's Yellow Carp platform supports runtime power management for
    XHCI Controllers, so enable the same by default for all XHCI Controllers.
    
    [ regrouped and aligned the PCI_DEVICE_ID definitions -Mathias]
    
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20211014121200.75433-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a71fa1a1025690adb47946f3f5b8f04319ed665
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Nov 5 18:00:36 2021 +0200

    xhci: Fix USB 3.1 enumeration issues by increasing roothub power-on-good delay
    
    commit e1959faf085b004e6c3afaaaa743381f00e7c015 upstream.
    
    Some USB 3.1 enumeration issues were reported after the hub driver removed
    the minimum 100ms limit for the power-on-good delay.
    
    Since commit 90d28fb53d4a ("usb: core: reduce power-on-good delay time of
    root hub") the hub driver sets the power-on-delay based on the
    bPwrOn2PwrGood value in the hub descriptor.
    
    xhci driver has a 20ms bPwrOn2PwrGood value for both roothubs based
    on xhci spec section 5.4.8, but it's clearly not enough for the
    USB 3.1 devices, causing enumeration issues.
    
    Tests indicate full 100ms delay is needed.
    
    Reported-by: Walt Jr. Brake <mr.yming81@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Fixes: 90d28fb53d4a ("usb: core: reduce power-on-good delay time of root hub")
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211105160036.549516-1-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>